Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/ne11nn/cantos-pluginnpx agentmods add skills/ne11nn/cantos-plugin/design-sub-agentWrote 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/ne11nn/cantos-plugin/design-sub-agent)<a href="https://agentmods.dev/skills/ne11nn/cantos-plugin/design-sub-agent"><img src="https://agentmods.dev/badge/skills/ne11nn/cantos-plugin/design-sub-agent.svg" alt="Measured on agentmods" height="20"></a>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.00034 | $0.02337 |
| Opus 5 | $0.00017 | $0.01169 |
| Sonnet 5 | $0.00007 | $0.00467 |
| Haiku 4.5 | $0.00003 | $0.00234 |
Grade A, and why
design-sub-agent 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 6d 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 — 241 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Designing Sub-agents
A reasoning skill — no file writes. Think before you build.
Work through every question and checklist item before drafting anything. If any answer is "I'm not sure," resolve it first.
When to Build a Sub-agent at All
Build a sub-agent when:
- The task produces verbose output you don't need in the main context (test runs, log processing, research)
- You want to enforce specific tool restrictions or permission modes
- The work is completely self-contained and can return a summary
- The same task type recurs across sessions and benefits from a persistent configuration
Don't build one when:
- The task fits in the current context window without quality loss
- The task needs frequent back-and-forth or iterative refinement with the user
- Multiple phases share significant context — sub-agents start fresh each time
- A skill would work — skills run in the main conversation context and are simpler
Check registry/index.md first. If something covers 80%+ of this task, extend that instead.
Critical constraint: Sub-agents cannot spawn other sub-agents. If a workflow requires nested delegation, chain sub-agents from the main conversation or use skills.
Frontmatter Fields — Complete Reference
Sub-agent files use YAML frontmatter for configuration. The markdown body after the frontmatter becomes the system prompt. Only name and description are required.
---
name: my-agent # Required. Lowercase, hyphens only.
description: ... # Required. When Claude should delegate here.
tools: Read, Glob, Bash # Optional. Allowlist — only these tools. Omit to inherit all.
disallowedTools: Write # Optional. Denylist — removes from inherited set.
model: haiku # Optional. haiku | sonnet | opus | inherit (default)
permissionMode: auto # Optional. default | acceptEdits | auto | dontAsk | bypassPermissions | plan
maxTurns: 20 # Optional. Cap on agentic turns before stopping.
memory: project # Optional. user | project | local — enables persistent memory.
skills: # Optional. Preload skill content into context at startup.
- skill-name
background: true # Optional. Always run as background task.
mcpServers: # Optional. MCP servers scoped to this sub-agent only.
- server-name
isolation: worktree # Optional. Give sub-agent isolated git worktree copy.
---
System prompt body goes here.
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.
- 6d ago First seen · 241 lines · 34 tokens per session scan A 22ae676057cb
design-sub-agent is a skill published in the GitHub repository ne11nn/cantos-plugin (1 stars, last pushed yesterday), licensed MIT. It adds 34 tokens to every session and 2,337 once invoked, about $0.0002 per session on Opus 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-31.
Other skills, from other repositories
stream-chain
Stream-JSON chaining for multi-agent pipelines, data transformation, and sequential workflows.
run
Run the agents-concerto multi-agent development pipeline for a task — classify by complexity, implement in isolated worktrees (TDD + Tidy First), review under a two-party boundary, and stop at open PRs for human merge. Invoke explicitly with a task description; a weak or empty description is shaped interactively first…
shape
Turn a rough idea into a well-formed task the pipeline can run — interrogate the ambiguity, derive testable acceptance criteria, flag contradictions, and write .agent-workspace/feature-request.md in the exact shape /run consumes. The upstream step before /agents-concerto:run. Invoke explicitly with a rough idea.
setup
Bootstrap agents-concerto in the current project by interviewing the user for every configurable option — target repos (with per-repo PR host), tasksource, base branch, commit convention, and fix-cycle cap — then writing a filled .agent-workspace/config.md. Detects sensible defaults and asks for confirmation rather…
foundry-hosted-agent-validation
Step-by-step process for validating a Python Foundry hosted agent sample (under python/samples/04-hosting/foundry-hosted-agents/) end to end — running it locally (native runtime and azd ai agent run) and after deploying it to an Azure AI Foundry project with azd. Use this when asked to validate a hosted agent sample.
python-feature-lifecycle
Guidance for package and feature lifecycle in the Agent Framework Python codebase, including stage meanings, feature-stage decorators, feature enums, and how to move APIs from one stage to the next.