@zeyue0329/xiaoma-cli 1.12.0 → 1.15.0

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-05-code-review.md

@@ -1,95 +0,0 @@
----
-name: "step-05-code-review"
-description: "Perform adversarial code review using Reviewer role, delegating to code-review workflow logic"
-nextStepFile: "./step-06-test-story.md"
-nextStepFile_issues: "./step-07-fix-and-retest.md"
----
-
-# Step 5 of 9: Code Review
-
-**Goal:** Perform an adversarial code review to validate implementation quality, catching issues before QA testing.
-
-**Role:** Adversarial Code Reviewer
-
----
-
-## EXECUTION SEQUENCE
-
-### 1. Switch to Reviewer Role
-
-Adopt the Adversarial Code Reviewer persona:
-- YOU ARE AN ADVERSARIAL CODE REVIEWER — Find what's wrong or missing!
-- Validate story file claims against actual implementation
-- Challenge everything: Are tasks marked [x] actually done? Are ACs really implemented?
-- Find 3-10 specific issues minimum — no lazy "looks good" reviews
-
-### 2. Execute Code Review
-
-Invoke the `xiaoma-code-review` skill to perform the code review.
-
-Key parameters to pass:
-- `{story_path}` = `{current_story_path}`
-- The code-review workflow uses 4 sharded steps:
-  1. `step-01-gather-context` — Load story and discover changes via git
-  2. `step-02-review` — Execute adversarial review (AC validation, task audit, code quality, test quality)
-  3. `step-03-triage` — Categorize findings by severity (CRITICAL/HIGH/MEDIUM/LOW)
-  4. `step-04-present` — Present findings and fix recommendations
-
-**CRITICAL PIPELINE MODE INSTRUCTIONS:**
-- When the code-review workflow presents findings and asks for user choice (fix/action items/details), automatically select **fix** for all HIGH and MEDIUM issues
-- Do NOT exclude `_xiaoma/` or IDE configuration folders from review scope — the workflow handles these exclusions internally
-
-### 3. Auto-Fix Review Findings
-
-**CRITICAL:** In pipeline mode, automatically fix issues instead of asking the user:
-
-1. Fix ALL HIGH severity issues immediately
-2. Fix ALL MEDIUM severity issues
-3. Document LOW severity issues as action items but do not block the pipeline
-4. Update the story file with:
-   - Fixed issues noted in Dev Agent Record
-   - Updated File List with any newly modified files
-   - Change Log entry for review fixes
-
-### 4. Evaluate Review Outcome
-
-**IF all HIGH and MEDIUM issues are fixed AND all ACs are implemented:**
-- Set story status to "review" (ready for QA)
-- Output: "Code review complete. All critical issues resolved. Proceeding to QA testing."
-- **NEXT:** Proceed to step-06 (test story) [frontmatter: nextStepFile]
-
-**IF there are remaining HIGH or MEDIUM issues that could not be auto-fixed:**
-- Output the unresolved issues
-- **NEXT:** Proceed to step-07 (fix and retest) to address remaining issues [frontmatter: nextStepFile_issues]
-
-### 5. Pipeline Status Update
-
-- Set `{pipeline_status}` = "code-review-complete"
-- Set `{steps_completed}` = `{steps_completed}` + 1
-
----
-
-## NEXT STEP
-
-**If all issues resolved:**
-**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-06-test-story.md`
-
-**If issues remain:**
-**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-07-fix-and-retest.md`
-
----
-
-## SUCCESS METRICS
-
-- All HIGH and MEDIUM issues identified and resolved
-- No tasks marked [x] that are not actually implemented
-- All ACs verified as implemented
-- Code quality meets project standards
-- Tests are real assertions, not placeholders
-
-## FAILURE MODES
-
-- Lazy "looks good" review with < 3 findings
-- Not cross-referencing git reality vs story claims
-- Skipping AC validation
-- Not fixing HIGH severity issues before proceeding

package/src/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-08-complete-story.md

