Initial commit

commands/create-pull-request.md

@@ -0,0 +1,41 @@
+---
+name: create-pull-request
+description: Commit changes and create pull request
+argument-hint: [issue-key] [state-management-file-path]
+model: claude-haiku-4-5
+---
+
+# Create Pull Request Command
+
+## Purpose
+
+Create pull request for increment implemented to satisfy the issue.
+Add, commit, push code for the finished increment. Create Pull request in GitHub using the `gh` CLI.
+This command is called by an orchestrating command, and is one of the steps in a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Workflow Steps
+
+1. List unstaged changes using `git status`
+
+2. Read the specification linked in the state management file ($2) and compare with unstaged changes to understand how the increment has been implemented and which unstaged changes are relevant to the increment. Ignore the specifications and state_management folders.
+
+3. Create a git commit using the guidelines in @docs/git-commit.md
+
+4. Push the commit using `git push`
+
+5. Read the Settings section in the state management file ($2)
+
+6. **Check Silent Mode for Pull Request Creation**:
+   - If `silentMode` is `false`:
+     - Create a pull request using `gh pr create --title "feat: $1 [brief description from commit]" --base [default branch name] --head $(git branch --show-current)`
+   - If `silentMode` is `true`:
+     - Log: "Silent mode: Would have created PR with title 'feat: [issue key] [brief description]'"
+     - Skip the actual PR creation
+
+7. **Check Silent Mode for Issue Status Update**:
+   - If `silentMode` is `false` AND `issueTrackingProvider` is NOT `"prompt"`:
+     - Use the SlashCommand tool to execute `/update-issue $1 "Code Review" $2`
+   - If `silentMode` is `true` OR `issueTrackingProvider` is `"prompt"`:
+     - Log: "Silent mode: Would have updated issue $1 status to 'Code Review'"
+     - Skip the issue update

commands/create-state-management-file.md

@@ -0,0 +1,21 @@
+---
+name: create-state-management-file
+description: Create state management file for feature workflow
+argument-hint: [issue-key]
+model: claude-haiku-4-5
+---
+
+# Create State Management File Command
+
+## Purpose
+
+Create a state management file and add the issue key.
+These instructions are read and followed as part of a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Workflow Steps
+
+1. Create a state management file called `state_management/$1.md`.
+
+2. Write the following at the top of the empty state management file:
+`Issue Key: {$1}`

commands/feature.md

