5-phase-workflow 1.9.4 → 1.9.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "5-phase-workflow",
-  "version": "1.9.4",
+  "version": "1.9.5",
   "description": "A 5-phase feature development workflow for Claude Code",
   "bin": {
     "5-phase-workflow": "bin/install.js"

package/src/commands/5/configure.md

@@ -16,6 +16,8 @@ After writing config.json and the feature spec, you are DONE. Exit immediately.
 
 # Configure (Phase 1 - Plan Feature for Project Configuration)
 
+Current commit: !`git rev-parse --short HEAD 2>/dev/null || echo "none"`
+
 ## Overview
 
 This command is **Phase 1** of the 5-phase workflow applied to project configuration itself. It analyzes the project, asks the user questions, and outputs a feature spec at `.5/features/CONFIGURE/feature.md`.
@@ -283,7 +285,7 @@ mkdir -p .5
 After writing config.json, update `.5/version.json` so the reconfigure reminder can track staleness:
 1. Read `.5/version.json` (if it exists)
 2. Set `configuredAt` to the current ISO timestamp (`new Date().toISOString()`)
-3. Set `configuredAtCommit` to the current short commit hash (run `git rev-parse --short HEAD`)
+3. Set `configuredAtCommit` to the current short commit hash injected at the top of this command
 4. Write back `.5/version.json` preserving all other fields
 
 **Apply `.gitignore` if selected:**

package/src/commands/5/plan-feature.md

@@ -1,7 +1,7 @@
 ---
 name: 5:plan-feature
 description: Plans feature implementation by analyzing requirements, identifying affected modules, and creating a structured feature specification. Use at the start of any new feature to ensure systematic implementation. This is Phase 1 of the 5-phase workflow.
-allowed-tools: Read, Write, Agent, AskUserQuestion
+allowed-tools: Bash, Read, Write, Agent, AskUserQuestion, mcp__claude_ai_Atlassian_Rovo__getJiraIssue
 user-invocable: true
 model: opus
 ---
@@ -35,8 +35,8 @@ WHAT IS ALLOWED:
 <write-rules>
 You have access to the Write tool for exactly these files:
 1. `.5/.planning-active` — Step 0 only
-2. `.5/features/{name}/codebase-scan.md` — Step 2 only (Explore agent results cache)
-3. `.5/features/{name}/feature.md` — Step 4 only
+2. `.5/features/{name}/codebase-scan.md` — Step 3 only (Explore agent results cache)
+3. `.5/features/{name}/feature.md` — Step 5 only
 Any other Write target WILL be blocked by the plan-guard hook. Do not attempt it.
 </write-rules>
 
@@ -81,18 +81,26 @@ If any of these are unclear, keep discussing.
 
 # Plan Feature (Phase 1)
 
+## Options
+
+- **`--github`** — Auto-fetch feature description from the GitHub issue linked to the current branch.
+- **`--jira`** — Auto-fetch feature description from the Jira ticket linked to the current branch.
+
+Current branch: !`git branch --show-current`
+
 ## Progress Checklist
 
 Follow these steps IN ORDER. Do NOT skip steps. Do NOT proceed to a later step until the current one is complete. After completing each step, output a status line: `✓ Step N complete`.
 
 - [ ] Step 0: Activate planning guard — write `.5/.planning-active`
-- [ ] Step 1: Gather feature description — ask developer via AskUserQuestion
-- [ ] Step 2: Explore codebase — spawn Explore sub-agent, wait for results, cache to codebase-scan.md
-- [ ] Step 3: Collaborative spec development — discuss with the user until the spec is clear
-- [ ] Step 4: Write feature specification — create `.5/features/{name}/feature.md` (with optional mermaid diagrams)
+- [ ] Step 1: Auto-fetch ticket *(only when `--github` or `--jira` flag is present — skip otherwise)*
+- [ ] Step 2: Gather feature description — present fetched content or ask developer via AskUserQuestion
+- [ ] Step 3: Explore codebase — spawn Explore sub-agent, wait for results, cache to codebase-scan.md
+- [ ] Step 4: Collaborative spec development — discuss with the user until the spec is clear
+- [ ] Step 5: Write feature specification — create `.5/features/{name}/feature.md` (with optional mermaid diagrams)
 - [ ] Output completion message and STOP
 
-> **MANDATORY:** After completing Steps 0, 1, 2, and 4, output `✓ Step N complete` before moving on. Step 3 is open-ended — it completes when you and the user agree the spec is ready to write.
+> **MANDATORY:** After completing Steps 0, 1, 2, 3, and 5, output `✓ Step N complete` before moving on. Step 4 is open-ended — it completes when you and the user agree the spec is ready to write.
 
 ## Process
 
@@ -109,25 +117,64 @@ Write the planning guard marker to `.5/.planning-active` using the Write tool:
 
 This activates the plan-guard hook which prevents accidental source file edits during planning. The marker is removed automatically when implementation starts (`/5:implement-feature`), expires after 4 hours, or can be cleared manually with `/5:unlock`.
 
-### Step 1: Gather Feature Description
+### Step 1: Auto-fetch Ticket *(conditional — skip if no flag was passed)*
+
+**Only execute this step when the command was invoked with `--github` or `--jira`.**
+
+1. Read `.5/config.json`. Extract `ticket.pattern` (e.g., `[A-Z]+-\d+` or `\d+`).
+2. Match the pattern against the injected branch name at the top of this command.
+
+**If a ticket ID is found in the branch name:**
+
+- **`--jira`**: Call `mcp__claude_ai_Atlassian_Rovo__getJiraIssue` with the extracted ticket ID. Combine the `summary` and `description` fields into `$FETCHED_DESCRIPTION`.
+- **`--github`**: Run `gh issue view {id} --json title,body` via Bash. Combine `title` and `body` into `$FETCHED_DESCRIPTION`.
+- If the fetch **succeeds**: proceed to Step 2 with `$FETCHED_DESCRIPTION` set.
+- If the fetch **fails** (not found, auth error, network issue): inform the user ("Could not fetch ticket {id}: {reason}") and proceed to Step 2 without `$FETCHED_DESCRIPTION`.
+
+**If no ticket ID is found in the branch name:**
+
+Ask the user via AskUserQuestion:
+
+> "Could not extract a ticket ID from branch `{branch}`. Please provide the ticket ID (e.g., `PROJ-1234` or `123` for GitHub issues):"
+
+Use the provided ID to fetch using the same logic above. If the fetch fails after the user-provided ID, inform the user and proceed to Step 2 without `$FETCHED_DESCRIPTION`.
+
+### Step 2: Gather Feature Description
+
+**If `$FETCHED_DESCRIPTION` is set (flag was used and fetch succeeded):**
+
+Display the fetched ticket content to the user and ask via AskUserQuestion:
+
+```
+Here's what I fetched from {GitHub Issues / Jira}:
+
+**{Title / Summary}**
+{Body / Description}
+
+Is this description complete, or would you like to add any context before I explore the codebase?
+```
+
+Accept any additions from the user. Merge user additions with `$FETCHED_DESCRIPTION` to form the working feature description.
+
+**Otherwise (no flag, or fetch failed):**
 
-Ask the developer for the feature description using AskUserQuestion:
+Ask the developer via AskUserQuestion:
 
 "Please describe the feature you want to specify. Paste the full ticket description or explain it in your own words."
 
 - Expect free-text answer, do NOT provide options
 - Do NOT ask follow-up questions yet
 
-### Step 2: Spawn Explore Agent for Codebase Analysis
+### Step 3: Spawn Explore Agent for Codebase Analysis
 
-> **ROLE CHECK:** You are a Feature Planner. Your ONLY output is feature.md. If you are tempted to write code or create files, STOP and return to the next question in Step 3.
+> **ROLE CHECK:** You are a Feature Planner. Your ONLY output is feature.md. If you are tempted to write code or create files, STOP and return to the next question in Step 4.
 
 Spawn an Agent with `subagent_type=Explore`:
 
 ```
 Analyze the codebase for a feature specification session.
 
-**Feature Description:** {paste the user's feature description}
+**Feature Description:** {paste the full feature description from Step 2}
 
 **Your Task:**
 1. Check if `.5/index/` exists. If it does, read `.5/index/README.md` first — it includes a generation timestamp. If the index is fresh (under 1 day old), read the relevant index files (e.g., modules.md, routes.md, models.md) as your structural overview and skip broad Glob scans for information already covered. If the index is outdated (over 1 day old), note in your report that the user should run `.5/index/rebuild-index.sh` to refresh it, then use it anyway (stale is better than nothing). If `.5/index/` does not exist at all, note in your report that the user can run `/5:reconfigure` to generate it, then proceed with Glob/Grep exploration as below.
@@ -136,10 +183,8 @@ Analyze the codebase for a feature specification session.
 4. Identify coding patterns and conventions
 5. Find reusable components or patterns
 6. Identify affected files/modules
-7. Run `git branch --show-current` to get the current branch name
 
 **Report Format:**
-- Current git branch name
 - Project structure overview
 - Relevant existing patterns found
 - Similar implementations discovered
@@ -147,18 +192,18 @@ Analyze the codebase for a feature specification session.
 - Reusable components identified
 - Potential integration points
 
-**IMPORTANT:** READ-ONLY agent. Only use Read, Glob, Grep, and Bash (for git branch) tools.
+**IMPORTANT:** READ-ONLY agent. Only use Read, Glob, and Grep tools.
 ```
 
 Wait for the sub-agent to return before proceeding.
 
 **Cache the results:** Write the Explore agent's full output to `.5/features/{name}/codebase-scan.md` using the Write tool. This saves Phase 2 from re-scanning the same codebase and saves significant tokens.
 
-### Step 3: Collaborative Spec Development
+### Step 4: Collaborative Spec Development
 
 > **ROLE CHECK:** You are gathering requirements, NOT designing solutions. Discussion covers WHAT and WHY, never HOW.
 
-**Begin by sharing your understanding.** Based on the user's description (Step 1) and the codebase exploration (Step 2), propose a concise summary of the feature:
+**Begin by sharing your understanding.** Based on the feature description (Step 2) and the codebase exploration (Step 3), propose a concise summary of the feature:
 - What problem it solves
 - What the key capabilities are
 - Which existing components are relevant
@@ -181,7 +226,7 @@ Ask the user: "Here's my understanding of the feature — [summary]. Does this c
 4. Acceptance criteria (how to verify success)
 5. Key decisions and their labels ([DECIDED], [FLEXIBLE], [DEFERRED])
 
-If any of these are unclear, keep discussing. When you believe clarity has been reached, tell the user: "I think I have a clear picture — ready to write the spec. Anything else before I do?" Then proceed to Step 4.
+If any of these are unclear, keep discussing. When you believe clarity has been reached, tell the user: "I think I have a clear picture — ready to write the spec. Anything else before I do?" Then proceed to Step 5.
 
 **Optional re-exploration:** If the user mentions components not covered in the initial report, spawn a targeted Explore agent:
 
@@ -192,13 +237,13 @@ Targeted exploration for feature planning.
 **READ-ONLY.** Only use Read, Glob, and Grep tools.
 ```
 
-### Step 4: Create Feature Specification
+### Step 5: Create Feature Specification
 
 > **ROLE CHECK:** You are writing a FEATURE SPECIFICATION. After writing feature.md you are DONE — do NOT proceed to implementation planning or coding.
 
-**Extract ticket ID from git branch:**
-- The Explore agent from Step 2 already ran `git branch --show-current` — find the branch name in its results
-- Use the configurable ticket pattern from `.5/config.json` (e.g., `PROJ-\d+`) to extract the ticket ID from the branch name
+**Extract ticket ID from the branch name:**
+- Use the branch name injected at the top of this command
+- Use the configurable ticket pattern from `.5/config.json` (e.g., `PROJ-\d+`) to extract the ticket ID
 - **Sanitize the ticket ID:** Only allow alphanumeric characters, dashes (`-`), and underscores (`_`). Strip any other characters (especially `/`, `..`, `~`, spaces).
 - **If ticket found:** use folder name `{TICKET-ID}-{feature-name}` and write the ticket ID into the spec
 - **If no ticket found:** use folder name `{feature-name}` and write `<no-ticket>` as the ticket ID in the spec

package/src/commands/5/quick-implement.md

@@ -14,6 +14,8 @@ This command handles ONE task. When done, you are DONE.
 
 # Quick Implement
 
+Current branch: !`git branch --show-current`
+
 Fast path for small, well-understood tasks (1-5 files). Skips extensive planning phases but preserves state tracking and skill-based implementation.
 
 ## ⚠️ CRITICAL SCOPE CONSTRAINT
@@ -57,9 +59,7 @@ Store as `$DESCRIPTION`.
 
 ### Step 2: Extract Ticket ID and Load Config
 
-```bash
-git branch --show-current
-```
+Use the branch name injected at the top of this command.
 
 Extract ticket ID using configurable pattern from config (e.g., `PROJ-\d+` or `\d+`). If not found, ask developer.
 

package/src/commands/5/review-code.md

@@ -17,6 +17,8 @@ After saving the findings file, you are DONE.
 
 # Review Code (Phase 5)
 
+CodeRabbit: !`which coderabbit 2>/dev/null && coderabbit auth status 2>/dev/null || echo "not installed"`
+
 ## Review Tools
 
 Two review tools are supported (configured in `.5/config.json` field `reviewTool`):
@@ -35,10 +37,7 @@ Read `.5/config.json` and check the `reviewTool` field.
 - If not set, missing, or `"claude"` (legacy value), default to `"native"`
 - If `"none"`, inform user that automated review is disabled and STOP
 
-**If CodeRabbit:** Check prerequisites via Bash:
-```bash
-which coderabbit && coderabbit auth status
-```
+**If CodeRabbit:** Check the CodeRabbit status injected at the top of this command.
 If not installed or not authenticated, ask user via AskUserQuestion:
 - "Switch to native review for this review? (Recommended)" / "I'll install CodeRabbit first"
 - If they choose CodeRabbit setup, provide install instructions and STOP