@zeyue0329/xiaoma-cli 1.13.0 → 1.15.1

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

@@ -1,88 +0,0 @@
-# Discover Inputs Protocol
-
-**Objective:** Intelligently load project files (whole or sharded) based on the workflow's Input Files configuration.
-
-**Prerequisite:** Only execute this protocol if the workflow defines an Input Files section. If no input file patterns are configured, skip this entirely.
-
----
-
-## Step 1: Parse Input File Patterns
-
-- Read the Input Files table from the workflow configuration.
-- For each input group (prd, architecture, epics, ux, etc.), note the **load strategy** if specified.
-
-## Step 2: Load Files Using Smart Strategies
-
-For each pattern in the Input Files table, work through the following substeps in order:
-
-### 2a: Try Sharded Documents First
-
-If a sharded pattern exists for this input, determine the load strategy (defaults to **FULL_LOAD** if not specified), then apply the matching strategy:
-
-#### FULL_LOAD Strategy
-
-Load ALL files in the sharded directory. Use this for PRD, Architecture, UX, brownfield docs, or whenever the full picture is needed.
-
-1. Use the glob pattern to find ALL `.md` files (e.g., `{planning_artifacts}/*architecture*/*.md`).
-2. Load EVERY matching file completely.
-3. Concatenate content in logical order: `index.md` first if it exists, then alphabetical.
-4. Store the combined result in a variable named `{pattern_name_content}` (e.g., `{architecture_content}`).
-
-#### SELECTIVE_LOAD Strategy
-
-Load a specific shard using a template variable. Example: used for epics with `{{epic_num}}`.
-
-1. Check for template variables in the sharded pattern (e.g., `{{epic_num}}`).
-2. If the variable is undefined, ask the user for the value OR infer it from context.
-3. Resolve the template to a specific file path.
-4. Load that specific file.
-5. Store in variable: `{pattern_name_content}`.
-
-#### INDEX_GUIDED Strategy
-
-Load index.md, analyze the structure and description of each doc in the index, then intelligently load relevant docs.
-
-**DO NOT BE LAZY** -- use best judgment to load documents that might have relevant information, even if there is only a 5% chance of relevance.
-
-1. Load `index.md` from the sharded directory.
-2. Parse the table of contents, links, and section headers.
-3. Analyze the workflow's purpose and objective.
-4. Identify which linked/referenced documents are likely relevant.
-   - *Example:* If the workflow is about authentication and the index shows "Auth Overview", "Payment Setup", "Deployment" -- load the auth docs, consider deployment docs, skip payment.
-5. Load all identified relevant documents.
-6. Store combined content in variable: `{pattern_name_content}`.
-
-**When in doubt, LOAD IT** -- context is valuable, and being thorough is better than missing critical info.
-
----
-
-After applying the matching strategy, mark the pattern as **RESOLVED** and move to the next pattern.
-
-### 2b: Try Whole Document if No Sharded Found
-
-If no sharded matches were found OR no sharded pattern exists for this input:
-
-1. Attempt a glob match on the "whole" pattern (e.g., `{planning_artifacts}/*prd*.md`).
-2. If matches are found, load ALL matching files completely (no offset/limit).
-3. Store content in variable: `{pattern_name_content}` (e.g., `{prd_content}`).
-4. Mark pattern as **RESOLVED** and move to the next pattern.
-
-### 2c: Handle Not Found
-
-If no matches were found for either sharded or whole patterns:
-
-1. Set `{pattern_name_content}` to empty string.
-2. Note in session: "No {pattern_name} files found" -- this is not an error, just unavailable. Offer the user a chance to provide the file.
-
-## Step 3: Report Discovery Results
-
-List all loaded content variables with file counts. Example:
-
-```
-OK Loaded {prd_content} from 5 sharded files: prd/index.md, prd/requirements.md, ...
-OK Loaded {architecture_content} from 1 file: Architecture.md
-OK Loaded {epics_content} from selective load: epics/epic-3.md
--- No ux_design files found
-```
-
-This gives the workflow transparency into what context is available.

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

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

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

@@ -1,6 +0,0 @@
----
-name: xiaoma-dev-story
-description: 'Execute story implementation following a context filled story spec file. Use when the user says "dev this story [story file]" or "implement the next story in the sprint plan"'
----
-
-Follow the instructions in ./workflow.md.

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

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

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

@@ -1,6 +0,0 @@
----
-name: xiaoma-retrospective
-description: 'Post-epic review to extract lessons and assess success. Use when the user says "run a retrospective" or "lets retro the epic [epic]"'
----
-
-Follow the instructions in ./workflow.md.

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

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

package/src/xmc/workflows/4-implementation/xiaoma-sprint-planning/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-sprint-planning
-description: 'Generate sprint status tracking from epics. Use when the user says "run sprint planning" or "generate sprint plan"'
----
-
-Follow the instructions in ./workflow.md.

