@zeyue0329/xiaoma-cli 1.13.0 → 1.15.1

package/src/core/tasks/xiaoma-create-prd/templates/prd-skeleton-reference.md

@@ -1,428 +0,0 @@
-# PRD Skeleton Reference
-
-> **Audience:** PM agent (xiaochan / 小蝉) and human reviewers.
-> **Role:** Design reference and quality bar — what each PRD section "looks like done well".
-> **Not:** Copied to the output PRD. Loaded into agent context during `xiaoma-create-prd` and
-> used as the side-by-side standard during `xiaoma-validate-prd`.
-
-For density rules, SMART criteria, anti-pattern catalog (AP-01..AP-05), FR-to-Story
-heuristics, NFR industry baselines, and dual-audience checklist, read:
-`../data/prd-purpose.md`.
-
-For Analyst → PM upstream input expectations and field-to-section mapping, read:
-`../data/upstream-input-contract.md`.
-
----
-
-## How to Use This Reference
-
-1. **Per-section guidance.** For each of the 9 required sections, this file provides:
-   purpose, fields, a good Chinese example, an anti-pattern Chinese example, and self-check questions.
-2. **Workflow alignment.** Each section maps to one or more `step-c` files; that step is the
-   primary author of the section. PM agent should read the relevant subsection of this reference
-   immediately before generating content for the corresponding step.
-3. **Validation alignment.** Each section's quality bar maps to one or more `step-v` validation
-   dimensions (D01..D13). The reference's "self-check questions" are the lightweight version of
-   those validations.
-4. **Skip rules.** Sections 5, 6, 7 may be marked "N/A" when not applicable — see the project-type
-   matrix at the end of this file.
-
----
-
-## Section 1 — Executive Summary
-
-**Step source:** `steps-c/step-02c-executive-summary.md`
-**Validation refs:** D04 Brief Coverage · D06 Traceability · D11 Holistic Quality
-
-### Purpose
-
-Anchor the entire PRD in one screen. A reader who skims only this section must come away knowing:
-**what we are building, for whom, what problem it solves, and why it wins.**
-
-### Required fields
-
-| Field                  | Required | Length             |
-| ---------------------- | -------- | ------------------ |
-| Vision statement       | yes      | 1-2 sentences      |
-| Problem statement      | yes      | 1-2 sentences      |
-| Target users (primary) | yes      | bullet list, 2-4   |
-| Value proposition      | yes      | 2-4 bullets        |
-| Differentiation        | yes      | 1-3 bullets        |
-| Project classification | auto     | 1 line (from CSVs) |
-
-### Good example (中文)
-
-> **愿景：** 让中型企业的客户成功团队在统一画布上看见、解读并干预客户旅程，把流失预警的发现到触达从平均 7 天压到 24 小时内。
->
-> **目标用户：** 客户成功经理（CSM）· 客服主管 · 数据分析师。
->
-> **价值主张：**
-> - 跨系统聚合的客户旅程视图，单页可视化 ≥ 12 个月历史
-> - LLM 自动摘要近 30 天高风险对话，CSM 平均处理时间从 18 分钟降至 6 分钟
-> - 风险评分与触达建议同源，CSM 单人服务客户数提升 30%
-
-### Anti-pattern example (AP-01 口号化目标)
-
-> ❌ "打造业界领先的、智能化、一站式客户成功平台，赋能企业数字化转型。"
->
-> 问题：无可测量目标、无主语、无差异化、纯营销话术。
-
-### Self-check
-
-- 愿景是否能被翻译成至少 1 条 Success Criteria 量化指标？
-- 目标用户是否唯一？没有"所有人"或"企业"这种泛主语？
-- 差异化点是否能与至少 1 个竞品对比？
-
----
-
-## Section 2 — Success Criteria
-
-**Step source:** `steps-c/step-03-success.md`
-**Validation refs:** D05 Measurability · D06 Traceability · D10 SMART
-
-### Purpose
-
-Define what "success" means in numbers. Every metric must be testable post-launch.
-
-### Required fields per metric
-
-| Field             | Required | Example                                |
-| ----------------- | -------- | -------------------------------------- |
-| Metric name       | yes      | 流失预警触达率                         |
-| Baseline          | yes      | 当前 30%（来自 2025 Q4 客服日志抽样）  |
-| Target            | yes      | 上线后 6 个月内 ≥ 95%                  |
-| Measurement       | yes      | 工单系统标签 `risk_alert_acknowledged` |
-| Time window       | yes      | 滚动 30 天                             |
-| Linked to vision? | yes      | §1 愿景"24 小时内触达"                 |
-
-### Good example (中文)
-
-> **SC-01 流失预警触达率**
-> Baseline 30%（2025 Q4 客服日志抽样）→ 上线后 6 个月内 ≥ 95%。
-> 测量：工单系统标签 `risk_alert_acknowledged` ÷ 同期生成的 `risk_alert` 数。
-> 滚动窗口 30 天。对应愿景"24 小时内触达"。
-
-### Anti-pattern example (AP-05 量词缺失)
-
-> ❌ "客户满意度显著提升，流失率明显下降。"
->
-> 问题：无 baseline、无 target、无测量方法、无时间窗。"显著"/"明显"是反模式。
-
-### Self-check
-
-- 每条指标是否可在产品上线 + 1 个完整测量周期内被验证？
-- 每条指标是否与 §1 中至少一项愿景或价值主张存在可追溯链接？
-- 是否避免了"提升用户体验"这类不可量化指标？
-
----
-
-## Section 3 — Product Scope
-
-**Step source:** `steps-c/step-08-scoping.md`
-**Validation refs:** D04 Brief Coverage · D12 Completeness
-
-### Purpose
-
-明确写出"做什么、不做什么、之后做什么"。out-of-scope 与 in-scope 同等重要 — 它阻止后续无声扩张。
-
-### Required fields
-
-- **MVP（必须）：** 列表，按 capability area 分组
-- **Out-of-Scope（必须）：** 列表，每条附"为什么不做"一句话
-- **Growth Phase（推荐）：** 列表 + 大致时间窗
-- **Vision Phase（可选）：** 列表
-
-### Good example (中文)
-
-> **MVP（2026 H2 上线）**
-> - 客户档案管理：多源聚合 · 标签 · 检索
-> - 旅程画布：单租户 · 12 个月历史 · 时间轴视图
-> - 风险预警：3 类规则引擎 · 工单系统单向集成
->
-> **Out-of-Scope**
-> - 海外多语：首期客户均为国内中型企业，海外需求量 < 5%
-> - 自营客服坐席系统：与现有合作伙伴 Salesforce/钉钉客服重叠
->
-> **Growth Phase（2027 Q1）**
-> - 客户健康度模型可调校
-> - 移动端 PWA
-
-### Anti-pattern
-
-> ❌ "MVP 包含核心功能，后续根据需求迭代。"
->
-> 问题：无具体功能列表，"核心"/"根据需求"全是占位词。
-
-### Self-check
-
-- Out-of-Scope 是否覆盖了至少 1 个"显然会被问到但本期不做"的场景？
-- MVP 列表是否能 1:1 映射到 §8 的 capability areas？
-
----
-
-## Section 4 — User Journeys
-
-**Step source:** `steps-c/step-04-journeys.md`
-**Validation refs:** D04 Brief Coverage · D06 Traceability
-
-### Purpose
-
-For each primary persona from §1, capture an end-to-end journey. Journeys are the bridge from
-target users to functional requirements — every FR in §8 must trace back to at least one journey
-step.
-
-### Required fields per journey
-
-- Persona (与 §1 一致)
-- Trigger（旅程触发点）
-- 5-9 steps，每步含：动作 · 触点（系统/页面）· 情绪 · 痛点（如有）
-- Outcome（成功/失败两种结局）
-
-### Good example (中文)
-
-> **CSM 日检视旅程**
->
-> 触发：上午 9:00 进入工作台。
->
-> | # | 动作                       | 触点              | 情绪    | 痛点                |
-> | - | -------------------------- | ----------------- | ------- | ------------------- |
-> | 1 | 打开客户旅程画布           | Web 工作台首页    | 期望    | -                   |
-> | 2 | 查看高风险客户列表         | 风险预警面板      | 警觉    | 当前需手动多系统切换 |
-> | 3 | 点击客户卡片查看 30 天摘要 | 客户档案 · 摘要 Tab | 专注    | -                   |
-> | 4 | 决定干预动作               | 触达建议面板      | 紧迫    | -                   |
-> | 5 | 一键创建工单并触达客户     | 工单 + IM 集成   | 满足    | -                   |
->
-> 结局：成功路径 = 触达后 24h 内客户回复；失败路径 = 工单进入超时队列。
-
-### Anti-pattern
-
-> ❌ "用户登录后查看数据并采取行动。"
->
-> 问题：步骤过粗（无法映射到 FR）、无触点、无情绪、无失败路径。
-
-### Self-check
-
-- 每个 §1 中列出的 persona 是否至少有一条旅程？
-- 每个旅程步骤是否能追溯到至少 1 个 FR（即将在 §8 中出现）？
-- 是否包含了至少 1 条失败路径？
-
----
-
-## Section 5 — Domain Requirements
-
-**Step source:** `steps-c/step-05-domain.md`
-**Driver:** `../data/domain-complexity.csv`
-**Validation ref:** D08 Domain Compliance
-
-### Purpose
-
-Industry-mandatory requirements (HIPAA, PCI-DSS, 等保, etc). Auto-detected from project signals;
-the PM agent expands `special_sections` from `domain-complexity.csv` into actual requirements.
-
-### When to write "N/A"
-
-- `domain` 检测为 `general` 且 `complexity` 为 `low`
-- 团队明确无合规外部约束
-
-### Good example (中文 — SaaS B2B 内部企业服务)
-
-> **5.1 数据合规**
-> - 等保二级（要求：访问控制 · 审计日志 · 数据备份 · 安全管理制度）
-> - 个人信息保护法：客户对话内容仅在租户内可见，跨租户隔离强制启用
-> - 数据本地化：客户数据仅存储于中国大陆 IDC
->
-> **5.2 行业术语表**
-> - 客户健康度（Customer Health Score）：0-100 综合评分
-> - 流失预警（Churn Risk Alert）：触发条件参见 FR-RISK-01
->
-> **5.3 外部依赖**
-> - 钉钉开放平台 API（v2，限流 100 QPS）
-> - Salesforce REST API（v55.0，OAuth 2.0 授权）
-
-### Anti-pattern
-
-> ❌ "系统满足相关法规要求，符合行业标准。"
->
-> 问题：未列出具体法规、未列出可验证条款。
-
----
-
-## Section 6 — Innovation Analysis
-
-**Step source:** `steps-c/step-06-innovation.md`
-**Validation ref:** D11 Holistic Quality
-
-### Purpose
-
-差异化与新颖度分析，避免"做一个市场已有的产品"。
-
-### When to write "N/A"
-
-- 项目为既有产品的复刻或维护性扩展
-- 内部工具，不与外部产品对比
-
-### Good example (中文)
-
-> **6.1 核心差异化**
-> - 唯一同时整合"客户旅程画布 + LLM 摘要 + 风险评分"三能力的国内 SaaS
-> - 国内同类产品（如 X、Y）只覆盖其中 1-2 项
->
-> **6.2 技术新颖度**
-> - LLM 摘要质量基线 ≥ 4.2/5（人工标注 100 样本）
-> - 风险评分模型可解释性：每条预警附 top-3 触发因子
->
-> **6.3 风险**
-> - LLM 输出稳定性 — 缓解：引入提示词回归测试集 + 摘要重生成机制
-> - 国内 LLM 厂商策略变化 — 缓解：抽象 LLM 适配层，支持 ≥ 2 家厂商
-
----
-
-## Section 7 — Project-Type Requirements
-
-**Step source:** `steps-c/step-07-project-type.md`
-**Driver:** `../data/project-types.csv`
-**Validation ref:** D09 Project-Type Fit
-
-### Purpose
-
-Platform-specific 需求清单。从 `project-types.csv.required_sections` 展开，跳过 `skip_sections`
-中列出的章节。
-
-### Good example (saas_b2b)
-
-> - 多租户模型：行级数据隔离 + 租户级配置覆盖
-> - RBAC 矩阵：4 种角色（Admin / Manager / Operator / Viewer）× 8 类资源
-> - 订阅层级：Starter（≤ 10 人）/ Team（≤ 50 人）/ Business（≤ 200 人）
-> - 集成清单：钉钉 · 飞书 · Salesforce · Slack · Webhook
-> - 合规需求：等保二级 · ISO 27001（未来）
-
----
-
-## Section 8 — Functional Requirements
-
-**Step source:** `steps-c/step-09-functional.md`
-**Validation refs:** D05 Measurability · D06 Traceability · D07 Implementation Leakage · D10 SMART
-
-### Format
-
-```
-### 8.x [Capability Area Name — 名词短语，非动词]
-
-- FR-AREA-NN: [Actor] can [capability]
-```
-
-- FR# 全局唯一，按 capability area 缩写编号（如 FR-PROFILE-01, FR-RISK-01）
-- 总量 20-50 条，按 5-8 个 capability area 分组
-- Capability area = **名词短语**（"客户档案管理"），不是动词短语（"管理客户档案"）
-
-### Good FR examples (中文)
-
-> ### 8.1 客户档案管理
->
-> - **FR-PROFILE-01:** CSM 可以按公司名 · 标签 · 客户健康度区间检索客户档案
-> - **FR-PROFILE-02:** CSM 可以查看客户的 12 个月聚合活动时间轴
-> - **FR-PROFILE-03:** Admin 可以为客户档案添加自定义标签（最多 20 个/客户）
->
-> ### 8.2 风险预警
->
-> - **FR-RISK-01:** 系统可以基于规则引擎对客户产生风险评分（0-100）
-> - **FR-RISK-02:** CSM 可以接收 24 小时内未触达的高风险客户提醒
-
-### FR Anti-patterns (per AP-03 implementation leakage / AP-04 复合需求)
-
-> ❌ "**FR-X:** 系统使用 PostgreSQL 存储客户档案并通过 Redis 缓存查询结果"
-> 修复：剔除技术名词 → "FR-PROFILE-04: 客户档案查询 p95 < 200ms"（这条本应放 §9 NFR）
->
-> ❌ "**FR-Y:** CSM 可以查询客户、添加标签并导出 Excel"
-> 修复：拆为 3 条 FR，每条单一动作
-
-### Self-check (per FR)
-
-- 单一 Actor？
-- 不含技术栈名词、库名、协议名？
-- 不含主观形容词（"快速"/"易用"）？
-- 能映射到 §4 中至少一个 journey 步骤？
-- 1 条 FR 能拆出 1-3 个 user story？（参见 prd-purpose.md "FR-to-Story Heuristics"）
-
----
-
-## Section 9 — Non-Functional Requirements
-
-**Step source:** `steps-c/step-10-nonfunctional.md`
-**Profile driver:** `prd-purpose.md "NFR Industry Baselines"`
-**Validation refs:** D05 Measurability · D10 SMART
-
-### 6 dimensions
-
-Performance · Availability · Security · Scalability · Observability · Compliance.
-
-每条 NFR 必须含：metric · threshold · condition · measurement method · profile reference。
-
-### Format
-
-```
-- **NFR-PERF-01:** [metric] [condition] [threshold] (measured by [method])
-```
-
-### Good NFR examples (SaaS B2B profile)
-
-> - **NFR-PERF-01:** API 接口在正常负载下 p95 < 500ms（APM 监控统计）
-> - **NFR-AVAIL-01:** 工作时间（工作日 8:00-22:00）月度 SLA ≥ 99.9%（云厂商 SLA 监控）
-> - **NFR-SEC-01:** 客户对话数据传输强制 TLS 1.2+，静态加密 AES-256（架构评审条目）
-> - **NFR-SCALE-01:** 单租户支持并发 1000 用户，横向扩容时间 ≤ 5 分钟（压测报告）
-> - **NFR-OBS-01:** 关键链路 trace 覆盖率 ≥ 95%，错误率告警延迟 < 5 分钟（Grafana SLO）
-> - **NFR-COMP-01:** 审计日志保留 ≥ 180 天（数据归档策略）
-
-### NFR Anti-pattern
-
-> ❌ "**NFR-X:** 系统应具备良好的扩展性和稳定性"
->
-> 修复：拆出 NFR-SCALE-01（横向扩容 ≤ 5 分钟）+ NFR-AVAIL-01（SLA ≥ 99.9%），各带阈值。
-
----
-
-## Traceability Matrix
-
-**Built by:** `steps-c/step-11-polish.md`
-
-A table with one row per FR. Columns:
-
-| FR ID            | Capability Area | Maps to Vision | Maps to Success Criteria | Maps to Journey Step |
-| ---------------- | --------------- | -------------- | ------------------------ | -------------------- |
-| FR-PROFILE-01    | 客户档案管理     | §1 价值主张 1  | SC-03 检索效率           | §4.CSM日检视 step 2  |
-
-A FR with empty "Maps to" cells is a validation D06 Traceability failure.
-
----
-
-## FR Numbering & Capability Area Naming
-
-- Capability area names: 名词短语（中英均可，与 `{document_output_language}` 一致）
-- Suggested prefixes: `PROFILE`, `JOURNEY`, `RISK`, `SUMMARY`, `TICKET`, `TENANT`, `AUTH`, ...
-- FR ID format: `FR-<AREA>-<NN>`，编号从 01 起，**不复用**已删除的编号
-- 跨章节引用 FR 时使用全 ID（避免歧义）
-
----
-
-## When to Skip Sections
-
-| Project type     | Skip          | Mark as "N/A"        |
-| ---------------- | ------------- | -------------------- |
-| api_backend      | -             | §4 (replace with API consumer scenarios), §6 if internal |
-| cli_tool         | -             | §4 (replace with CLI usage scenarios) |
-| internal_tool    | -             | §6 if no external competition |
-| general / low complexity | - | §5, §6 |
-
-详见 `../data/project-types.csv` 的 `skip_sections` 列。
-
----
-
-## Dual-Audience Writing Tips
-
-- **Section headers must be `## Level 2`** — used by LLMs as anchors
-- **One concept per paragraph** — LLMs chunk on paragraph boundaries
-- **Tables for matrices, lists for enumerations** — never inline lists in prose
-- **Cross-references use `§N` or full FR ID** — keeps anchor stable
-- **Avoid forward references** — every section should be self-contained
-
-For the full dual-audience checklist, see `../data/prd-purpose.md` "Dual-Audience Checklist".