@@ -0,0 +1,87 @@
+---
+name: feature
+description: Implement feature from issue tracking system or user prompt
+argument-hint: [issue-key-or-prompt] [--provider=<linear|jira|prompt>] [--silent=<true|false>]
+model: claude-sonnet-4-5
+---
+
+# Feature Implementation Command
+
+## Purpose
+
+This command guides the implementation of new functionality using **minimal iteration cycles**. Each workflow run should implement the smallest possible increment that provides measurable value while maintaining the system's quality standards.
+
+You are responsible for making sure all steps are done according to the workflow steps description below.
+
+IMPORTANT: All steps MUST complete, and they must be completed in the order described below.
+You are only allowed to move to the next step after the previous step has completed.
+
+The issue key or prompt for the feature to implement is $1.
+
+Create a TODO list for the workflow steps, and follow it.
+
+## Arguments
+
+- `$1`: Issue key or feature prompt (required)
+- `$2+`: Optional settings in format `--provider=<value>` or `--silent=<value>`
+  - `--provider`: Override issue tracking provider (`linear`, `jira`, or `prompt`)
+  - `--silent`: Override silent mode (`true` or `false`)
+
+## Pre-Processing
+
+Before starting the workflow for user prompts, create an issue key based on $1:
+
+- List the contents of `state_management` in the additional directories
+- If there are no filenames using the format `prompt-{number}`, use issue key `prompt-1-{short-description}`
+- If there is at least one filename using the format `prompt-{number}`, use issue key `prompt-{number+1}-{short-description}`
+- The short description should be a kebab-case summary of the prompt (e.g., `prompt-1-implement-cli`, `prompt-2-add-auth`)
+
+Parse optional settings arguments ($2, $3, etc.) to extract provider and silent overrides for passing to `/read-settings`.
+
+## Workflow Steps
+
+1. Read @CLAUDE.md: General principles, quality gates, and development workflow. If the @CLAUDE.md refers to other @CLAUDE.md files, read those as well.
+2. Create a state management file for this increment - use the SlashCommand tool to execute `/create-state-management-file $1` if the workflow was started from an issue, or the issue key if it was started from a prompt
+3. Read settings - use the SlashCommand tool to execute `/read-settings [state-management-file-path]` with any optional settings arguments from $2+ (e.g., `/read-settings [path] --provider=prompt --silent=true`)
+4. Read issue - check the issueTrackingProvider in the Settings section of the state management file. If not "prompt", use the SlashCommand tool to execute `/read-issue [issue-key] [state-management-file-path]`. If "prompt", skip this step as there is no external issue to read.
+5. Define requirements - Use the requirements-definer subagent to define requirements for [state-management-file-path]
+6. Audit requirements - Use the requirements-definer-auditor subagent to audit requirements in [state-management-file-path]. If audit fails with critical issues, return to step 5 to address them.
+7. Get sign-off on requirements. You are not allowed to go to step 8 until the user has signed off on the requirements. Use the SlashCommand tool to execute `/requirements-sign-off [state-management-file-path]`
+8. Write specification - Use the specification-writer subagent to write specification for [state-management-file-path]
+9. Audit specification - Use the specification-writer-auditor subagent to audit specification in [state-management-file-path]. If audit fails with critical issues, return to step 8 to address them.
+10. Get sign-off on specification. You are not allowed to go to step 11 until the user has signed off on the specification. Use the SlashCommand tool to execute `/specification-sign-off [state-management-file-path]`
+11. Check out new branch - use the SlashCommand tool to execute `/git-checkout [issue-key] [state-management-file-path]`
+12. Implement increment - use the SlashCommand tool to execute `/implement-increment [issue-key] [state-management-file-path]`
+13. Perform security review:
+    - Use the security-reviewer subagent to analyze the implementation at [state-management-file-path]
+    - Parse the verdict from the subagent's output (look for "**Decision**: APPROVED" or "**Decision**: NEEDS_CHANGES")
+    - If APPROVED: proceed to next step
+    - If NEEDS_CHANGES:
+      a. Inform user that security vulnerabilities were found
+      b. Return to step 12 (implement increment) where agents will read security_reviews/{issue-key}.md to understand what needs to be fixed
+      c. Continue through steps 12-13 until APPROVED
+14. Write end-to-end tests for the increment - use the SlashCommand tool to execute `/write-end-to-end-tests [state-management-file-path]`
+15. Perform code review:
+    - Use the code-reviewer subagent to review the implementation for [state-management-file-path]
+    - Parse the verdict from the agent's output (look for "**Decision**: APPROVED" or "**Decision**: NEEDS_CHANGES")
+    - If APPROVED:
+      a. Extract issue key from state management file
+      b. Extract code review summary from agent output:
+         - Look for the section starting with "## Code Review Summary"
+         - Extract everything from that heading through the end of the output
+         - This section must include Decision, Summary, Completed, and other details
+         - Format contract: The agent outputs this in a specific format (see code-reviewer.md section 9)
+      c. Use SlashCommand tool to execute `/issue:create-comment [issue-key] "[code review summary]" [state-management-file-path]`
+      d. Proceed to next step
+    - If NEEDS_CHANGES:
+      a. Inform the user that code review returned NEEDS_CHANGES and implementation will be revised
+      b. Return to step 12 (implement increment) where implementation agents will read code_reviews/{issue-key}.md and address the issues
+      c. Continue through steps 12-15 again until APPROVED
+16. Create pull request - use the SlashCommand tool to execute `/create-pull-request [issue-key] [state-management-file-path]`
+17. Review pull request - use the SlashCommand tool to execute `/review-pull-request [issue-key] [state-management-file-path]`
+
+**If issue tracking system operations fail**:
+
+- Continue with local specification files
+- Log issue tracking system errors but don't block development
+- Manually update issue status if needed

commands/git-checkout.md

@@ -0,0 +1,24 @@
+---
+name: git-checkout
+description: Create feature branch for implementation
+argument-hint: [issue-key] [state-management-file-path]
+model: claude-haiku-4-5
+---
+
+# Git Checkout Command
+
+## Purpose
+
+Check out a new git branch to be ready for implementation start.
+These instructions are read and followed as part of a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Workflow Steps
+
+1. Read the Settings section in the state management file ($2) to get the default branch name
+
+2. Run `git checkout [default branch name]`
+
+3. Ensure that you have the latest changes, using `git pull`
+
+4. Check out a new branch, using `git checkout -b feat/$1`

