{"slug": "manage-scopes-of-work-a-sow-skill-for-claude-code", "title": "Manage Scopes of Work: a /sow Skill for Claude Code", "summary": "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.", "body_md": "**By Hudson Atwell, GBTI Network Member.** Originally published on\n\nClaude Code loads any markdown file at `.claude/skills/<name>/SKILL.md`\n\nas a reusable slash command (a \"skill\"). This one gives your agent a `/sow`\n\ncommand 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.\n\nIt 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.\n\n`.claude/skills/sow/`\n\nin your repo.`.claude/skills/sow/SKILL.md`\n\n.`/sow init`\n\nonce to scaffold the framework, then `/sow <request>`\n\nto author.\n\n```\n---\nname: sow\ndescription: \">\"\n  Author or improve a Scope of Work (SOW) in .data/sow/. Invoke for \"/sow\", \"/sow init\",\n  \"create a sow\", \"write a sow\", or when the user asks to capture work as a SOW. \"/sow init\"\n  scaffolds the lane framework (idempotent). Otherwise enforce the pre-checks: improve an existing\n  SOW before creating a new one, ground it in a code audit, reference related completed SOWs,\n  default the lane to queue, and follow the project's plan-mode and writing conventions.\n---\n\n# Managing Scopes of Work\n\nSOWs are local planning documents in `.data/sow/` (kept OUT of version control), organized into\nlanes a work item moves through: `0_queue` -> `1_progressing` -> `2_waiting_review` ->\n`3_completed`, plus a `_staging` side-lane for items parked on an external blocker. One canonical\nmarkdown file per SOW; move the same file between lanes as the work advances.\n\n## Initialize (/sow init)\n\nWhen invoked as /sow init (or when the lane folders do not exist yet), scaffold idempotently, then\nstop (this command only builds folders, it never authors a SOW):\n\n``` bash\nmkdir -p .data/sow/{_staging,0_queue,1_progressing,2_waiting_review,3_completed}\n[ -f .data/sow/todo.md ] || printf '# SOW todo\\n' > .data/sow/todo.md\ngrep -qxF '.data/' .gitignore 2>/dev/null || echo '.data/' >> .gitignore\n```\n\nIt creates only what is missing and never overwrites an existing todo.md.\n\n## Authoring a SOW: do these steps IN ORDER\n\n1. **Improve an existing SOW first (never duplicate).** Search the open lanes for a SOW this work\n   belongs in and extend it (a decision, a phase, an open-question resolution). An item in\n   2_waiting_review is code-complete, so additions there are dated review-feedback notes. Only\n   create a new SOW when no open SOW is a reasonable home, and say that you checked.\n2. **Ground it in a code audit (no guessing).** Read the real code so the SOW cites file and line\n   and the true root cause, not assumptions. For a bug, name the root cause; for a feature, name\n   the surfaces and the pattern to reuse. Prefer reusing existing infrastructure.\n3. **Reference related completed SOWs.** Search the completed lane and cite the relevant items:\n   dependencies, the origin of a regression, or the pattern to reuse, each by id and path.\n4. **Number and place it.** Find the next free sow-NNN. Default the lane to 0_queue unless told to\n   start in 1_progressing. Group SOWs into subfolders matching your project's areas.\n5. **Plan mode and conventions.** Every SOW is BUILT in plan mode: add a banner note saying its\n   build begins there, and leave genuine decisions as open questions rather than pinning what is\n   the owner's call. Follow your project's writing conventions throughout.\n6. **Structure.** Frontmatter: id, title, status (matching the lane), priority, phase, created (an\n   absolute date), depends_on, related, owner. Then the title, a status banner (what and why,\n   grounded in the audit), design decisions, phases, constraints and guardrails, open questions,\n   and cross-references.\n7. **Design-first SOWs.** A SOW that redesigns a visual surface is never built from prose: request\n   a mockup, store the assets under `sow-NNN-assets/` with a source note, and reference them.\n\n## Reminders\n\n- The planning docs are local only and never committed.\n- A SOW is a living document: keep its status field and lane in sync as work moves.\n- When a build completes, write an as-built note into the banner before moving lanes, so the doc\n  reads true months later.\n```\n\nThree dials worth adjusting:\n\n`.data/sow/`\n\nis 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.\n\nThe resource shared in this post is a new prompt published by GBTI Network member Hudson Atwell.\n\nAre 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\n\n[https://gbti.network]To follow Hudson Atwell's work more closely, consider joining our network and subscribing to them directly:\n\n[https://gbti.network/members/atwellpub/]", "url": "https://wpnews.pro/news/manage-scopes-of-work-a-sow-skill-for-claude-code", "canonical_source": "https://dev.to/gbti-network/manage-scopes-of-work-a-sow-skill-for-claude-code-33ke", "published_at": "2026-07-28 13:10:49+00:00", "updated_at": "2026-07-28 13:36:37.525595+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "artificial-intelligence"], "entities": ["Hudson Atwell", "GBTI Network", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/manage-scopes-of-work-a-sow-skill-for-claude-code", "markdown": "https://wpnews.pro/news/manage-scopes-of-work-a-sow-skill-for-claude-code.md", "text": "https://wpnews.pro/news/manage-scopes-of-work-a-sow-skill-for-claude-code.txt", "jsonld": "https://wpnews.pro/news/manage-scopes-of-work-a-sow-skill-for-claude-code.jsonld"}}