Tech Tool Super Admin Creator

Ask these as a tight grouped question, not one at a time.

PHASE 1: DEEP RESEARCH (The Foundation)

This is the most critical phase. A skill built on shallow understanding produces shallow output. You need to build genuine expertise before writing a single line of the skill.

1A: Official Documentation Crawl

Use WebSearch and WebFetch to systematically research:

Search queries to execute (adapt [TOOL] to actual tool name):
1. "[TOOL] official documentation API reference"
2. "[TOOL] best practices guide 2025 2026"
3. "[TOOL] rate limits pricing tiers constraints"
4. "[TOOL] common mistakes pitfalls troubleshooting"
5. "[TOOL] integration webhooks API"
6. "[TOOL] power user advanced features"
7. "[TOOL] vs [competitor] comparison" (find 2-3 top competitors)

Extract and organize:

• API/MCP capabilities: Every operation the tool supports, grouped by category
• Pricing & credit economics: Tiers, credit costs, what's free vs paid, cost optimization levers
• Rate limits & hard constraints: Requests/second, row limits, field limits, payload sizes
• Authentication: API keys, OAuth, webhook signatures, token refresh
• Webhook events: What events the tool can push, payload shapes
• Known bugs/limitations: What the docs don't say but forums complain about

1B: Community & Expert Knowledge

Search for practitioner knowledge (not just vendor docs):

Search queries:
1. "[TOOL] tips tricks reddit"
2. "[TOOL] power user workflow examples"
3. "[TOOL] agency setup best practices"
4. "[TOOL] ColdIQ OR FullFunnel OR SalesCaptain" (check if reference agencies use it)
5. "[TOOL] n8n integration" OR "[TOOL] automation workflow"
6. "[TOOL] MENA OR Arabic OR Middle East" (regional coverage/support)
7. "site:youtube.com [TOOL] masterclass OR tutorial advanced"

Look specifically for:

• Agency-grade workflows: How do agencies (not solo users) operate this tool at scale?
• Cost optimization tricks: BYO API keys, batch operations, caching strategies
• Failure modes: What breaks at scale? What breaks with international data?
• Integration gotchas: Webhook reliability, data format mismatches, dedup challenges

1C: MCP Tool Inventory (If Connected)

If the tool is connected as an MCP, systematically catalog every available tool:

1. List all MCP tools with prefix matching the tool name
2. Group by operation type (CRUD, search, messaging, analytics, admin)
3. Identify which operations are missing (common need but no MCP tool = manual workaround needed)
4. Note parameter requirements and optional fields for each tool
5. Test 2-3 key operations to verify they work and understand response shapes

1D: User's Existing Knowledge

Check these locations for existing SOPs, workflows, or preferences:

• Current workspace folder for any files related to this tool
• Ask user directly: "Do you have any existing SOPs, workflow docs, or playbooks for [TOOL]? Any specific workflows you've already built that I should incorporate?"
• Check if any n8n workflows reference this tool (via n8n-architect skill)
• Check if any GHL integrations reference this tool

1E: Competitive Context

Research 2-3 direct competitors to understand:

• What the tool does better than alternatives (positioning for when user asks "should I use X or Y?")
• What the tool does worse (honest assessment, not vendor marketing)
• Migration paths if needed
• Feature parity gaps relevant to MENA/GTM use cases

PHASE 2: ARCHITECTURE THE SKILL

Before writing, design the skill structure. Every operator skill follows this blueprint (read references/skill-blueprint.md for the complete template):

Required Sections (Non-Negotiable)

