
Project Planning
Turn an approved product spec into a phased, dependency-ordered implementation plan before your agent starts coding.
Overview
Project-planning is an agent skill most often used in Build (also Validate scope, Ship launch) that converts a completed specification into a phased, dependency-ordered implementation plan before execution begins.
Install
npx skills add https://github.com/athola/claude-night-market --skill project-planningWhat is this skill?
- Converts a finished specification into phased, dependency-ordered tasks
- Delegates deep planning to spec-kit:task-planning; stays lightweight for quick breakdowns
- Integrates with superpowers:writing-plans and checkpoint-based execution patterns
- Covers architecture design, interface definitions, and estimation-oriented sprint planning
- Explicit gates: requires spec first; points to project-execution when the plan is ready
- Delegates thorough plans to spec-kit:task-planning
- Estimated metadata: ~900 tokens, intermediate complexity
Adoption & trust: 1 installs on skills.sh; 304 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You have an approved spec but no ordered architecture, task list, or dependency map for your agent or sprint to follow.
Who is it for?
Solo builders finishing the spec phase who need structured task breakdown and architecture before the first implementation commit.
Skip if: Teams still exploring the problem (use brainstorming), without any specification (use project-specification), or already holding an approved plan ready to run (use project-execution).
When should I use this skill?
After specification phase completes and before execution begins; when you need architecture, task breakdown, or sprint planning.
What do I get? / Deliverables
You get a phased implementation plan with interfaces and dependencies defined so you can invoke project-execution or spec-kit:task-planning without replanning from scratch.
- Phased implementation plan
- Dependency-ordered task list
- Component interface definitions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Implementation planning sits at the handoff from scoped requirements to execution—the canonical shelf is Build because the primary artifact is an architecture and task breakdown for shipping software. PM-style planning (sprints, dependencies, interfaces) maps directly to the build/pm subphase rather than early ideation or post-launch ops.
Where it fits
Freeze MVP scope into ordered milestones and explicit out-of-scope items before build starts.
Design component boundaries and dependency order for a multi-service indie SaaS.
Define API and data-layer interfaces as planned tasks rather than improvised endpoints.
Sequence release tasks (migrations, feature flags, smoke checks) in dependency-safe order.
How it compares
Use instead of jumping straight from a spec doc into ad-hoc coding tasks in chat.
Common Questions / FAQ
Who is project-planning for?
Solo and indie builders using Claude Code or similar agents who have a written specification and want a dependency-aware plan before implementation.
When should I use project-planning?
After specification is complete and before execution—e.g. in Validate when locking scope into tasks, in Build/pm when designing architecture and sprint breakdown, or in Ship/launch prep when sequencing release-critical work.
Is project-planning safe to install?
Review the Security Audits panel on this Prism page for install risk and file integrity; the skill is planning-only and does not imply shell or network access by itself.
Workflow Chain
Requires first: project specification
Then invoke: writing plans, project execution
SKILL.md
READMESKILL.md - Project Planning
## Delegation For detailed task planning workflows, this skill delegates to `spec-kit:task-planning` as the canonical implementation. Use this skill for quick planning needs; use spec-kit for thorough project plans. ## When To Use - After specification phase completes - Need to design system architecture - Need task breakdown for implementation - Planning sprints and resource allocation - Converting requirements into concrete tasks - Defining component interfaces and dependencies ## When NOT To Use - No specification exists yet (use `Skill(attune:project-specification)` first) - Still exploring problem space (use `Skill(attune:project-brainstorming)` instead) - Ready to execute existing plan (use `Skill(attune:project-execution)` instead) - Need to adjust running project (update plan incrementally, don't restart) ## Integration **With superpowers**: - Uses `Skill(superpowers:writing-plans)` for structured planning - Applies checkpoint-based execution patterns - Uses dependency analysis framework **Without superpowers**: - Standalone planning methodology - Task breakdown templates - Dependency tracking patterns ## Quality Checks Before completing plan: - ✅ All architecture components documented - ✅ File Structure section present before tasks - ✅ All task files appear in File Structure table - ✅ All FRs mapped to tasks - ✅ All tasks have acceptance criteria - ✅ Dependencies are acyclic - ✅ Effort estimates provided - ✅ Critical path identified - ✅ Risks assessed with mitigations - ✅ Sprints balanced by capacity ## Record the Tradeoff (decision journal) Planning is where architecture and scope decisions get made: the pattern chosen, the dependency accepted, the work deferred. Record each decision that had real alternatives to `docs/tradeoffs.md` (draft and confirm): - If leyline is installed, invoke `Skill(leyline:decision-journal)` and append a tradeoff entry (the decision, the options weighed, and what was sacrificed; set `phase` to `plan`). Show the draft; append on confirmation. - Fallback (leyline absent): append to `docs/tradeoffs.md` using the in-file ENTRY TEMPLATE; assign the next `TR-NNN` id. ## Post-Completion: Workflow Continuation (REQUIRED) **Automatic Trigger**: After Quality Checks pass and `docs/implementation-plan.md` is saved, MUST auto-invoke the next phase. **When continuation is invoked**: 1. Verify `docs/implementation-plan.md` exists and is non-empty 2. Display checkpoint message to user: ``` Implementation plan complete. Saved to docs/implementation-plan.md. Proceeding to execution phase... ``` 3. Invoke next phase: ``` Skill(attune:project-execution) ``` **Bypass Conditions** (ONLY skip continuation if ANY true): - `--standalone` flag was provided by the user - `docs/implementation-plan.md` does not exist or is empty (phase failed) - User explicitly requests to stop after planning **Do NOT prompt the user for confirmation**: this is a lightweight checkpoint, not an interactive gate. The user can always interrupt if needed. ## Exit Criteria - [ ] `docs/implementation-plan.md` exists, is non-empty, and passes Quality Checks (acyclic dependencies, FRs mapped, critical path identified). - [ ] Architecture and scope decisions with alternatives are recorded to `docs/tradeoffs.md`. - [ ] The execution phase is auto-invoked unless a bypass condition holds. ## Related Skills - `Skill(superpowers:writing-plans)` - Planning methodology (if available) - `Skill(spec-kit:task-planning)` - Task breakdown (