@zeyue0329/xiaoma-cli 1.13.0 → 1.15.0

package/src/xmc-skills/4-implementation/xiaoma-retrospective/customize.toml

@@ -0,0 +1,41 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for xiaoma-retrospective. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per XiaoMa structural rules: ---
+#   scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+#   arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+# Steps to run before the standard activation (config load, greet).
+# Overrides append. Use for pre-flight loads, compliance checks, etc.
+
+activation_steps_prepend = []
+
+# Steps to run after greet but before the workflow begins.
+# Overrides append. Use for context-heavy setup that should happen
+# once the user has been acknowledged.
+
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run
+# (standards, compliance constraints, stylistic guardrails).
+# Distinct from the runtime memory sidecar — these are static context
+# loaded on activation. Overrides append.
+#
+# Each entry is either:
+#   - a literal sentence, e.g. "All retrospectives must produce SMART action items with named owners."
+#   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
+#     (glob patterns are supported; the file's contents are loaded and treated as facts).
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+# Scalar: executed when the workflow reaches Step 12 (Final Summary and Handoff),
+# after the retrospective document is saved and sprint-status is updated. Override wins.
+# Leave empty for no custom post-completion behavior.
+
+on_complete = ""

package/src/{xmc/workflows/4-implementation/xiaoma-sprint-planning/workflow.md → xmc-skills/4-implementation/xiaoma-sprint-planning/SKILL.md}

@@ -1,14 +1,44 @@
+---
+name: xiaoma-sprint-planning
+description: 'Generate sprint status tracking from epics. Use when the user says "run sprint planning" or "generate sprint plan"'
+---
+
 # Sprint Planning Workflow
 
 **Goal:** Generate sprint status tracking from epics, detecting current story statuses and building a complete sprint-status.yaml file.
 
-**Your Role:** You are a Scrum Master generating and maintaining sprint tracking. Parse epic files, detect story statuses, and produce a structured sprint-status.yaml.
+**Your Role:** You are a Developer generating and maintaining sprint tracking. Parse epic files, detect story statuses, and produce a structured sprint-status.yaml.
 