@@ -1,114 +0,0 @@
----
-name: "step-08-complete-story"
-description: "Mark story as done, update sprint-status, and generate completion summary"
-nextStepFile: "./step-09-finalize.md"
----
-
-# Step 8 of 9: Complete Story
-
-**Goal:** Mark the story as done, sync all tracking artifacts, and generate a completion summary.
-
-**Role:** Pipeline Orchestrator
-
----
-
-## EXECUTION SEQUENCE
-
-### 1. Final Validation
-
-Before marking complete, verify all gates:
-1. **Fresh Read:** Read the COMPLETE story file at `{current_story_path}` directly from disk (not from cache or prior state). This is critical because step-07 may have modified the file (e.g., updated task checkboxes, changed story status), and you MUST verify the current on-disk state, not a stale in-memory version.
-2. Verify ALL tasks and subtasks are marked [x], [X], or [✓] (case-insensitive, all formats accepted)
-3. Verify ALL acceptance criteria have been tested and passed
-4. Verify no unresolved HIGH or MEDIUM issues remain
-5. Verify the full test suite passes
-
-If any gate fails: **DO NOT mark as done** — return to the appropriate step:
-- Incomplete tasks → step-04 (develop)
-- Failed tests → step-07 (fix and retest)
-- Unresolved review issues → step-07 (fix and retest)
-
-### 2. Update Story Status
-
-1. Update the story Status field to "done"
-2. Add completion timestamp to Dev Agent Record
-3. Add final Change Log entry: "Story completed via auto-pipeline on {date}"
-4. Save the story file
-
-### 3. Update Sprint Status
-
-1. Load the FULL file: `{sprint_status}`
-2. Find `development_status` key matching `{current_story_key}`
-3. Update `development_status[{current_story_key}]` = "done"
-4. Update `last_updated` field to current date
-5. Save file, preserving ALL comments and structure
-
-### 4. Check Epic Completion
-
-1. Extract `{epic_num}` from `{current_story_key}` using pattern matching:
-   - Pattern: story key must match `{epic_num}-{story_num}-{name}` where epic_num and story_num are positive integers
-   - Extract: Read first numeric component before first dash
-   - Example: "1-2-user-auth" → epic_num = "1"
-   - Example: "12-3-payment-flow" → epic_num = "12"
-   - Skip keys that don't match pattern (e.g., "epic-1-retrospective" is an epic marker, not a story)
-   - If key doesn't match expected pattern: Output WARNING — "Could not extract epic number from {current_story_key}. Skipping epic completion check." and skip to section 5
-   - If extraction fails for any reason: Continue without epic update (non-blocking)
-2. In sprint-status.yaml, find all stories for epic `{epic_num}` (pattern: `{epic_num}-*`, excluding epic markers like `epic-{epic_num}` and retrospectives like `epic-{epic_num}-retrospective`)
-3. Check if ALL stories in this epic have status "done"
-4. If all stories are done:
-   - Update `development_status[epic-{epic_num}]` = "done"
-   - Output: "Epic {epic_num} fully completed! All stories are done."
-5. If some stories remain:
-   - Output: "Epic {epic_num}: {done_in_epic}/{total_in_epic} stories completed."
-
-### 5. Generate Completion Summary
-
-Increment `{stories_completed}` by 1
-
-Output:
-```
-Story {current_story_key} — COMPLETED
-
-Summary:
-- Story: {story_title}
-- File: {current_story_path}
-- Status: done
-- Fix Iterations Used: {fix_iteration}
-- Stories Completed This Pipeline Run: {stories_completed}
-
-Pipeline Phases Completed:
-  [x] Story Creation (SM)
-  [x] Story Validation (PM)
-  [x] Development (Dev)
-  [x] Code Review (Reviewer)
-  [x] QA Testing (QA)
-  [x] Status Updated (done)
-```
-
-### 6. Pipeline Status Update
-
-- Set `{pipeline_status}` = "story-completed"
-- Set `{steps_completed}` = `{steps_completed}` + 1
-
----
-
-## NEXT STEP
-
-**NEXT:** Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-09-finalize.md`
-
----
-
-## SUCCESS METRICS
-
-- Story status set to "done" in story file
-- Sprint-status.yaml updated with "done" for story key
-- Epic completion checked and updated if applicable
-- Completion summary generated
-- `{stories_completed}` counter incremented
-
-## FAILURE MODES
-
-- Marking story done without verifying all gates
-- Not updating sprint-status.yaml
-- Not checking epic-level completion
-- Not generating completion summary

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

@@ -1,69 +0,0 @@
----
-name: "step-09-finalize"
-description: "Finalize the single-story pipeline run and output completion report."
-nextStepFile: null
----
-
-# Step 9 of 9: Pipeline Finalization
-
-**Goal:** Generate the final completion report for this single-story pipeline run.
-
-**Role:** Pipeline Orchestrator
-
----
-
-## EXECUTION SEQUENCE
-
-### 1. Refresh Sprint Status
-
-1. Load the FULL file: `{sprint_status}`
-2. Read ALL lines from beginning to end — do not skip any content
-3. Recount all stories by current status:
-   - `{backlog_count}` — Stories with status "backlog"
-   - `{ready_count}` — Stories with status "ready-for-dev"
-   - `{in_progress_count}` — Stories with status "in-progress"
-   - `{review_count}` — Stories with status "review"
-   - `{done_count}` — Stories with status "done"
-
-### 2. Generate Final Report
-
-Output:
-```
-Auto Story Pipeline — COMPLETE
-
-Pipeline Summary:
-- Mode: single
-- Story Processed: {current_story_key}
-- Steps Executed: {steps_completed}
-- Pipeline Status: finalized
-
-Sprint Status (current):
-- Backlog: {backlog_count} remaining
-- Ready for Dev: {ready_count}
-- In Progress: {in_progress_count}
-- In Review: {review_count}
-- Done: {done_count}
-
-The automated story development pipeline has finished.
-```
-
-**IF `{backlog_count}` == 0 AND `{ready_count}` == 0 AND `{in_progress_count}` == 0 AND `{review_count}` == 0:**
-- Output: "All stories in the sprint are complete! Consider running epic-retrospective (ER) to review the work."
-
-**IF `{backlog_count}` > 0 OR `{ready_count}` > 0:**
-- Output: "There are still {backlog_count + ready_count} pending stories. Run ASPB (`/xiaoma-auto-story-pipeline-batch`) to process all remaining stories in batch mode, or run ASP again to process the next story."
-
-**HALT** — Pipeline complete.
-
----
-
-## SUCCESS METRICS
-
-- Final sprint status refreshed from disk
-- Comprehensive completion report generated
-- User informed of remaining stories and next steps
-
-## FAILURE MODES
-
-- Not refreshing sprint status before generating report
-- Skipping final report generation

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

@@ -1,89 +0,0 @@
----
-name: auto-story-pipeline
-description: "Automated end-to-end story development pipeline (single story): create → validate → develop → review → test → fix → done. Use when the user says 'run auto pipeline', 'automate story development', or 'auto story pipeline'. For batch processing of all stories, use xiaoma-auto-story-pipeline-batch (ASPB) instead."
----
-
-# Auto Story Pipeline Workflow
-
-**Goal:** Execute the complete automated story development lifecycle for a **single story** — from story creation through validation, development, code review, testing, bug fixing, and final delivery — as a single continuous pipeline.
-
-**Your Role:** Pipeline Orchestrator. You switch expert roles at each phase:
-- **SM (xiaomin)** — Story creation and sprint coordination
-- **PM (xiaochan)** — Story validation and quality gate
-- **Dev (xiaokai)** — Code implementation and bug fixing
-- **Reviewer** — Adversarial code review
-- **QA (xiaoce)** — Functional testing with real data
-
-- Communicate all responses in {communication_language} and generate all documents in {document_output_language}
-- Execute ALL steps in exact order; do NOT skip steps
-- Absolutely DO NOT stop because of "milestones", "significant progress", or "session boundaries". Continue in a single execution until the pipeline is COMPLETE or a HALT condition is triggered
-- Each step file loads fresh to combat "lost in the middle" context degradation
-
-> **Note:** This workflow processes a **single story** (or resumes a specific story). For batch processing of all backlog stories, use the **Auto Story Pipeline Batch** skill (`ASPB` or `/xiaoma-auto-story-pipeline-batch`), which uses Agent subprocess isolation for each story.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for focused execution across a long-running pipeline:
-
-- Each step loads fresh to prevent context loss in long sessions
-- State persists via variables passed between steps
-- Sequential progression through pipeline phases with conditional branching
-- Role switching at each phase boundary
-
-### State Variables
-
-- `{pipeline_mode}` — "single" (process next backlog story) or "resume" (resume a specific story by key)
-- `{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}`). Whenever re-reading the story file in subsequent steps (e.g., step-08 final validation, step-03 re-checks), always perform a FRESH read directly from disk using this path variable. Do NOT rely on cached/stale in-memory state from earlier steps, as intermediate steps (step-04, step-05, step-06, step-07) may have modified the file
-- `{fix_iteration}` — Bug fix loop counter (max controlled by `{max_fix_iterations}`, default 5)
-- `{max_fix_iterations}` — Maximum fix-and-retest cycles per story (configurable via `max_fix_iterations` in config.yaml; default 5 if not set)
-- `{fix_source}` — Origin of failures being fixed in step-07: "code-review" (step-05 routed here with unresolvable issues), "qa-testing" (step-06 routed here with test failures), or "mixed" (both code review and QA issues); set in step-07 section 2; determines post-fix routing (code-review/mixed → inline targeted re-check before step-08; qa-testing → step-08 directly)
-- `{pipeline_status}` — Current pipeline phase for tracking
-- `{validation_attempt}` — Story validation attempt counter (used in step-03, max 3; re-initialized at start of step-03)
-- `{steps_completed}` — Count of pipeline step files executed in this run (initialized to 0 in step-01)
-
-### Status Machine
-
-Stories progress through these states:
-- `backlog` → `ready-for-dev` → `in-progress` → `review` → `done`
-
----
-
-## 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
-
-- `installed_path` = `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline`
-- `sprint_status` = `{implementation_artifacts}/sprint-status.yaml`
-- `validation` = `{installed_path}/checklist.md`
-
-### Related Workflows
-
-These existing workflows contain the detailed logic that pipeline steps delegate to:
-
-- `create_story_workflow` = `{project-root}/_xiaoma/xmc/workflows/4-implementation/xiaoma-create-story/workflow.md`
-- `dev_story_workflow` = `{project-root}/_xiaoma/xmc/workflows/4-implementation/xiaoma-dev-story/workflow.md`
-- `code_review_workflow` = `{project-root}/_xiaoma/xmc/workflows/4-implementation/xiaoma-code-review/workflow.md`
-- `qa_test_workflow` = `{project-root}/_xiaoma/xmc/workflows/xiaoma-qa-generate-e2e-tests/workflow.md`
-
-### Context
-
-- `project_context` = `**/project-context.md` (load if exists)
-
----
-
-## EXECUTION
-
-Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline/steps/step-01-init-and-validate.md` to begin the pipeline.

