Initial commit

commands/00-setup.md

@@ -0,0 +1,98 @@
+---
+description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
+argument-hint: Optional principle inputs or constitution parameters
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+You are updating the project constitution at `specs/constitution.md`, create folder and file if not exists. Use file template at the bottom, it is containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+
+Follow this execution flow:
+
+1. Write the existing constitution template to `specs/constitution.md` file.
+   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
+   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
+
+2. Collect/derive values for placeholders:
+   - If user input (conversation) supplies a value, use it.
+   - Otherwise infer from existing repo context (README, docs, CLAUDE.md,prior constitution versions if embedded).
+   - For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
+   - `CONSTITUTION_VERSION` must increment according to semantic versioning rules:
+     - MAJOR: Backward incompatible governance/principle removals or redefinitions.
+     - MINOR: New principle/section added or materially expanded guidance.
+     - PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
+   - If version bump type ambiguous, propose reasoning before finalizing.
+
+3. Draft the updated constitution content:
+   - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
+   - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
+   - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
+   - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
+
+4. Consistency propagation checklist (convert prior checklist into active validations):
+   - Write `specs/templates/plan-template.md` if it not exists and ensure any "Constitution Check" or rules align with updated principles.
+   - Write `specs/templates/spec-template.md` if it not exists and ensure scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
+   - Write `specs/templates/tasks-template.md` if it not exists and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
+   - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
+
+5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
+   - Version change: old → new
+   - List of modified principles (old title → new title if renamed)
+   - Added sections
+   - Removed sections
+   - Templates requiring updates (✅ updated / ⚠ pending) with file paths
+   - Follow-up TODOs if any placeholders intentionally deferred.
+
+6. Validation before final output:
+   - No remaining unexplained bracket tokens.
+   - Version line matches report.
+   - Dates ISO format YYYY-MM-DD.
+   - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
+
+7. Write the completed constitution back to `specs/constitution.md` (overwrite).
+
+8. Output a final summary to the user with:
+   - New version and bump rationale.
+   - Any files flagged for manual follow-up.
+   - Suggested commit message (e.g., `docs: amend constitution to vX.Y.Z (principle additions + governance update)`).
+
+Formatting & Style Requirements:
+
+- Use Markdown headings exactly as in the template (do not demote/promote levels).
+- Wrap long rationale lines to keep readability (<100 chars ideally) but do not hard enforce with awkward breaks.
+- Keep a single blank line between sections.
+- Avoid trailing whitespace.
+
+If the user supplies partial updates (e.g., only one principle revision), still perform validation and version decision steps.
+
+If critical info missing (e.g., ratification date truly unknown), insert `TODO(<FIELD_NAME>): explanation` and include in the Sync Impact Report under deferred items.
+
+Do not create a new template; always operate on the existing `specs/constitution.md` file.
+
+### Consitutation Template
+
+Load file from this url <https://raw.githubusercontent.com/github/spec-kit/7e568c1201be9f70df4ef241bc9e7dab4e70d61e/memory/constitution.md> and write it to `specs/constitution.md` using `curl` or `wget` command.
+
+### Plan Template
+
+Load file from this url <https://raw.githubusercontent.com/github/spec-kit/7e568c1201be9f70df4ef241bc9e7dab4e70d61e/templates/plan-template.md> and write it to `specs/templates/plan-template.md` using `curl` or `wget` command.
+
+### Specification Template
+
+Load file from this url <https://raw.githubusercontent.com/github/spec-kit/7e568c1201be9f70df4ef241bc9e7dab4e70d61e/templates/spec-template.md> and write it to `specs/templates/spec-template.md` using `curl` or `wget` command.
+
+### Checklists Template
+
+Load file from this url <https://raw.githubusercontent.com/NeoLabHQ/context-engineering-kit/refs/heads/master/plugins/sdd/templates/spec-checklist.md> and write it to `specs/templates/spec-checklist.md` using `curl` or `wget` command.
+
+### Tasks Template
+
+Load file from this url <https://raw.githubusercontent.com/github/spec-kit/7e568c1201be9f70df4ef241bc9e7dab4e70d61e/templates/tasks-template.md> and write it to `specs/templates/tasks-template.md` using `curl` or `wget` command.