package/src/core/tasks/xiaoma-create-prd/templates/prd-template.md

@@ -1,108 +0,0 @@
----
-stepsCompleted: []
-inputDocuments: []
-workflowType: 'prd'
-templateVersion: '2.0-m1'
-densityLevel: ''
-domainTier: ''
-projectType: ''
-version: '0.1.0'
----
-
-# 产品需求文档（PRD） — {{project_name}}
-
-**作者：** {{user_name}}　**日期：** {{date}}　**版本：** {{version}}
-
-<!--
-================================================================================
-PRD STRUCTURE — 9 required sections (per prd-purpose.md)
-
-Each section is a placeholder ({{xxx_body}}) to be filled by the create-prd
-workflow (steps-c/step-02c through step-10). Section-level guidance, good/bad
-examples, and naming conventions live in:
-
-  ./prd-skeleton-reference.md
-
-For PRD philosophy, density rules, SMART criteria, FR/NFR anti-patterns,
-NFR industry baselines, and Chinese-language patterns, see:
-
-  ../data/prd-purpose.md
-
-For upstream input expectations (Analyst → PM contract), see:
-
-  ../data/upstream-input-contract.md
-
-Transitional note (M1):
-  step-c steps still append at end-of-file. Until step-c migrates to
-  placeholder-replacement semantics (M3), step-11-polish must scan for any
-  residual {{...}} markers and resolve them before completion.
-================================================================================
--->
-
-## 1. Executive Summary
-<!-- Purpose:  Vision · Problem · Target Users · Value Prop · Differentiation
-     Length:   3-5 short paragraphs (≤120 chars each)
-     Source:   step-02c (synthesized from steps 2 + 2b)
-     Anti:     口号化目标 (AP-01) · 模糊主语 (AP-02) -->
-{{executive_summary_body}}
-
-## 2. Success Criteria
-<!-- Purpose:  3-7 SMART metrics
-     Each:     baseline · target · measurement method · time window
-     Source:   step-03
-     Anti:     量词缺失 (AP-05) -->
-{{success_criteria_body}}
-
-## 3. Product Scope
-<!-- Purpose:  In-Scope · Out-of-Scope · Future Phases (MVP → Growth → Vision)
-     Format:   list-only, no slogans
-     Source:   step-08 -->
-{{product_scope_body}}
-
-## 4. User Journeys
-<!-- Purpose:  per-persona end-to-end journey
-     Each:     5-9 steps · touchpoints · emotion notes
-     Source:   step-04 -->
-{{user_journeys_body}}
-
-## 5. Domain Requirements
-<!-- Purpose:  mandatory compliance · industry terms · external dependencies
-     Driver:   domain-complexity.csv (auto-detected in step-02-discovery)
-     Empty:    write "N/A — general domain"
-     Source:   step-05 -->
-{{domain_requirements_body}}
-
-## 6. Innovation Analysis
-<!-- Purpose:  differentiation · novelty · competitive risk
-     Empty:    write "N/A"
-     Source:   step-06 -->
-{{innovation_body}}
-
-## 7. Project-Type Requirements
-<!-- Purpose:  platform-specific needs (saas_b2b / api_backend / mobile_app / ...)
-     Driver:   project-types.csv (required_sections · skip_sections)
-     Source:   step-07 -->
-{{project_type_body}}
-
-## 8. Functional Requirements
-<!-- Purpose:  20-50 FRs grouped into 5-8 capability areas
-     Format:   FR-AREA-NN: [Actor] can [capability]
-     Anti:     implementation leakage (AP-03) · 复合需求 (AP-04) · subjective adjectives
-     Source:   step-09 -->
-{{functional_requirements_body}}
-
-## 9. Non-Functional Requirements
-<!-- Purpose:  6 dimensions — Performance · Availability · Security · Scalability · Observability · Compliance
-     Each:     quantitative threshold + measurement method
-     Profile:  SaaS B2B / Internal Tool / High-concurrency C-end (see prd-purpose.md "NFR Industry Baselines")
-     Source:   step-10
-     Anti:     unmeasurable claim · missing context -->
-{{nonfunctional_requirements_body}}
-
----
-
-## Traceability Matrix
-<!-- Built by step-11-polish:
-       Vision (§1) → Success Criteria (§2) → User Journey (§4) → FR (§8) → Capability Area
-     Format:  table with one row per FR -->
-{{traceability_matrix}}