package/src/xmc/workflows/4-implementation/xiaoma-sprint-planning/xiaoma-skill-manifest.yaml

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

package/src/xmc/workflows/4-implementation/xiaoma-sprint-status/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-sprint-status
-description: 'Summarize sprint status and surface risks. Use when the user says "check sprint status" or "show sprint status"'
----
-
-Follow the instructions in ./workflow.md.

package/src/xmc/workflows/4-implementation/xiaoma-sprint-status/xiaoma-skill-manifest.yaml

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

package/src/xmc/workflows/xiaoma-document-project/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-document-project
-description: 'Document brownfield projects for AI context. Use when the user says "document this project" or "generate project docs"'
----
-
-Follow the instructions in ./workflow.md.

package/src/xmc/workflows/xiaoma-document-project/workflow.md

@@ -1,27 +0,0 @@
-# Document Project Workflow
-
-**Goal:** Document brownfield projects for AI context.
-
-**Your Role:** Project documentation specialist.
-- Communicate all responses in {communication_language}
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
-
-- `project_knowledge`
-- `user_name`
-- `communication_language`
-- `document_output_language`
-- `user_skill_level`
-- `date` as system-generated current datetime
-
----
-
-## EXECUTION
-
-Read fully and follow: `./instructions.md`

package/src/xmc/workflows/xiaoma-document-project/xiaoma-skill-manifest.yaml

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

package/src/xmc/workflows/xiaoma-generate-project-context/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-generate-project-context
-description: 'Create project-context.md with AI rules. Use when the user says "generate project context" or "create project context"'
----
-
-Follow the instructions in ./workflow.md.

package/src/xmc/workflows/xiaoma-generate-project-context/workflow.md

@@ -1,43 +0,0 @@
-# Generate Project Context Workflow
-
-**Goal:** Create a concise, optimized `project-context.md` file containing critical rules, patterns, and guidelines that AI agents must follow when implementing code. This file focuses on unobvious details that LLMs need to be reminded of.
-
-**Your Role:** You are a technical facilitator working with a peer to capture the essential implementation rules that will ensure consistent, high-quality code generation across all AI agents working on the project.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **micro-file architecture** for disciplined execution:
-
-- Each step is a self-contained file with embedded rules
-- Sequential progression with user control at each step
-- Document state tracked in frontmatter
-- Focus on lean, LLM-optimized content generation
-- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
-
-- `project_name`, `output_folder`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
-
-### Paths
-
-- `output_file` = `{output_folder}/project-context.md`
-
----
-
-## EXECUTION
-
-Load and execute `./steps/step-01-discover.md` to begin the workflow.
-
-**Note:** Input document discovery and initialization protocols are handled in step-01-discover.md.

package/src/xmc/workflows/xiaoma-generate-project-context/xiaoma-skill-manifest.yaml

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

package/src/xmc/workflows/xiaoma-qa-generate-e2e-tests/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-qa-generate-e2e-tests
-description: 'Generate end to end automated tests for existing features. Use when the user says "create qa automated tests for [feature]"'
----
-
-Follow the instructions in ./workflow.md.

package/src/xmc/workflows/xiaoma-qa-generate-e2e-tests/xiaoma-skill-manifest.yaml

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

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev/SKILL.md

@@ -1,6 +0,0 @@
----
-name: xiaoma-quick-dev
-description: 'Implement a Quick Tech Spec for small changes or features. Use when the user provides a quick tech spec and says "implement this quick spec" or "proceed with implementation of [quick tech spec]"'
----
-
-Follow the instructions in ./workflow.md.

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev/steps/step-01-mode-detection.md