commands/implement-increment.md

@@ -0,0 +1,79 @@
+---
+name: implement-increment
+description: Orchestrate implementation of feature increment
+argument-hint: [issue-key] [state-management-file-path]
+model: claude-sonnet-4-5
+---
+
+# Implement Increment Command
+
+## Purpose
+
+Implement the increment using the specification in the state management file.
+These instructions are read and followed as part of a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Workflow Steps
+
+1. Ensure that the specification was explicitly signed off by the user. If not, go back to the specification signoff step in the larger workflow.
+
+2. Update issue status to "In Progress":
+   - Use the SlashCommand tool to execute `/update-issue $1 "In Progress"`
+
+3. Add implementation comment:
+   - Read the state management file ($2) to get the specification file name
+   - Use the SlashCommand tool to execute `/create-comment $1 "Claude Code implementation started for [specification-file-name]"`
+
+4. Understand the division of work and implement tasks:
+    - Read specification to identify agent_ids and Dependency Graph from the Implementation Plan
+    - Check for code review feedback:
+      - Determine code-review file path: `code_reviews/{issue-key}.md` (where issue-key is $1)
+      - If file exists: Read the latest review (most recent "Review #N" section) to understand what needs fixing
+      - If this is a revision (code-review file exists), prioritize addressing review issues over spec additions
+      - Note: Subagents will automatically check for and read code_reviews/{issue-key}.md if it exists - no need to pass review content explicitly
+    - Create "Implementation Agents Status" section in state management file to track progress:
+
+      ```markdown
+      ## Implementation Agents Status
+      - agent-1: pending (revision: 0)
+      - agent-2: pending (revision: 0)
+      ```
+
+    - Process agents in dependency order:
+      a. Identify agents with no dependencies or whose dependencies are complete
+      b. Update their status to "in_progress" in Implementation Agents Status
+      c. Spawn those agents in parallel using the increment-implementer subagent via Task tool
+      d. Pass to each subagent: the agent_id and state management file path
+      e. Monitor for completion signals ("AGENT_COMPLETE: [agent_id]")
+      f. When an agent reports completion, invoke increment-implementer-auditor subagent via Task tool
+      g. Pass to auditor: the agent_id and state management file path
+      h. Wait for audit result (AUDIT_PASSED/AUDIT_FAILED)
+      i. If audit passes, update status to "completed" in Implementation Agents Status
+      j. If audit fails:
+         - Update status to "needs_revision" in Implementation Agents Status
+         - Extract specific feedback from audit report
+         - Re-spawn the increment-implementer subagent with the feedback
+         - Pass: agent_id, state management file path, and "Validator/Auditor feedback: [specific issues]"
+         - Increment revision counter for tracking
+         - Repeat audit cycle until pass or max revisions reached (3 attempts)
+         - If max revisions reached, mark as "failed" and handle as agent failure
+      k. Repeat until all agents are complete
+    - Handle agent failures:
+      - If an agent reports failure, mark it as "failed" in Implementation Agents Status
+      - Do not spawn agents that depend on failed agents
+      - Report the failure chain to the user
+    - When all agent_ids are complete, implementation is finished
+
+## This part of the workflow is done when
+
+- [ ] All subagents are complete and have passed their audits
+- [ ] All audit feedback has been addressed through the revision process
+- [ ] Single behavior is fully implemented, both on the backend and the frontend
+- [ ] All unit and integration tests pass
+- [ ] All quality gates pass (see @CLAUDE.md for commands)
+- [ ] No breaking changes introduced
+- [ ] No test failures introduced in areas of the code unrelated to this increment
+- [ ] Feature works in both development and build modes
+- [ ] Business rules are enforced consistently
+- [ ] Implementation strictly adheres to specification without scope creep
+- [ ] No unnecessary code or over-engineering detected in audits

commands/issue/create-comment.md