----
+## Conventions
+
+- Bare paths (e.g. `checklist.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `node {project-root}/_xiaoma/scripts/resolve_customization.js --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_xiaoma/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_xiaoma/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
 
-## INITIALIZATION
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
 
-### Configuration Loading
+### Step 4: Load Config
 
 Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
 
@@ -17,9 +47,21 @@ Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
 - `implementation_artifacts`
 - `planning_artifacts`
 - `date` as system-generated current datetime
+- `project_context` = `**/project-context.md` (load if exists)
 - YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Generate all documents in `{document_output_language}`
+
+### Step 5: Greet the User
+
+If running headless (no interactive user — e.g. invoked by an auto-\* pipeline), follow `references/headless.md` for the whole run instead of greeting. Otherwise greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
 
-### Paths
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
+
+## Paths
 
 - `tracking_system` = `file-system`
 - `project_key` = `NOKEY`
@@ -29,19 +71,13 @@ Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
 - `epics_pattern` = `*epic*.md`
 - `status_file` = `{implementation_artifacts}/sprint-status.yaml`
 
-### Input Files
+## Input Files
 
 | Input | Path | Load Strategy |
 |-------|------|---------------|
 | Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD |
 
-### Context
-
-- `project_context` = `**/project-context.md` (load if exists)
-
----
-
-## EXECUTION
+## Execution
 
 ### Document Discovery - Full Epic Loading
 
@@ -81,6 +117,13 @@ Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
 - Convert title to kebab-case: `user-authentication`
 - Final key: `1-1-user-authentication`
 
+**Non-ASCII / 中文标题（当 `document_output_language` 为中文时是常态）：** kebab-case 不适用于中文等非 ASCII 标题。改用一个简短、稳定、纯 ASCII 的语义 slug 概括标题，例如 `### Story 1.1: 用户认证` → `1-1-user-auth`。规则：
+
+- 保留 `{epic}-{story}-` 数字前缀不变；slug 取标题语义的简短英文小写连字符串（≤ 5 词）。
+- **确定性：** 同一标题每次必须产出同一 slug（不要随机化），否则重跑会产生不一致的 key。
+- **下游一致性约束（关键）：** `xiaoma-create-story` 生成故事文件名时必须沿用**同一套 slug 约定**，否则本技能 step-3 的 `{story-key}.md` 存在性探测会落空、状态无法从 `backlog` 升级。
+- 生成 key 后，在该故事行尾以 `# title: <原始标题>` 注释保留原始（可能为中文的）标题，便于人工回溯与下游对齐。
+
 <action>Build complete inventory of all epics and stories from all epic files</action>
 </step>
 
@@ -162,7 +205,7 @@ development_status:
 # ===============
 # - Epic transitions to 'in-progress' automatically when first story is created
 # - Stories can be worked in parallel if team capacity allows
-# - SM typically creates next story after previous one is 'done' to incorporate learnings
+# - Developer typically creates next story after previous one is 'done' to incorporate learnings
 # - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
 
 generated: { date }
@@ -215,6 +258,7 @@ development_status:
 3. Agents will update statuses as they work
 4. Re-run this workflow to refresh auto-detected statuses
 
+<action>Run: `node {project-root}/_xiaoma/scripts/resolve_customization.js --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
 </step>
 
 </workflow>
@@ -260,4 +304,4 @@ optional ↔ done
 2. **Sequential Default**: Stories are typically worked in order, but parallel work is supported
 3. **Parallel Work Supported**: Multiple stories can be `in-progress` if team capacity allows
 4. **Review Before Done**: Stories should pass through `review` before `done`
-5. **Learning Transfer**: SM typically creates next story after previous one is `done` to incorporate learnings
+5. **Learning Transfer**: Developer typically creates next story after previous one is `done` to incorporate learnings

package/src/xmc-skills/4-implementation/xiaoma-sprint-planning/customize.toml

@@ -0,0 +1,41 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for xiaoma-sprint-planning. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per XiaoMa structural rules: ---
+#   scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+#   arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+# Steps to run before the standard activation (config load, greet).
+# Overrides append. Use for pre-flight loads, compliance checks, etc.
+
+activation_steps_prepend = []
+
+# Steps to run after greet but before the workflow begins.
+# Overrides append. Use for context-heavy setup that should happen
+# once the user has been acknowledged.
+
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run
+# (standards, compliance constraints, stylistic guardrails).
+# Distinct from the runtime memory sidecar — these are static context
+# loaded on activation. Overrides append.
+#
+# Each entry is either:
+#   - a literal sentence, e.g. "All stories must include testable acceptance criteria."
+#   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
+#     (glob patterns are supported; the file's contents are loaded and treated as facts).
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+# Scalar: executed when the workflow reaches its final step,
+# after sprint-status.yaml is generated and validated. Override wins.
+# Leave empty for no custom post-completion behavior.
+
+on_complete = ""

package/src/xmc-skills/4-implementation/xiaoma-sprint-planning/references/headless.md

@@ -0,0 +1,28 @@
+# Headless Mode
+
+Load this file when xiaoma-sprint-planning is invoked headless (no interactive user — e.g. by auto-prd-to-stories step-03, auto-full-pipeline step-03, or auto-requirements-pipeline). Follow it for the whole run.
+
+## Detection
+
+Headless mode is in effect when any of the following is true:
+
+- the invoking caller sets a `headless: true` flag (or equivalent argument the harness exposes),
+- the invocation is from another skill or a non-interactive runner (no TTY, no user message stream),
+- `{workflow.activation_steps_prepend}` includes an entry that explicitly declares headless,
+- the first message comes from an automation context that pre-supplies the inputs and asks for the sprint-status path back.
+
+When ambiguous, default to interactive.
+
+## Inputs the caller is expected to provide
+
+- the `epics.md` path (or a workspace containing one / multiple `epic-N.md` files) — the input the sprint plan is built from.
+
+## General
+
+Do not ask, do not greet. Walk every step to completion; auto-proceed through any confirmation or completion-summary prompt — never halt for input.
+
+Produce `sprint-status.yaml` with a `development_status:` section listing every story key (`{epic}-{story}-{slug}`), each epic marker (`epic-N`), and each retrospective (`epic-N-retrospective: optional`), in `epic → its stories → its retrospective` order, all stories defaulting to `backlog`. Apply the **Story ID Conversion Rules** in the SKILL — including the non-ASCII / 中文 → stable ASCII-slug strategy — deterministically, so the same title always yields the same key. Preserve the original title as a trailing `# title: <…>` comment when it was slugged.
+
+## Completion
+
+End by writing `sprint-status.yaml` to the implementation-artifacts location and returning its path.

package/src/{xmc/workflows → xmc-skills}/4-implementation/xiaoma-sprint-planning/sprint-status-template.yaml

@@ -29,13 +29,13 @@
 # WORKFLOW NOTES:
 # ===============
 # - Mark epic as 'in-progress' when starting work on its first story
-# - SM typically creates next story ONLY after previous one is 'done' to incorporate learnings
+# - Developer typically creates next story ONLY after previous one is 'done' to incorporate learnings
 # - Dev moves story to 'review', then Dev runs code-review (fresh context, ideally different LLM)
 
 # EXAMPLE STRUCTURE (your actual epics/stories will replace these):
 
-generated: 05-06-2-2025 21:30
-last_updated: 05-06-2-2025 21:30
+generated: 05-06-2025 21:30
+last_updated: 05-06-2025 21:30
 project: My Awesome Project
 project_key: NOKEY
 tracking_system: file-system

package/src/{xmc/workflows/4-implementation/xiaoma-sprint-status/workflow.md → xmc-skills/4-implementation/xiaoma-sprint-status/SKILL.md}

@@ -1,14 +1,44 @@
+---
+name: xiaoma-sprint-status
+description: 'Summarize sprint status and surface risks. Use when the user says "check sprint status" or "show sprint status"'
+---
+
 # Sprint Status Workflow
 
 **Goal:** Summarize sprint status, surface risks, and recommend the next workflow action.
 
-**Your Role:** You are a Scrum Master providing clear, actionable sprint visibility. No time estimates — focus on status, risks, and next steps.
+**Your Role:** You are a Developer providing clear, actionable sprint visibility. No time estimates — focus on status, risks, and next steps.
 
----
+## Conventions
+
+- Bare paths (e.g. `checklist.md`) resolve from the skill root.
+- `{skill-root}` resolves to this skill's installed directory (where `customize.toml` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+Run: `node {project-root}/_xiaoma/scripts/resolve_customization.js --skill {skill-root} --key workflow`
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `{skill-root}/customize.toml` — defaults
+2. `{project-root}/_xiaoma/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/_xiaoma/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
 
-## INITIALIZATION
+### Step 3: Load Persistent Facts
 
-### Configuration Loading
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
 
 Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
 
@@ -16,25 +46,30 @@ Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
 - `communication_language`, `document_output_language`
 - `implementation_artifacts`
 - `date` as system-generated current datetime
+- `project_context` = `**/project-context.md` (load if exists)
 - YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
 
-### Paths
+### Step 5: Greet the User
+
+Greet `{user_name}`, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. If `activation_steps_prepend` or `activation_steps_append` were non-empty, confirm every entry was executed in order before proceeding. Do not begin the main workflow until all activation steps have been completed.
+
+## Paths
 
 - `sprint_status_file` = `{implementation_artifacts}/sprint-status.yaml`
 
-### Input Files
+## Input Files
 
 | Input | Path | Load Strategy |
 |-------|------|---------------|
 | Sprint status | `{sprint_status_file}` | FULL_LOAD |
 
-### Context
-
-- `project_context` = `**/project-context.md` (load if exists)
-
----
-
-## EXECUTION
+## Execution
 
 <workflow>
 
@@ -58,7 +93,7 @@ Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
   <action>Load {project_context} for project-wide patterns and conventions (if exists)</action>
   <action>Try {sprint_status_file}</action>
   <check if="file not found">
-    <output>❌ sprint-status.yaml not found.
+    <output>sprint-status.yaml not found.
 Run `/xiaoma:xmc:workflows:sprint-planning` to generate it, then rerun sprint-status.</output>
     <action>Exit workflow</action>
   </check>
@@ -69,9 +104,9 @@ Run `/xiaoma:xmc:workflows:sprint-planning` to generate it, then rerun sprint-st
   <action>Read the FULL file: {sprint_status_file}</action>
   <action>Parse fields: generated, last_updated, project, project_key, tracking_system, story_location</action>
   <action>Parse development_status map. Classify keys:</action>
-  - Epics: keys starting with "epic-" (and not ending with "-retrospective")
-  - Retrospectives: keys ending with "-retrospective"
-  - Stories: everything else (e.g., 1-2-login-form)
+- Epics: keys starting with "epic-" (and not ending with "-retrospective")
+- Retrospectives: keys ending with "-retrospective"
+- Stories: everything else (e.g., 1-2-login-form)
   <action>Map legacy story status "drafted" → "ready-for-dev"</action>
   <action>Count story statuses: backlog, ready-for-dev, in-progress, review, done</action>
   <action>Map legacy epic status "contexted" → "in-progress"</action>
@@ -86,7 +121,7 @@ Run `/xiaoma:xmc:workflows:sprint-planning` to generate it, then rerun sprint-st
 
   <check if="any status is unrecognized">
     <output>
-⚠️ **Unknown status detected:**
+**Unknown status detected:**
 {{#each invalid_entries}}
 
 - `{{key}}`: "{{status}}" (not recognized)
@@ -129,12 +164,12 @@ Enter corrections (e.g., "1=in-progress, 2=backlog") or "skip" to continue witho
   4. Else if any story status == backlog → recommend `create-story`
   5. Else if any retrospective status == optional → recommend `retrospective`
   6. Else → All implementation items done; congratulate the user - you both did amazing work together!
-  <action>Store selected recommendation as: next_story_id, next_workflow_id, next_agent (SM/DEV as appropriate)</action>
+  <action>Store selected recommendation as: next_story_id, next_workflow_id, next_agent (DEV)</action>
 </step>
 
 <step n="4" goal="Display summary">
   <output>
-## 📊 Sprint Status
+## Sprint Status
 
 - Project: {{project}} ({{project_key}})
 - Tracking: {{tracking_system}}
@@ -186,6 +221,7 @@ If the command targets a story, set `story_key={{next_story_id}}` when prompted.
   </check>
 
   <check if="choice == 4">
+    <action>Run: `node {project-root}/_xiaoma/scripts/resolve_customization.js --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
     <action>Exit workflow</action>
   </check>
 </step>
@@ -256,6 +292,7 @@ If the command targets a story, set `story_key={{next_story_id}}` when prompted.
 
 <template-output>is_valid = true</template-output>
 <template-output>message = "sprint-status.yaml valid: metadata complete, all statuses recognized"</template-output>
+<action>Run: `node {project-root}/_xiaoma/scripts/resolve_customization.js --skill {skill-root} --key workflow.on_complete` — if the resolved value is non-empty, follow it as the final terminal instruction before exiting.</action>
 </step>
 
 </workflow>

package/src/xmc-skills/4-implementation/xiaoma-sprint-status/customize.toml

@@ -0,0 +1,41 @@
+# DO NOT EDIT -- overwritten on every update.
+#
+# Workflow customization surface for xiaoma-sprint-status. Mirrors the
+# agent customization shape under the [workflow] namespace.
+
+[workflow]
+
+# --- Configurable below. Overrides merge per XiaoMa structural rules: ---
+#   scalars: override wins • arrays (persistent_facts, activation_steps_*): append
+#   arrays-of-tables with `code`/`id`: replace matching items, append new ones.
+
+# Steps to run before the standard activation (config load, greet).
+# Overrides append. Use for pre-flight loads, compliance checks, etc.
+
+activation_steps_prepend = []
+
+# Steps to run after greet but before the workflow begins.
+# Overrides append. Use for context-heavy setup that should happen
+# once the user has been acknowledged.
+
+activation_steps_append = []
+
+# Persistent facts the workflow keeps in mind for the whole run
+# (standards, compliance constraints, stylistic guardrails).
+# Distinct from the runtime memory sidecar — these are static context
+# loaded on activation. Overrides append.
+#
+# Each entry is either:
+#   - a literal sentence, e.g. "All stories must include testable acceptance criteria."
+#   - a file reference prefixed with `file:`, e.g. "file:{project-root}/docs/standards.md"
+#     (glob patterns are supported; the file's contents are loaded and treated as facts).
+
+persistent_facts = [
+  "file:{project-root}/**/project-context.md",
+]
+
+# Scalar: executed when the workflow reaches its final step,
+# after sprint status is summarized and risks are surfaced. Override wins.
+# Leave empty for no custom post-completion behavior.
+
+on_complete = ""

package/src/{xmc/workflows/5-full-pipeline/auto-full-pipeline → xmc-skills/5-full-pipeline/xiaoma-auto-full-pipeline}/checklist.md

@@ -34,4 +34,10 @@ Use this checklist to validate the full requirements-to-delivery pipeline comple
 - [ ] **No Unhandled HALT Conditions** — All halts properly reported with context
 - [ ] **Unified Completion Report Generated** — Final summary output with all phase statuses
 - [ ] **Machine-Readable Status** — `{implementation_artifacts}/full-pipeline-status.json` generated with accurate data
+- [ ] **Readiness Status Propagated** — `phases.requirements.readiness_status` populated from Phase 1's `pipeline-status.json` (one of `ready` / `gaps` / `blocked` / `not_checked`)
+- [ ] **Warnings Aggregated** — `warnings[]` in `full-pipeline-status.json` contains de-duplicated entries from Phase 1's `pipeline-status.json` (prefix `[phase-1]`) and Phase 3's `story-pipeline-status.json` (prefix `[phase-3:{story_key}]`)
+- [ ] **Atomic Status Write** — `full-pipeline-status.json` written via temp-file-then-rename
 - [ ] **Artifact Consistency** — Sprint status entries match story files on disk
+- [ ] **Bridge-Failure Marker (if Phase 2 failed)** — `{implementation_artifacts}/bridge-failure.json` was written via atomic temp-file-then-rename and contains failure reason, captured `sprint_planning_error`, preserved Phase-1 artifact paths, and recovery instructions
+- [ ] **Per-Story Status Archives Aggregated** — When Phase 3 ran in batch mode, `{implementation_artifacts}/batch-pipeline-status.json` exists and its `archived_status_files[]` was used as the source-of-truth enumeration for per-story Phase-3 warning aggregation
+- [ ] **Deep Prerequisite Probe Passed** — Step-01 verified all transitively-required inner workflows (Phase 1: create-prd, validate-prd, create-epics-and-stories, create-architecture; Phase 3: create-story, dev-story, code-review, qa-generate-e2e-tests, auto-story-pipeline) are present before any sub-pipeline started

package/src/{xmc/workflows/5-full-pipeline/auto-full-pipeline → xmc-skills/5-full-pipeline/xiaoma-auto-full-pipeline}/steps/step-01-init-and-validate.md

@@ -2,6 +2,7 @@
 name: "step-01-init-and-validate"
 description: "Validate unified environment prerequisites, initialize master pipeline state variables, and prepare for end-to-end execution"
 nextStepFile: "./step-02-run-requirements-pipeline.md"
+kind: "init"
 ---
 
 # Step 1 of 5: Initialize and Validate Environment
@@ -34,16 +35,37 @@ Check that the following required artifacts and workflows exist:
 1. **Requirements Document** — `{planning_artifacts}/req.md` must exist
    - If missing: HALT — "No requirements document found at `{planning_artifacts}/req.md`. Create a requirements document before running the full pipeline."
 
-2. **Auto Requirements Pipeline** — `{project-root}/_xiaoma/xmc/workflows/1-analysis/auto-requirements-pipeline/workflow.md` must be readable
+2. **Auto Requirements Pipeline** — `skill:xiaoma-auto-requirements-pipeline` must be readable
    - If missing: HALT — "Auto Requirements Pipeline workflow not found. Verify XiaoMa installation is complete."
 
-3. **Sprint Planning Workflow** — `{project-root}/_xiaoma/xmc/workflows/4-implementation/xiaoma-sprint-planning/workflow.md` must be readable
+3. **Sprint Planning Workflow** — `skill:xiaoma-sprint-planning` must be readable
    - If missing: HALT — "Sprint Planning workflow not found. Verify XiaoMa installation is complete."
 
-4. **Auto Story Pipeline Batch** — `{project-root}/_xiaoma/xmc/workflows/4-implementation/auto-story-pipeline-batch/workflow.md` must be readable
+4. **Auto Story Pipeline Batch** — `skill:xiaoma-auto-story-pipeline-batch` must be readable
    - If missing: HALT — "Auto Story Pipeline Batch workflow not found. Verify XiaoMa installation is complete."
 
-5. **Source Directory** — `src/` directory should exist (warning only if missing)
+5. **Deep Prerequisite Probe — Transitively Required Workflows (fail-fast, mirrors auto-requirements-pipeline A1)** — Probe every workflow that the sub-pipelines will delegate to. Failing here at master step-01 saves the user from waiting through Phase 1 (or worse, mid Phase 3) only to discover an inner workflow is missing.
+
+   **Phase 1 delegated workflows (consumed by auto-requirements-pipeline steps 04/05/06/07):**
+   - `skill:xiaoma-prd` (create intent in step-04, validate intent in step-05)
+   - `skill:xiaoma-create-epics-and-stories`
+   - `skill:xiaoma-create-architecture`
+
+   **Phase 3 delegated workflows (consumed by Agent subprocesses launched in auto-story-pipeline-batch):**
+   - `skill:xiaoma-create-story`
+   - `skill:xiaoma-dev-story`
+   - `skill:xiaoma-code-review`
+   - `skill:xiaoma-qa-generate-e2e-tests`
+   - `skill:xiaoma-auto-story-pipeline` (the per-story step files are read by Agent subprocesses)
+
+   Collect missing entries into `{missing_inner_workflows[]}`.
+   - If `{missing_inner_workflows[]}` is non-empty: HALT — "Required inner workflow(s) missing: {missing_inner_workflows}. Reinstall the affected module(s) before re-running auto-full-pipeline."
+   - If all present: log INFO — "Deep prerequisite probe passed ({N} inner workflows present)."
+
+   **Optional probe (non-blocking, mirrors A1's readiness probe):**
+   - `skill:xiaoma-check-implementation-readiness` — if missing, log INFO — "Implementation-readiness check workflow not found; sub-pipeline step-08 will skip the readiness gate, and Phase-1 `pipeline-status.json` will surface `readiness_status: not_checked`."
+
+6. **Source Directory** — `src/` directory should exist (warning only if missing)
    - If missing: Output WARNING — "No `src/` directory found. Architecture analysis may be limited."
 
 ### 3. Check Existing Artifacts
@@ -140,6 +162,7 @@ Master Step: 1/5
 - Config loaded and all variables resolved
 - Requirements document exists and is readable
 - All three sub-pipeline workflows accessible
+- Deep prerequisite probe passed: all transitively required Phase 1 + Phase 3 inner workflows present
 - Master state variables initialized
 - Resume mode correctly detected (if applicable)
 - Environment summary output
@@ -149,4 +172,5 @@ Master Step: 1/5
 - Missing req.md (cannot proceed without requirements)
 - Missing XiaoMa config (installation incomplete)
 - Missing sub-pipeline workflows (installation incomplete)
+- Missing inner workflows (caught by deep prerequisite probe; previously would surface late inside Phase 1 or Phase 3)
 - Directory creation failures

package/src/{xmc/workflows/5-full-pipeline/auto-full-pipeline → xmc-skills/5-full-pipeline/xiaoma-auto-full-pipeline}/steps/step-02-run-requirements-pipeline.md

@@ -2,6 +2,7 @@
 name: "step-02-run-requirements-pipeline"
 description: "Execute the complete auto-requirements-pipeline to produce PRD, epics, and architecture design"
 nextStepFile: "./step-03-bridge-sprint-planning.md"
+kind: "orchestrator"
 ---
 
 # Step 2 of 5: Execute Requirements Analysis Pipeline
@@ -38,7 +39,7 @@ Delegating to auto-requirements-pipeline...
 
 ### 2. Execute Auto Requirements Pipeline
 
-Read fully and follow: `{project-root}/_xiaoma/xmc/workflows/1-analysis/auto-requirements-pipeline/workflow.md`
+Read fully and follow: `skill:xiaoma-auto-requirements-pipeline`
 
 **Critical Full Pipeline Mode Instructions:**