Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.

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 Identifiers must be uniquely declared. Every identifier ( REQ NNN , SEC NNN , CON NNN , GUD NNN , PAT NNN , GOAL NNN , TASK NNN , ALT NNN , DEP NNN , FILE NNN , TEST NNN , RISK NNN , ASSUMPTION NNN ) must be declared exactly once . A declaration is where the identifier introduces a row: the leading cell in a TASK/GOAL table row, or the bolded prefix in a bullet line like REQ 001 : ... . The same identifier may then appear any number of times as a reference elsewhere in the plan (a TASK body citing a REQ , one TASK citing another TASK , the Dependencies section pointing at a DEP already declared upstream, etc.). References are expected and not collisions. Identifier Uniqueness Check Run these checks before finalizing the plan. Checks (1) and (2) target declarations and must return zero rows. Check (3) is a broad informational scan: it will surface valid references too, so use it for awareness rather than as a gate. Prerequisites: a POSIX compatible shell ( sh / bash ) with grep , sed , sort , and uniq . On Windows without these tools, use equivalent platform native commands and preserve the same declaration vs reference logic. If check (1) or (2) returns any row, re number the duplicate so each identifier is declared exactly once, then re run the checks until both are empty. 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.

create-implementation-plan