1. Identity & Mental Model - What the tool IS in the stack context (not what the vendor says it is)
2. Stack Position Map - ASCII diagram showing where it connects to GHL, Instantly, HeyReach, Clay, n8n
3. Pre-Flight Questions - What to ask before any operation (region, volume, budget, destination)
4. Pricing & Economics - Tier table, credit costs, cost-per-lead math, optimization levers
5. Platform Constraints - Hard limits table (rate limits, row limits, field limits, payload sizes)
6. MCP/API Tools Reference - Complete operation table grouped by category
7. Mode-Based Operations - Request type identification → mode routing (Mode A, B, C, etc.)
8. Core Workflow Patterns - 3-5 battle-tested patterns with ASCII flow diagrams
9. MENA-Specific Adaptations - Arabic handling, coverage gaps, timing, compliance
10. Integration Patterns - How data flows to/from each connected tool
11. Troubleshooting - Common errors table with symptoms, causes, fixes
12. Agency Economics - Service + markup model, per-unit pricing by region
13. Cross-Skill Integration - Handoff points to other operator skills with tag taxonomy
14. Self-Learning Protocol - How to capture and apply operational learnings
15. Reference Files Index - Table of reference docs with "when to read" guidance

Conditional Sections (Include When Relevant)

• Compliance Requirements - If tool handles PII, messaging, or data storage
• Implementation Timeline - Day-by-day onboarding for new tool setup
• Prompt Packs - If tool has AI/LLM features (like Clay's AI Formulas or Claygent)
• Migration Guide - If replacing another tool
• Scaling Playbook - Performance considerations at 10x, 100x volume

PHASE 3: WRITE THE SKILL

3A: Write SKILL.md

Follow the blueprint from Phase 2. Key writing principles:

Voice: You're writing instructions for Claude acting as a super admin. Write in imperative form. Be specific, not generic. Include the "why" alongside every "how."

Description field (HARD LIMIT: 1024 characters max): Aim for 600-900 characters. Be aggressive on triggers but concise: 8-10 trigger phrases, 3-5 natural language requests, 2-3 "Do NOT trigger for" boundaries. Never list example tool names. Never pad with redundant phrasing. Always verify character count before finalizing: python3 -c "print(len('''[description]'''))"

Depth over breadth: Better to have 3 deeply documented workflow patterns than 10 shallow ones. Each pattern should include: trigger condition, data flow, error handling, success criteria.

Numbers matter: Include specific rate limits, credit costs, response times, batch sizes. Vague guidance like "be careful with rate limits" is useless; "max 100 req/10sec, batch in groups of 20 with 2s delays" is actionable.

MENA section is mandatory: Even if the tool has zero Arabic support, document that gap and the workaround. Coverage percentages for MENA, timing adjustments for Gulf business hours, Ramadan handling if messaging is involved.

3B: Write Reference Files

Create these reference files in references/:

For tools with AI features, also create: | prompt-pack.md | Pre-built prompts/formulas for the tool's AI capabilities |

3C: Write Scripts (If Applicable)

If the tool has an API that benefits from validation or automation:

• scripts/validate-config.py - Pre-deployment validation
• scripts/health-check.py - Verify tool connectivity and permissions
• scripts/cost-calculator.py - Estimate costs for a given operation volume

PHASE 4: INTEGRATION MAPPING

This is what separates a useful skill from a great one. Map every touchpoint with the existing stack:

Integration Matrix Template

[NEW TOOL] → GHL:
  - What data flows: [fields]
  - How: [native integration / HTTP API / n8n webhook]
  - Dedup strategy: [email match / custom ID / composite key]
  - Tags to apply: [Source_[Tool], enrichment_status, etc.]

[NEW TOOL] → Instantly:
  - What triggers: [signal type]
  - Data shape: [fields needed]
  - Rate limits: [batch size, delays]

[NEW TOOL] → HeyReach:
  - LinkedIn URL requirement: [yes/no]
  - Campaign enrollment: [method]

[NEW TOOL] → n8n:
  - Webhook events available: [list]
  - Webhook payload shape: [key fields]
  - Recommended workflow patterns: [list]

[NEW TOOL] → Clay:
  - Enrichment integration: [native / API / Claygent]
  - Data provider in waterfall: [yes/no, position]

Tag Taxonomy Extension

Every new tool should extend the shared tag taxonomy:

Source_[ToolName]           - Lead originated from this tool
[ToolName]_status:[value]   - Tool-specific status tracking
[ToolName]_campaign:[id]    - Campaign membership in this tool

PHASE 5: QUALITY VALIDATION

Before presenting the skill to the user, validate:

Completeness Checklist

• All 15 required sections present in SKILL.md
• Description field is UNDER 1024 characters (verify with python3 char count)
• Description has 8-10 trigger phrases AND "Do NOT trigger for" boundaries
• Stack position map shows connections to at least GHL, n8n
• Pricing table has real numbers (not "varies")
• Rate limits are specific (not "be careful")
• At least 3 workflow patterns with ASCII flow diagrams
• MENA section has specific coverage percentages or gaps documented
• Troubleshooting has minimum 8 common errors
• All reference files created and indexed
• Cross-skill handoff points documented with tag taxonomy
• Self-learning protocol section included

Reality Check

• Tested 2-3 MCP tools (if connected) to verify they work as documented
• Pricing data sourced from official docs (not guessed)
• Rate limits verified from API documentation
• Integration patterns are technically feasible (not theoretical)
• MENA adaptations based on real coverage data (not assumptions)

Conflict Check

• No trigger overlap with existing operator skills
• Tag taxonomy doesn't conflict with existing prefixes
• n8n workflow patterns don't duplicate existing templates
• GHL custom field names don't conflict with existing schema

PHASE 6: PRESENT & ITERATE

1. Present the skill to the user with:

   • Executive summary: what the skill does, where the tool fits in the stack
   • Key decisions you made and why (architecture choices)
   • Gaps you identified that need user input
   • Suggested next steps (test operations, build first workflow)

2. Offer to test the skill with 2-3 realistic scenarios

3. After user feedback, iterate on the skill

4. Offer to package as a .skill file for installation

OUTPUT STRUCTURE

The final skill should be saved as:

smorch-[tool-name]-operator/
├── SKILL.md                          (Main skill, <500 lines)
├── references/
│   ├── api-reference.md              (Complete tool catalog)
│   ├── integration-patterns.md       (Stack connection patterns)
│   ├── troubleshooting.md            (Error diagnosis guide)
│   ├── workflow-templates.md         (Ready-to-deploy patterns)
│   ├── cost-optimization.md          (Credit/cost strategies)
│   ├── mena-adaptations.md           (Regional specifics)
│   └── learnings-log.md              (Operational discoveries)
├── scripts/                          (Optional automation)
│   ├── validate-config.py
│   └── health-check.py
└── assets/                           (Templates, schemas)
    └── signal-schema.json            (If tool produces signals)

NAMING CONVENTION

Skill name: smorch-[tool-name]-operator Examples:

• smorch-hubspot-operator
• smorch-apollo-operator
• smorch-airtable-operator
• smorch-notion-operator
• smorch-lemlist-operator

EXISTING OPERATOR SKILLS (Don't Duplicate)

These tools already have operator skills. If the user asks to create one for these, offer to UPGRADE the existing skill instead:

SPEED VS DEPTH TRADEOFF

If user needs a quick-start skill (just connected a new MCP, wants basic coverage):

• Skip Phase 1B (community research) and 1E (competitive context)
• Write SKILL.md with modes and constraints only
• Create only api-reference.md and integration-patterns.md
• Mark as "v0.1 - Quick Start" and offer to deepen later

If user wants a full battle-tested skill:

• Execute all phases
• Multiple research rounds
• Test with real operations
• Full reference file set
• Offer eval loop via skill-creator

SELF-LEARNING: PATTERN CAPTURE

Every time you build a new operator skill, capture:

1. Research sources that were most valuable (update this skill's references)
2. Tool-specific patterns that might apply to future tools
3. Integration patterns that generalize across tools
4. MENA gaps that repeat across tools (add to a master MENA coverage doc)

Update references/learnings-log.md after each skill creation.