@zeyue0329/xiaoma-cli 1.6.4 → 1.7.0

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev/steps/step-05-adversarial-review.md

@@ -0,0 +1,94 @@
+---
+---
+
+# Step 5: Adversarial Code Review
+
+**Goal:** Construct diff of all changes, invoke adversarial review skill, present findings.
+
+---
+
+## AVAILABLE STATE
+
+From previous steps:
+
+- `{baseline_commit}` - Git HEAD at workflow start (CRITICAL for diff)
+- `{execution_mode}` - "tech-spec" or "direct"
+- `{tech_spec_path}` - Tech-spec file (if Mode A)
+
+---
+
+### 1. Construct Diff
+
+Build complete diff of all changes since workflow started.
+
+### If `{baseline_commit}` is a Git commit hash:
+
+**Tracked File Changes:**
+
+```bash
+git diff {baseline_commit}
+```
+
+**New Untracked Files:**
+Only include untracked files that YOU created during this workflow (steps 2-4).
+Do not include pre-existing untracked files.
+For each new file created, include its full content as a "new file" addition.
+
+### If `{baseline_commit}` is "NO_GIT":
+
+Use best-effort diff construction:
+
+- List all files you modified during steps 2-4
+- For each file, show the changes you made (before/after if you recall, or just current state)
+- Include any new files you created with their full content
+- Note: This is less precise than Git diff but still enables meaningful review
+
+### Capture as {diff_output}
+
+Merge all changes into `{diff_output}`.
+
+**Note:** Do NOT `git add` anything - this is read-only inspection.
+
+---
+
+### 2. Invoke Adversarial Review
+
+With `{diff_output}` constructed, invoke the `xiaoma-review-adversarial-general` skill. If possible, use information asymmetry: invoke the skill in a separate subagent or process with read access to the project, but no context except the `{diff_output}`.
+
+Pass `{diff_output}` as the content to review. The skill should return a list of findings.
+
+---
+
+### 3. Process Findings
+
+Capture the findings from the skill output.
+**If zero findings:** HALT - this is suspicious. Re-analyze or request user guidance.
+Evaluate severity (Critical, High, Medium, Low) and validity (real, noise, undecided).
+DO NOT exclude findings based on severity or validity unless explicitly asked to do so.
+Order findings by severity.
+Number the ordered findings (F1, F2, F3, etc.).
+If TodoWrite or similar tool is available, turn each finding into a TODO, include ID, severity, validity, and description in the TODO; otherwise present findings as a table with columns: ID, Severity, Validity, Description
+
+---
+
+## NEXT STEP
+
+With findings in hand, read fully and follow: `./step-06-resolve-findings.md` for user to choose resolution approach.
+
+---
+
+## SUCCESS METRICS
+
+- Diff constructed from baseline_commit
+- New files included in diff
+- Skill invoked with diff as input
+- Findings received
+- Findings processed into TODOs or table and presented to user
+
+## FAILURE MODES
+
+- Missing baseline_commit (can't construct accurate diff)
+- Not including new untracked files in diff
+- Invoking skill without providing diff input
+- Accepting zero findings without questioning
+- Presenting fewer findings than the review skill returned without explicit instruction to do so

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev/steps/step-06-resolve-findings.md

@@ -0,0 +1,144 @@
+---
+---
+
+# Step 6: Resolve Findings
+
+**Goal:** Handle adversarial review findings interactively, apply fixes, finalize tech-spec.
+
+---
+
+## 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)
+- Findings table from step-05
+
+---
+
+## RESOLUTION OPTIONS
+
+Present: "How would you like to handle these findings?"
+
+Display:
+
+**[W] Walk through** - Discuss each finding individually
+**[F] Fix automatically** - Automatically fix issues classified as "real"
+**[S] Skip** - Acknowledge and proceed to commit
+
+### Menu Handling Logic:
+
+- IF W: Execute WALK THROUGH section below
+- IF F: Execute FIX AUTOMATICALLY section below
+- IF S: Execute SKIP section below
+
+### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed when user makes a selection
+
+---
+
+## WALK THROUGH [W]
+
+For each finding in order:
+
+1. Present the finding with context
+2. Ask: **fix now / skip / discuss**
+3. If fix: Apply the fix immediately
+4. If skip: Note as acknowledged, continue
+5. If discuss: Provide more context, re-ask
+6. Move to next finding
+
+After all findings processed, summarize what was fixed/skipped.
+
+---
+
+## FIX AUTOMATICALLY [F]
+
+1. Filter findings to only those classified as "real"
+2. Apply fixes for each real finding
+3. Report what was fixed:
+
+```
+**Auto-fix Applied:**
+- F1: {description of fix}
+- F3: {description of fix}
+...
+
+Skipped (noise/uncertain): F2, F4
+```
+
+---
+
+## SKIP [S]
+
+1. Acknowledge all findings were reviewed
+2. Note that user chose to proceed without fixes
+3. Continue to completion
+
+---
+
+## UPDATE TECH-SPEC (Mode A only)
+
+If `{execution_mode}` is "tech-spec":
+
+1. Load `{tech_spec_path}`
+2. Update status to "Completed"
+3. Add review notes:
+   ```
+   ## Review Notes
+   - Adversarial review completed
+   - Findings: {count} total, {fixed} fixed, {skipped} skipped
+   - Resolution approach: {walk-through/auto-fix/skip}
+   ```
+4. Save changes
+
+---
+
+## COMPLETION OUTPUT
+
+```
+**Review complete. Ready to commit.**
+
+**Implementation Summary:**
+- {what was implemented}
+- Files modified: {count}
+- Tests: {status}
+- Review findings: {X} addressed, {Y} skipped
+
+{Explain what was implemented based on user_skill_level}
+```
+
+---
+
+## WORKFLOW COMPLETE
+
+This is the final step. The Quick Dev workflow is now complete.
+
+User can:
+
+- Commit changes
+- Run additional tests
+- Start new Quick Dev session
+
+---
+
+## SUCCESS METRICS
+
+- User presented with resolution options
+- Chosen approach executed correctly
+- Fixes applied cleanly (if applicable)
+- Tech-spec updated with final status (Mode A)
+- Completion summary provided
+- User understands what was implemented
+
+## FAILURE MODES
+
+- Not presenting resolution options
+- Auto-fixing "noise" or "uncertain" findings
+- Not updating tech-spec after resolution (Mode A)
+- No completion summary
+- Leaving user unclear on next steps

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

@@ -0,0 +1,38 @@
+# Quick Dev Workflow
+
+**Goal:** Execute implementation tasks efficiently, either from a tech-spec or direct user instructions.
+
+**Your Role:** You are an elite full-stack developer executing tasks autonomously. Follow patterns, ship code, run tests. Every response moves the project forward.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for focused execution:
+
+- Each step loads fresh to combat "lost in the middle"
+- State persists via variables: `{baseline_commit}`, `{execution_mode}`, `{tech_spec_path}`
+- Sequential progression through implementation phases
+
+---
+
+## INITIALIZATION
+
+### Configuration Loading
+
+Load config from `{project-root}/_xiaoma/xmc/config.yaml` and resolve:
+
+- `user_name`, `communication_language`, `user_skill_level`
+- `planning_artifacts`, `implementation_artifacts`
+- `date` as system-generated current datetime
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+### Paths
+
+- `project_context` = `**/project-context.md` (load if exists)
+
+---
+
+## EXECUTION
+
+Read fully and follow: `./steps/step-01-mode-detection.md` to begin the workflow.

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev/xiaoma-skill-manifest.yaml

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

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

@@ -1,6 +1,6 @@
 ---
 name: xiaoma-quick-dev-new-preview
-description: 'Implements any user intent, requirement, story, bug fix or change request by producing clean working code artifacts that follow the projects existing architecture, patterns and conventions. Use when the user wants to build, fix, tweak, refactor, add or modify any code, component or feature.'
+description: 'Implements any user intent, requirement, story, bug fix or change request by producing clean working code artifacts that follow the project''s existing architecture, patterns and conventions. Use when the user wants to build, fix, tweak, refactor, add or modify any code, component or feature.'
 ---
 
 Follow the instructions in [workflow.md](workflow.md).

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

@@ -0,0 +1,6 @@
+---
+name: bmad-quick-dev-new-preview
+description: 'Implements any user intent, requirement, story, bug fix or change request by producing clean working code artifacts that follow the project''s existing architecture, patterns and conventions. Use when the user wants to build, fix, tweak, refactor, add or modify any code, component or feature.'
+---
+
+Follow the instructions in [workflow.md](workflow.md).

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev-new-preview/steps/step-01-clarify-and-route.md

@@ -1,7 +1,4 @@
 ---
-name: 'step-01-clarify-and-route'
-description: 'Capture intent, route to execution path'
-
 wipFile: '{implementation_artifacts}/tech-spec-wip.md'
 deferred_work_file: '{implementation_artifacts}/deferred-work.md'
 spec_file: '' # set at runtime before leaving this step
@@ -50,5 +47,5 @@ spec_file: '' # set at runtime before leaving this step
 
 ## NEXT
 
-- One-shot / ready-for-dev: Read fully and follow `./steps/step-03-implement.md`
-- Plan-code-review: Read fully and follow `./steps/step-02-plan.md`
+- One-shot / ready-for-dev: Read fully and follow `./step-03-implement.md`
+- Plan-code-review: Read fully and follow `./step-02-plan.md`

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev-new-preview/steps/step-02-plan.md

@@ -1,8 +1,4 @@
 ---
-name: 'step-02-plan'
-description: 'Investigate, generate spec, present for approval'
-
-templateFile: '../tech-spec-template.md'
 wipFile: '{implementation_artifacts}/tech-spec-wip.md'
 deferred_work_file: '{implementation_artifacts}/deferred-work.md'
 ---
@@ -17,7 +13,7 @@ deferred_work_file: '{implementation_artifacts}/deferred-work.md'
 ## INSTRUCTIONS
 
 1. Investigate codebase. _Isolate deep exploration in sub-agents/tasks where available. To prevent context snowballing, instruct subagents to give you distilled summaries only._
-2. Read `{templateFile}` fully. Fill it out based on the intent and investigation, and write the result to `{wipFile}`.
+2. Read `../tech-spec-template.md` fully. Fill it out based on the intent and investigation, and write the result to `{wipFile}`.
 3. Self-review against READY FOR DEVELOPMENT standard.
 4. If intent gaps exist, do not fantasize, do not leave open questions, HALT and ask the human.
 5. Token count check (see SCOPE STANDARD). If spec exceeds 1600 tokens:
@@ -36,4 +32,4 @@ Present summary. If token count exceeded 1600 and user chose [K], include the to
 
 ## NEXT
 
-Read fully and follow `./steps/step-03-implement.md`
+Read fully and follow `./step-03-implement.md`

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev-new-preview/steps/step-03-implement.md

@@ -1,6 +1,4 @@
 ---
-name: 'step-03-implement'
-description: 'Execute implementation directly or via sub-agent. Local only.'
 ---
 
 # Step 3: Implement
@@ -32,4 +30,4 @@ Otherwise (`execution_mode = "plan-code-review"`): hand `{spec_file}` to a sub-a
 
 ## NEXT
 
-Read fully and follow `./steps/step-04-review.md`
+Read fully and follow `./step-04-review.md`

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev-new-preview/steps/step-04-review.md

@@ -1,7 +1,4 @@
 ---
-name: 'step-04-review'
-description: 'Adversarial review, classify findings, optional spec loop'
-
 deferred_work_file: '{implementation_artifacts}/deferred-work.md'
 specLoopIteration: 1
 ---
@@ -43,13 +40,11 @@ Do NOT `git add` anything — this is read-only inspection.
    - **defer** — pre-existing issue not caused by this story, surfaced incidentally by the review. Collect for later focused attention.
    - **reject** — noise. Drop silently. When unsure between defer and reject, prefer reject — only defer findings you are confident are real.
 3. Process findings in cascading order. If intent_gap or bad_spec findings exist, they trigger a loopback — lower findings are moot since code will be re-derived. If neither exists, process patch and defer normally. Increment `{specLoopIteration}` on each loopback. If it exceeds 5, HALT and escalate to the human. On any loopback, re-evaluate routing — if scope has grown beyond one-shot, escalate `execution_mode` to plan-code-review.
-   - **intent_gap** — Root cause is inside `<frozen-after-approval>`. Revert code changes. Loop back to the human to resolve, then re-run steps 2–4.
-   - **bad_spec** — Root cause is outside `<frozen-after-approval>`. Before reverting code: extract KEEP instructions for positive preservation (what worked well and must survive re-derivation). Revert code changes. Read the `## Spec Change Log` in `{spec_file}` and strictly respect all logged constraints when amending the non-frozen sections that contain the root cause. Append a new change-log entry recording: the triggering finding, what was amended, the known-bad state avoided, and the KEEP instructions. Read fully and follow `./steps/step-03-implement.md` to re-derive the code, then this step will run again.
+   - **intent_gap** — Root cause is inside `<frozen-after-approval>`. Revert code changes. Loop back to the human to resolve. Once resolved, read fully and follow `./step-02-plan.md` to re-run steps 2–4.
+   - **bad_spec** — Root cause is outside `<frozen-after-approval>`. Before reverting code: extract KEEP instructions for positive preservation (what worked well and must survive re-derivation). Revert code changes. Read the `## Spec Change Log` in `{spec_file}` and strictly respect all logged constraints when amending the non-frozen sections that contain the root cause. Append a new change-log entry recording: the triggering finding, what was amended, the known-bad state avoided, and the KEEP instructions. Read fully and follow `./step-03-implement.md` to re-derive the code, then this step will run again.
    - **patch** — Auto-fix. These are the only findings that survive loopbacks.
    - **defer** — Append to `{deferred_work_file}`.
    - **reject** — Drop silently.
-4. Commit.
-
 ## NEXT
 
-Read fully and follow `./steps/step-05-present.md`
+Read fully and follow `./step-05-present.md`

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev-new-preview/steps/step-05-present.md

@@ -1,6 +1,4 @@
 ---
-name: 'step-05-present'
-description: 'Present findings, get approval, create PR'
 ---
 
 # Step 5: Present
@@ -12,8 +10,8 @@ description: 'Present findings, get approval, create PR'
 
 ## INSTRUCTIONS
 
-1. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
-2. Change `{spec_file}` status to `done` in the frontmatter.
+1. Change `{spec_file}` status to `done` in the frontmatter.
+2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
 3. Display summary of your work to the user, including the commit hash if one was created. Advise on how to review the changes. Offer to push and/or create a pull request.
 
 Workflow complete.

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-dev-new-preview/workflow.md

@@ -1,9 +1,5 @@
 ---
 main_config: '{project-root}/_xiaoma/xmc/config.yaml'
-
-# Related workflows
-advanced_elicitation: '{project-root}/_xiaoma/core/workflows/advanced-elicitation/workflow.md'
-party_mode_exec: '{project-root}/_xiaoma/core/workflows/party-mode/workflow.md'
 ---
 
 # Quick Dev New Preview Workflow
@@ -76,7 +72,6 @@ YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `
 
 ### 2. Paths
 
-- `templateFile` = `./tech-spec-template.md`
 - `wipFile` = `{implementation_artifacts}/tech-spec-wip.md`
 
 ### 3. First Step Execution

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

@@ -0,0 +1,6 @@
+---
+name: xiaoma-quick-spec
+description: 'Very quick process to create implementation-ready quick specs for small changes or features. Use when the user says "create a quick spec" or "generate a quick tech spec"'
+---
+
+Follow the instructions in [workflow.md](workflow.md).

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

@@ -0,0 +1,6 @@
+---
+name: bmad-quick-spec
+description: 'Very quick process to create implementation-ready quick specs for small changes or features. Use when the user says "create a quick spec" or "generate a quick tech spec"'
+---
+
+Follow the instructions in [workflow.md](workflow.md).

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-spec/steps/step-01-understand.md

@@ -0,0 +1,185 @@
+---
+wipFile: '{implementation_artifacts}/tech-spec-wip.md'
+---
+
+# Step 1: Analyze Requirement Delta
+
+**Progress: Step 1 of 4** - Next: Deep Investigation
+
+## RULES:
+
+- MUST NOT skip steps.
+- MUST NOT optimize sequence.
+- MUST follow exact instructions.
+- MUST NOT look ahead to future steps.
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## CONTEXT:
+
+- Variables from `workflow.md` are available in memory.
+- Focus: Define the technical requirement delta and scope.
+- Investigation: Perform surface-level code scans ONLY to verify the delta. Reserve deep dives into implementation consequences for Step 2.
+- Objective: Establish a verifiable delta between current state and target state.
+
+## SEQUENCE OF INSTRUCTIONS
+
+### 0. Check for Work in Progress
+
+a) **Before anything else, check if `{wipFile}` exists:**
+
+b) **IF WIP FILE EXISTS:**
+
+1. Read the frontmatter and extract: `title`, `slug`, `stepsCompleted`
+2. Calculate progress: `lastStep = max(stepsCompleted)`
+3. Present to user:
+
+```
+Hey {user_name}! Found a tech-spec in progress:
+
+**{title}** - Step {lastStep} of 4 complete
+
+Is this what you're here to continue?
+
+[Y] Yes, pick up where I left off
+[N] No, archive it and start something new
+```
+
+4. **HALT and wait for user selection.**
+
+a) **Menu Handling:**
+
+- **[Y] Continue existing:**
+  - Jump directly to the appropriate step based on `stepsCompleted`:
+    - `[1]` → Read fully and follow: `./step-02-investigate.md` (Step 2)
+    - `[1, 2]` → Read fully and follow: `./step-03-generate.md` (Step 3)
+    - `[1, 2, 3]` → Read fully and follow: `./step-04-review.md` (Step 4)
+- **[N] Archive and start fresh:**
+  - Rename `{wipFile}` to `{implementation_artifacts}/tech-spec-{slug}-archived-{date}.md`
+
+### 1. Greet and Ask for Initial Request
+
+a) **Greet the user briefly:**
+
+"Hey {user_name}! What are we building today?"
+
+b) **Get their initial description.** Don't ask detailed questions yet - just understand enough to know where to look.
+
+### 2. Quick Orient Scan
+
+a) **Before asking detailed questions, do a rapid scan to understand the landscape:**
+
+b) **Check for existing context docs:**
+
+- Check `{implementation_artifacts}` and `{planning_artifacts}`for planning documents (PRD, architecture, epics, research)
+- Check for `**/project-context.md` - if it exists, skim for patterns and conventions
+- Check for any existing stories or specs related to user's request
+
+c) **If user mentioned specific code/features, do a quick scan:**
+
+- Search for relevant files/classes/functions they mentioned
+- Skim the structure (don't deep-dive yet - that's Step 2)
+- Note: tech stack, obvious patterns, file locations
+
+d) **Build mental model:**
+
+- What's the likely landscape for this feature?
+- What's the likely scope based on what you found?
+- What questions do you NOW have, informed by the code?
+
+**This scan should take < 30 seconds. Just enough to ask smart questions.**
+
+### 3. Ask Informed Questions
+
+a) **Now ask clarifying questions - but make them INFORMED by what you found:**
+
+Instead of generic questions like "What's the scope?", ask specific ones like:
+- "`AuthService` handles validation in the controller — should the new field follow that pattern or move it to a dedicated validator?"
+- "`NavigationSidebar` component uses local state for the 'collapsed' toggle — should we stick with that or move it to the global store?"
+- "The epics doc mentions X - is this related?"
+
+**Adapt to {user_skill_level}.** Technical users want technical questions. Non-technical users need translation.
+
+b) **If no existing code is found:**
+
+- Ask about intended architecture, patterns, constraints
+- Ask what similar systems they'd like to emulate
+
+### 4. Capture Core Understanding
+
+a) **From the conversation, extract and confirm:**
+
+- **Title**: A clear, concise name for this work
+- **Slug**: URL-safe version of title (lowercase, hyphens, no spaces)
+- **Problem Statement**: What problem are we solving?
+- **Solution**: High-level approach (1-2 sentences)
+- **In Scope**: What's included
+- **Out of Scope**: What's explicitly NOT included
+
+b) **Ask the user to confirm the captured understanding before proceeding.**
+
+### 5. Initialize WIP File
+
+a) **Create the tech-spec WIP file:**
+
+1. Copy template from `../tech-spec-template.md`
+2. Write to `{wipFile}`
+3. Update frontmatter with captured values:
+   ```yaml
+   ---
+   title: '{title}'
+   slug: '{slug}'
+   created: '{date}'
+   status: 'in-progress'
+   stepsCompleted: [1]
+   tech_stack: []
+   files_to_modify: []
+   code_patterns: []
+   test_patterns: []
+   ---
+   ```
+4. Fill in Overview section with Problem Statement, Solution, and Scope
+5. Fill in Context for Development section with any technical preferences or constraints gathered during informed discovery.
+6. Write the file
+
+b) **Report to user:**
+
+"Created: `{wipFile}`
+
+**Captured:**
+
+- Title: {title}
+- Problem: {problem_statement_summary}
+- Scope: {scope_summary}"
+
+### 6. Present Checkpoint Menu
+
+a) **Display menu:**
+
+Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Deep Investigation (Step 2 of 4)"
+
+b) **HALT and wait for user selection.**
+
+#### Menu Handling Logic:
+
+- IF A: Invoke the `xiaoma-advanced-elicitation` skill with current tech-spec content, process enhanced insights, ask user "Accept improvements? (y/n)", if yes update WIP file then redisplay menu, if no keep original then redisplay menu
+- IF P: Invoke the `xiaoma-party-mode` skill with current tech-spec content, process collaborative insights, ask user "Accept changes? (y/n)", if yes update WIP file then redisplay menu, if no keep original then redisplay menu
+- IF C: Verify `{wipFile}` has `stepsCompleted: [1]`, then read fully and follow: `./step-02-investigate.md`
+- IF Any other comments or queries: respond helpfully then redisplay menu
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- ONLY proceed to next step when user selects 'C'
+- After A or P execution, return to this menu
+
+---
+
+## REQUIRED OUTPUTS:
+
+- MUST initialize WIP file with captured metadata.
+
+## VERIFICATION CHECKLIST:
+
+- [ ] WIP check performed FIRST before any greeting.
+- [ ] `{wipFile}` created with correct frontmatter, Overview, Context for Development, and `stepsCompleted: [1]`.
+- [ ] User selected [C] to continue.