New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Wf Spec Breakdown

by changkun in changkun/wallfacer

Split one spec into children — sub-design specs when questions are still open, or implementation-ready leaves when the plan is clear.

MITAuto-check passedAgent Workflows

Install Wf Spec Breakdown

skills CLI
$ npx skills add changkun/wallfacer --skill wf-spec-breakdown -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install changkun/wallfacer wf-spec-breakdown --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/changkun/wallfacer.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/wf-spec-breakdown .claude/skills/wf-spec-breakdown && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
wf-spec-breakdown
GitHub stars
112
Token cost
~2.6k tokens
SKILL.md length
932 words
Files
1
Skills in repo
14
Repo updated
First seen
Licence
MIT

At a glance

Split one spec into children — sub-design specs when questions are still open, or implementation-ready leaves when the plan is clear.

  • Works in 9 steps: Parse arguments and determine mode → Read the spec and context → Explore the codebase → …
  • A spec is too large to build in one pass
  • SKILL.md covers Step 0: Parse arguments and…, Step 1: Read the spec and…, Step 2: Explore the codebase and Step 3: Design the breakdown, plus 5 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Wf Spec Breakdown is an agent skill from changkun/wallfacer. Split one spec into children — sub-design specs when questions are still open, or implementation-ready leaves when the plan is clear. Picks the mode from the spec's lifecycle state unless told otherwise. Writes new spec files and indexes them on the parent. Use when a spec is too large to build in one pass.

Its SKILL.md is about 2.6k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Agent Workflows. The repository describes itself as: Chat, specs, tasks, and code. An autonomous engineering platform. Full autonomy when you trust it. Full control when you don't. The licence is MIT.

When your agent uses it

  • A spec is too large to build in one pass

Example prompts

  • “/wf-spec-breakdown”

Requirements

  • Pre-approved tools (allowed-tools): Read, Grep, Glob, Edit, Write, Agent, Bash(ls *), Bash(mkdir *)

Workflow steps

9 steps, taken from the step headings in SKILL.md.

  1. Parse arguments and determine mode
  2. Read the spec and context
  3. Explore the codebase
  4. Design the breakdown
  5. Create the child spec folder and files
  6. Verify the breakdown
  7. Index the breakdown on the parent spec
  8. Commit
  9. Summary

What it can do on your machine

Read from SKILL.md and the folder at commit 5b3cea1. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Grep
    • Glob
    • Edit
    • Write
    • Agent
    • Bash(ls *)
    • Bash(mkdir *)

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Wf Spec Breakdown loads about 2.6k tokens when it runs. Until then it costs about 82 tokens; SKILL.md has 932 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~82
When it runs · the whole SKILL.md, loaded when a task matches
~2.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from changkun/wallfacer at commit 5b3cea1, republished under its MIT licence (© changkun). 932 words, ~2,635 tokens.

