skills/devops/create-implementation-plan/SKILL.md
Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.
npx skillsauth add ImaginerLabs/skill-manager create-implementation-planInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
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.
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.
/plan/ directory[purpose]-[component]-[version].mdupgrade|refactor|feature|data|infrastructure|process|architecture|designupgrade-system-command-4.md, feature-auth-module-1.mdAll 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.
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.
---
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

[A short concise introduction to the plan and the goal it is intended to achieve.]
## 1. Requirements & Constraints
[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]
- **REQ-001**: Requirement 1
- **SEC-001**: Security Requirement 1
- **[3 LETTERS]-001**: Other Requirement 1
- **CON-001**: Constraint 1
- **GUD-001**: Guideline 1
- **PAT-001**: Pattern to follow 1
## 2. Implementation Steps
### Implementation Phase 1
- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
| Task | Description | Completed | Date |
| -------- | --------------------- | --------- | ---------- |
| TASK-001 | Description of task 1 | ✅ | 2025-04-25 |
| TASK-002 | Description of task 2 | | |
| TASK-003 | Description of task 3 | | |
### Implementation Phase 2
- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
| Task | Description | Completed | Date |
| -------- | --------------------- | --------- | ---- |
| TASK-004 | Description of task 4 | | |
| TASK-005 | Description of task 5 | | |
| TASK-006 | Description of task 6 | | |
## 3. Alternatives
[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]
- **ALT-001**: Alternative approach 1
- **ALT-002**: Alternative approach 2
## 4. Dependencies
[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]
- **DEP-001**: Dependency 1
- **DEP-002**: Dependency 2
## 5. Files
[List the files that will be affected by the feature or refactoring task.]
- **FILE-001**: Description of file 1
- **FILE-002**: Description of file 2
## 6. Testing
[List the tests that need to be implemented to verify the feature or refactoring task.]
- **TEST-001**: Description of test 1
- **TEST-002**: Description of test 2
## 7. Risks & Assumptions
[List any risks or assumptions related to the implementation of the plan.]
- **RISK-001**: Risk 1
- **ASSUMPTION-001**: Assumption 1
## 8. Related Specifications / Further Reading
[Link to related spec 1]
[Link to relevant external documentation]
development
Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a 'report', 'memo', 'letter', 'template', or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.
tools
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
documentation
Generates standardized porting documentation from completed feature changes. Analyzes commit diffs or file contents, extracts change intent, and outputs Markdown documentation for cross-team understanding. Should be used when the user needs to document a change for cross-team or cross-project consumption. Distinguished from cross-branch-fix-porter which actively re-implements fixes, this skill documents changes.
development
Cross-branch fix porting expert. Understands fix intent and re-implements the same fix goal in the current branch's code context when direct cherry-pick isn't feasible. Should be used when the user needs to apply a fix from one branch to another where code structures differ significantly. Distinguished from feature-port-doc-generator which documents changes, this skill actively re-implements fixes.