@@ -1,169 +0,0 @@
----
----
-
-# Step 1: Mode Detection
-
-**Goal:** Determine execution mode, capture baseline, handle escalation if needed.
-
----
-
-## STATE VARIABLES (capture now, persist throughout)
-
-These variables MUST be set in this step and available to all subsequent steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start (or "NO_GIT" if not a git repo)
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Path to tech-spec file (if Mode A)
-
----
-
-## EXECUTION SEQUENCE
-
-### 1. Capture Baseline
-
-First, check if the project uses Git version control:
-
-**If Git repo exists** (`.git` directory present or `git rev-parse --is-inside-work-tree` succeeds):
-
-- Run `git rev-parse HEAD` and store result as `{baseline_commit}`
-
-**If NOT a Git repo:**
-
-- Set `{baseline_commit}` = "NO_GIT"
-
-### 2. Load Project Context
-
-Check if `{project_context}` exists (`**/project-context.md`). If found, load it as a foundational reference for ALL implementation decisions.
-
-### 3. Parse User Input
-
-Analyze the user's input to determine mode:
-
-**Mode A: Tech-Spec**
-
-- User provided a path to a tech-spec file (e.g., `quick-dev tech-spec-auth.md`)
-- Load the spec, extract tasks/context/AC
-- Set `{execution_mode}` = "tech-spec"
-- Set `{tech_spec_path}` = provided path
-- **NEXT:** Read fully and follow: `./step-03-execute.md`
-
-**Mode B: Direct Instructions**
-
-- User provided task description directly (e.g., `refactor src/foo.ts...`)
-- Set `{execution_mode}` = "direct"
-- **NEXT:** Evaluate escalation threshold, then proceed
-
----
-
-## ESCALATION THRESHOLD (Mode B only)
-
-Evaluate user input with minimal token usage (no file loading):
-
-**Triggers escalation (if 2+ signals present):**
-
-- Multiple components mentioned (dashboard + api + database)
-- System-level language (platform, integration, architecture)
-- Uncertainty about approach ("how should I", "best way to")
-- Multi-layer scope (UI + backend + data together)
-- Extended timeframe ("this week", "over the next few days")
-
-**Reduces signal:**
-
-- Simplicity markers ("just", "quickly", "fix", "bug", "typo", "simple")
-- Single file/component focus
-- Confident, specific request
-
-Use holistic judgment, not mechanical keyword matching.
-
----
-
-## ESCALATION HANDLING
-
-### No Escalation (simple request)
-
-Display: "**Select:** [P] Plan first (tech-spec) [E] Execute directly"
-
-#### Menu Handling Logic:
-
-- IF P: Direct user to invoke the `xiaoma-quick-spec` skill. **EXIT Quick Dev.**
-- IF E: Ask for any additional guidance, then **NEXT:** Read fully and follow: `./step-02-context-gathering.md`
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed when user makes a selection
-
----
-
-### Escalation Triggered - Level 0-2
-
-Present: "This looks like a focused feature with multiple components."
-
-Display:
-
-**[P] Plan first (tech-spec)** (recommended)
-**[W] Seems bigger than quick-dev** - Recommend the Full XiaoMa Flow PRD Process
-**[E] Execute directly**
-
-#### Menu Handling Logic:
-
-- IF P: Direct user to invoke the `xiaoma-quick-spec` skill. **EXIT Quick Dev.**
-- IF W: Direct user to run the PRD workflow instead. **EXIT Quick Dev.**
-- IF E: Ask for guidance, then **NEXT:** Read fully and follow: `./step-02-context-gathering.md`
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed when user makes a selection
-
----
-
-### Escalation Triggered - Level 3+
-
-Present: "This sounds like platform/system work."
-
-Display:
-
-**[W] Start XiaoMa Method** (recommended)
-**[P] Plan first (tech-spec)** (lighter planning)
-**[E] Execute directly** - feeling lucky
-
-#### Menu Handling Logic:
-
-- IF P: Direct user to invoke the `xiaoma-quick-spec` skill. **EXIT Quick Dev.**
-- IF W: Direct user to run the PRD workflow instead. **EXIT Quick Dev.**
-- IF E: Ask for guidance, then **NEXT:** Read fully and follow: `./step-02-context-gathering.md`
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed when user makes a selection
-
----
-
-## NEXT STEP DIRECTIVE
-
-**CRITICAL:** When this step completes, explicitly state which step to load:
-
-- Mode A (tech-spec): "**NEXT:** read fully and follow: `./step-03-execute.md`"
-- Mode B (direct, [E] selected): "**NEXT:** Read fully and follow: `./step-02-context-gathering.md`"
-- Escalation ([P] or [W]): "**EXITING Quick Dev.** Follow the directed workflow."
-
----
-
-## SUCCESS METRICS
-
-- `{baseline_commit}` captured and stored
-- `{execution_mode}` determined ("tech-spec" or "direct")
-- `{tech_spec_path}` set if Mode A
-- Project context loaded if exists
-- Escalation evaluated appropriately (Mode B)
-- Explicit NEXT directive provided
-
-## FAILURE MODES
-
-- Proceeding without capturing baseline commit
-- Not setting execution_mode variable
-- Loading step-02 when Mode A (tech-spec provided)
-- Attempting to "return" after escalation instead of EXIT
-- No explicit NEXT directive at step completion

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev/steps/step-02-context-gathering.md