Download SKILL.mdSave it as .claude/skills/wf-spec-breakdown/SKILL.md (or your agent's skills folder).
name
wf-spec-breakdown
description
Split one spec into children — sub-design specs when questions are still open, or implementation-ready leaves when the plan is clear. Picks the mode from the spec's lifecycle state unless told otherwise. Writes new spec files and indexes them on the parent. Use when a spec is too large to build in one pass.
allowed-tools
Read, Grep, Glob, Edit, Write, Agent, Bash(ls *), Bash(mkdir *)
argument-hint
<spec-file.md> [design|tasks]

Break Down Spec

Decompose a spec into smaller child specs. The output is either design specs (sub-design problems that need further iteration) or implementation tasks (leaf specs ready to dispatch to the board).

Step 0: Parse arguments and determine mode

$ARGUMENTS has the form: <spec-file.md> [design|tasks]

  • The first token is the spec file path.
  • The optional second token is an explicit mode override: design or tasks.

If no mode is given, determine it from the spec's lifecycle state:

  • vague or drafted with unresolved open questions → design mode. The spec's design problems need further exploration before implementation.
  • validated with a clear implementation plan → tasks mode. The design is settled; decompose into implementable leaf specs.
  • stale → warn the user and suggest /wf-spec-refine first.
  • complete → warn the user; completed specs don't normally need breakdown.

If the heuristic is ambiguous (e.g., drafted but the spec has a detailed implementation plan), ask the user which mode to use.

Step 1: Read the spec and context

  1. Read the spec file in full.
  2. Parse YAML frontmatter — extract title, status, depends_on, affects, effort, created, updated, author, dispatched_task_id.
  3. Check dependencies — for each path in depends_on, read that spec's frontmatter and confirm its status is complete. Report any incomplete blockers. (In design mode, incomplete dependencies are a warning; in tasks mode, they are a stronger signal that the breakdown may be premature.)
  4. Read specs/README.md to understand track organization and dependency graph.
  5. Use the affects list to identify the primary code files and packages.
  6. Identify the spec's structure: design problems, implementation plan, phases, existing breakdown.

Step 2: Explore the codebase

For each major area the spec touches, explore the codebase to understand:

  • What files will be created or modified
  • What existing patterns, types, and interfaces are relevant
  • What test patterns exist in those packages
  • Whether any items are already partially implemented

Use Agent subagents (Explore type) for thorough codebase exploration. Launch up to 3 in parallel for independent areas.

Step 3: Design the breakdown

Design mode

Identify the distinct design problems embedded in the spec. Each child should:

  • Focus on one design problem — a single architectural decision, interface design, data model, protocol, UX flow, or integration concern
  • Be explorable independently — the user can iterate on this sub-design without needing to resolve other sub-designs first (though dependencies are allowed)
  • Contain open questions that need resolution before implementation

Guidelines for identifying design boundaries:

  • Separate concerns that touch different subsystems or packages
  • Separate decisions that have independent trade-offs
  • Separate user-facing design (UX, API surface) from internal design (data model, algorithms)
  • Separate integration concerns (how components connect) from component design

Order by: (1) dependency flow, (2) risk — uncertain or high-impact decisions earlier, (3) incremental understanding — earlier designs build foundations for later ones.

Tasks mode

Break the spec into discrete, implementable tasks. Each child should:

  • Be completable in a single commit
  • Leave the project in a working state (tests pass)
  • Have clear boundaries (what to change, what NOT to change)
  • Include specific test requirements

Sizing guidelines:

  • Small (~50-100 lines changed): add a type, method, or field
  • Medium (~100-300 lines): refactor a function, add a new file with tests
  • Large (~300+ lines): multi-file refactor, complex feature

Prefer smaller tasks. If a task feels large, split it further.

Order so dependencies flow forward (no task depends on a later task). Maximize parallelism — tasks without mutual dependencies should be independent.

Show full SKILL.md (375 more words)Show less

Step 4: Create the child spec folder and files

Per the spec document model, child specs live in a subdirectory named after the parent. For example, breaking down specs/local/desktop-app.md creates children in specs/local/desktop-app/.

  1. Create the subdirectory if it doesn't exist.
  2. Create one markdown file per child, using descriptive names (no numeric prefixes — execution order comes from depends_on, not filenames).
Design mode child template
markdown
---
title: <Descriptive title of the design problem>
status: drafted
depends_on:
  - <relative path to sibling spec if ordering matters, or empty list>
affects:
  - <code paths / packages this design will govern>
effort: <small | medium | large | xlarge>
created: <today>
updated: <today>
author: <from parent spec>
dispatched_task_id: null
---

# <Title>

## Design Problem

<Clear statement of the single design problem this spec addresses. What
decision needs to be made? What are the constraints? Why can't this be
resolved trivially?>

## Context

<Relevant codebase context, existing patterns, related specs, prior art.
What does the reader need to know to reason about this problem?>

## Options

<At least two concrete approaches, each with pro/con analysis. Include
enough detail that the user can make an informed decision or direct the
agent to explore further.>

## Open Questions

<Specific questions that need resolution before this design can move to
`validated` and be broken into implementation tasks. Each question should
be answerable — avoid vague "what should we do?" in favor of "should X
use approach A or B, given constraint C?">

## Affects

<Which parts of the codebase this design governs, and how the design
decision will ripple into implementation.>

Key properties: status is drafted (needs iteration), body has Options and Open Questions, dispatched_task_id is always null (non-leaf).

Tasks mode child template
markdown
---
title: <Descriptive title>
status: validated
depends_on:
  - <relative path to sibling spec, or empty list>
affects:
  - <files/directories this task will create or modify>
effort: <small | medium | large | xlarge>
created: <today>
updated: <today>
author: <from parent spec>
dispatched_task_id: null
---

# <Title>

## Goal

<1-2 sentences explaining what this task achieves and why>

## What to do

<Numbered list of specific implementation steps with file paths,
function names, and code patterns. Include pseudocode for non-obvious
changes.>

## Tests

<Bulleted list of specific test cases to write, with test function
names and what they verify>

## Boundaries

<Bulleted list of what NOT to change in this task — helps scope the
work and prevents task creep>

Key properties: status is validated (ready to dispatch), body has Goal, What to do, Tests, Boundaries.

Important for both modes: Use depends_on with full relative paths from the repo root (e.g., specs/local/desktop-app/sandbox-interface.md) to express ordering. Do not use task numbers.

Step 5: Verify the breakdown

Check that:

  • Every item from the spec's plan is covered by at least one child
  • No circular dependencies exist in the depends_on DAG
  • The dependency graph allows parallel execution where possible
  • All depends_on paths resolve to existing spec files
  • Each child's affects paths are plausible

Additional checks for tasks mode:

  • Each child's "What to do" references real file paths and function names
  • Leaf specs are small enough for one agent task (2-5 files, one clear goal)

Step 6: Index the breakdown on the parent spec

Append or update a breakdown section on the parent spec.

Design mode: ## Design Breakdown
markdown
## Design Breakdown

| # | Sub-design | Design problem | Depends on | Effort | Status |
|---|-----------|---------------|-----------|--------|--------|
| 1 | [Sandbox interface](desktop-app/sandbox-interface.md) | How to abstract container backends | — | medium | drafted |
| 2 | [Window lifecycle](desktop-app/window-lifecycle.md) | Native window create/destroy | — | large | drafted |
| 3 | [IPC protocol](desktop-app/ipc-protocol.md) | Communication between shell and webview | sandbox-interface | medium | drafted |

```mermaid
graph LR
  A[Sandbox interface] --> C[IPC protocol]
  B[Window lifecycle] --> D[Build pipeline]
  C --> D
```

**Recommended iteration order:** Start with #1 and #2 in parallel — they
are independent. Then #3 once the sandbox interface is settled.

The # column provides a recommended reading/iteration order (suggestion, not constraint). The depends_on DAG is the actual constraint.

Tasks mode: ## Task Breakdown
markdown
## Task Breakdown

| Child spec | Depends on | Effort | Status |
|------------|-----------|--------|--------|
| [Define interface](sandbox-backends/define-interface.md) | — | small | validated |
| [Local backend](sandbox-backends/local-backend.md) | define-interface | medium | validated |
| [Refactor launch](sandbox-backends/refactor-launch.md) | local-backend | small | validated |

```mermaid
graph LR
  A[Define interface] --> B[Local backend]
  B --> C[Refactor launch]
```

Use relative links from the parent spec to the child spec files. If the parent already has a breakdown section, replace its contents.

Step 7: Commit

Stage the new folder, child spec files, and the updated parent spec. Commit:

  • Design mode: specs: break down <spec-name> into sub-design specs
  • Tasks mode: specs: break down <spec-name> into implementable tasks

Do NOT push unless the user explicitly asks.

Step 8: Summary

Report to the user:

  • Mode used (design or tasks) and why
  • Total number of child specs created
  • The dependency graph and parallelism opportunities
  • Any spec items intentionally excluded and why
  • Suggested next steps:
    • Design mode: "Iterate on sub-designs, then /wf-spec-breakdown <child> tasks when each is validated"
    • Tasks mode: "Run /wf-spec-review-breakdown <spec> to validate, then dispatch"

© changkun, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/wf-spec-breakdown of changkun/wallfacer.

Open the folder on GitHubat commit 5b3cea1

Compare with similar skills

Wf Spec Breakdown next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Wf Spec Breakdown compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Wf Spec Breakdown this skillchangkun/wallfacer112—~2.6kAutomated safety check: PassMIT
MCP Server Builderanthropics/skills180k63 repos~2.3kAutomated safety check: PassApache-2.0
Hook Development for Claude Code Pluginsanthropics/claude-plugins-official38k10 repos~4.1kAutomated safety check: NotesApache-2.0
Using Superpowersfarm-fe/farm5.6k35 repos~1.4kAutomated safety check: PassMIT
Executing Plans Inlineobra/superpowers297k2 repos~5.1kAutomated safety check: PassMIT
Skill CreatorAzure/azqr79589 repos~8.2kAutomated safety check: PassApache-2.0

Similar skills

  • MCP Server Builder

    anthropics/skills

    Official

    Guides the design and implementation of Model Context Protocol servers in TypeScript or Python, from tool naming and error messages to evaluation.

    180k GitHub starsUsed in 63 repos~2.3k tokens
    Agent WorkflowsAuto-check passed

  • Hook Development for Claude Code Plugins

    anthropics/claude-plugins-official

    Official

    Explains how to write Claude Code plugin hooks, both prompt-based checks and bash commands, for events such as PreToolUse, Stop and SessionStart.

    38k GitHub starsUsed in 10 repos~4.1k tokens
    Agent WorkflowsAuto-check: notes

  • Using Superpowers

    farm-fe/farm

    A skill your agent uses when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions

    5.6k GitHub starsUsed in 35 repos~1.4k tokens
    Agent WorkflowsAuto-check passed

  • Executing Plans Inline

    obra/superpowers

    Has the agent carry out an implementation plan itself, task by task in the current session, keeping a ledger, proving each step with a test and ending with one whole-branch review.

    297k GitHub starsUsed in 2 repos~5.1k tokens
    Agent WorkflowsAuto-check passed

  • Skill Creator

    Azure/azqr

    Official

    Create new skills, modify and improve existing skills, and measure skill performance.

    795 GitHub starsUsed in 89 repos~8.2k tokens
    Agent WorkflowsAuto-check passed

  • Claude Code Agent Development

    anthropics/claude-plugins-official

    Official

    Explains how to write agents for Claude Code plugins: the markdown file with YAML frontmatter, trigger descriptions, model and color settings, and system prompt design.

    38k GitHub starsUsed in 7 repos~2.8k tokens
    Agent WorkflowsAuto-check passed

More from changkun/wallfacer

All 14 skills in this repo

  • Wf Spec Create

    changkun/wallfacer

    Write a new spec from scratch when none exists for the idea yet.

    112 GitHub stars~2.3k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Dispatch

    changkun/wallfacer

    Mark a validated spec ready to build and resolve its dependency wiring; where a task board with a transition API is present, create the linked task atomically.

    112 GitHub stars~1.6k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Drive

    changkun/wallfacer

    Run the whole lifecycle for one spec, calling the other skills in order and advancing one legal transition at a time until it reaches a target state (default complete), stopping to ask at…

    112 GitHub stars~2.3k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Report

    changkun/wallfacer

    Survey the whole spec tree: what is complete, in progress, blocked, and actionable next.

    112 GitHub stars~1.6k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Review Impl

    changkun/wallfacer

    Read-only verdict on whether an implementation meets its spec: each acceptance criterion classified, unintended changes flagged, test coverage checked.

    112 GitHub stars~1.1k tokensUpdated 5 days ago
    Auto-check passed

  • Wf Spec Validate

    changkun/wallfacer

    Structural lint over the spec tree — required frontmatter fields, valid status and effort values, track location, DAG acyclicity, dispatch consistency, orphans, status consistency.

    112 GitHub stars~2.2k tokensUpdated 5 days ago
    Auto-check passed

Categories

Questions about Wf Spec Breakdown

What does Wf Spec Breakdown do?

Split one spec into children — sub-design specs when questions are still open, or implementation-ready leaves when the plan is clear. Wf Spec Breakdown is an agent skill from changkun/wallfacer. Split one spec into children — sub-design specs when questions are still open, or implementation-ready leaves when the plan is clear.

When should I use Wf Spec Breakdown?

Wf Spec Breakdown fits situations like: A spec is too large to build in one pass.

How do I install Wf Spec Breakdown in Claude Code?

Run `npx skills add changkun/wallfacer --skill wf-spec-breakdown -a claude-code`. Or copy the skill folder (.claude/skills/wf-spec-breakdown in changkun/wallfacer) into .claude/skills/wf-spec-breakdown in your project. Claude Code loads it when a task matches its description.

How do I install Wf Spec Breakdown in Codex?

Run `npx skills add changkun/wallfacer --skill wf-spec-breakdown -a codex`. Or copy the skill folder (.claude/skills/wf-spec-breakdown in changkun/wallfacer) into .agents/skills/wf-spec-breakdown in your project. Codex loads it when a task matches its description.

Can I use Wf Spec Breakdown in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add changkun/wallfacer --skill wf-spec-breakdown -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/wf-spec-breakdown, .gemini/skills/wf-spec-breakdown, .github/skills/wf-spec-breakdown and .opencode/skills/wf-spec-breakdown in your project.

What does Wf Spec Breakdown need to run?

SKILL.md names no scripts, command-line tools or credentials: Wf Spec Breakdown is instructions for the agent only. Its frontmatter pre-approves these tools: Read, Grep, Glob, Edit, Write, Agent, Bash(ls *), Bash(mkdir *).

Does Wf Spec Breakdown access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Wf Spec Breakdown safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Wf Spec Breakdown use?

Wf Spec Breakdown is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Wf Spec Breakdown use?

About 2.6k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Wf Spec Breakdown?

Skills that share tags, products or a category with Wf Spec Breakdown: MCP Server Builder (anthropics/skills, 180k stars), Hook Development for Claude Code Plugins (anthropics/claude-plugins-official, 38k stars), Using Superpowers (farm-fe/farm, 5.6k stars) and Executing Plans Inline (obra/superpowers, 297k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Wf Spec Breakdown?

changkun (a GitHub user) maintains it in changkun/wallfacer, which has 112 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 4, 2026.

Source: changkun/wallfacer on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.