@@ -0,0 +1,61 @@
+---
+name: create-comment
+description: Add comment to issue in tracking system
+argument-hint: [issue-key] "[comment-text]" [state-management-file-path]
+model: claude-haiku-4-5
+allowed-tools: Read, Bash(echo:*)
+---
+
+# Create Issue Comment Command
+
+## Purpose
+
+Add a comment to an issue in the configured issue tracking system.
+This command is called by other orchestrating commands, and is one of the steps in a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Arguments
+
+- `$1`: Issue key (required)
+- `$2`: Comment text (required)
+- `$3`: Path to state management file (required)
+
+## Workflow Steps
+
+1. **Read Settings from State Management File**:
+   - Read the Settings section from the state management file ($3)
+   - Extract `issueTrackingProvider` and `silentMode` values
+   - If Settings section is missing, fail with error: "Settings not found in state management file. Run /read-settings first."
+
+2. **Validate Provider Configuration**:
+   - If issueTrackingProvider is "linear":
+     - Check that Linear MCP tools are available
+     - If NOT available: **FAIL with error**: "Provider is 'linear' but Linear MCP tools are not configured. Please configure Linear MCP or update settings with /read-settings --provider=prompt"
+   - If issueTrackingProvider is "jira":
+     - Check that Jira MCP tools are available
+     - If NOT available: **FAIL with error**: "Provider is 'jira' but Jira MCP tools are not configured. Please configure Jira MCP or update settings with /read-settings --provider=prompt"
+
+3. **Check Silent Mode or Prompt Issue Provider**:
+   - If silentMode is true OR issueTrackingProvider is "prompt":
+     - Log the comment operation locally: "Silent mode: Would have added comment to $1: $2"
+     - Skip the actual API call (step 4)
+     - Continue to step 5
+
+4. **Execute Create Comment Operation** (only if silentMode is false and issueTrackingProvider is not "prompt"):
+
+### For Linear Provider (`"linear"`)
+
+- Use `linear:create_comment` with $1 (issue ID) and $2 (comment text)
+- Add the comment to the specified issue
+
+### For Jira Provider (`"jira"`)
+
+- Use `jira:add_comment_to_issue` with $1 (issue key) and $2 (comment text)
+- Add the comment to the specified issue
+
+5. **Output Results**: Display confirmation of the comment creation:
+   - **Issue**: $1
+   - **Comment Added**: $2
+   - **Result**: Success/Failure (or "Skipped - Silent Mode" if applicable)
+
+6. **Error Handling**: If the issue operation fails, log the error but continue gracefully

commands/issue/get-issue.md

@@ -0,0 +1,60 @@
+---
+name: get-issue
+description: Retrieve issue details from tracking system
+argument-hint: [issue-key] [state-management-file-path]
+model: claude-haiku-4-5
+allowed-tools: Read, Bash(echo:*)
+---
+
+# Get Issue Command
+
+## Purpose
+
+Retrieve issue details from the configured issue tracking system for a given issue key.
+This command is called by other orchestrating commands, and is one of the steps in a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Arguments
+
+- `$1`: Issue key (required)
+- `$2`: Path to state management file (required)
+
+## Workflow Steps
+
+1. **Read Settings from State Management File**:
+   - Read the Settings section from the state management file ($2)
+   - Extract `issueTrackingProvider` value
+   - If Settings section is missing or issueTrackingProvider is not set, fail with error: "Settings not found in state management file. Run /read-settings first."
+
+2. **Validate Provider Configuration**:
+   - If issueTrackingProvider is "linear":
+     - Check that Linear MCP tools are available
+     - If NOT available: **FAIL with error**: "Provider is 'linear' but Linear MCP tools are not configured. Please configure Linear MCP or update settings with /read-settings --provider=prompt"
+   - If issueTrackingProvider is "jira":
+     - Check that Jira MCP tools are available
+     - If NOT available: **FAIL with error**: "Provider is 'jira' but Jira MCP tools are not configured. Please configure Jira MCP or update settings with /read-settings --provider=prompt"
+   - If issueTrackingProvider is "prompt":
+     - Log error: "get-issue should not be called for prompt provider"
+     - Skip to step 4
+
+3. **Execute Get Issue Operation**:
+
+   Based on the `issueTrackingProvider` value from the state management file:
+
+   ### For Linear Provider (`"linear"`)
+
+   - Use `linear:get_issue` with $1 (issue key)
+   - Retrieve issue key, ID, title, and description
+
+   ### For Jira Provider (`"jira"`)
+
+   - Use `jira:get_issue` with $1 (issue key)
+   - Retrieve issue key, ID, title, and description
+
+4. **Output Results**: Display the issue information in this format:
+   - **Key**: $1
+   - **ID**: Issue ID
+   - **Title**: Issue title
+   - **Description**: Issue description
+
+5. **Error Handling**: If the issue operation fails, log the error but continue gracefully

