design-skill

name	design-skill
description	Design and create a new skill for the system, applying the three-level operating model and fork/agent conventions on top of current skill-authoring standards (description-as-trigger, progressive disclosure). Use when the user says 'design a skill', 'create a skill', 'new skill for', or 'add a slash command'.
argument-hint	[skill purpose and requirements]
context	fork
agent	system-architect

Design Skill: $ARGUMENTS

Existing skill patterns

!head -8 .claude/skills/*/SKILL.md 2>/dev/null || echo "(Could not read existing skills)"

Available agents

!ls -1 .claude/agents/ 2>/dev/null || echo "(Could not list agents)"

Skill standards (current)

These are the standards a new skill must meet — and the yardstick the system's own skills are held to. Build on the skill-creator and plugin-dev:skill-development skills for general mechanics; this skill adds the vault-specific layer.

• Description is the trigger. The description frontmatter is the primary invocation mechanism — it must carry BOTH what the skill does AND when to use it (concrete trigger phrases/contexts). All "when to use" lives here, not in the body. Specific enough to fire reliably without colliding with sibling skills.
• Lean body + progressive disclosure. Keep SKILL.md focused (well under ~500 lines). Offload stable, heavy content (schemas, rubrics, worked examples, per-variant detail) into a references/ subdirectory (the upstream standard — the kepano skills like obsidian-bases use it), each file pointed to with an explicit "read X when Y." Prefer references/ for new skills. (The concept-forge / integrate-concept-forge / integrate-concept-cluster cluster uses this references/ layout and is a good content exemplar.)
• Don't restate the rules layer. Conventions already in CLAUDE.md and .claude/rules/*.md (frontmatter schema, proactive linking, obsidian-cli safety, MCP routing) are already loaded — reference the rule, don't re-paste it. Re-stating creates drift.
• Explain why, not just what. Prefer reasoning over rigid dictates; the model applies intent.
• Vault conventions: name = lowercase-with-hyphens matching the directory; context: fork + agent: only when the task benefits from isolation or persistent memory; disable-model-invocation: true only for procedural, argumentless skills.

Your task

Design and create a new skill based on: $ARGUMENTS

Follow this workflow:

1. Capture intent — From the requirements above, determine:

   • What does this skill do?
   • What trigger words should match? (for the description field)
   • Does it need arguments? (argument-hint or not)
   • Which operating level? (Architect, Orchestrate, or Partner)

2. Ground in the standards — Apply the Skill standards above. If you read existing skills for shape, prefer recent standards-compliant ones (the concept-forge cluster for progressive disclosure; open-workbench / evaluate-tool for right-sized non-forked skills) — the older corpus may carry legacy patterns, so don't copy uncritically. Decide:

   • Forked (context: fork) or non-forked?
   • If forked, which existing agent fits? Or does a new agent need designing first (/design-agent)?
   • What dynamic context (! commands) would help?

3. Design — Plan the SKILL.md per the standards:

   • Name (lowercase-with-hyphens, matches directory name)
   • description carrying what + concrete when-triggers (the invocation surface)
   • Frontmatter (description, argument-hint, context, agent as needed)
   • Dynamic context injection commands
   • Lean workflow steps; push heavy/stable detail to references/ with explicit pointers
   • Reference rules rather than restating them
   • Output format (what to return to the main conversation)

4. Create — Write the SKILL.md file to .claude/skills/{name}/SKILL.md

5. Verify — Check:

   • description carries what + concrete when-triggers; no collision with a sibling skill
   • SKILL.md is lean; heavy/stable content lives in references/ with clear pointers
   • No re-statement of rules-layer content
   • YAML frontmatter valid; referenced agent exists in .claude/agents/; directory name matches name
   • Workflow is clear and complete

6. Commit — Commit the new skill files to git

Output

Return:

• Skill created — Name and path
• Design decisions — Why this pattern (forked/non-forked, agent choice, etc.)
• Integration notes — How it connects to existing system components
• Test suggestion — How the user could test the new skill