@zeyue0329/xiaoma-cli 1.7.0 → 1.8.0

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-07-fix-and-retest.md

@@ -46,10 +46,12 @@ Adopt the Dev persona:
 ### 2. Analyze Failure Context
 
 1. Read the COMPLETE story file at `{current_story_path}`
-2. Identify the source of failures:
-   - Code review findings (from step-05): Check Dev Agent Record for review issues
-   - QA test failures (from step-06): Check QA Results section for test failures
-3. Compile a prioritized fix list:
+2. Identify the source of failures and set `{fix_source}`:
+   - Code review findings (from step-05): Check Dev Agent Record for review issues → `{fix_source}` = "code-review"
+   - QA test failures (from step-06): Check QA Results section for test failures → `{fix_source}` = "qa-testing"
+   - Mixed (both code review and QA issues): → `{fix_source}` = "mixed"
+3. Record `{fix_source}` — this determines post-fix routing (see section 6)
+4. Compile a prioritized fix list:
    - **Priority 1:** HIGH severity issues / failed acceptance criteria
    - **Priority 2:** MEDIUM severity issues / partial AC failures
    - **Priority 3:** LOW severity issues (fix if time permits)
@@ -86,8 +88,10 @@ After all fixes are applied:
 ### 6. Evaluate Fix Results
 
 **IF all tests pass AND all previously failed ACs now pass:**
-- Output: "All issues resolved in fix iteration {fix_iteration}. Tests passing. Proceeding to completion."
-- **NEXT:** Proceed to step-08 (complete story)
+- Output: "All issues resolved in fix iteration {fix_iteration}. Tests passing."
+- Determine routing based on `{fix_source}`:
+  - **IF `{fix_source}` == "code-review" or "mixed":** Run a targeted code re-check: re-verify that the specific code-review HIGH/MEDIUM issues are genuinely resolved (no full re-delegation required — do a focused inline verification of the fixed areas). If verified clean: **NEXT:** Proceed to step-08 (complete story). If new issues surface: Loop back to step-07.
+  - **IF `{fix_source}` == "qa-testing":** **NEXT:** Proceed to step-08 (complete story) directly — no additional code review needed.
 
 **IF some issues remain:**
 - Output: "Fix iteration {fix_iteration} resolved {fixed_count} issues. {remaining_count} issues remain: {remaining_list}"
@@ -97,9 +101,12 @@ After all fixes are applied:
 
 ## NEXT STEP
 
-**If all issues resolved:**
+**If all issues resolved AND (`{fix_source}` == "qa-testing" OR post-fix code re-check passed):**
 **NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-08-complete-story.md`
 
+**If all issues resolved but post-fix code re-check surfaced new issues (`{fix_source}` was "code-review" or "mixed"):**
+**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-07-fix-and-retest.md`
+
 **If issues remain and `{fix_iteration}` <= `{max_fix_iterations}`:**
 **NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-07-fix-and-retest.md`
 

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-09-cycle-check.md

@@ -46,7 +46,16 @@ nextStepFile: null
 
 **3.5. Batch Mode Progress Checkpoint**
 
-Before looping back to step-02 for the next story, output a progress summary:
+Before looping back to step-02 for the next story, refresh sprint status counts and output a progress summary:
+
+1. Reload the FULL file: `{sprint_status}` (status counts are stale since step-01 initialization)
+2. Recount all stories by current status:
+   - Update `{backlog_count}` — Stories with status "backlog"
+   - Update `{ready_count}` — Stories with status "ready-for-dev"
+   - Update `{in_progress_count}` — Stories with status "in-progress"
+   - Update `{review_count}` — Stories with status "review"
+   - Update `{done_count}` — Stories with status "done"
+3. Output progress summary:
 
 ```
 ═══════════════════════════════════════════════════
@@ -54,7 +63,7 @@ Before looping back to step-02 for the next story, output a progress summary:
 ═══════════════════════════════════════════════════
 - Stories Completed So Far: {stories_completed}
 - Starting Next Story: {current_story_key} (status: {found_status})