commands/issue/read-issue.md

@@ -0,0 +1,28 @@
+---
+name: read-issue
+description: Fetch issue details from tracking system
+argument-hint: [issue-key] [state-management-file-path]
+model: claude-haiku-4-5
+---
+
+# Read Issue Command
+
+## Purpose
+
+Read issue from the configured issue tracking system and add the information to the state management file.
+These instructions are read and followed as part of a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Workflow Steps
+
+1. Get issue details:
+   - Use the SlashCommand tool to execute `/get-issue $1 $2`
+
+2. Note findings in the state management file ($2)
+
+Create a new section called `## Issue Information`, with information on this format:
+
+- **Key**: $1
+- **ID**: Issue ID (from get-issue response)
+- **Title**: Issue title (from get-issue response)
+- **Description**: Issue description (from get-issue response)

commands/issue/update-issue.md

@@ -0,0 +1,68 @@
+---
+name: update-issue
+description: Update issue status in tracking system
+argument-hint: [issue-key] [status] [state-management-file-path]
+model: claude-haiku-4-5
+allowed-tools: Read, Bash(echo:*)
+---
+
+# Update Issue Command
+
+## Purpose
+
+Update the status of an issue in the configured issue tracking system.
+This command is called by other orchestrating commands, and is one of the steps in a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+Expected status values: "In Progress", "Code Review"
+
+## Arguments
+
+- `$1`: Issue key (required)
+- `$2`: Status to set (required)
+- `$3`: Path to state management file (required)
+
+## Workflow Steps
+
+1. **Read Settings from State Management File**:
+   - Read the Settings section from the state management file ($3)
+   - Extract `issueTrackingProvider` and `silentMode` values
+   - If Settings section is missing, fail with error: "Settings not found in state management file. Run /read-settings first."
+
+2. **Validate Provider Configuration**:
+   - If issueTrackingProvider is "linear":
+     - Check that Linear MCP tools are available
+     - If NOT available: **FAIL with error**: "Provider is 'linear' but Linear MCP tools are not configured. Please configure Linear MCP or update settings with /read-settings --provider=prompt"
+   - If issueTrackingProvider is "jira":
+     - Check that Jira MCP tools are available
+     - If NOT available: **FAIL with error**: "Provider is 'jira' but Jira MCP tools are not configured. Please configure Jira MCP or update settings with /read-settings --provider=prompt"
+
+3. **Check Silent Mode or Prompt Issue Provider**:
+   - If silentMode is true OR issueTrackingProvider is "prompt":
+     - Log the status update operation locally: "Silent mode: Would have updated $1 status to '$2'"
+     - Skip the actual API calls (step 4)
+     - Continue to step 5
+
+4. **Execute Update Status Operation** (only if silentMode is false and issueTrackingProvider is not "prompt"):
+
+### For Linear Provider (`"linear"`)
+
+- First, use `linear:list_issue_statuses` to get all available statuses for $1
+- Find the best match for $2 (handles typos/variations)
+- Use `linear:update_issue` with $1 to set the issue to the matched status
+- If no exact match is found, use the closest matching status name
+
+### For Jira Provider (`"jira"`)
+
+- First, use `jira:get_transitions_for_issue` with $1 to get all available columns
+- Find the best match for $2 (handles typos/variations)
+- Use `jira:transition_issue` with $1 to move the issue to the matched transition
+- If no exact match is found, use the closest matching status name
+
+5. **Output Results**: Display confirmation of the status update:
+   - **Issue**: $1
+   - **Previous Status**: [if available]
+   - **New Status**: $2
+   - **Result**: Success/Failure (or "Skipped - Silent Mode" if applicable)
+
+6. **Error Handling**: If the issue operation fails, log the error but continue gracefully

commands/read-settings.md