package/src/core/tasks/xiaoma-create-prd/workflow.md

@@ -1,62 +0,0 @@
----
-main_config: '{project-root}/_xiaoma/xmc/config.yaml'
-outputFile: '{planning_artifacts}/prd.md'
----
-
-# PRD Create Workflow
-
-**Goal:** Create comprehensive PRDs through structured workflow facilitation.
-
-**Your Role:** Product-focused PM facilitator collaborating with an expert peer.
-
-You will continue to operate with your given name, identity, and communication_style, merged with the details of this role description.
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self contained instruction file that is a part of an overall workflow that must be followed exactly
-- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until told to do so
-- **Sequential Enforcement**: Sequence within the step files must be completed in order, no skipping or optimization allowed
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array when a workflow produces a document
-- **Append-Only Building**: Build documents by appending content as directed to the output file
-
-### 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**: If the step has a menu with Continue as an option, 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 files when writing the final output for a specific 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`, `output_folder`, `planning_artifacts`, `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 configured `{communication_language}`.
-✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`.
-
-### 2. Route to Create Workflow
-
-"**Create Mode: Creating a new PRD from scratch.**"
-
-Read fully and follow: `./steps-c/step-01-init.md`

package/src/core/tasks/xiaoma-create-prd/xiaoma-skill-manifest.yaml

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

package/src/utility/agent-components/activation-rules.txt

@@ -1,6 +0,0 @@
-  <rules>
-    <r>ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.</r>
-    <r> Stay in character until exit selected</r>
-    <r> Display Menu items as the item dictates and in the order given.</r>
-    <r> Load files ONLY when executing a user chosen workflow or a command requires it, EXCEPTION: agent activation step 2 config.yaml</r>
-  </rules>

package/src/utility/agent-components/activation-steps.txt

@@ -1,14 +0,0 @@
-    <step n="1">Load persona from this current agent file (already in context)</step>
-    <step n="2">🚨 IMMEDIATE ACTION REQUIRED - BEFORE ANY OUTPUT:
-        - Load and read {project-root}/_bmad/{{module}}/config.yaml NOW
-        - Store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}
-        - VERIFY: If config not loaded, STOP and report error to user
-        - DO NOT PROCEED to step 3 until config is successfully loaded and variables stored
-    </step>
-    <step n="3">Remember: user's name is {user_name}</step>
-    {AGENT_SPECIFIC_STEPS}
-    <step n="{MENU_STEP}">Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section</step>
-    <step n="{HELP_STEP}">Let {user_name} know they can invoke the `bmad-help` skill at any time to get advice on what to do next, and that they can combine it with what they need help with <example>Invoke the `bmad-help` skill with a question like "where should I start with an idea I have that does XYZ?"</example></step>
-    <step n="{HALT_STEP}">STOP and WAIT for user input - do NOT execute menu items automatically - accept number or cmd trigger or fuzzy command match</step>
-    <step n="{INPUT_STEP}">On user input: Number → process menu item[n] | Text → case-insensitive substring match | Multiple matches → ask user to clarify | No match → show "Not recognized"</step>
-    <step n="{EXECUTE_STEP}">When processing a menu item: Check menu-handlers section below - extract any attributes from the selected menu item (exec, tmpl, data, action, multi) and follow the corresponding handler instructions</step>

package/src/utility/agent-components/agent-command-header.md

@@ -1 +0,0 @@
-You must fully embody this agent's persona and follow all activation instructions, steps and rules exactly as specified. NEVER break character until given an exit command.

package/src/utility/agent-components/agent.customize.template.yaml

@@ -1,41 +0,0 @@
-# Agent Customization
-# Customize any section below - all are optional
-
-# Override agent name
-agent:
-  metadata:
-    name: ""
-
-# Replace entire persona (not merged)
-persona:
-  role: ""
-  identity: ""
-  communication_style: ""
-  principles: []
-
-# Add custom critical actions (appended after standard config loading)
-critical_actions: []
-
-# Add persistent memories for the agent
-memories: []
-# Example:
-# memories:
-#   - "User prefers detailed technical explanations"
-#   - "Current project uses React and TypeScript"
-
-# Add custom menu items (appended to base menu)
-# Don't include * prefix or help/exit - auto-injected
-menu: []
-# Example:
-# menu:
-#   - trigger: my-workflow
-#     workflow: "{project-root}/custom/my.yaml"
-#     description: My custom workflow
-
-# Add custom prompts (for action="#id" handlers)
-prompts: []
-# Example:
-# prompts:
-# - id: my-prompt
-#   content: |
-#     Prompt instructions here

package/src/utility/agent-components/handler-action.txt

@@ -1,4 +0,0 @@
-  <handler type="action">
-    When menu item has: action="#id" → Find prompt with id="id" in current agent XML, follow its content
-    When menu item has: action="text" → Follow the text directly as an inline instruction
-  </handler>

package/src/utility/agent-components/handler-data.txt

@@ -1,5 +0,0 @@
-    <handler type="data">
-      When menu item has: data="path/to/file.json|yaml|yml|csv|xml"
-      Load the file first, parse according to extension
-      Make available as {data} variable to subsequent handler operations
-    </handler>