← BuildCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Build
Snapshot Sep 30, 2026 · 23:16 UTC · version 2.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "implement-spec",
"description": "Implement a specification in code.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 143
}
],
"skill_md_contents": "---\nname: implement-spec\ndescription: \"Implement a specification in code.\"\ndisable-model-invocation: true\n---\n\nYou have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.\n\nThe goal is a PR which implements the entire spec on a single branch.\n\nThe tickets are not a list of steps. They are a **task graph** with blocking relationships between them. This means there is always a **frontier** of tickets which are ready to be grabbed.\n\nCommunication to and from subagents should be sparse. Communicate primarily through **context pointers**: to the spec, tickets, research notes, and previous commits. Don't duplicate information already available via pointers.\n\n**Implementer subagents** should be run in the background where possible for **maximum concurrency**.\n\n## Steps\n\n1. Read the spec and tickets. Read enough to understand the task graph.\n\n2. (optional) Use an **exploration subagent** to conduct any exploration required by the tickets - relevant codebase files or external documentation. Ensure the exploration subagent can save files - it should save its markdown notes in a directory outside the repo, accessible by all future subagents. This lets **implementer subagents** focus on implementation rather than exploration.\n\n3. Create a branch, and a draft PR. The PR should be marked as 'closing' the spec issue and tickets.\n\n4. Use **implementer subagents** to implement each ticket. Each implementer subagent should work in its own worktree, on its own branch.\n\n5. Once an **implementer subagent** completes, merge its work to the PR branch with a **merger subagent**.\n\n6. If this changes the **frontier** of available tickets, kick off more **implementer subagents** to work on the new tickets. This allows for maximum concurrency.\n\n7. Once all tickets are complete, run /code-review on the PR branch. Fix all issues raised by the code review in a single **implementer subagent**.\n\n8. Mark the PR as ready for review.\n\n9. Clean up all **implementer subagent** worktrees.\n"
}SHA-256: eff0436d092626c5e597b6a07aed3e39c32fd11115180621346b958d46a1bc3a