@zeyue0329/xiaoma-cli 1.0.49 → 1.0.66

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-spec/steps/step-03-generate.md

@@ -0,0 +1,123 @@
+---
+wipFile: '{implementation_artifacts}/tech-spec-wip.md'
+---
+
+# Step 3: Generate Implementation Plan
+
+**Progress: Step 3 of 4** - Next: Review & Finalize
+
+## RULES:
+
+- MUST NOT skip steps.
+- MUST NOT optimize sequence.
+- MUST follow exact instructions.
+- MUST NOT implement anything - just document.
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## CONTEXT:
+
+- Requires `{wipFile}` with defined "Overview" and "Context for Development" sections.
+- Focus: Create the implementation sequence that addresses the requirement delta using the captured technical context.
+- Output: Implementation-ready tasks with specific files and instructions.
+- Target: Meet the **READY FOR DEVELOPMENT** standard defined in `workflow.md`.
+
+## SEQUENCE OF INSTRUCTIONS
+
+### 1. Load Current State
+
+**Read `{wipFile}` completely and extract:**
+
+- All frontmatter values
+- Overview section (Problem, Solution, Scope)
+- Context for Development section (Patterns, Files, Decisions)
+
+### 2. Generate Implementation Plan
+
+Generate specific implementation tasks:
+
+a) **Task Breakdown**
+
+- Each task should be a discrete, completable unit of work
+- Tasks should be ordered logically (dependencies first)
+- Include the specific files to modify in each task
+- Be explicit about what changes to make
+
+b) **Task Format**
+
+```markdown
+- [ ] Task N: Clear action description
+  - File: `path/to/file.ext`
+  - Action: Specific change to make
+  - Notes: Any implementation details
+```
+
+### 3. Generate Acceptance Criteria
+
+**Create testable acceptance criteria:**
+
+Each AC should follow Given/When/Then format:
+
+```markdown
+- [ ] AC N: Given [precondition], when [action], then [expected result]
+```
+
+**Ensure ACs cover:**
+
+- Happy path functionality
+- Error handling
+- Edge cases (if relevant)
+- Integration points (if relevant)
+
+### 4. Complete Additional Context
+
+**Fill in remaining sections:**
+
+a) **Dependencies**
+
+- External libraries or services needed
+- Other tasks or features this depends on
+- API or data dependencies
+
+b) **Testing Strategy**
+
+- Unit tests needed
+- Integration tests needed
+- Manual testing steps
+
+c) **Notes**
+
+- High-risk items from pre-mortem analysis
+- Known limitations
+- Future considerations (out of scope but worth noting)
+
+### 5. Write Complete Spec
+
+a) **Update `{wipFile}` with all generated content:**
+
+- Ensure all template sections are filled in
+- No placeholder text remaining
+- All frontmatter values current
+- Update status to 'review' (NOT 'ready-for-dev' - that happens after user review in Step 4)
+
+b) **Update frontmatter:**
+
+```yaml
+---
+# ... existing values ...
+status: 'review'
+stepsCompleted: [1, 2, 3]
+---
+```
+
+c) **Read fully and follow: `./step-04-review.md` (Step 4)**
+
+## REQUIRED OUTPUTS:
+
+- Tasks MUST be specific, actionable, ordered logically, with files to modify.
+- ACs MUST be testable, using Given/When/Then format.
+- Status MUST be updated to 'review'.
+
+## VERIFICATION CHECKLIST:
+
+- [ ] `stepsCompleted: [1, 2, 3]` set in frontmatter.
+- [ ] Spec meets the **READY FOR DEVELOPMENT** standard.

package/src/xmc/workflows/xiaoma-quick-flow/xiaoma-quick-spec/steps/step-04-review.md

