Create Implementation Plan
Generate a deterministic, machine-readable implementation plan with phased atomic tasks before your agent or you execute a feature, refactor, or upgrade.
Overview
Create-implementation-plan is an agent skill most often used in Build (also Validate) that produces machine-readable implementation plans with phased, deterministic tasks for autonomous execution.
Install
npx skills add https://github.com/ilteoood/harness --skill create-implementation-planWhat is this skill?
- AI-to-AI directive: output must be machine-readable and deterministic
- Discrete atomic phases with measurable completion criteria
- Tasks require explicit file paths, function names, and implementation details
- Parallel task execution within phases unless dependencies are declared
- Covers new features, refactors, package upgrades, design, architecture, and infrastructure
Adoption & trust: 1 installs on skills.sh; 2 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
You know the goal but lack a structured plan with file-level tasks your coding agent can run without back-and-forth.
Who is it for?
Indie builders delegating multi-step coding work to agents who need Confluence-free, repo-grounded planning artifacts.
Skip if: One-line bugfixes, pure brainstorming with no approved direction, or teams that only need informal todos without file paths.
When should I use this skill?
Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.
What do I get? / Deliverables
You get a new implementation plan document with atomic phases, explicit paths, and completion criteria ready for execution or review.
- Implementation plan file with phased atomic tasks
- Measurable per-phase completion criteria
- Parallelizable task graph with declared dependencies
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Build PM is the canonical shelf for turning intent into ordered, file-specific work agents can run without ambiguity. PM subphase captures planning artifacts—phases, tasks, completion criteria—not frontend or backend implementation itself.
Where it fits
Turn a validated feature idea into a scoped plan with phases before you greenlight the build.
Produce file-specific tasks for a backend API addition your agent will implement next.
Plan a package upgrade with explicit migration steps and completion checks per phase.
Document an infra or release migration as phased tasks with dependencies for a safe ship window.
How it compares
Structured implementation-plan files for agent execution—not open-ended brainstorming or a single-shot code generator.
Common Questions / FAQ
Who is create-implementation-plan for?
Solo and indie developers using Claude Code, Cursor, or Codex who want phased plans before autonomous implementation runs.
When should I use create-implementation-plan?
Use it in Validate when scoping a prototype or refactor contract; in Build PM before features or infra changes; and in Ship when planning a structured migration or upgrade with clear phase gates.
Is create-implementation-plan safe to install?
Review the Security Audits panel on this Prism page; the skill writes planning docs—risk depends on what paths and commands your agent executes after the plan is approved.
SKILL.md
READMESKILL.md - Create Implementation Plan
# Create Implementation Plan ## Primary Directive Your goal is to create a new implementation plan file for `${input:PlanPurpose}`. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans. ## Execution Context This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification. ## Core Requirements - Generate implementation plans that are fully executable by AI agents or humans - Use deterministic language with zero ambiguity - Structure all content for automated parsing and execution - Ensure complete self-containment with no external dependencies for understanding ## Plan Structure Requirements Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared. ## Phase Architecture - Each phase must have measurable completion criteria - Tasks within phases must be executable in parallel unless dependencies are specified - All task descriptions must include specific file paths, function names, and exact implementation details - No task should require human interpretation or decision-making ## AI-Optimized Implementation Standards - Use explicit, unambiguous language with zero interpretation required - Structure all content as machine-parseable formats (tables, lists, structured data) - Include specific file paths, line numbers, and exact code references where applicable - Define all variables, constants, and configuration values explicitly - Provide complete context within each task description - Use standardized prefixes for all identifiers (REQ-, TASK-, etc.) - Include validation criteria that can be automatically verified ## Output File Specifications - Save implementation plan files in `/plan/` directory - Use naming convention: `[purpose]-[component]-[version].md` - Purpose prefixes: `upgrade|refactor|feature|data|infrastructure|process|architecture|design` - Example: `upgrade-system-command-4.md`, `feature-auth-module-1.md` - File must be valid Markdown with proper front matter structure ## Mandatory Template Structure All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution. ## Template Validation Rules - All front matter fields must be present and properly formatted - All section headers must match exactly (case-sensitive) - All identifier prefixes must follow the specified format - Tables must include all required columns - No placeholder text may remain in the final output ## Status The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): `Completed` (bright green badge), `In progress` (yellow badge), `Planned` (blue badge), `Deprecated` (red badge), or `On Hold` (orange badge). It should also be displayed as a badge in the introduction section. ```md --- goal: [Concise Title Describing the Package Implementation Plan's Goal] version: [Optional: e.g., 1.0, Date] date_created: [YYYY-MM-DD] last_updated: [Optional: YYYY-MM-DD] owner: [Optional: Team/Individual responsible for this spec] status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold' tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc] --- # Introduction ![Status: <status>](https://img.shields.io/badge/status-<status>-<status_color