@@ -0,0 +1,70 @@
+---
+name: read-settings
+description: Read settings and add to state management file
+argument-hint: [state-management-file-path] [--provider=<linear|jira|prompt>] [--silent=<true|false>]
+model: claude-haiku-4-5
+allowed-tools: Read, Edit, Bash(git symbolic-ref:*), Bash(git rev-parse:*)
+---
+
+# Read Settings Command
+
+## Purpose
+
+Read Claude Constructor settings and add them to the state management file.
+Settings are determined by command arguments or auto-detection.
+These instructions are read and followed as part of a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Arguments
+
+- `$1`: Path to state management file (required)
+- `$2+`: Optional settings in format `--provider=<value>` or `--silent=<value>`
+
+## Workflow Steps
+
+1. Parse optional arguments ($2, $3, etc.) to extract settings overrides:
+   - Look for `--provider=<value>` (valid: "linear", "jira", "prompt")
+   - Look for `--silent=<value>` (valid: "true", "false")
+
+2. Determine settings in this priority order:
+
+   **Issue Tracking Provider:**
+   - If `--provider=<value>` argument provided:
+     - Validate it's one of: "linear", "jira", "prompt"
+     - If "linear": Check that Linear MCP tools are available (try calling `linear:list_teams` or similar)
+       - If NOT available: **FAIL with error**: "Provider set to 'linear' but Linear MCP tools are not configured. Please configure Linear MCP or use --provider=prompt"
+     - If "jira": Check that Jira MCP tools are available (try calling `jira:get_projects` or similar)
+       - If NOT available: **FAIL with error**: "Provider set to 'jira' but Jira MCP tools are not configured. Please configure Jira MCP or use --provider=prompt"
+     - If "prompt": No validation needed
+     - Use the validated provider value
+   - Otherwise, auto-detect:
+     - If Linear MCP tools are available → "linear"
+     - If Jira MCP tools are available → "jira"
+     - Otherwise → "prompt"
+
+   **Default Branch:**
+   - Auto-detect by running: `git symbolic-ref refs/remotes/origin/HEAD --short`
+   - Parse the output to extract the branch name after "origin/" (e.g., "origin/main" → "main")
+   - If that fails, try: `git rev-parse --abbrev-ref origin/HEAD` and parse similarly
+   - If both fail, default to "main"
+
+   **Silent Mode:**
+   - If `--silent=<value>` argument provided, use it
+   - Otherwise, default to "false"
+
+3. Read the state management file ($1) to check if Settings section already exists
+
+4. If Settings section exists:
+   - Update the existing Settings section with the determined values
+   - Use Edit tool to replace the Settings section
+
+5. If Settings section does not exist:
+   - Add a new Settings section to the state management file using Edit tool
+   - Format:
+
+     ```markdown
+     ## Settings
+     - issueTrackingProvider: [value]
+     - defaultBranch: [value]
+     - silentMode: [value]
+     ```

commands/requirements-sign-off.md

@@ -0,0 +1,35 @@
+---
+name: requirements-sign-off
+description: Get user approval on requirements
+argument-hint: [state-management-file-path]
+model: claude-haiku-4-5
+---
+
+# Requirements Sign-Off Command
+
+## Purpose
+
+Get sign-off on the requirements for the increment to be implemented.
+These instructions are read and followed as part of a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Workflow Steps
+
+1. **Read State Management File**:
+   - Read the state management file (path in $1)
+   - Locate the specification file path
+   - Present the Requirements Definition section to the user for review
+
+2. **Get User Feedback**:
+   - Ask the user to read and provide feedback on the Requirements Definition
+   - If user has feedback:
+     a. Use the requirements-definer subagent to revise requirements:
+
+        ```text
+        State management file: $1
+        User feedback to address: [user's feedback verbatim]
+        ```
+
+     b. The subagent will detect the feedback and revise accordingly
+     c. Return to step 1 for re-review
+   - If user provides explicit sign-off, requirements sign-off is complete

commands/review-pull-request.md