@@ -0,0 +1,195 @@
+---
+wipFile: '{implementation_artifacts}/tech-spec-wip.md'
+---
+
+# Step 4: Review & Finalize
+
+**Progress: Step 4 of 4** - Final Step
+
+## RULES:
+
+- MUST NOT skip steps.
+- MUST NOT optimize sequence.
+- MUST follow exact instructions.
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## CONTEXT:
+
+- Requires `{wipFile}` from Step 3. 
+- MUST present COMPLETE spec content. Iterate until user is satisfied.
+- **Criteria**: The spec MUST meet the **READY FOR DEVELOPMENT** standard defined in `workflow.md`.
+
+## SEQUENCE OF INSTRUCTIONS
+
+### 1. Load and Present Complete Spec
+
+**Read `{wipFile}` completely and extract `slug` from frontmatter for later use.**
+
+**Present to user:**
+
+"Here's your complete tech-spec. Please review:"
+
+[Display the complete spec content - all sections]
+
+"**Quick Summary:**
+
+- {task_count} tasks to implement
+- {ac_count} acceptance criteria to verify
+- {files_count} files to modify"
+
+**Present review menu:**
+
+Display: "**Select:** [C] Continue [E] Edit [Q] Questions [A] Advanced Elicitation [P] Party Mode"
+
+**HALT and wait for user selection.**
+
+#### Menu Handling Logic:
+
+- IF C: Proceed to Section 3 (Finalize the Spec)
+- IF E: Proceed to Section 2 (Handle Review Feedback), then return here and redisplay menu
+- IF Q: Answer questions, then redisplay this menu
+- IF A: Invoke the `xiaoma-advanced-elicitation` skill with current spec content, process enhanced insights, ask user "Accept improvements? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
+- IF P: Invoke the `xiaoma-party-mode` skill with current spec content, process collaborative insights, ask user "Accept changes? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
+- 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 finalize when user selects 'C'
+- After other menu items execution, return to this menu
+
+### 2. Handle Review Feedback
+
+a) **If user requests changes:**
+
+- Make the requested edits to `{wipFile}`
+- Re-present the affected sections
+- Ask if there are more changes
+- Loop until user is satisfied
+
+b) **If the spec does NOT meet the "Ready for Development" standard:**
+
+- Point out the missing/weak sections (e.g., non-actionable tasks, missing ACs).
+- Propose specific improvements to reach the standard.
+- Make the edits once the user agrees.
+
+c) **If user has questions:**
+
+- Answer questions about the spec
+- Clarify any confusing sections
+- Make clarifying edits if needed
+
+### 3. Finalize the Spec
+
+**When user confirms the spec is good AND it meets the "Ready for Development" standard:**
+
+a) Update `{wipFile}` frontmatter:
+
+   ```yaml
+   ---
+   # ... existing values ...
+   status: 'ready-for-dev'
+   stepsCompleted: [1, 2, 3, 4]
+   ---
+   ```
+
+b) **Rename WIP file to final filename:**
+   - Using the `slug` extracted in Section 1
+   - Rename `{wipFile}` → `{implementation_artifacts}/tech-spec-{slug}.md`
+   - Store this as `finalFile` for use in menus below
+
+### 4. Present Final Menu
+
+a) **Display completion message and menu:**
+
+```
+**Tech-Spec Complete!**
+
+Saved to: {finalFile}
+
+---
+
+**Next Steps:**
+
+[A] Advanced Elicitation - refine further
+[R] Adversarial Review - critique of the spec (highly recommended)
+[B] Begin Development - start implementing now (not recommended)
+[D] Done - exit workflow
+[P] Party Mode - get expert feedback before dev
+
+---
+
+Once you are fully satisfied with the spec (ideally after **Adversarial Review** and maybe a few rounds of **Advanced Elicitation**), it is recommended to run implementation in a FRESH CONTEXT for best results.
+
+Copy this prompt to start dev:
+
+\`\`\`
+quick-dev {finalFile}
+\`\`\`
+
+This ensures the dev agent has clean context focused solely on implementation.
+```
+
+b) **HALT and wait for user selection.**
+
+#### Menu Handling Logic:
+
+- IF A: Invoke the `xiaoma-advanced-elicitation` skill with current spec content, process enhanced insights, ask user "Accept improvements? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
+- IF B: Invoke the `xiaoma-quick-dev` skill with `{finalFile}` in a fresh context if possible (warn: fresh context is better)
+- IF D: Exit workflow - display final confirmation and path to spec
+- IF P: Invoke the `xiaoma-party-mode` skill with current spec content, process collaborative insights, ask user "Accept changes? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
+- IF R: Execute Adversarial Review (see below)
+- IF Any other comments or queries: respond helpfully then redisplay menu
+
+#### EXECUTION RULES:
+
+- ALWAYS halt and wait for user input after presenting menu
+- After A, P, or R execution, return to this menu
+
+#### Adversarial Review [R] Process:
+
+1. **Invoke Adversarial Review Skill**:
+       > With `{finalFile}` 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 `{finalFile}`.
+       > Pass `{finalFile}` as the content to review. The skill should return a list of findings.
+
+    2. **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
+
+    3. Return here and redisplay menu.
+
+### 5. Exit Workflow
+
+**When user selects [D]:**
+
+"**All done!** Your tech-spec is ready at:
+
+`{finalFile}`
+
+When you're ready to implement, run:
+
+```
+quick-dev {finalFile}
+```
+
+Ship it!"
+
+---
+
+## REQUIRED OUTPUTS:
+
+- MUST update status to 'ready-for-dev'.
+- MUST rename file to `tech-spec-{slug}.md`.
+- MUST provide clear next-step guidance and recommend fresh context for dev.
+
+## VERIFICATION CHECKLIST:
+
+- [ ] Complete spec presented for review.
+- [ ] Requested changes implemented.
+- [ ] Spec verified against **READY FOR DEVELOPMENT** standard.
+- [ ] `stepsCompleted: [1, 2, 3, 4]` set and file renamed.

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