package/src/xmc/workflows/4-implementation/auto-story-pipeline/xiaoma-skill-manifest.yaml

@@ -1,3 +0,0 @@
-canonicalId: xiaoma-auto-story-pipeline
-type: workflow
-description: "Automated end-to-end story development pipeline (single story). Use when the user says 'run auto pipeline', 'automate story development', or 'auto story pipeline'. For batch processing, use xiaoma-auto-story-pipeline-batch (ASPB)."

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

@@ -1,6 +0,0 @@
----
-name: xiaoma-code-review
-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.

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

@@ -1,23 +0,0 @@
-# Senior Developer Review - Validation Checklist
-
-- [ ] Story file loaded from `{{story_path}}`
-- [ ] Story Status verified as reviewable (review)
-- [ ] Epic and Story IDs resolved ({{epic_num}}.{{story_num}})
-- [ ] Story Context located or warning recorded
-- [ ] Epic Tech Spec located or warning recorded
-- [ ] Architecture/standards docs loaded (as available)
-- [ ] Tech stack detected and documented
-- [ ] MCP doc search performed (or web fallback) and references captured
-- [ ] Acceptance Criteria cross-checked against implementation
-- [ ] File List reviewed and validated for completeness
-- [ ] Tests identified and mapped to ACs; gaps noted
-- [ ] Code quality review performed on changed files
-- [ ] Security review performed on changed files and dependencies
-- [ ] Outcome decided (Approve/Changes Requested/Blocked)
-- [ ] Review notes appended under "Senior Developer Review (AI)"
-- [ ] Change Log updated with review entry
-- [ ] Status updated according to settings (if enabled)
-- [ ] Sprint status synced (if sprint tracking enabled)
-- [ ] Story saved successfully
-
-_Reviewer: {{user_name}} on {{date}}_

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

@@ -1,61 +0,0 @@
----
-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

@@ -1,41 +0,0 @@
----
-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-04-present.md

@@ -1,38 +0,0 @@
----
----
-
-# 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,54 +0,0 @@
----
-main_config: '{project-root}/_xiaoma/xmc/config.yaml'
----
-
-# Code Review Workflow
-
-**Goal:** Review code changes adversarially using parallel review layers and structured triage.
-
-**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.
-
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-- **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
-
-### Step Processing Rules
-
-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
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **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
-
-
-## INITIALIZATION SEQUENCE
-
-### 1. Configuration Loading
-
-Load and read full config from `{main_config}` and resolve:
-
-- `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)
-
-YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`.
-
-### 2. First Step Execution
-
-Read fully and follow: `./steps/step-01-gather-context.md` to begin the workflow.

package/src/xmc/workflows/4-implementation/xiaoma-code-review/xiaoma-skill-manifest.yaml

@@ -1 +0,0 @@
-type: skill

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

@@ -1,6 +0,0 @@
----
-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.

package/src/xmc/workflows/4-implementation/xiaoma-correct-course/xiaoma-skill-manifest.yaml

@@ -1 +0,0 @@
-type: skill

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

@@ -1,6 +0,0 @@
----
-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.