-- Sprint Status: Backlog {backlog_count} | Ready {ready_count} | In Progress {in_progress_count} | Review {review_count} | Done {done_count}
+- Sprint Status (refreshed): Backlog {backlog_count} | Ready {ready_count} | In Progress {in_progress_count} | Review {review_count} | Done {done_count}
 - Pipeline Continuing...
 ═══════════════════════════════════════════════════
 ```

package/src/xmc/workflows/4-implementation/auto-story-pipeline/workflow.md

@@ -35,16 +35,17 @@ This uses **step-file architecture** for focused execution across a long-running
 - `{pipeline_mode}` — "single" (one story) or "batch" (all backlog stories)
 - `{current_story_key}` — Key of story being processed (e.g., "1-2-user-auth")
 - `{current_story_path}` — Full path to current story file (derived in step-01 after resolving `{current_story_key}`; re-set in step-02 skip branch for batch cycles)
-- `{fix_iteration}` — Bug fix loop counter (max 5)
+- `{fix_iteration}` — Bug fix loop counter (max controlled by `{max_fix_iterations}`, default 5; reset per story)
+- `{max_fix_iterations}` — Maximum fix-and-retest cycles per story (configurable via `max_fix_iterations` in config.yaml; default 5 if not set)
 - `{stories_completed}` — Count of stories completed in this pipeline run
 - `{pipeline_status}` — Current pipeline phase for tracking
-- `{validation_attempt}` — Story validation attempt counter (used in step-03, max 3)
-- `{steps_completed}` — Count of pipeline step files executed in this run (initialized to 0 in step-01)
-- `{backlog_count}` — Count of stories with status "backlog" (initialized in step-01)
-- `{ready_count}` — Count of stories with status "ready-for-dev" (initialized in step-01)
-- `{in_progress_count}` — Count of stories with status "in-progress" (initialized in step-01)
-- `{review_count}` — Count of stories with status "review" (initialized in step-01)
-- `{done_count}` — Count of stories with status "done" (initialized in step-01)
+- `{validation_attempt}` — Story validation attempt counter (used in step-03, max 3; re-initialized at start of step-03 for each story)
+- `{steps_completed}` — Count of pipeline step files executed in this run (initialized to 0 in step-01; accumulates across all stories in batch mode)
+- `{backlog_count}` — Count of stories with status "backlog" (initialized in step-01; refreshed in step-09 batch checkpoints and final finalization)
+- `{ready_count}` — Count of stories with status "ready-for-dev" (initialized in step-01; refreshed in step-09)
+- `{in_progress_count}` — Count of stories with status "in-progress" (initialized in step-01; refreshed in step-09)
+- `{review_count}` — Count of stories with status "review" (initialized in step-01; refreshed in step-09)
+- `{done_count}` — Count of stories with status "done" (initialized in step-01; refreshed in step-09)
 
 ### Status Machine
 

package/src/xmc/workflows/4-implementation/xiaoma-code-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: xiaoma-code-review
-description: 'Perform adversarial code review finding specific issues. Use when the user says "run code review" or "review this code"'
+description: 'Review code changes adversarially using parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor) with structured triage into actionable categories. Use when the user says "run code review" or "review this code"'
 ---
 
-Follow the instructions in [workflow.md](workflow.md).
+Follow the instructions in ./workflow.md.

package/src/xmc/workflows/4-implementation/xiaoma-code-review/steps/step-01-gather-context.md

@@ -0,0 +1,61 @@
+---
+diff_output: '' # set at runtime
+spec_file: '' # set at runtime (path or empty)
+review_mode: '' # set at runtime: "full" or "no-spec"
+---
+
+# Step 1: Gather Context
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- The prompt that triggered this workflow IS the intent — not a hint.
+- Do not modify any files. This step is read-only.
+
+## INSTRUCTIONS
+
+1. **Detect review intent from invocation text.** Check the triggering prompt for phrases that map to a review mode:
+   - "staged" / "staged changes" → Staged changes only
+   - "uncommitted" / "working tree" / "all changes" → Uncommitted changes (staged + unstaged)
+   - "branch diff" / "vs main" / "against main" / "compared to {branch}" → Branch diff (extract base branch if mentioned)
+   - "commit range" / "last N commits" / "{sha}..{sha}" → Specific commit range
+   - "this diff" / "provided diff" / "paste" → User-provided diff (do not match bare "diff" — it appears in other modes)
+   - When multiple phrases match, prefer the most specific match (e.g., "branch diff" over bare "diff").
+   - **If a clear match is found:** Announce the detected mode (e.g., "Detected intent: review staged changes only") and proceed directly to constructing `{diff_output}` using the corresponding sub-case from instruction 3. Skip to instruction 4 (spec question).
+   - **If no match from invocation text, check sprint tracking.** Look for a sprint status file (`*sprint-status*`) in `{implementation_artifacts}` or `{planning_artifacts}`. If found, scan for any story with status `review`. Handle as follows:
+     - **Exactly one `review` story:** Suggest it: "I found story {{story-id}} in `review` status. Would you like to review its changes? [Y] Yes / [N] No, let me choose". If confirmed, use the story context to determine the diff source (branch name derived from story slug, or uncommitted changes). If declined, fall through to instruction 2.
+     - **Multiple `review` stories:** Present them as numbered options alongside a manual choice option. Wait for user selection. Then use the selected story's context to determine the diff source as in the single-story case above, and proceed to instruction 3.
+   - **If no match and no sprint tracking:** Fall through to instruction 2.
+
+2. HALT. Ask the user: **What do you want to review?** Present these options:
+   - **Uncommitted changes** (staged + unstaged)
+   - **Staged changes only**
+   - **Branch diff** vs a base branch (ask which base branch)
+   - **Specific commit range** (ask for the range)
+   - **Provided diff or file list** (user pastes or provides a path)
+
+3. Construct `{diff_output}` from the chosen source.
+   - For **branch diff**: verify the base branch exists before running `git diff`. If it does not exist, HALT and ask the user for a valid branch.
+   - For **commit range**: verify the range resolves. If it does not, HALT and ask the user for a valid range.
+   - For **provided diff**: validate the content is non-empty and parseable as a unified diff. If it is not parseable, HALT and ask the user to provide a valid diff.
+   - For **file list**: validate each path exists in the working tree. Construct `{diff_output}` by running `git diff HEAD -- <path1> <path2> ...`. If any paths are untracked (new files not yet staged), use `git diff --no-index /dev/null <path>` to include them. If the diff is empty (files have no uncommitted changes and are not untracked), ask the user whether to review the full file contents or to specify a different baseline.
+   - After constructing `{diff_output}`, verify it is non-empty regardless of source type. If empty, HALT and tell the user there is nothing to review.
+
+4. Ask the user: **Is there a spec or story file that provides context for these changes?**
+   - If yes: set `{spec_file}` to the path provided, verify the file exists and is readable, then set `{review_mode}` = `"full"`.
+   - If no: set `{review_mode}` = `"no-spec"`.
+
+5. If `{review_mode}` = `"full"` and the file at `{spec_file}` has a `context` field in its frontmatter listing additional docs, load each referenced document. Warn the user about any docs that cannot be found.
+
+6. Sanity check: if `{diff_output}` exceeds approximately 3000 lines, warn the user and offer to chunk the review by file group.
+   - If the user opts to chunk: agree on the first group, narrow `{diff_output}` accordingly, and list the remaining groups for the user to note for follow-up runs.
+   - If the user declines: proceed as-is with the full diff.
+
+### CHECKPOINT
+
+Present a summary before proceeding: diff stats (files changed, lines added/removed), `{review_mode}`, and loaded spec/context docs (if any). HALT and wait for user confirmation to proceed.
+
+
+## NEXT
+
+Read fully and follow `./step-02-review.md`

package/src/xmc/workflows/4-implementation/xiaoma-code-review/steps/step-02-review.md

@@ -0,0 +1,41 @@
+---
+failed_layers: '' # set at runtime: comma-separated list of layers that failed or returned empty
+---
+
+# Step 2: Review
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- The Blind Hunter subagent receives NO project context — diff only.
+- The Edge Case Hunter subagent receives diff and project read access.
+- The Acceptance Auditor subagent receives diff, spec, and context docs.
+
+## INSTRUCTIONS
+
+1. Launch parallel subagents. Each subagent gets NO conversation history from this session:
+
+   - **Blind Hunter** -- Invoke the `xiaoma-review-adversarial-general` skill in a subagent. Pass `content` = `{diff_output}` only. No spec, no project access.
+
+   - **Edge Case Hunter** -- Invoke the `xiaoma-review-edge-case-hunter` skill in a subagent. Pass `content` = `{diff_output}`. This subagent has read access to the project.
+
+   - **Acceptance Auditor** (only if `{review_mode}` = `"full"`) -- A subagent that receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Its prompt:
+     > You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
+
+2. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
+
+3. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
+
+4. **Fallback** (if subagents are not available): Generate prompt files in `{implementation_artifacts}` -- one per active reviewer:
+   - `review-blind-hunter.md` (always)
+   - `review-edge-case-hunter.md` (always)
+   - `review-acceptance-auditor.md` (only if `{review_mode}` = `"full"`)
+
+   HALT. Tell the user to run each prompt in a separate session and paste back findings. When findings are pasted, resume from this point and proceed to step 3.
+
+5. Collect all findings from the completed layers.
+
+
+## NEXT
+
+Read fully and follow `./step-03-triage.md`

package/src/xmc/workflows/4-implementation/xiaoma-code-review/steps/step-03-triage.md

@@ -0,0 +1,50 @@
+---
+---
+
+# Step 3: Triage
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Be precise. When uncertain between categories, prefer the more conservative classification.
+
+## INSTRUCTIONS
+
+1. **Normalize** findings into a common format. Expected input formats:
+   - Adversarial (Blind Hunter): markdown list of descriptions
+   - Edge Case Hunter: JSON array with `location`, `trigger_condition`, `guard_snippet`, `potential_consequence` fields
+   - Acceptance Auditor: markdown list with title, AC/constraint reference, and evidence
+
+   If a layer's output does not match its expected format, attempt best-effort parsing. Note any parsing issues for the user.
+
+   Convert all to a unified list where each finding has:
+   - `id` -- sequential integer
+   - `source` -- `blind`, `edge`, `auditor`, or merged sources (e.g., `blind+edge`)
+   - `title` -- one-line summary
+   - `detail` -- full description
+   - `location` -- file and line reference (if available)
+
+2. **Deduplicate.** If two or more findings describe the same issue, merge them into one:
+   - Use the most specific finding as the base (prefer edge-case JSON with location over adversarial prose).
+   - Append any unique detail, reasoning, or location references from the other finding(s) into the surviving `detail` field.
+   - Set `source` to the merged sources (e.g., `blind+edge`).
+
+3. **Classify** each finding into exactly one bucket:
+   - **intent_gap** -- The spec/intent is incomplete; cannot resolve from existing information. Only possible if `{review_mode}` = `"full"`.
+   - **bad_spec** -- The spec should have prevented this; spec is wrong or ambiguous. Only possible if `{review_mode}` = `"full"`.
+   - **patch** -- Code issue that is trivially fixable without human input. Just needs a code change.
+   - **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
+   - **reject** -- Noise, false positive, or handled elsewhere.
+
+   If `{review_mode}` = `"no-spec"` and a finding would otherwise be `intent_gap` or `bad_spec`, reclassify it as `patch` (if code-fixable) or `defer` (if not).
+
+4. **Drop** all `reject` findings. Record the reject count for the summary.
+
+5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping rejects AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
+
+6. If zero findings remain after dropping rejects and no layers failed, note clean review.
+
+
+## NEXT
+
+Read fully and follow `./step-04-present.md`

package/src/xmc/workflows/4-implementation/xiaoma-code-review/steps/step-04-present.md

@@ -0,0 +1,38 @@
+---
+---
+
+# Step 4: Present
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Do NOT auto-fix anything. Present findings and let the user decide next steps.
+
+## INSTRUCTIONS
+
+1. Group remaining findings by category.
+
+2. Present to the user in this order (include a section only if findings exist in that category):
+
+   - **Intent Gaps**: "These findings suggest the captured intent is incomplete. Consider clarifying intent before proceeding."
+     - List each with title + detail.
+
+   - **Bad Spec**: "These findings suggest the spec should be amended. Consider regenerating or amending the spec with this context:"
+     - List each with title + detail + suggested spec amendment.
+
+   - **Patch**: "These are fixable code issues:"
+     - List each with title + detail + location (if available).
+
+   - **Defer**: "Pre-existing issues surfaced by this review (not caused by current changes):"
+     - List each with title + detail.
+
+3. Summary line: **X** intent_gap, **Y** bad_spec, **Z** patch, **W** defer findings. **R** findings rejected as noise.
+
+4. If clean review (zero findings across all layers after triage): state that N findings were raised but all were classified as noise, or that no findings were raised at all (as applicable).
+
+5. Offer the user next steps (recommendations, not automated actions):
+   - If `patch` findings exist: "These can be addressed in a follow-up implementation pass or manually."
+   - If `intent_gap` or `bad_spec` findings exist: "Consider running the planning workflow to clarify intent or amend the spec before continuing."
+   - If only `defer` findings remain: "No action needed for this change. Deferred items are noted for future attention."
+
+Workflow complete.

package/src/xmc/workflows/4-implementation/xiaoma-code-review/workflow.md

@@ -1,261 +1,54 @@
-# Code Review Workflow
-
-**Goal:** Perform adversarial code review finding specific issues.
-
-**Your Role:** Adversarial Code Reviewer.
-- YOU ARE AN ADVERSARIAL CODE REVIEWER - Find what's wrong or missing!
-- Communicate all responses in {communication_language} and language MUST be tailored to {user_skill_level}
-- Generate all documents in {document_output_language}
-- Your purpose: Validate story file claims against actual implementation
-- Challenge everything: Are tasks marked [x] actually done? Are ACs really implemented?
-- Be thorough and specific — find real issues, not manufactured ones. If the code is genuinely good after fixes, say so
-- Read EVERY file in the File List - verify implementation against story requirements
-- Tasks marked complete but not done = CRITICAL finding
-- Acceptance Criteria not implemented = HIGH severity finding
-- Do not review files that are not part of the application's source code. Always exclude the `_xiaoma/` and `_bmad-output/` folders from the review. Always exclude IDE and CLI configuration folders like `.cursor/` and `.windsurf/` and `.claude/`
-
 ---
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
-
-- `project_name`, `user_name`
-- `communication_language`, `document_output_language`
-- `user_skill_level`
-- `planning_artifacts`, `implementation_artifacts`
-- `date` as system-generated current datetime
-
-### Paths
-
-- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
-
-### Input Files
-
-| Input | Description | Path Pattern(s) | Load Strategy |
-|-------|-------------|------------------|---------------|
-| architecture | System architecture for review context | whole: `{planning_artifacts}/*architecture*.md`, sharded: `{planning_artifacts}/*architecture*/*.md` | FULL_LOAD |
-| ux_design | UX design specification (if UI review) | whole: `{planning_artifacts}/*ux*.md`, sharded: `{planning_artifacts}/*ux*/*.md` | FULL_LOAD |
-| epics | Epic containing story being reviewed | whole: `{planning_artifacts}/*epic*.md`, sharded_index: `{planning_artifacts}/*epic*/index.md`, sharded_single: `{planning_artifacts}/*epic*/epic-{{epic_num}}.md` | SELECTIVE_LOAD |
-
-### Context
-
-- `project_context` = `**/project-context.md` (load if exists)
-
+main_config: '{project-root}/_xiaoma/xmc/config.yaml'
 ---
 
-## EXECUTION
-
-<workflow>
-
-<step n="1" goal="Load story and discover changes">
-  <action>Use provided {{story_path}} or ask user which story file to review</action>
-  <action>Read COMPLETE story file</action>
-  <action>Set {{story_key}} = extracted key from filename (e.g., "1-2-user-authentication.md" → "1-2-user-authentication") or story
-    metadata</action>
-  <action>Parse sections: Story, Acceptance Criteria, Tasks/Subtasks, Dev Agent Record → File List, Change Log</action>
-
-  <!-- Discover actual changes via git -->
-  <action>Check if git repository detected in current directory</action>
-  <check if="git repository exists">
-    <action>Run `git status --porcelain` to find uncommitted changes</action>
-    <action>Run `git diff --name-only` to see modified files</action>
-    <action>Run `git diff --cached --name-only` to see staged files</action>
-    <action>Compile list of actually changed files from git output</action>
-  </check>
-
-  <!-- Cross-reference story File List vs git reality -->
-  <action>Compare story's Dev Agent Record → File List with actual git changes</action>
-  <action>Note discrepancies:
-    - Files in git but not in story File List
-    - Files in story File List but no git changes
-    - Missing documentation of what was actually changed
-  </action>
-
-  <action>Read fully and follow `./discover-inputs.md` to load all input files</action>
-  <action>Load {project_context} for coding standards (if exists)</action>
-</step>
-
-<step n="2" goal="Build review attack plan">
-  <action>Extract ALL Acceptance Criteria from story</action>
-  <action>Extract ALL Tasks/Subtasks with completion status ([x] vs [ ])</action>
-  <action>From Dev Agent Record → File List, compile list of claimed changes</action>
-
-  <action>Create review plan:
-    1. **AC Validation**: Verify each AC is actually implemented
-    2. **Task Audit**: Verify each [x] task is really done
-    3. **Code Quality**: Security, performance, maintainability
-    4. **Test Quality**: Real tests vs placeholder bullshit
-  </action>
-</step>
-
-<step n="3" goal="Execute adversarial review">
-  <critical>VALIDATE EVERY CLAIM - Check git reality vs story claims</critical>
-
-  <!-- Git vs Story Discrepancies -->
-  <action>Review git vs story File List discrepancies:
-    1. **Files changed but not in story File List** → MEDIUM finding (incomplete documentation)
-    2. **Story lists files but no git changes** → HIGH finding (false claims)
-    3. **Uncommitted changes not documented** → MEDIUM finding (transparency issue)
-  </action>
-
-  <!-- Use combined file list: story File List + git discovered files -->
-  <action>Create comprehensive review file list from story File List and git changes</action>
-
-  <!-- AC Validation -->
-  <action>For EACH Acceptance Criterion:
-    1. Read the AC requirement
-    2. Search implementation files for evidence
-    3. Determine: IMPLEMENTED, PARTIAL, or MISSING
-    4. If MISSING/PARTIAL → HIGH SEVERITY finding
-  </action>
-
-  <!-- Task Completion Audit -->
-  <action>For EACH task marked [x]:
-    1. Read the task description
-    2. Search files for evidence it was actually done
-    3. **CRITICAL**: If marked [x] but NOT DONE → CRITICAL finding
-    4. Record specific proof (file:line)
-  </action>
-
-  <!-- Code Quality Deep Dive -->
-  <action>For EACH file in comprehensive review list:
-    1. **Security**: Look for injection risks, missing validation, auth issues
-    2. **Performance**: N+1 queries, inefficient loops, missing caching
-    3. **Error Handling**: Missing try/catch, poor error messages
-    4. **Code Quality**: Complex functions, magic numbers, poor naming
-    5. **Test Quality**: Are tests real assertions or placeholders?
-  </action>
-
-  <check if="total_issues_found == 0">
-    <action>Double-check by re-examining code for:
-      - Edge cases and null handling
-      - Architecture violations
-      - Integration issues
-      - Dependency problems
-    </action>
-    <action>If still no issues found after thorough re-examination, that is a valid outcome — report a clean review</action>
-  </check>
-</step>
-
-<step n="4" goal="Present findings and fix them">
-  <action>Categorize findings: HIGH (must fix), MEDIUM (should fix), LOW (nice to fix)</action>
-  <action>Set {{fixed_count}} = 0</action>
-  <action>Set {{action_count}} = 0</action>
-
-  <output>**🔥 CODE REVIEW FINDINGS, {user_name}!**
-
-    **Story:** {{story_file}}
-    **Git vs Story Discrepancies:** {{git_discrepancy_count}} found
-    **Issues Found:** {{high_count}} High, {{medium_count}} Medium, {{low_count}} Low
-
-    ## 🔴 CRITICAL ISSUES
-    - Tasks marked [x] but not actually implemented
-    - Acceptance Criteria not implemented
-    - Story claims files changed but no git evidence
-    - Security vulnerabilities
-
-    ## 🟡 MEDIUM ISSUES
-    - Files changed but not documented in story File List
-    - Uncommitted changes not tracked
-    - Performance problems
-    - Poor test coverage/quality
-    - Code maintainability issues
+# Code Review Workflow
 
-    ## 🟢 LOW ISSUES
-    - Code style improvements
-    - Documentation gaps
-    - Git commit message quality
-  </output>
+**Goal:** Review code changes adversarially using parallel review layers and structured triage.
 
-  <ask>What should I do with these issues?
+**Your Role:** You are an elite code reviewer. You gather context, launch parallel adversarial reviews, triage findings with precision, and present actionable results. No noise, no filler.
 
-    1. **Fix them automatically** - I'll update the code and tests
-    2. **Create action items** - Add to story Tasks/Subtasks for later
-    3. **Show me details** - Deep dive into specific issues
 
-    Choose [1], [2], or specify which issue to examine:</ask>
+## WORKFLOW ARCHITECTURE
 
-  <check if="user chooses 1">
-    <action>Fix all HIGH and MEDIUM issues in the code</action>
-    <action>Add/update tests as needed</action>
-    <action>Update File List in story if files changed</action>
-    <action>Update story Dev Agent Record with fixes applied</action>
-    <action>Set {{fixed_count}} = number of HIGH and MEDIUM issues fixed</action>
-    <action>Set {{action_count}} = 0</action>
-  </check>
+This uses **step-file architecture** for disciplined execution:
 
-  <check if="user chooses 2">
-    <action>Add "Review Follow-ups (AI)" subsection to Tasks/Subtasks</action>
-    <action>For each issue: `- [ ] [AI-Review][Severity] Description [file:line]`</action>
-    <action>Set {{action_count}} = number of action items created</action>
-    <action>Set {{fixed_count}} = 0</action>
-  </check>
+- **Micro-file Design**: Each step is self-contained and followed exactly
+- **Just-In-Time Loading**: Only load the current step file
+- **Sequential Enforcement**: Complete steps in order, no skipping
+- **State Tracking**: Persist progress via in-memory variables
+- **Append-Only Building**: Build artifacts incrementally
 
-  <check if="user chooses 3">
-    <action>Show detailed explanation with code examples</action>
-    <action>Return to fix decision</action>
-  </check>
-</step>
+### Step Processing Rules
 
-<step n="5" goal="Update story status and sync sprint tracking">
-  <!-- Determine new status based on review outcome -->
-  <check if="all HIGH and MEDIUM issues fixed AND all ACs implemented">
-    <action>Set {{new_status}} = "done"</action>
-    <action>Update story Status field to "done"</action>
-  </check>
-  <check if="HIGH or MEDIUM issues remain OR ACs not fully implemented">
-    <action>Set {{new_status}} = "in-progress"</action>
-    <action>Update story Status field to "in-progress"</action>
-  </check>
-  <action>Save story file</action>
+1. **READ COMPLETELY**: Read the entire step file before acting
+2. **FOLLOW SEQUENCE**: Execute sections in order
+3. **WAIT FOR INPUT**: Halt at checkpoints and wait for human
+4. **LOAD NEXT**: When directed, read fully and follow the next step file
 
-  <!-- Determine sprint tracking status -->
-  <check if="{sprint_status} file exists">
-    <action>Set {{current_sprint_status}} = "enabled"</action>
-  </check>
-  <check if="{sprint_status} file does NOT exist">
-    <action>Set {{current_sprint_status}} = "no-sprint-tracking"</action>
-  </check>
+### Critical Rules (NO EXCEPTIONS)
 
-  <!-- Sync sprint-status.yaml when story status changes (only if sprint tracking enabled) -->
-  <check if="{{current_sprint_status}} != 'no-sprint-tracking'">
-    <action>Load the FULL file: {sprint_status}</action>
-    <action>Find development_status key matching {{story_key}}</action>
+- **NEVER** load multiple step files simultaneously
+- **ALWAYS** read entire step file before execution
+- **NEVER** skip steps or optimize the sequence
+- **ALWAYS** follow the exact instructions in the step file
+- **ALWAYS** halt at checkpoints and wait for human input
 
-    <check if="{{new_status}} == 'done'">
-      <action>Update development_status[{{story_key}}] = "done"</action>
-      <action>Update last_updated field to current date</action>
-      <action>Save file, preserving ALL comments and structure</action>
-      <output>✅ Sprint status synced: {{story_key}} → done</output>
-    </check>
 
-    <check if="{{new_status}} == 'in-progress'">
-      <action>Update development_status[{{story_key}}] = "in-progress"</action>
-      <action>Update last_updated field to current date</action>
-      <action>Save file, preserving ALL comments and structure</action>
-      <output>🔄 Sprint status synced: {{story_key}} → in-progress</output>
-    </check>
+## INITIALIZATION SEQUENCE
 
-    <check if="story key not found in sprint status">
-      <output>⚠️ Story file updated, but sprint-status sync failed: {{story_key}} not found in sprint-status.yaml</output>
-    </check>
-  </check>
+### 1. Configuration Loading
 
-  <check if="{{current_sprint_status}} == 'no-sprint-tracking'">
-    <output>ℹ️ Story status updated (no sprint tracking configured)</output>
-  </check>
+Load and read full config from `{main_config}` and resolve:
 
-  <output>**✅ Review Complete!**
+- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
+- `communication_language`, `document_output_language`, `user_skill_level`
+- `date` as system-generated current datetime
+- `project_context` = `**/project-context.md` (load if exists)
+- CLAUDE.md / memory files (load if exist)
 
-    **Story Status:** {{new_status}}
-    **Issues Fixed:** {{fixed_count}}
-    **Action Items Created:** {{action_count}}
+YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
 
-    {{#if new_status == "done"}}Code review complete!{{else}}Address the action items and continue development.{{/if}}
-  </output>
-</step>
+### 2. First Step Execution
 
-</workflow>
+Read fully and follow: `./steps/step-01-gather-context.md` to begin the workflow.

package/src/xmc/workflows/4-implementation/xiaoma-correct-course/SKILL.md

@@ -3,4 +3,4 @@ name: xiaoma-correct-course
 description: 'Manage significant changes during sprint execution. Use when the user says "correct course" or "propose sprint change"'
 ---
 
-Follow the instructions in [workflow.md](workflow.md).
+Follow the instructions in ./workflow.md.

package/src/xmc/workflows/4-implementation/xiaoma-correct-course/workflow.md

@@ -68,7 +68,7 @@ Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
 3. **Selectively load sections** based on relevance to the change being analyzed — do NOT load everything, only sections that relate to the impacted areas
 4. **This document is optional** — skip if `{project_knowledge}` does not exist (greenfield projects)
 
-**Fuzzy matching**: Be flexible with document names — users may use variations like `prd.md`, `bmm-prd.md`, `product-requirements.md`, etc.
+**Fuzzy matching**: Be flexible with document names — users may use variations like `prd.md`, `xmc-prd.md`, `product-requirements.md`, etc.
 
 **Missing documents**: Not all documents may exist. PRD and Epics are essential; Architecture, UX Design, Tech Spec, and Document Project are loaded if available. HALT if PRD or Epics cannot be found.
 

package/src/xmc/workflows/4-implementation/xiaoma-create-story/SKILL.md

@@ -3,4 +3,4 @@ name: xiaoma-create-story
 description: 'Creates a dedicated story file with all the context the agent will need to implement it later. Use when the user says "create the next story" or "create story [story identifier]"'
 ---
 
-Follow the instructions in [workflow.md](workflow.md).
+Follow the instructions in ./workflow.md.