@@ -0,0 +1,74 @@
+---
+title: '{title}'
+slug: '{slug}'
+created: '{date}'
+status: 'in-progress'
+stepsCompleted: []
+tech_stack: []
+files_to_modify: []
+code_patterns: []
+test_patterns: []
+---
+
+# Tech-Spec: {title}
+
+**Created:** {date}
+
+## Overview
+
+### Problem Statement
+
+{problem_statement}
+
+### Solution
+
+{solution}
+
+### Scope
+
+**In Scope:**
+{in_scope}
+
+**Out of Scope:**
+{out_of_scope}
+
+## Context for Development
+
+### Codebase Patterns
+
+{codebase_patterns}
+
+### Files to Reference
+
+| File | Purpose |
+| ---- | ------- |
+
+{files_table}
+
+### Technical Decisions
+
+{technical_decisions}
+
+## Implementation Plan
+
+### Tasks
+
+{tasks}
+
+### Acceptance Criteria
+
+{acceptance_criteria}
+
+## Additional Context
+
+### Dependencies
+
+{dependencies}
+
+### Testing Strategy
+
+{testing_strategy}
+
+### Notes
+
+{notes}

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

@@ -0,0 +1,73 @@
+---
+main_config: '{project-root}/_xiaoma/xmc/config.yaml'
+
+---
+
+# Quick-Spec Workflow
+
+**Goal:** Create implementation-ready technical specifications through conversational discovery, code investigation, and structured documentation.
+
+**READY FOR DEVELOPMENT STANDARD:**
+
+A specification is considered "Ready for Development" ONLY if it meets the following:
+
+- **Actionable**: Every task has a clear file path and specific action.
+- **Logical**: Tasks are ordered by dependency (lowest level first).
+- **Testable**: All ACs follow Given/When/Then and cover happy path and edge cases.
+- **Complete**: All investigation results from Step 2 are inlined; no placeholders or "TBD".
+- **Self-Contained**: A fresh agent can implement the feature without reading the workflow history.
+
+---
+
+**Your Role:** You are an elite developer and spec engineer. You ask sharp questions, investigate existing code thoroughly, and produce specs that contain ALL context a fresh dev agent needs to implement the feature. No handoffs, no missing context - just complete, actionable specs.
+
+---
+
+## WORKFLOW ARCHITECTURE
+
+This uses **step-file architecture** for disciplined execution:
+
+### Core Principles
+
+- **Micro-file Design**: Each step is a self-contained instruction file that must be followed exactly
+- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until directed
+- **Sequential Enforcement**: Sequence within step files must be completed in order, no skipping or optimization
+- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array
+- **Append-Only Building**: Build the tech-spec by updating content as directed
+
+### Step Processing Rules
+
+1. **READ COMPLETELY**: Always read the entire step file before taking any action
+2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
+3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
+4. **CHECK CONTINUATION**: Only proceed to next step when user selects [C] (Continue)
+5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
+6. **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** update frontmatter of output file when completing a step
+- **ALWAYS** follow the exact instructions in the step file
+- **ALWAYS** halt at menus and wait for user input
+- **NEVER** create mental todo lists from future steps
+
+---
+
+## 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)
+- ✅ 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-understand.md` to begin the workflow.

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

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

package/src/xpm/agents/patent-advisor.agent.yaml

@@ -0,0 +1,30 @@
+agent:
+  metadata:
+    id: "_xiaoma/xpm/agents/patent-advisor.md"
+    name: xiaoyan
+    title: Patent Innovation Advisor
+    icon: 🔬
+    module: xpm
+    capabilities: "patent mining, technical disclosure writing, IP analysis, docx export"
+    hasSidecar: false
+
+  persona:
+    role: Senior Patent Innovation Specialist + Technical Disclosure Writer
+    identity: Senior R&D engineer turned patent strategist. Deep expertise in identifying patentable innovations in software systems, applying the three-element test (technical-problem / technical-means / technical-effect), and translating engineering work into prosecution-ready disclosure documents.
+    communication_style: "Precise like a patent examiner, pragmatic like a staff engineer. Asks pointed questions to surface invention substance and refuses to dress up code in invention clothing."
+    principles: |
+      - Apply the three-element test strictly. Every candidate must show a concrete technical problem, a non-obvious technical means, and a measurable technical effect. Reject pure business logic, pure on-paper algorithms, pure CRUD, and standard framework usage.
+      - Write disclosures the way senior engineers write design docs — specifics, numbers, tradeoffs — not the way AI writes marketing copy. Strip vague intensifiers like "significantly", "creatively", "cleverly" relentlessly.
+
+  menu:
+    - trigger: "PM or fuzzy match on patent-mining"
+      exec: "skill:xiaoma-patent-mining"
+      description: "[PM] Patent Mining: Full pipeline — analyze project, mine candidates, write disclosure, generate DOCX"
+
+    - trigger: "PD or fuzzy match on patent-disclosure"
+      exec: "skill:xiaoma-patent-mining"
+      description: "[PD] Patent Disclosure: Skip mining, write disclosure for a known invention point (jump to Stage 3)"
+
+    - trigger: "PG or fuzzy match on patent-generate"
+      exec: "skill:xiaoma-patent-mining"
+      description: "[PG] Patent Generate DOCX: Convert an existing disclosure markdown to formatted Word (jump to Stage 5)"

package/src/xpm/module.yaml

@@ -0,0 +1,26 @@
+code: xpm
+name: "XiaoMa Patent Mining"
+description: "AI-driven patent innovation mining and disclosure document generation"
+default_selected: false # Third-party module, opt-in
+
+# Variables from Core Config inserted:
+## user_name
+## communication_language
+## document_output_language
+## output_folder
+
+# Note: inventor_name / inventor_contact_{name,phone,email} are intentionally
+# NOT collected at install time — each disclosure may have different inventors
+# and contacts. The skill collects them interactively in step-02. Users may
+# pre-populate these keys manually in the generated _xiaoma/xpm/config.yaml
+# if they have a single fixed contact; the skill reads them as defaults when
+# present and prompts when absent.
+
+patent_output_folder:
+  prompt: "Where should patent disclosure artifacts be stored?"
+  default: "{output_folder}/patent-disclosures"
+  result: "{project-root}/{value}"
+
+# Directories to create during installation (declarative, no code execution)
+directories:
+  - "{patent_output_folder}"

package/src/xpm/skills/xiaoma-patent-mining/SKILL.md

@@ -0,0 +1,6 @@
+---
+name: xiaoma-patent-mining
+description: "Mine patentable innovations from software projects and generate prosecution-ready disclosure DOCX. Implements the three-element test, six-section disclosure template, and engineer-style anti-AI writing checks. Triggers on patent mining, disclosure drafting, IP analysis from code, or markdown-to-DOCX conversion of an existing disclosure draft."
+---
+
+Follow the instructions in ./workflow.md.

package/src/xpm/skills/xiaoma-patent-mining/references/disclosure-template.md

@@ -0,0 +1,84 @@
+**技术交底书**
+
+**交底书名称：**
+
+**本专利发明人：刘二杨**
+
+**技术问题联系人: 刘二杨**
+
+**联系人电话：** 13473186668
+
+**E-MAIL：** [liueryang@yljr.com]{.underline}
+
+**该发明所属技术领域：**
+
+**术语解释：**(请将您认为代理人可能不理解的术语进行解释)
+
+**1、详细介绍技术背景,并描述已有的与本发明最相近似的实现方案**
+
+> （背景技术及现有技术方案）
+
+**2、现有技术的缺点是什么？针对这些缺点，说明本发明的目的。**
+
+> （请客观评价，现有技术的缺点是针对于本发明的优点来说的，本发明不能解决的缺点不必写；基于本发明能解决的问题写出发明的目的。
+>
+> 2.1
+> 如果找不出对比技术方案及其缺点，可用反推法，根据本发明的优点来找现有技术对应的缺点；
+
+2.2 本发明不能解决的缺点，不需提供；
+
+2.3 缺点可以是成本高、效率低、不环保、误码率高、反应速度慢等类似问题。）
+
+> **3、本发明技术方案的详细阐述，应该结合附图进行说明（附图可以是流程图、原理框图、电路图、时序图等）**
+>
+> （所有附图都应该有详细的文字描述，同时附图中的关键词或方框图中的注释都尽量用中文；方法专利都应该提供一个流程图，并提供相关的系统装置）。
+>
+> 3.1 基本原理（从原理、概括的层次说明本发明是如何解决上述技术问题的？）
+>
+> 3.2
+> 详细的技术方案*（*专利必须是一个技术方案，应该阐述发明目的通过什么技术方案来实现的，不能只有原理，也不能只做功能介绍.
+> ）
+
+*例如，对于您开发完成的产品而言，包括哪些模块（部件），各个模块（部件）之间是如何相关连接和相互工作的？各个模块（部件）分别起什么作用，完成什么功能？*
+
+*对于您需要保护的结构而言，哪个部件、哪种连接是您的创新，具体部件、连接的结构细部描述、在产品中所起的关键作用。对于您需要保护的工艺或制作方法而言，需要哪些步骤，如何控制工艺参数的设置。对于您希望保护的方法而言，需要哪些流程步骤？请详细说明，需要采用数据流的角度说明流程步骤。*
+
+**4、与第1部分所述的现有技术相比，本发明有何优点**
+
+> *4.1
+> 结合技术方案来描述，做到有理有据，即用推理或因果关系的方式推理说明；*
+>
+> *4.2 可以对应第2部分的发明目的来描述。*
+
+**5、本发明的关键点和欲保护点是什么？**
+
+> （本部分是提炼出技术方案的关键创新点，列出1、2、3\...，以提醒代理人注意，便于专利代理人撰写权利要求书）
+>
+> *5.1简单点明；*
+>
+> *5.2 具体可以对应第4部分能给本发明带来有益效果（优点）的关键技术点。*
+
+**6、针对第3部分的技术方案，是否还有别的替代方案同样能完成发明目的？**
+
+> *6.1
+> 如果有，请尽量写明，内容的提供可以扩大专利的保护范围，防止他人绕过本技术去实现同样的发明目的；*
+>
+> *6.2
+> 所述替代可以是部分结构、器件、方法步骤的替代，也可以是完整的技术方案。*
+
+**注意：**
+
+1\.
+代理人并不是技术专家，交底书要使代理人能看懂，**尤其是第3点本发明技术方案**，一定要写的全面、清楚。
+
+2.英文缩写有中文译文，避免使用英文单词，最好在术语解释部分给出。
+
+3.全文对同一事物的叫法应统一，避免出现一种东西多种叫法。
+
+4.认为需要保密的地方可在交底书中注明，对代理人不必保密。
+
+5.专利法规定：
+
+1)  专利必须是一个技术方案，应该阐述发明目的是通过什么技术方案来实现的，不能只有原理，也不能只做功能介绍；
+
+2)  专利必须充分公开，以本领域技术人员不需付出创造性劳动即可实现为准。