Plan and scope projects from inception through production. Decomposes requirements into phased deliverables, generates SOW (scope) and implementation plans (execution), defines acceptance criteria, and structures sprint/phase backlogs. Use when starting new projects, scoping features, writing requirements, planning sprints, or when the orchestrator needs to decompose a complex task into executable subtasks.
From cabnpx claudepluginhub daneyon/cc-architecture-builder --plugin cabThis skill uses the workspace's default tool permissions.
assets/implementation-plan-template.mdassets/sow-template.mdSearches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides agent creation for Claude Code plugins with file templates, frontmatter specs (name, description, model), triggering examples, system prompts, and best practices.
This skill provides the procedural knowledge for the PLAN phase of any project or task — from initial scoping through detailed implementation planning. It bridges the gap between "we have an idea" and "the team knows exactly what to build and how."
Idea/Request
|
v
+--------------------------+
| 1. SCOPE (SOW) | "What are we building and why?"
| Problem -> Solution | Concise, approvable, stakeholder-facing
| -> Feasibility -> KPIs | Template: assets/sow-template.md
+-----------+--------------+
| Approved?
v
+--------------------------+
| 2. PLAN (Implementation) | "How exactly do we build it?"
| Architecture -> Phases | Detailed, actionable, team-facing
| -> Tasks -> Acceptance | Template: assets/implementation-plan-template.md
+-----------+--------------+
|
v
+--------------------------+
| 3. EXECUTE | Handed off to executing-tasks skill
| Sprint -> Build -> | or domain-specific project agents
| Verify -> Commit |
+--------------------------+
| Situation | Template | Audience |
|---|---|---|
| New project proposal / internal pitch | SOW | PM, advisor, client, leadership |
| Approved project ready for development | Implementation Plan | Engineering team, QA, DevOps |
| Quick feature addition | Neither — use executing-tasks skill directly | Self |
| Complex feature with unknowns | SOW (lightweight) -> Implementation Plan (targeted sections) | Team |
The SOW (Statement of Work) is the concise approval document — it defines what we're building, why, for whom, and what success looks like. It does NOT specify technical implementation details.
Key principle: The SOW should be approachable by non-technical stakeholders while containing enough technical signal for engineers to estimate feasibility.
Full template: assets/sow-template.md
Once the SOW is approved, the implementation plan provides the actionable technical blueprint. This is the hybrid PRD+SRD — combining product requirements with system requirements into a single working document.
Every phase transition requires explicit criteria before proceeding:
| Transition | Gate |
|---|---|
| Discovery -> Strategy | Problem validated, feasibility confirmed |
| Strategy -> Architecture | Requirements approved, KPIs defined, risks accepted |
| Architecture -> Implementation | Architecture reviewed, designs approved, specs complete |
| Implementation -> Validation | Feature-complete, code reviewed, CI green |
| Validation -> Deployment | Critical bugs resolved, UAT signed off, performance acceptable |
| Deployment -> Operations | Deployed, monitoring active, rollback tested |
Full template: assets/implementation-plan-template.md
Product Vision (SOW Section 3)
|
+-- Epic 1: [Major capability]
| +-- Feature 1.1: [Specific feature]
| | +-- User Story 1.1.1: "As a [role], I want [action] so that [benefit]"
| | | +-- Acceptance Criteria: Given [context], When [action], Then [result]
| | +-- User Story 1.1.2: ...
| +-- Feature 1.2: ...
+-- Epic 2: ...
| Framework | Best For | Method |
|---|---|---|
| RICE | Feature backlogs | (Reach x Impact x Confidence) / Effort |
| MoSCoW | MVP scoping | Must / Should / Could / Won't |
| Kano | UX prioritization | Basic / Performance / Delight classification |
| Value vs. Effort | Quick sprint planning | 2x2 matrix: high-value + low-effort first |
Every story/task must have acceptance criteria that are:
When the project involves AI/ML components, add these considerations:
When planning full-stack implementations, consider the dependency graph between layers:
| Pattern | When to Use | Approach |
|---|---|---|
| API-first (backend leads ~1 sprint) | Data-heavy apps, complex business logic | Backend builds endpoints -> frontend integrates with real APIs |
| Design-first (frontend leads with mocks) | UX-critical apps, design-driven products | Frontend builds UI with mock data -> backend implements to match |
| Contract-first (parallel) | Clear API contracts, experienced teams | Both develop against shared API spec simultaneously |
Let the project's actual architecture determine which pattern fits — don't default to one approach for all projects.
assets/sow-template.md — Full SOW templateassets/implementation-plan-template.md — Full hybrid PRD+SRD templateknowledge/reference/product-design-cycle.md — Universal 7-phase lifecycle (conceptual framework, not prescriptive)