@@ -1,114 +0,0 @@
----
----
-
-# Step 2: Context Gathering (Direct Mode)
-
-**Goal:** Quickly gather context for direct instructions - files, patterns, dependencies.
-
-**Note:** This step only runs for Mode B (direct instructions). If `{execution_mode}` is "tech-spec", this step was skipped.
-
----
-
-## AVAILABLE STATE
-
-From step-01:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - Should be "direct"
-- `{project_context}` - Loaded if exists
-
----
-
-## EXECUTION SEQUENCE
-
-### 1. Identify Files to Modify
-
-Based on user's direct instructions:
-
-- Search for relevant files using glob/grep
-- Identify the specific files that need changes
-- Note file locations and purposes
-
-### 2. Find Relevant Patterns
-
-Examine the identified files and their surroundings:
-
-- Code style and conventions used
-- Existing patterns for similar functionality
-- Import/export patterns
-- Error handling approaches
-- Test patterns (if tests exist nearby)
-
-### 3. Note Dependencies
-
-Identify:
-
-- External libraries used
-- Internal module dependencies
-- Configuration files that may need updates
-- Related files that might be affected
-
-### 4. Create Mental Plan
-
-Synthesize gathered context into:
-
-- List of tasks to complete
-- Acceptance criteria (inferred from user request)
-- Order of operations
-- Files to touch
-
----
-
-## PRESENT PLAN
-
-Display to user:
-
-```
-**Context Gathered:**
-
-**Files to modify:**
-- {list files}
-
-**Patterns identified:**
-- {key patterns}
-
-**Plan:**
-1. {task 1}
-2. {task 2}
-...
-
-**Inferred AC:**
-- {acceptance criteria}
-
-Ready to execute? (y/n/adjust)
-```
-
-- **y:** Proceed to execution
-- **n:** Gather more context or clarify
-- **adjust:** Modify the plan based on feedback
-
----
-
-## NEXT STEP DIRECTIVE
-
-**CRITICAL:** When user confirms ready, explicitly state:
-
-- **y:** "**NEXT:** Read fully and follow: `./step-03-execute.md`"
-- **n/adjust:** Continue gathering context, then re-present plan
-
----
-
-## SUCCESS METRICS
-
-- Files to modify identified
-- Relevant patterns documented
-- Dependencies noted
-- Mental plan created with tasks and AC
-- User confirmed readiness to proceed
-
-## FAILURE MODES
-
-- Executing this step when Mode A (tech-spec)
-- Proceeding without identifying files to modify
-- Not presenting plan for user confirmation
-- Missing obvious patterns in existing code

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev/steps/step-03-execute.md

@@ -1,107 +0,0 @@
----
----
-
-# Step 3: Execute Implementation
-
-**Goal:** Implement all tasks, write tests, follow patterns, handle errors.
-
-**Critical:** Continue through ALL tasks without stopping for milestones.
-
----
-
-## AVAILABLE STATE
-
-From previous steps:
-
-- `{baseline_commit}` - Git HEAD at workflow start
-- `{execution_mode}` - "tech-spec" or "direct"
-- `{tech_spec_path}` - Tech-spec file (if Mode A)
-- `{project_context}` - Project patterns (if exists)
-
-From context:
-
-- Mode A: Tasks and AC extracted from tech-spec
-- Mode B: Tasks and AC from step-02 mental plan
-
----
-
-## EXECUTION LOOP
-
-For each task:
-
-### 1. Load Context
-
-- Read files relevant to this task
-- Review patterns from project-context or observed code
-- Understand dependencies
-
-### 2. Implement
-
-- Write code following existing patterns
-- Handle errors appropriately
-- Follow conventions observed in codebase
-- Add appropriate comments where non-obvious
-
-### 3. Test
-
-- Write tests if appropriate for the change
-- Run existing tests to catch regressions
-- Verify the specific AC for this task
-
-### 4. Mark Complete
-
-- Check off task: `- [x] Task N`
-- Continue to next task immediately
-
----
-
-## HALT CONDITIONS
-
-**HALT and request guidance if:**
-
-- 3 consecutive failures on same task
-- Tests fail and fix is not obvious
-- Blocking dependency discovered
-- Ambiguity that requires user decision
-
-**Do NOT halt for:**
-
-- Minor issues that can be noted and continued
-- Warnings that don't block functionality
-- Style preferences (follow existing patterns)
-
----
-
-## CONTINUOUS EXECUTION
-
-**Critical:** Do not stop between tasks for approval.
-
-- Execute all tasks in sequence
-- Only halt for blocking issues
-- Tests failing = fix before continuing
-- Track all completed work for self-check
-
----
-
-## NEXT STEP
-
-When ALL tasks are complete (or halted on blocker), read fully and follow: `./step-04-self-check.md`.
-
----
-
-## SUCCESS METRICS
-
-- All tasks attempted
-- Code follows existing patterns
-- Error handling appropriate
-- Tests written where appropriate
-- Tests passing
-- No unnecessary halts
-
-## FAILURE MODES
-
-- Stopping for approval between tasks
-- Ignoring existing patterns
-- Not running tests after changes
-- Giving up after first failure
-- Not following project-context rules (if exists)