skills/skillful-subagent-creator/SKILL.md
Creates Claude subagents equipped with curated skills for solving problems within DAG workflows. Use when designing a specialist subagent, selecting skills for a subagent, writing the 4-section subagent prompt, or wiring subagents into orchestration DAGs. Activate on "create subagent", "subagent with skills", "specialist agent", "agent DAG", "orchestrate agents", "skill-equipped agent". NOT for creating skills themselves (use skill-architect), general Claude Code usage, or single-agent prompting without skills.
npx skillsauth add curiositech/windags-skills skillful-subagent-creatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Creates Claude subagents that are equipped with curated skills as their standard operating procedures. Each subagent is "a specialist with a toolkit" — a narrow role, a small skill set, and a clear workflow for applying those skills.
✅ Use for:
❌ NOT for:
skill-architect)flowchart TD
A[Define the role] --> B[Select 2-5 skills]
B --> C[Write 4-section prompt]
C --> D[Define input/output contracts]
D --> E[Choose DAG position]
E --> F{Standalone or chained?}
F -->|Standalone| G[Test with sample task]
F -->|Chained| H[Define handoff protocol]
H --> G
G --> I{Works correctly?}
I -->|No| C
I -->|Yes| J[Deploy]
A subagent's role must be narrow enough to be expert, broad enough to be useful.
flowchart TD
A{How narrow?} -->|Too broad| B["Do all marketing" ❌]
A -->|Right| C["Draft landing page copy" ✅]
A -->|Too narrow| D["Fix typos in H1 tags" ❌]
Test: Can you describe what this subagent does in one sentence with a specific verb and noun? If not, narrow it.
Examples of well-scoped roles:
| Role | Domain | Sentence | |------|--------|----------| | Refactorer | TypeScript | "Designs and executes safe refactors in TypeScript monorepos" | | PR Reviewer | Code review | "Reviews pull request diffs for correctness, style, and security" | | Research Synthesizer | Research | "Synthesizes multi-source research into cited briefing documents" | | Migration Planner | Databases | "Plans database schema migrations with rollback strategies" |
Skills are the subagent's standard operating procedures. Too few and it improvises; too many and it drowns in context.
flowchart TD
A{For each candidate skill} --> B{Needed for >50% of tasks?}
B -->|Yes| C[Preload into context]
B -->|No| D{Needed for 10-50%?}
D -->|Yes| E[Add to dynamic catalog]
D -->|No| F[Don't include]
| Tier | Skills | How Loaded | Token Cost | |------|--------|------------|------------| | Preloaded | 2-5 core skills | Full SKILL.md injected into system prompt | ~2-5k tokens per skill | | Catalog | 5-20 available skills | Name + 1-line description in prompt; loaded on demand | ~50 tokens per skill | | None | Everything else | Not mentioned; agent uses generic reasoning | 0 tokens |
Role: PR Reviewer for TypeScript/React
| Tier | Skill | Why |
|------|-------|-----|
| Preloaded | code-review-skill | Core to every task |
| Preloaded | react-server-components | Catches RSC anti-patterns |
| Catalog | typescript-strict-mode | Sometimes relevant |
| Catalog | testing-patterns | Only for test file reviews |
| None | database-migration | Not in scope |
Every subagent prompt has exactly four sections. This structure ensures the subagent knows its role, its tools, its workflow, and its constraints.
You are the **[Role Name]** subagent for this system.
You handle [narrow domain of tasks].
When a task is outside this scope, explicitly say so and
ask the orchestrator for a different agent.
Keep it to 2-4 sentences. Name the specific domain. State the boundary explicitly.
You have access to the following skills, which define your methods:
- `skill-a`: [1-line purpose]
- `skill-b`: [1-line purpose]
- `skill-c`: [1-line purpose]
These are your standard operating procedures, not optional hints.
When tackling a task:
1. Decide which skill(s) apply
2. Follow their step-by-step workflow
3. Use their output formats and checklists
4. Reference skill steps by number as you work
For each task you receive:
1. Restate the task in your own words
2. Select one or more skills that fit. If none fit well, say so.
3. If needed, ask 2-5 clarifying questions
4. Produce a short internal plan
5. Execute the skill workflow step by step
6. Run any validation/QA steps from the skill
7. Return:
(a) Final artifacts
(b) Which skills you used (and which steps)
(c) Assumptions and remaining risks
Quality bar: [e.g., "Never knowingly leave tests failing"]
Safety: [e.g., "No destructive operations without confirmation"]
Tie-breaking: [e.g., "If speed vs robustness conflict, pick robustness"]
Output format: [e.g., "Always return valid JSON matching the output contract"]
Every subagent must have explicit contracts so orchestrators and downstream agents can work with it.
{
"task": "string — description of what to do",
"files": ["string — paths to relevant files"],
"context": "string — prior agent output or user requirements",
"constraints": {
"time_budget": "string — e.g., '5 minutes'",
"quality_bar": "string — e.g., 'production-ready'"
}
}
{
"status": "pass | warn | fail",
"artifacts": ["string — files created or modified"],
"summary": "string — 1-3 sentence description of what was done",
"skills_used": ["string — skill names and step numbers"],
"risks": ["string — remaining risks or assumptions"],
"metadata": {
"duration_ms": "number",
"tokens_used": "number"
}
}
flowchart TD
subgraph "Single Specialist"
O1[Orchestrator] --> S1[Specialist]
S1 --> O1
end
subgraph "Chain"
O2[Orchestrator] --> C1[Designer]
C1 --> C2[Implementer]
C2 --> C3[Tester]
C3 --> O2
end
subgraph "Fan-out / Fan-in"
O3[Orchestrator] --> P1[Auth Agent]
O3 --> P2[Billing Agent]
O3 --> P3[UI Agent]
P1 --> M[Merger]
P2 --> M
P3 --> M
M --> O3
end
| Pattern | When to Use | Skill Requirement | |---------|-------------|-------------------| | Single Specialist | Task maps to one domain | Agent has 2-5 preloaded skills | | Chain | Sequential transformation pipeline | Each agent has different skills; output of A feeds input of B | | Fan-out / Fan-in | Independent parallel work | Agents work concurrently; merger resolves conflicts | | Loop | Iterative refinement | Same agent re-runs with feedback until quality bar met | | Human-in-the-Loop | Approval required | Agent produces draft; human reviews; agent revises |
Each node in a DAG is a subagent with:
node:
id: review-pr
agent: pr-reviewer
skills: [code-review-skill, react-server-components]
input_from: [parse-diff]
output_to: [merge-decision]
retry: 2
timeout: 300s
on_failure: escalate-to-human
name: pr-reviewer
role: "Reviews TypeScript/React pull requests for correctness, style, and security"
skills:
preloaded:
- code-review-skill
- react-server-components
catalog:
- typescript-strict-mode
- testing-patterns
tools: [Read, Grep, Glob]
input_from: [diff-parser]
output_to: [merge-decision]
You are the **PR Reviewer** subagent. You review TypeScript and React
pull request diffs for correctness, readability, performance, and security.
You do NOT implement features, fix bugs, or write new code. If asked to do
so, say "This is outside my scope — route to the Implementer agent."
Your skills define your standard process:
- `code-review-skill`: Structured review methodology (correctness → style → perf → security)
- `react-server-components`: Catches RSC anti-patterns ('use client' overuse, async component errors)
For each PR you receive:
1. Restate what the PR changes and why
2. Select applicable skills (always code-review-skill; add react-server-components if React files changed)
3. Follow the skill's review steps in order
4. Produce findings in the output contract format
5. Summarize: approve, request changes, or block
Quality bar: Never approve a PR with failing tests or security vulnerabilities.
Tie-breaking: If unsure whether something is a bug or style preference, flag it as "suggestion" not "required."
Output: Always return JSON matching the output contract schema.
Wrong: Creating a subagent with just a role description and no skills. Why: It will improvise a new process every time instead of following a consistent methodology. Fix: Attach 2-5 skills as standard operating procedures.
Wrong: Attaching 15 skills to one subagent. Why: Blows context window; agent spends tokens selecting skills instead of executing. Fix: Max 5 preloaded, rest in catalog. Let the orchestrator pre-filter.
Wrong: Subagent returns free-form text that downstream agents can't parse. Why: DAG breaks because the next node can't consume the output. Fix: Define explicit JSON output contract. Validate in tests.
Wrong: Subagent tries to handle everything instead of refusing out-of-scope tasks. Why: Identity section doesn't state boundaries clearly enough. Fix: Add "You do NOT handle X, Y, Z. If asked, say so and suggest the right agent."
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.