cli-tools/ai-tools/skills/wbs/SKILL.md

name, description

name	description
wbs	Break down architecture.md into a prioritized feature backlog, skipping already-built features.

Plan

Produce or update docs/feature_backlog.md.

Process

1. Read docs/architecture.md. This is the source of truth for what needs to be built.
2. Scan docs/features/ for existing feature spec files (pattern: [0-9][0-9][0-9]-*.md). These are already built — do not include them in the backlog.
3. Find the highest NNN number across both docs/features/ files and any existing docs/feature_backlog.md entries. New items start from one higher.
4. Produce docs/feature_backlog.md with this structure:

# Feature Backlog

Completed features are tracked in `docs/features/` and removed from this list.

---

## NNN — slug-style-title

One sentence describing what gets built.

## NNN — next-item

One sentence. Optionally:
depends: NNN

What goes on the backlog

Cover everything in the architecture that is not yet implemented. Group logically — infrastructure first, then features, then integrations.

Do not add items for:

• Work already represented by a file in docs/features/
• Documentation, comments, or cleanup unless explicitly in the architecture
• Vague future ideas not grounded in the architecture

Chunk sizing

Each backlog item will be handed to a coding agent that writes a spec, implements the code, and commits — all in one automated pass with no human in the loop. Size items accordingly:

• Self-contained: scope should contain a single functionality that can be implemented and tested.
• Scoped: touches at most 2 modules and adds roughly 50–200 lines of production code
• Testable: success is checkable by running the test suite — no manual inspection required

If an architectural feature is large, split it into ordered items (e.g. data model, then API layer, then UI). If a feature is trivial (a single function or config value), merge it with a related item.

If an item depends on another, note it on a second line as depends: NNN.

Rules

• Ask only if a trade-off materially changes scope or ordering and cannot be resolved from the architecture.
• Preserve items already in docs/feature_backlog.md that are not yet in docs/features/ — only add, reorder, or remove items, do not rewrite existing descriptions without good reason.
• Each item is a ## NNN — slug-style-title subheading followed by one sentence (and optionally a depends: line).
• Keep descriptions to one sentence — just enough for the coding agent to understand the scope.
• Do not mark any item as done. Completed work is tracked in docs/features/, not here.