simple-harness

Orchestrate full feature implementation: loop through a feature's issues.json, invoking simple-implement for each task until all are done or a blocker is hit. Use when the user wants to auto-complete a feature, run through all tasks, or execute the task queue without manual intervention. Triggers: "run all tasks", "auto-implement", "complete the feature", "implement everything", "execute the task list".

Audit a recent implementation diff for unnecessary complexity and propose behavior-preserving simplifications without changing code. Use after simple-implement or simple-run when the user asks to simplify, reduce complexity, remove overengineering, or review generated code for a smaller and clearer solution.

Compact oversized feature artifacts — issues.json and progress-log.md — to keep them useful for future agents. Use when issues.json has 15+ done tasks, progress-log.md exceeds 300 lines, or simple-implement/simple-run reports a size threshold was hit. Triggers: "clean up the issues", "compact the progress log", "archive done tasks", "the files are getting too long".

Write a technical design document (docs/<feature-name>/design.md) describing how to build a feature — architecture, data flow, interfaces, key decisions, testing strategy — from a spec, user message, or codebase context. Use when the user wants to design a feature, plan an implementation approach, document architecture decisions, or turn a spec.md into its design. Triggers: "write a design doc", "design this feature", "plan the implementation", "how should we build this", "technical approach", "architecture for".

Implement one task from a feature's issues.json work queue: reads the feature's planning docs in docs/<feature-name>/, picks the highest-priority unblocked task (or a task ID the user names), implements and verifies it, then updates issues.json and progress-log.md. Use when the user wants to implement a task, work on the next issue, continue building a feature, or make progress on a task list. Triggers: "implement the next task", "work on the next issue", "continue implementation", "pick up where we left off", "do the next task".

Write a product/feature specification (docs/<feature-name>/spec.md) defining what to build and why — scope, user stories, acceptance criteria, edge cases — from a user message, input file, or codebase context. Use when the user wants to spec a feature, define requirements, write acceptance criteria, or scope work before implementation. Triggers: "write a spec", "create requirements", "define the feature", "scope this out", "what should we build", "spec this".

Promote durable, high-level knowledge from a completed feature's docs into app-level documentation (docs/architecture.md, docs/capabilities.md, docs/adr/, docs/CHANGELOG.md), then archive the feature folder. Distills first, retires second. Use when a feature is finished and you want to capture its lasting decisions and behavior before its planning docs go stale. Triggers: "distill this feature", "promote the docs", "update the architecture doc", "write an ADR for this", "archive this feature", "capture what we learned".

Break a feature's spec and design into an ordered, dependency-aware task list (docs/<feature-name>/issues.json) — each task small enough for one implementation session. Use when the user wants to break down a feature, generate issues, create a work queue, or plan implementation steps. Triggers: "break this down", "create tasks", "generate issues", "task list", "work breakdown", "plan the work".

Write an app-level visual design system document (docs/visual.md) — colors, typography, spacing, components, visual guidelines — from documentation, a user message, or codebase context. One per project, not per feature. Use when the user wants to create, extract, or formalize a consistent visual identity for their app. Triggers: "create a design system", "define the visual style", "style guide", "UI design tokens", "design language", "look and feel".