Add 18 new prompts files

prompts/create-architectural-decision-record.prompt.md

@@ -0,0 +1,97 @@
+---
+mode: 'agent'
+description: 'Create an Architectural Decision Record (ADR) document for AI-optimized decision documentation.'
+tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# Create Architectural Decision Record
+
+Create an ADR document for `${input:DecisionTitle}` using structured formatting optimized for AI consumption and human readability.
+
+## Inputs
+
+- **Context**: `${input:Context}`
+- **Decision**: `${input:Decision}`
+- **Alternatives**: `${input:Alternatives}`
+- **Stakeholders**: `${input:Stakeholders}`
+
+## Input Validation
+If any of the required inputs are not provided or cannot be determined from the conversation history, ask the user to provide the missing information before proceeding with ADR generation.
+
+## Requirements
+
+- Use precise, unambiguous language
+- Follow standardized ADR format with front matter
+- Include both positive and negative consequences
+- Document alternatives with rejection rationale
+- Structure for machine parsing and human reference
+- Use coded bullet points (3-4 letter codes + 3-digit numbers) for multi-item sections
+
+The ADR must be saved in the `/docs/adr/` directory using the naming convention: `adr-NNNN-[title-slug].md`, where NNNN is the next sequential 4-digit number (e.g., `adr-0001-database-selection.md`).
+
+## Required Documentation Structure
+
+The documentation file must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:
+
+```md
+---
+title: "ADR-NNNN: [Decision Title]"
+status: "Proposed"
+date: "YYYY-MM-DD"
+authors: "[Stakeholder Names/Roles]"
+tags: ["architecture", "decision"]
+supersedes: ""
+superseded_by: ""
+---
+
+# ADR-NNNN: [Decision Title]
+
+## Status
+
+**Proposed** | Accepted | Rejected | Superseded | Deprecated
+
+## Context
+
+[Problem statement, technical constraints, business requirements, and environmental factors requiring this decision.]
+
+## Decision
+
+[Chosen solution with clear rationale for selection.]
+
+## Consequences
+
+### Positive
+
+- **POS-001**: [Beneficial outcomes and advantages]
+- **POS-002**: [Performance, maintainability, scalability improvements]
+- **POS-003**: [Alignment with architectural principles]
+
+### Negative
+
+- **NEG-001**: [Trade-offs, limitations, drawbacks]
+- **NEG-002**: [Technical debt or complexity introduced]
+- **NEG-003**: [Risks and future challenges]
+
+## Alternatives Considered
+
+### [Alternative 1 Name]
+
+- **ALT-001**: **Description**: [Brief technical description]
+- **ALT-002**: **Rejection Reason**: [Why this option was not selected]
+
+### [Alternative 2 Name]
+
+- **ALT-003**: **Description**: [Brief technical description]
+- **ALT-004**: **Rejection Reason**: [Why this option was not selected]
+
+## Implementation Notes
+
+- **IMP-001**: [Key implementation considerations]
+- **IMP-002**: [Migration or rollout strategy if applicable]
+- **IMP-003**: [Monitoring and success criteria]
+
+## References
+
+- **REF-001**: [Related ADRs]
+- **REF-002**: [External documentation]
+- **REF-003**: [Standards or frameworks referenced]
+```

prompts/create-github-issue-feature-from-specification.prompt.md

@@ -0,0 +1,28 @@
+---
+mode: 'agent'
+description: 'Create GitHub Issue for feature request from specification file using feature_request.yml template.'
+tools: ['codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
+---
+# Create GitHub Issue from Specification
+
+Create GitHub Issue for the specification at `${file}`.
+
+## Process
+
+1. Analyze specification file to extract requirements
+2. Check existing issues using `search_issues`
+3. Create new issue using `create_issue` or update existing with `update_issue`
+4. Use `feature_request.yml` template (fallback to default)
+
+## Requirements
+
+- Single issue for the complete specification
+- Clear title identifying the specification
+- Include only changes required by the specification
+- Verify against existing issues before creation
+
+## Issue Content
+
+- Title: Feature name from specification
+- Description: Problem statement, proposed solution, and context
+- Labels: feature, enhancement (as appropriate)

prompts/create-github-issues-feature-from-implementation-plan.prompt.md

@@ -0,0 +1,28 @@
+---
+mode: 'agent'
+description: 'Create GitHub Issues from implementation plan phases using feature_request.yml or chore_request.yml templates.'
+tools: ['codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
+---
+# Create GitHub Issue from Implementation Plan
+
+Create GitHub Issues for the implementation plan at `${file}`.
+
+## Process
+
+1. Analyze plan file to identify phases
+2. Check existing issues using `search_issues`
+3. Create new issue per phase using `create_issue` or update existing with `update_issue`
+4. Use `feature_request.yml` or `chore_request.yml` templates (fallback to default)
+
+## Requirements
+
+- One issue per implementation phase
+- Clear, structured titles and descriptions
+- Include only changes required by the plan
+- Verify against existing issues before creation
+
+## Issue Content
+
+- Title: Phase name from implementation plan
+- Description: Phase details, requirements, and context
+- Labels: Appropriate for issue type (feature/chore)

prompts/create-github-issues-for-unmet-specification-requirements.prompt.md

@@ -0,0 +1,35 @@
+---
+mode: 'agent'
+description: 'Create GitHub Issues for unimplemented requirements from specification files using feature_request.yml template.'
+tools: ['codebase', 'search', 'github', 'create_issue', 'search_issues', 'update_issue']
+---
+# Create GitHub Issues for Unmet Specification Requirements
+
+Create GitHub Issues for unimplemented requirements in the specification at `${file}`.
+
+## Process
+
+1. Analyze specification file to extract all requirements
+2. Check codebase implementation status for each requirement
+3. Search existing issues using `search_issues` to avoid duplicates
+4. Create new issue per unimplemented requirement using `create_issue`
+5. Use `feature_request.yml` template (fallback to default)
+
+## Requirements
+
+- One issue per unimplemented requirement from specification
+- Clear requirement ID and description mapping
+- Include implementation guidance and acceptance criteria
+- Verify against existing issues before creation
+
+## Issue Content
+
+- Title: Requirement ID and brief description
+- Description: Detailed requirement, implementation method, and context
+- Labels: feature, enhancement (as appropriate)
+
+## Implementation Check
+
+- Search codebase for related code patterns
+- Check related specification files in `/spec/` directory
+- Verify requirement isn't partially implemented

prompts/create-implementation-plan.prompt.md

@@ -0,0 +1,146 @@
+---
+mode: 'agent'
+description: 'Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.'
+tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'githubRepo', 'openSimpleBrowser', 'problems', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI']
+---
+# 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
+
+```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]
+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]
+```