@@ -0,0 +1,43 @@
+---
+name: review-pull-request
+description: Monitor and respond to PR feedback
+argument-hint: [issue-key] [state-management-file-path]
+model: claude-sonnet-4-5
+---
+
+# Review Pull Request Command
+
+## Purpose
+
+Review pull request for the increment implemented to satisfy the issue.
+This command is called by an orchestrating command, and is one of the steps in a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Workflow Steps
+
+1. **Load Settings**: Read the Settings section in the state management file ($2)
+
+2. **Check Silent Mode**:
+   - If `silentMode` is `true`:
+     - Log: "Silent mode: Skipping PR review monitoring and comments"
+     - Skip to step 7
+   - If `silentMode` is `false`:
+     - Continue with normal PR review workflow (steps 3-6)
+
+3. Monitor the pull request for comments and/or reviews. Use `gh api repos/{OWNER}/{REPO}/pulls/{PR_NUMBER}/comments --jq '.[] | {author: .user.login, body: .body, path: .path, line: .line}'`
+
+4. For each unaddressed comment:
+    - Implement the requested changes
+    - Commit and push changes. Read @docs/git-commit.md for commit guidelines. Check that there are not unstaged changes you haven't considered.
+
+5. Add a reply to each addressed comment explaining how the requested changes were addressed (or if it was a question, your response to the question): `gh api repos/{OWNER}/{REPO}/pulls/{PR_NUMBER}/comments --method POST --field body="Your message here" --field in_reply_to={COMMENT_ID_NUMBER}`
+    - Do not edit existing comments
+    - Reply to specific comments, do not make general PR comments
+
+6. Repeat steps 3 through 5 until the user approves the pull request. You are not allowed to approve the pull request yourself.
+
+7. **Add pull request feedback comment** (only if silent mode and not prompt):
+   - If `silentMode` is `false` AND `issueTrackingProvider` is NOT `"prompt"`:
+     - Use the SlashCommand tool to execute `/create-comment $1 "[user feedback summary and changes made in response]" $2`
+   - If `silentMode` is `true` OR `issueTrackingProvider` is `"prompt"`:
+     - Log: "Silent mode: Would have added PR feedback comment to issue"

commands/specification-sign-off.md

@@ -0,0 +1,40 @@
+---
+name: specification-sign-off
+description: Get user approval on implementation plan
+argument-hint: [state-management-file-path]
+model: claude-haiku-4-5
+---
+
+# Specification Sign-Off Command
+
+## Purpose
+
+Get sign-off on the specification for the increment to be implemented.
+These instructions are read and followed as part of a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Workflow Steps
+
+1. **Read State Management File**:
+   - Read the state management file (path in $1)
+   - Locate the specification file path
+   - Present the Implementation Plan section to the user for review
+
+2. **Get User Feedback**:
+   - Ask the user to read and provide feedback on the Implementation Plan
+   - If user has feedback:
+     a. Use the specification-writer subagent to revise specification:
+
+        ```text
+        State management file: $1
+        User feedback to address: [user's feedback verbatim]
+        ```
+
+     b. The subagent will detect the feedback and revise accordingly
+     c. Return to step 1 for re-review
+   - If user provides explicit sign-off, proceed to step 3
+
+3. **Add Issue Comment**:
+   - Did you get explicit approval on the specification? If not, go back to step 2.
+   - Read the state management file to get the issue key
+   - Use the SlashCommand tool to execute `/create-comment [issue-key] "[specification details and assumptions]"`

commands/write-end-to-end-tests.md

@@ -0,0 +1,31 @@
+---
+name: write-end-to-end-tests
+description: Write E2E tests for implemented increment
+argument-hint: [state-management-file-path]
+model: claude-sonnet-4-5
+---
+
+# Write End-To-End Tests for Increment Command
+
+## Purpose
+
+Write end-to-end tests for the implemented increment using the specification linked in the state management file ($1).
+This command is called by an orchestrating command, and is one of the steps in a larger workflow.
+You MUST follow all workflow steps below, not skipping any step and doing all steps in order.
+
+## Workflow Steps
+
+1. Understand how the increment has been implemented, and the context surrounding it:
+    - Read specification to learn the business value that the increment is delivering, and what the plan for implementing that value is
+    - Read the code implemented, using git to identify what has been added
+
+2. Write a plan for how to test the necessary behavior
+
+3. Write end-to-end tests that cover your plan
+
+## This part of the workflow is done when
+
+- [ ] Frontend behavior is verified using end-to-end tests
+- [ ] All unit, integration, and end-to-end tests pass (100% coverage of user behavior expected)
+- [ ] All quality gates pass (see @CLAUDE.md for commands)
+- [ ] No test failures introduced in areas of the code unrelated to this increment