Manage Scopes of Work: a /sow Skill for Claude Code

Hudson Atwell, a GBTI Network Member, created a /sow skill for Claude Code that manages Scopes of Work as local, lane-based planning documents. The skill scaffolds a kanban-style board with lanes from queue to completed, keeps work items outside version control, and enforces authoring rules to prevent duplication and ground plans in code audits.

By Hudson Atwell, GBTI Network Member. Originally published on Claude Code loads any markdown file at .claude/skills/<name /SKILL.md as a reusable slash command a "skill" . This one gives your agent a /sow command for managing Scopes of Work: local, lane-based planning documents that move kanban-style from queue to completed, living beside your code but outside version control. It exists because agent-driven projects accumulate work items faster than anyone can track them in their head. A SOW gives every work item one canonical markdown file with a status banner, phases, and open questions; the lanes give the whole project a glanceable board; and the authoring rules keep the agent from duplicating items or writing plans detached from the real code. .claude/skills/sow/ in your repo. .claude/skills/sow/SKILL.md . /sow init once to scaffold the framework, then /sow <request to author. --- name: sow description: " " Author or improve a Scope of Work SOW in .data/sow/. Invoke for "/sow", "/sow init", "create a sow", "write a sow", or when the user asks to capture work as a SOW. "/sow init" scaffolds the lane framework idempotent . Otherwise enforce the pre-checks: improve an existing SOW before creating a new one, ground it in a code audit, reference related completed SOWs, default the lane to queue, and follow the project's plan-mode and writing conventions. --- Managing Scopes of Work SOWs are local planning documents in .data/sow/ kept OUT of version control , organized into lanes a work item moves through: 0 queue - 1 progressing - 2 waiting review - 3 completed , plus a staging side-lane for items parked on an external blocker. One canonical markdown file per SOW; move the same file between lanes as the work advances. Initialize /sow init When invoked as /sow init or when the lane folders do not exist yet , scaffold idempotently, then stop this command only builds folders, it never authors a SOW : bash mkdir -p .data/sow/{ staging,0 queue,1 progressing,2 waiting review,3 completed} -f .data/sow/todo.md || printf ' SOW todo\n' .data/sow/todo.md grep -qxF '.data/' .gitignore 2 /dev/null || echo '.data/' .gitignore It creates only what is missing and never overwrites an existing todo.md. Authoring a SOW: do these steps IN ORDER 1. Improve an existing SOW first never duplicate . Search the open lanes for a SOW this work belongs in and extend it a decision, a phase, an open-question resolution . An item in 2 waiting review is code-complete, so additions there are dated review-feedback notes. Only create a new SOW when no open SOW is a reasonable home, and say that you checked. 2. Ground it in a code audit no guessing . Read the real code so the SOW cites file and line and the true root cause, not assumptions. For a bug, name the root cause; for a feature, name the surfaces and the pattern to reuse. Prefer reusing existing infrastructure. 3. Reference related completed SOWs. Search the completed lane and cite the relevant items: dependencies, the origin of a regression, or the pattern to reuse, each by id and path. 4. Number and place it. Find the next free sow-NNN. Default the lane to 0 queue unless told to start in 1 progressing. Group SOWs into subfolders matching your project's areas. 5. Plan mode and conventions. Every SOW is BUILT in plan mode: add a banner note saying its build begins there, and leave genuine decisions as open questions rather than pinning what is the owner's call. Follow your project's writing conventions throughout. 6. Structure. Frontmatter: id, title, status matching the lane , priority, phase, created an absolute date , depends on, related, owner. Then the title, a status banner what and why, grounded in the audit , design decisions, phases, constraints and guardrails, open questions, and cross-references. 7. Design-first SOWs. A SOW that redesigns a visual surface is never built from prose: request a mockup, store the assets under sow-NNN-assets/ with a source note, and reference them. Reminders - The planning docs are local only and never committed. - A SOW is a living document: keep its status field and lane in sync as work moves. - When a build completes, write an as-built note into the banner before moving lanes, so the doc reads true months later. Three dials worth adjusting: .data/sow/ is a convention, not a requirement; any gitignored folder works. Keep it out of version control either way; plans churn too fast for useful history and the lanes ARE the state.Each authoring rule closes a failure mode agents repeat: creating a duplicate SOW instead of extending the open one rule 1 ; writing plans from memory that cite code that does not exist rule 2 ; losing the thread between related work items rule 3 ; and building straight from a prose wish without surfacing the decisions that belong to a human rule 5 . The lane system does the rest: at any moment, the queue is the backlog, progressing is the work in flight, waiting-review is what needs a human eye, and completed is the record. The resource shared in this post is a new prompt published by GBTI Network member Hudson Atwell. Are you a writer, musician, or product developer? We would love to support your work on the GBTI Network. For more information about how to join our community visit https://gbti.network To follow Hudson Atwell's work more closely, consider joining our network and subscribing to them directly: https://gbti.network/members/atwellpub/