commands/01-specify.md

@@ -0,0 +1,167 @@
+---
+description: Create or update the feature specification from a natural language feature description. 
+argument-hint: Feature description
+---
+
+# Specify Feature
+
+Guided feature development with codebase understanding and architecture focus.
+
+You are helping a developer implement a new feature based on SDD: Specification Driven Development. Follow a systematic approach: understand the codebase deeply, identify and ask about all underspecified details, design detailed specification.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Stage 1: Discovery/Specification Design
+
+**Goal**: Understand what needs to be built
+
+**Actions**:
+
+1. If feature unclear, **Ask clarifying questions**: Identify all ambiguities, edge cases, and underspecified behaviors. Ask specific, concrete questions rather than making assumptions. Wait for user answers before proceeding with next steps. Ask questions early.
+
+2. Once feature is clear, summarize understanding by answering on this questions:
+   - What problem are they solving?
+   - What should the feature do?
+   - Any constraints or requirements?
+
+3. Write feature specification following #Outline section.
+
+## Outline
+
+The text the user typed after `/sdd:01-specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `{ARGS}` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
+
+Given that feature description, do this:
+
+1. **Generate a concise short name** (2-4 words) for the branch:
+   - Analyze the feature description and extract the most meaningful keywords
+   - Create a 2-4 word short name that captures the essence of the feature
+   - Use action-noun format when possible (e.g., "add-user-auth", "fix-payment-bug")
+   - Preserve technical terms and acronyms (OAuth2, API, JWT, etc.)
+   - Keep it concise but descriptive enough to understand the feature at a glance
+   - Examples:
+     - "I want to add user authentication" → "user-auth"
+     - "Implement OAuth2 integration for the API" → "oauth2-api-integration"
+     - "Create a dashboard for analytics" → "analytics-dashboard"
+     - "Fix payment processing timeout bug" → "fix-payment-timeout"
+
+2. **Check for existing branches before creating new one**:
+
+   a. First, fetch all remote branches to ensure we have the latest information:
+
+      ```bash
+      git fetch --all --prune
+      ```
+
+   b. Find the highest feature number across all sources for the short-name:
+      - Remote branches: `git ls-remote --heads origin | grep -E 'refs/heads/feature/[0-9]+-<short-name>$'`
+      - Local branches: `git branch | grep -E '^[* ]*feature/[0-9]+-<short-name>$'`
+      - Specs directories: Check for directories matching `specs/[0-9]+-<short-name>`
+
+   c. Determine the next available number:
+      - Extract all numbers from all three sources
+      - Find the highest number N
+      - Use N+1 for the new branch number
+
+   d. Create new feature folder in `specs/` directory with the calculated number and short-name:
+      - Create folder `specs/<number-padded-to-3-digits>-<short-name>`, in future refered as `FEATURE_DIR`
+      - Create file `FEATURE_DIR/spec.md` by copying `specs/templates/spec-template.md` file, in future refered as `SPEC_FILE`.
+      - Example: `cp specs/templates/spec-template.md specs/5-user-auth/spec.md`
+
+   **IMPORTANT**:
+   - Check all three sources (remote branches, local branches, specs directories) to find the highest number
+   - Only match branches/directories with the exact short-name pattern
+   - If no existing branches/directories found with this short-name, start with number 1
+   - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot")
+
+3. Launch `business-analyst` agent with provided prompt exactly, while prefiling required variables:
+
+      ```markdown
+      Perform business analysis and requirements gathering.
+      Write the specification to {SPEC_FILE} using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings, and expanding specification based on use case and feature information.
+      
+      User Input: {provide user input here}
+      
+      FEATURE_NAME: {FEATURE_NAME}
+      FEATURE_DIR: {FEATURE_DIR}
+      SPEC_FILE: {SPEC_FILE}
+
+      ```
+
+4. **Specification Quality Validation**: After writing the initial spec, validate it against quality criteria:
+
+   a. **Create Spec Quality Checklist**: Copy `specs/templates/spec-checklist.md` file to `FEATURE_DIR/spec-checklist.md` using `cp` command, in future refered as `CHECKLIST_FILE`.
+
+   b. Launch new `business-analyst` agent with provided prompt exactly, while prefiling required variables
+
+      ```markdown
+      Peform following steps:
+      1. Fill in {CHECKLIST_FILE} file with based on user input.
+      2. Review the specification in {SPEC_FILE} file against each checklist item in this checklist:
+         - For each item, determine if it passes or fails
+         - Document specific issues found (quote relevant spec sections)
+      3. Reflect on specification and provide feedback on potential issues and missing areas, even if they not present in checklist.
+
+      ---
+
+      User Input: {provide user input here}
+      
+      FEATURE_NAME: {FEATURE_NAME}
+      FEATURE_DIR: {FEATURE_DIR}
+      SPEC_FILE: {SPEC_FILE}
+      
+      ```
+
+   c. **Handle Validation Results**:
+
+      - **If all items pass**: Mark checklist complete and proceed to step 6
+
+      - **If items fail (excluding [NEEDS CLARIFICATION])**:
+        1. List the failing items and specific issues
+        2. Launch new `business-analyst` agent and ask it to analyze and update the spec to address each issue
+        3. Re-run validation by launching new `business-analyst` agent until all items pass (max 3 iterations)
+        4. If still failing after 3 iterations, document remaining issues in checklist notes and warn user
+
+      - **If [NEEDS CLARIFICATION] markers remain**:
+        1. Extract all [NEEDS CLARIFICATION: ...] markers from the spec:
+        2. **LIMIT CHECK**: If more than 3 markers exist, keep only the 3 most critical (by scope/security/UX impact) and and launch new `business-analyst` agent to make informed guesses for the rest
+        3. For each clarification needed (max 3), present options to user in this format:
+
+           ```markdown
+           ## Question [N]: [Topic]
+           
+           **Context**: [Quote relevant spec section]
+           
+           **What we need to know**: [Specific question from NEEDS CLARIFICATION marker]
+           
+           **Suggested Answers**:
+           
+           | Option | Answer | Implications |
+           |--------|--------|--------------|
+           | A      | [First suggested answer] | [What this means for the feature] |
+           | B      | [Second suggested answer] | [What this means for the feature] |
+           | C      | [Third suggested answer] | [What this means for the feature] |
+           | Custom | Provide your own answer | [Explain how to provide custom input] |
+           
+           **Your choice**: _[Wait for user response]_
+           ```
+
+        4. **CRITICAL - Table Formatting**: Ensure markdown tables are properly formatted:
+           - Use consistent spacing with pipes aligned
+           - Each cell should have spaces around content: `| Content |` not `|Content|`
+           - Header separator must have at least 3 dashes: `|--------|`
+           - Test that the table renders correctly in markdown preview
+        5. Number questions sequentially (Q1, Q2, Q3 - max 3 total)
+        6. Present all questions together before waiting for responses
+        7. Wait for user to respond with their choices for all questions (e.g., "Q1: A, Q2: Custom - [details], Q3: B")
+        8. Launch new `business-analyst` agent to update the spec by replacing each [NEEDS CLARIFICATION] marker with the user's selected or provided answer
+        9. Re-run validation by launching new `business-analyst` agent after all clarifications are resolved
+
+   d. **Update Checklist**: After each validation iteration, update the checklist file with current pass/fail status
+
+5. Report completion with branch name, spec file path, checklist results, and readiness for the next stage `/sdd:01-plan`.

commands/02-plan.md

@@ -0,0 +1,198 @@
+---
+description: Plan the feature development based on the feature specification. 
+argument-hint: Plan specifics suggestions
+---
+
+# Plan Feature Development
+
+Guided feature development with codebase understanding and architecture focus.
+
+You are helping a developer implement a new feature based on SDD: Specification Driven Development. Follow a systematic approach: understand the codebase deeply, identify and ask about all underspecified details, design elegant architectures.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Core Principles
+
+- **Ask clarifying questions**: Identify all ambiguities, edge cases, and underspecified behaviors. Ask specific, concrete questions rather than making assumptions. Wait for user answers before proceeding with implementation. Ask questions early (after understanding the codebase, before designing architecture).
+- **Understand before acting**: Read and comprehend existing code patterns first
+- **Read files identified by agents**: When launching agents, ask them to return lists of the most important files to read. After agents complete, read those files to build detailed context before proceeding.
+- **Simple and elegant**: Prioritize readable, maintainable, architecturally sound code
+- **Use TodoWrite**: Track all progress throughout
+
+## Outline
+
+1. **Setup**: Get the current git branch, if it written in format `feature/<number-padded-to-3-digits>-<kebab-case-title>`, part after `feature/` is defined as FEATURE_NAME. Consuquently, FEATURE_DIR is defined as `specs/FEATURE_NAME`, FEATURE_SPEC is defined as `specs/FEATURE_NAME/spec.md`, IMPL_PLAN is defined as `specs/FEATURE_NAME/plan.md`, SPECS_DIR is defined as `specs/`. 
+
+2. **Load context**: Read FEATURE_SPEC and `specs/constitution.md`.
+3. Copy `specs/templates/plan-template.md` to `FEATURE_DIR/plan.md` using `cp` command, in future refered as `PLAN_FILE`.
+4. Continue with stage 2
+
+## Stage 2: Research & Codebase Exploration
+
+**Goal**: Understand relevant existing code and patterns at both high and low levels. Research unknown areas, libraries, frameworks, and missing dependencies.
+
+Follow the structure in {PLAN_FILE} template to:
+
+- Fill Technical Context (mark unknowns as "NEEDS CLARIFICATION")
+- Fill Constitution Check section from constitution
+- Evaluate gates (ERROR if violations unjustified)
+
+### Actions
+
+**Technical Context**:
+
+1. **Extract unknowns from Technical Context** above:
+   - For each NEEDS CLARIFICATION → research task
+   - For each dependency → best practices task
+   - For each integration → patterns task
+2. **Launch `researcher` agent to perform created tasks**:
+
+   ```text
+   For each unknown in Technical Context:
+     Task: "Research {unknown} for {feature context}"
+   For each technology choice:
+     Task: "Find best practices for {tech} in {domain}"
+   ```
+
+3. **Consolidate findings** in `research.md` using format:
+   - Decision: [what was chosen]
+   - Rationale: [why chosen]
+   - Alternatives considered: [what else evaluated]
+
+**Codebase Exploration**:
+
+1. For code explaration launch 2-3 `code-explorer` agents in parallel. Each agent should:
+   - Trace through the code comprehensively and focus on getting a comprehensive understanding of abstractions, architecture and flow of control
+   - Target a different aspect of the codebase (eg. similar features, high level understanding, architectural understanding, user experience, etc)
+   - Include a list of 5-10 key files to read
+
+   **Example agent prompts**:
+   - "Find features similar to [feature] and trace through their implementation comprehensively"
+   - "Map the architecture and abstractions for [feature area], tracing through the code comprehensively"
+   - "Analyze the current implementation of [existing feature/area], tracing through the code comprehensively"
+   - "Identify UI patterns, testing approaches, or extension points relevant to [feature]"
+
+2. Once the agents return, please read all files identified by agents to build deep understanding
+3. Update research report in `FEATURE_DIR/research.md` file with all findings and set links to relevant files.
+4. Present comprehensive summary of findings and patterns discovered to user.
+
+---
+
+## Stage 3: Clarifying Questions
+
+**Goal**: Fill in gaps and resolve all ambiguities before designing
+
+**CRITICAL**: This is one of the most important stages. DO NOT SKIP.
+
+**Actions**:
+
+1. Review the codebase findings and original feature request
+2. Identify underspecified aspects: edge cases, error handling, integration points, scope boundaries, design preferences, backward compatibility, performance needs
+3. **Present all questions to the user in a clear, organized list**
+4. **Wait for answers before proceeding to architecture design**
+
+If the user says "whatever you think is best", provide your recommendation and set it as a assumed decision in `research.md` file.
+
+### Output
+
+`research.md` with all NEEDS CLARIFICATION resolved and links to relevant files.
+
+---
+
+## Stage 4: Architecture Design
+
+**Prerequisites:** `research.md` complete
+
+**Goal**: Design multiple implementation approaches with different trade-offs.
+
+### Actions
+
+1. Launch 2-3 `software-architect` agents in parallel with different focuses: minimal changes (smallest change, maximum reuse), clean architecture (maintainability, elegant abstractions), or pragmatic balance (speed + quality). Use provided prompt exactly, while prefiling required variables:
+
+   ```markdown
+   Perform software architecture plan design.
+   
+
+
+   **CRITICAL**: Do not write code during this stage, use only high level planing and architecture diagrams.
+
+   User Input: {provide user input here if it exists}
+
+   ## Steps
+
+   - **Load context**: Read `specs/constitution.md`, {FEATURE_SPEC}, {FEATURE_DIR}/research.md.
+   - Write the architecture design to {FEATURE_DIR}/design.{focus-name}.md file, while focusing on following aspect: {focus description}. 
+   ```
+
+2. Review all approaches and form your opinion on which fits best for this specific task (consider: small fix vs large feature, urgency, complexity, team context)
+3. Present to user: brief summary of each approach, trade-offs comparison, **your recommendation with reasoning**, concrete implementation differences.
+4. **Ask user which approach they prefer**
+
+## Stage 5: Plan
+
+Launch new `software-architect` agent to make final design doc, based on appraoch choosen by user in previous stage. Use provided prompt exactly, while prefiling required variables:
+
+   ```markdown
+   Perform software architecture plan design.
+   
+   **Goal**: Plan the implementation based on approach choosen by the user and clarify all unclear or uncertain areas.
+
+   **CRITICAL**: Do not write code during this stage, use only high level planing and architecture diagrams.
+
+   User Input: {provide user input here}
+
+   ## Steps
+
+   1. **Load context**: Read `specs/constitution.md`, {FEATURE_SPEC}, {FEATURE_DIR}/research.md.
+   2. Read design files: {list of design files generated by previous agents}.
+
+   3. Write the final design doc to {FEATURE_DIR}/design.md file, based on appraoch choosen by the user.
+   4. Write implementation plan by filling `FEATURE_DIR/plan.md` template.
+   5. **Extract entities from feature spec** → `FEATURE_DIR/data-model.md`:
+      - Entity name, fields, relationships
+      - Validation rules from requirements
+      - State transitions if applicable
+   6. **Generate API contracts** from functional requirements if it applicable:
+      - For each user action → endpoint
+      - Use standard REST/GraphQL patterns
+      - Output OpenAPI/GraphQL schema to `FEATURE_DIR/contract.md`
+   7. Output implementation plan summary.
+   ```
+
+## Stage 6: Review Implementation Plan
+
+### Actions
+
+1. Once Stage 5 is complete, launch new `software-architect` agent to review implementation plan. Use provided prompt exactly, while prefiling required variables:
+
+   ```markdown
+   Review implementation plan.
+   
+   **Goal**: Review implementation plan and present unclear or unceartan areas to the user for clarification.
+   
+   **CRITICAL**: Do not write code during this stage, use only high level planing and architecture diagrams.
+   
+   User Input: {provide user input here}
+
+   ## Steps
+
+   1. **Load context**: Read `specs/constitution.md`, {FEATURE_SPEC}, {FEATURE_DIR}/research.md.
+   2. Review implementation plan in {FEATURE_DIR}/plan.md file, identify unclear or unceartan areas.
+   3. Resolve high confidence issues by yourself.
+   4. Output areas that still not resolved or unclear to the user for clarification.
+   ```
+
+2. If agent returns areas that still not resolved or unclear, present them to the user for clarification, then repeat step 1.
+
+3. Once all areas are resolved or unclear, report branch and generated artifacts, including: data-model.md, contract.md, plan.md, etc.
+
+## Key rules
+
+- Use absolute paths
+- ERROR on gate failures or unresolved clarifications

commands/03-tasks.md

@@ -0,0 +1,42 @@
+---
+description: Generate an actionable, dependency-ordered tasks.md for the feature based on available design artifacts, with complexity analysis
+argument-hint: Optional task creation guidance or specific areas to focus on
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+## Outline
+
+1. **Setup**: Get the current git branch, if it written in format `feature/<number-padded-to-3-digits>-<kebab-case-title>`, part after `feature/` is defined as FEATURE_NAME. Consuquently, FEATURE_DIR is defined as `specs/FEATURE_NAME`.
+
+2. **Load context**: Read `specs/constitution.md`, also read files from FEATURE_DIR:
+   - **Required**: plan.md (tech stack, libraries, structure), spec.md (user stories with priorities)
+   - **Optional**: data-model.md (entities), contracts.md (API endpoints), research.md (decisions),
+   - Note: These files were written during previus stages of SDD workflow (Discovery, Research, Planining, etc.). Not all projects have all documents. Generate tasks based on what's available.
+3. Copy `specs/templates/tasks-template.md` to `FEATURE_DIR/tasks.md` using `cp` command, in future refered as `TASKS_FILE`.
+4. Continue with stage 6
+
+## Stage 6: Create Tasks
+
+1. Launch `tech-lead` agent to create tasks, using provided prompt exactly, while prefiling required variables:
+
+    ```markdown
+    **Goal**: Create tasks for the implementation.
+
+    User Input: {provide user input here if it exists}
+
+    FEATURE_NAME: {FEATURE_NAME}
+    FEATURE_DIR: {FEATURE_DIR}
+    TASKS_FILE: {TASKS_FILE}
+
+    Please, fill/improve tasks.md file based on the task generation workflow.
+
+    ```
+
+2. Provide user with agent output and ask to answer on questions if any require clarification and repeat step 1, while adding questions and answers list as user input. Repeat until all questions are answered, no more than 2 times.

commands/04-implement.md

@@ -0,0 +1,115 @@
+---
+description: Execute the implementation plan by processing and executing all tasks defined in tasks.md
+argument-hint: Optional implementation preferences or specific tasks to prioritize
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+# Implement Feature
+
+## Outline
+
+1. **Setup**: Get the current git branch, if it written in format `feature/<number-padded-to-3-digits>-<kebab-case-title>`, part after `feature/` is defined as FEATURE_NAME. Consuquently, FEATURE_DIR is defined as `specs/FEATURE_NAME`.
+2. **Load context**: Load and analyze the implementation context from FEATURE_DIR:
+   - **REQUIRED**: Read tasks.md for the complete task list and execution plan
+   - **REQUIRED**: Read plan.md for tech stack, architecture, and file structure
+   - **IF EXISTS**: Read data-model.md for entities and relationships
+   - **IF EXISTS**: Read contracts.md for API specifications and test requirements
+   - **IF EXISTS**: Read research.md for technical decisions and constraints
+3. Continue with Stage 8
+
+## Stage 8: Implement
+
+**Goal**: Implement taks list written in `FEATURE_DIR/tasks.md` file.
+
+**Actions**:
+
+1. Read all relevant files identified in previous phases.
+2. Parse tasks.md structure and extract:
+   - **Task phases**: Setup, Tests, Core, Integration, Polish
+   - **Task dependencies**: Sequential vs parallel execution rules
+   - **Task details**: ID, description, file paths, parallel markers [P]
+   - **Execution flow**: Order and dependency requirements
+
+### Phase Execution
+
+For each phase in `tasks.md` file perform following actions:
+
+1. Execute implementation by launching new `developer` agent to implement each phase, verify that all tasks are completed in order and without errors:
+   - **Phase-by-phase execution**: Complete each phase before moving to the next
+   - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together  
+   - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
+   - **File-based coordination**: Tasks affecting the same files must run sequentially
+   - **Validation checkpoints**: Verify each phase completion before proceeding
+
+   Use provided prompt exactly, while prefiling required variables:
+
+      ```markdown
+      **Goal**: Implement {phase name} phase of tasks.md file by following Tasks.md Execution Workflow.
+
+      User Input: {provide user input here if it exists}
+
+      FEATURE_NAME: {FEATURE_NAME}
+      FEATURE_DIR: {FEATURE_DIR}
+      TASKS_FILE: {TASKS_FILE}
+      ```
+
+2. Progress tracking and error handling:
+   - Report progress after each completed phase
+   - Halt execution if any non-parallel phase fails
+   - For parallel phase [P], continue with successful phase, report failed ones
+   - Provide clear error messages with context for debugging
+   - Suggest next steps if implementation cannot proceed
+   - **IMPORTANT** For completed phase, make sure that all tasks in that phase are marked off as [X] in the tasks.md file.
+
+3. Completion validation - Launch new `developer` agent to verify that all tasks are completed in order and without errors by using provided prompt exactly, while prefiling required variables:
+
+   ```markdown
+   **Goal**: Verify that all tasks in tasks.md file are completed in order and without errors.
+      - Verify all required tasks are completed
+      - Check that implemented features match the original specification
+      - Validate that tests pass and coverage meets requirements
+      - Confirm the implementation follows the technical plan
+      - Report final status with summary of completed work
+
+   User Input: {provide user input here if it exists}
+
+   FEATURE_NAME: {FEATURE_NAME}
+   FEATURE_DIR: {FEATURE_DIR}
+   TASKS_FILE: {TASKS_FILE}
+   ```
+
+4. If not all phases are completed, repeat steps 1-4 for the next phase.
+
+## Stage 9: Quality Review
+
+1. Perform `/code-review:review-local-changes` command if it is available, if not then launch 3 `developer` agent to review code quality by using provided prompt exactly, while prefiling required variables, each of them should focus on different aspect of code quality: simplicity/DRY/elegance, bugs/functional correctness, project conventions/abstractions. Prompt for each agent:
+
+   ```markdown
+   **Goal**: Tasks.md file is implemented, review newly implemented code. Focus on {focus area}.
+
+   User Input: {provide user input here if it exists}
+
+   FEATURE_NAME: {FEATURE_NAME}
+   FEATURE_DIR: {FEATURE_DIR}
+   TASKS_FILE: {TASKS_FILE}
+   ```
+
+2. Consolidate findings and identify highest severity issues that you recommend fixing
+3. **Present findings to user and ask what they want to do** (fix now, fix later, or proceed as-is)
+4. Launch new `developer` agent to address issues based on user decision
+
+### Guidelines
+
+- DO NOT CREATE new specification files
+- Maintain consistent documentation style across all documents
+- Include practical examples where appropriate
+- Cross-reference related documentation sections
+- Document best practices and lessons learned during implementation
+- Ensure documentation reflects actual implementation, not just plans

commands/05-document.md

@@ -0,0 +1,64 @@
+---
+description: Document completed feature implementation with API guides, architecture updates, and lessons learned
+argument-hint: Optional documentation focus areas or specific sections to update
+---
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+You **MUST** consider the user input before proceeding (if not empty).
+
+# Document Feature
+
+## Outline
+
+1. **Setup**: Get the current git branch, if it written in format `feature/<number-padded-to-3-digits>-<kebab-case-title>`, part after `feature/` is defined as FEATURE_NAME. Consuquently, FEATURE_DIR is defined as `specs/FEATURE_NAME`, TASKS_FILE is defined as `specs/FEATURE_NAME/tasks.md`.
+
+2. **Load context**: Load and analyze the implementation context from FEATURE_DIR:
+   - **REQUIRED**: Read tasks.md to verify task completion
+   - **IF EXISTS**: Read plan.md for architecture and file structure
+   - **IF EXISTS**: Read spec.md for feature requirements
+   - **IF EXISTS**: Read contracts.md for API specifications
+   - **IF EXISTS**: Read data-model.md for entities and relationships
+   - Note: These files were written during previous stages of SDD workflow (Discovery, Research, Planning, etc.).
+
+3. Continue with Stage 10
+
+## Stage 10: Document Feature
+
+**Goal**: Document feature completion based on implementation results and update project documentation.
+
+### Actions
+
+**Implementation Verification**:
+
+1. Verify implementation status:
+   - Review tasks.md to confirm all tasks are marked as completed [X]
+   - Identify any incomplete or partially implemented tasks
+   - Review codebase for any missing or incomplete functionality
+
+2. **Present to user** any missing or incomplete functionality:
+   - List incomplete tasks and their status
+   - **Ask if they want to fix it now or later**
+   - If user chooses to fix now, launch `developer` agent to address issues before proceeding
+   - If there are no issues or user accepts the results as-is, proceed to documentation
+
+**Documentation Update**:
+
+3. Launch `tech-writer` agent to update documentation, using provided prompt exactly, while prefiling required variables:
+
+   ```markdown
+   **Goal**: Document feature implementation with API guides, architecture updates, and lessons learned, by following Documentation Update Workflow.
+
+   User Input: {provide user input here if it exists}
+
+   FEATURE_NAME: {FEATURE_NAME}
+   FEATURE_DIR: {FEATURE_DIR}
+   TASKS_FILE: {TASKS_FILE}
+
+   ```
+
+4. Present agent output to user with summary of documentation updates

commands/brainstorm.md

@@ -0,0 +1,59 @@
+---
+description: Use when creating or developing, before writing code or implementation plans - refines rough ideas into fully-formed designs through collaborative questioning, alternative exploration, and incremental validation. Don't use during clear 'mechanical' processes
+argument-hint: Optional initial feature concept or topic to brainstorm
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design in small sections (200-300 words), checking after each section whether it looks right so far.
+
+## The Process
+
+**Understanding the idea:**
+
+- Check out the current project state first (files, docs, recent commits)
+- Ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message - if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+
+- Once you believe you understand what you're building, present the design
+- Break it into sections of 200-300 words
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Documentation:**
+
+- Write the validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
+- Use elements-of-style:writing-clearly-and-concisely skill if available
+- Commit the design document to git
+
+**Implementation (if continuing):**
+
+- Ask: "Ready to set up for implementation?"
+- Use superpowers:using-git-worktrees to create isolated workspace
+- Use superpowers:writing-plans to create detailed implementation plan
+
+## Key Principles
+
+- **One question at a time** - Don't overwhelm with multiple questions
+- **Multiple choice preferred** - Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** - Remove unnecessary features from all designs
+- **Explore alternatives** - Always propose 2-3 approaches before settling
+- **Incremental validation** - Present design in sections, validate each
+- **Be flexible** - Go back and clarify when something doesn't make sense