Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add PyModel/claude-architect --skill subagent-driven-delegationgit clone --depth 1 https://github.com/PyModel/claude-architectWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/pymodel/claude-architect/subagent-driven-delegation)<a href="https://agentmods.dev/skills/pymodel/claude-architect/subagent-driven-delegation"><img src="https://agentmods.dev/badge/skills/pymodel/claude-architect/subagent-driven-delegation/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/pymodel/claude-architect/subagent-driven-delegation"><img src="https://agentmods.dev/badge/skills/pymodel/claude-architect/subagent-driven-delegation.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Anti-Refusal · line 111 Skill instructs the agent to omit warnings, disclaimers, or ethical commentary. Stripping safety caveats hides risk from the user and is a common jailbreak preamble.Fix: Remove instructions that suppress warnings, disclaimers, or ethical commentary. Let the agent surface safety-relevant caveats to the user.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00066 | $0.03172 |
| Opus 5.5 | $0.00026 | $0.01269 |
| Sonnet 5.5 | $0.00013 | $0.00634 |
| Haiku 4.5 | $0.00007 | $0.00317 |
Grade A, and why
subagent-driven-delegation scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 23d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 138 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Subagent-Driven Delegation
PROTOCOL_VERSION: 3.0.0
Superpowers subagent-driven-development (SDD) dispatches a fresh implementer subagent per task, reviews each task, and reviews the whole branch at the end. This skill runs that same loop with one substitution: the implementer is a Claude Architect delegation, not a generic subagent. Each task becomes a versioned Delegation Spec executed by an untrusted Producer in an isolated worktree, frozen as a Candidate Artifact, and independently verified by the runtime before any reviewer sees it.
Always present this skill as /architect:subagent-driven-delegation.
Use /architect:delegate for a single delegation. Use this skill when a plan has multiple tasks and you want the SDD ledger, per-task review, and final whole-branch review on top of verified delegation.
What the substitution buys
Upstream SDD's task reviewer reads a diff and the implementer's report; it trusts that the implementer ran the tests it claims. Here that trust is removed:
| SDD stage | Generic subagent | Verified delegation |
|---|---|---|
| Implement | Subagent edits the branch | Producer edits an isolated worktree it cannot escape |
| Test evidence | Implementer's report | Runtime re-runs verification on frozen bytes |
| Task review | Reviews a diff | Reviews the exact anchored candidate, never the implementer's context |
| Complete | Controller marks done | The configured runtime authority records acceptance, then integration is hash-matched |
The Producer's self-report is never evidence. It is a correlation aid and a summary; every reviewable fact comes from runtime evidence.
Where this diverges from upstream SDD
Follow upstream SDD except on these four points, where a trust invariant governs. Do not "restore" the upstream behavior.
- No implementer resume. Upstream says fix rounds 1–3 resume the original implementer with its context intact. Claude Architect forbids it: every attempt starts with fresh context in a fresh worktree. Every fix round is therefore a new attempt carrying the findings in a revised spec. The report file, not conversational memory, is the continuity.
- The controller never marks a task complete directly. Upstream lets the controller close a task after a clean review. Here a task closes only after
decideCandidaterecordsacceptedunder the configured authority andintegrateCandidatereportsapplied. - Implementer self-review is not a review. Upstream's implementer self-reviews before handing off. A Producer may summarize, but the gate is runtime verification plus
reviewCandidate. Never let a self-report shorten the review. - The controller never fixes findings. Upstream already says this to protect controller context; here it is also a trust rule. The architect authors specs and reviews bytes. It does not edit Producer output into shape.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 23d ago Changed a1a4114aee93
- 1mo ago Changed · -4 lines 5639b145482b
- 2mo ago First seen · 142 lines · 66 tokens per session scan A 1d0f36670ba7
subagent-driven-delegation is a skill published in the GitHub repository PyModel/claude-architect (32 stars, last pushed 3d ago), licensed MIT. It adds 66 tokens to every session and 3,172 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
delegation-core
Delegates execution to eight CLIs (Gemini, Qwen, MiniMax, GLM, Muse, Codex, OpenCode, Glimmer). Use for execution tasks. Do not use for secrets.
opencode-delegation
Delegates tasks to OpenCode (opencode run) via delegation-core. Use when delegation-core selects OpenCode or a provider-agnostic harness is wanted.
AI Agent Review Readiness
Checks whether AI-assisted work defines review criteria, accessible context, explicit review loop, human judgment boundary, and feedback capture before delegating to an agent.
evolution-guide
Explains how Evolving Lite works when the user asks about the system, its features, or how to use it. Triggers on questions like "how does this work", "what is evolving lite", "what hooks are running", "explain the system".
architecture-summary
Create or refresh backlog/docs/architecture.yml, the curated source of the project summary page (architecture diagram, flows, highlights, tech stack, commands). Use when the user asks for a project summary, an architecture overview or diagram, or after structural changes to the codebase.
spec-to-backlog
Convert an approved design/implementation plan (from brainstorming/writing-plans) into reviewed Backlog.md tasks with acceptance criteria, milestones and dependencies. Use after a design is approved, when the user asks to decompose work into tasks, or before starting planned work in this project.