ss-coding

Multi-Agent Parallel TDD Development

Execute an implementation plan by dispatching multiple subagents in parallel, each following test-driven development, then hand off to the ss-code-review skill for one comprehensive review pass once every task passes its tests.

Core architecture: the orchestrator (you) never writes code. You read the plan, dispatch subagents, track progress, and collect results. All code is written by implementer subagents.

Fresh-context assumption: each implementer subagent starts with no chat history. Give it the authoritative plan path plus exact task number/heading, concise scene-setting context, applicable spec paths, interfaces/dependencies, cwd, scope boundary, and verification commands. The implementer reads only that task and its referenced material from the repository instead of receiving a duplicated full-task payload.

Inputs

This skill expects one of:

• a path to a plan file already broken into tasks (produced by the ss-plan skill);
• a link to an external requirement or design document (wiki page, ticket, PRD);
• a plain-language description of the requirement.

If none of these is supplied, ask the user for one before proceeding.

Iron Rules

Violating any of these means stop and escalate to the user:

1. The orchestrator never writes code. You dispatch, track, and review status. You never directly edit source files. (Non-source edits — updating plan checkboxes, correcting plan text — are fine.)
2. Review is delegated to ss-code-review. Once all tasks complete and tests pass, invoke it in post-coding mode. Do not dispatch your own per-task reviewers.
3. Continuous execution. Don't pause between tasks to ask "should I continue?" Run until every task is done or blocked.
4. Respect parallel boundaries. Subagents in the same parallel group may run concurrently; subagents in different groups must run sequentially.
5. No file conflicts. Parallel subagents must never modify the same file. If the plan has parallel tasks touching the same file, run them sequentially instead.
6. Three strikes and you stop. The same error on the same task, three times, means stop and report to the user. "Same error" means the same failing test case, the same compiler/lint error at the same file:line, or the same exception type from the same stack-trace origin — different messages on different lines count as separate errors.
7. Scope breach is a hard stop. If a subagent modifies files outside its task's file list, reject the work and re-dispatch with an explicit constraint.
8. Specs are binding. Any specs discovered for the repository apply to every implementer prompt.
9. Never implement directly on the trunk branch (main/master). If the current branch is main/master, stop and ask the user to create a feature branch first (the ss-create-branch skill can do this).
10. Deliver full scope — no silent reduction. Execute every task in the plan. Never skip a task, stub out logic, or downgrade an implementation to a "simplified version" to finish faster, and never re-scope the plan into "MVP now, phase two later" on your own initiative. If the full plan can't be completed, stop and report the blocker — never present partial work as complete. Exception: scope the user explicitly cut, deferred, or accepted as blocked. Record that decision under a "User-Confirmed Scope Adjustments" section in the plan file (the persistent record the downstream review reads) and repeat it in the final report.
11. Plan freshness is mandatory. For plan input, validate canonical **BASE_SHA:** against current repository drift before first dispatch. Never execute stale file/symbol/interface instructions blindly.
12. Checkboxes are hints, not completion evidence. On resume, validate each checked task's exact plan/task/base identity, reachable commit, scoped files, and task verification before skipping it. Invalid or stale checks are reopened.