Update Implementation Plan
Revise an existing implementation plan file when scope, architecture, packages, or design requirements change so agents can execute deterministically.
Overview
Update Implementation Plan is an agent skill most often used in Build (also Validate scope) that rewrites an existing implementation plan file into deterministic, agent-executable phases and tasks.
Install
npx skills add https://github.com/github/awesome-copilot --skill update-implementation-planWhat is this skill?
- Primary directive: update `${file}` implementation plans from new or changed requirements
- Deterministic, zero-ambiguity language structured for AI-to-AI and automated parsing
- Phase architecture with atomic tasks, optional parallel execution, and explicit cross-phase dependencies
- Measurable completion criteria per phase for autonomous execution
- Self-contained plans with no external doc dependencies for understanding
Adoption & trust: 10k installs on skills.sh; 34.6k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your implementation plan file no longer matches new requirements, but ad-hoc edits would break the structured format agents need to execute work reliably.
Who is it for?
Builders maintaining a living IMPLEMENTATION_PLAN.md (or similar) who want scope changes reflected without losing deterministic structure.
Skip if: Brainstorming greenfield ideas with no plan file yet, or one-line todos where a full phased plan would be overhead.
When should I use this skill?
Update an existing implementation plan file with new or updated requirements for features, refactors, package upgrades, design, architecture, or infrastructure.
What do I get? / Deliverables
An updated, self-contained plan with atomic phases, clear task specs, and completion criteria ready for parallel agent or human execution.
- Updated implementation plan with phased atomic tasks
- Measurable per-phase completion criteria
- Explicit task dependencies where cross-phase order matters
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build → PM because the artifact is an implementation plan meant for ongoing product execution, not one-off ideation. PM subphase covers planning artifacts, phased roadmaps, and machine-readable task breakdowns autonomous agents consume.
Where it fits
Fold trimmed MVP scope into the plan after validation without rewriting from scratch.
Insert new phases for a feature and parallelize tasks agents can pick up independently.
Add launch-prep and infra upgrade tasks with explicit dependencies before release week.
How it compares
Use to mutate an existing structured plan, not as a substitute for initial brainstorming or open-ended chat scoping.
Common Questions / FAQ
Who is update-implementation-plan for?
Solo builders and indie teams running AI agents against markdown implementation plans who need safe, structured updates when requirements change.
When should I use update-implementation-plan?
In Validate when rescoping a prototype, in Build PM when adding features or refactors, or before Ship when package, design, or infra upgrades must be sequenced into the plan file.
Is update-implementation-plan safe to install?
It guides document edits only; confirm trust via the Security Audits panel on this Prism page before pointing it at production repos.
SKILL.md
READMESKILL.md - Update Implementation Plan
# Update Implementation Plan ## Primary Directive You are an AI agent tasked with updating the implementation plan file `${file}` based on new or updated requirements. 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] --- # Introductio