@ai-content-space/loopx 0.2.9 → 0.2.10

package/plugins/loopx/skills/requirement-analyzer/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: requirement-analyzer
+description: "Reviews existing requirements, PRDs, specs, and feature briefs for ambiguity, missing business closure, impact, feasibility, and development readiness. Not for changing workflow state, inventing business decisions, writing implementation plans, or editing code."
+when_to_use: "requirement-analyzer, PRD review, requirement gaps, feasibility review, ambiguity analysis, development readiness, 需求分析, 需求缺口"
+metadata:
+  version: "0.2.10"
+---
+
+# Requirement Analyzer
+
+## Purpose
+
+`requirement-analyzer` reviews an existing written requirement and produces a gap report or readiness assessment. It is a support skill like `doc-readability`: users can invoke it directly, and loopx workflow skills may use its output as source material later, but this skill does not advance workflow state.
+
+Do not turn this skill into `clarify`, `spec`, or `plan-to-exec`. If analysis shows the requirement is not ready, report the gaps. If the user later wants to proceed, route that separate request through the normal loopx flow.
+
+## Inputs
+
+Accept one primary input:
+
+- a document path
+- pasted document content
+- a URL or external document the agent can read with available tools
+
+Optional inputs:
+
+- repository root for narrow context lookup
+- analysis depth: `quick`, `standard`, or `deep`
+- output mode: `gap_checklist` or `analysis_report`
+- output path
+
+If no source document or content is available, stop and ask for it.
+
+## Analysis Rules
+
+- Do not invent missing business facts. Mark them as unknowns.
+- Separate facts, inferences, and assumptions.
+- Every P0 or P1 issue must cite evidence from the requirement or nearby repo context.
+- Keep repository scanning narrow. Read only directly related docs, interfaces, schemas, or code paths.
+- Prefer concrete follow-up questions over broad requests for more detail.
+- Do not treat every API, schema, or implementation detail as a PRD defect when it clearly belongs in technical design.
+
+## Core Workflow
+
+1. **Identify the source artifact** — Read the requirement, PRD, spec, ticket, or feature brief. If only an excerpt is available, state that limitation.
+2. **Classify the document** — State whether it is a product requirement, engineering requirement, design brief, migration brief, bug requirement, or mixed document.
+3. **Extract facts** — List actors, triggers, inputs, outputs, user-visible states, constraints, and explicit acceptance rules before judging quality.
+4. **Run gap checks** — Review business closure, ambiguity, impact, feasibility, and development readiness. Load references only when the corresponding check is needed.
+5. **Prioritize issues** — Assign P0/P1/P2 using the priority rules below. Do not inflate every missing implementation detail into a requirement blocker.
+6. **Recommend next step** — Recommend `clarify`, `spec`, `plan-to-exec`, or blocked pending owner decisions. This is only a recommendation; do not create workflow artifacts unless separately asked.
+
+## Reference Guide
+
+Load detailed guidance based on context:
+
+| Topic | Reference | Load When |
+| --- | --- | --- |
+| PRD gap checklist | `references/prd-gap-checklist.md` | Reviewing business closure, ambiguity, impact, or Chinese PRDs |
+| Readiness rubric | `references/readiness-rubric.md` | Deciding whether work is ready for `clarify`, `spec`, or `plan-to-exec` |
+| Report template | `references/report-template.md` | Writing a gap checklist or narrative analysis report |
+| Example reports | `references/example-reports.md` | Understanding expected output quality and format |
+
+## Priority Levels
+
+- `P0`: Blocks design or implementation. Key behavior, ownership, timing, failure handling, contract, permission, or acceptance rule is missing or contradictory.
+- `P1`: Does not block kickoff, but creates major design uncertainty, integration risk, or likely rework.
+- `P2`: Clarity, operability, UX, or maintenance issue that should be improved but does not block work.
+
+Use the lowest priority that still protects the work. If a missing detail can be decided during technical design without changing product behavior, classify it as a design input or P2 note, not a P0 requirement blocker.
+
+## Review Dimensions
+
+### Business Closure
+
+Check whether the requirement has a complete loop:
+
+```text
+input -> process -> output -> feedback
+```
+
+Look for missing actors, triggers, success events, failure handling, ownership, and user-visible completion states.
+
+For each missing closure point, state who must decide it and what downstream work is blocked.
+
+### Ambiguity
+
+Find terms, quantities, timing, permissions, integrations, and acceptance criteria that can be interpreted more than one way.
+
+Convert each ambiguity into a concrete question with two or three plausible interpretations when possible.
+
+### Impact
+
+Identify affected users, systems, APIs, data, permissions, migrations, operations, analytics, and rollback concerns.
+
+Call out impact as unknown only when the requirement gives no evidence. Do not invent affected systems from generic architecture assumptions.
+
+### Feasibility
+
+Call out technical, product, operational, legal, data-quality, schedule, or dependency risks that would change design or planning.
+
+Separate feasibility blockers from implementation difficulty. Hard work is not a requirement gap unless the requirement assumes an impossible or unapproved constraint.
+
+### Development Readiness
+
+State whether the requirement is ready for:
+
+- `clarify`
+- `spec`
+- `plan-to-exec`
+- blocked pending owner decisions
+
+This is a recommendation only. Do not create workflow artifacts unless the user separately asks.
+
+Use these readiness rules:
+
+- Ready for `clarify` when the source is incomplete or contradictory and owner decisions are needed before design.
+- Ready for `spec` when product behavior is mostly clear but API, data, permission, migration, compatibility, or architecture decisions must be fixed before planning.
+- Ready for `plan-to-exec` when scope, non-goals, acceptance rules, affected surfaces, and constraints are clear enough to break into implementation tasks.
+- Blocked pending owner decisions when a P0 question has no safe default and no local repo evidence can answer it.
+
+## Output
+
+Default to a markdown report with this structure:
+
+```markdown
+# Requirement Analysis
+
+## Summary
+
+## Readiness Recommendation
+
+## P0 Blockers
+
+## P1 Major Risks
+
+## P2 Improvements
+
+## Facts
+
+## Inferences
+
+## Assumptions
+
+## Follow-Up Questions
+
+## Suggested Next Step
+```
+
+If writing to disk, use a sibling file next to the source document when practical:
+
+- `需求缺口清单.md` for gap reports
+- `需求分析报告.md` for narrative analysis
+
+## Review Checklist
+
+- Did every P0/P1 cite requirement text or nearby repo evidence?
+- Are facts, inferences, and assumptions separated?
+- Are follow-up questions concrete enough for an owner to answer?
+- Are technical design questions separated from true requirement gaps?
+- Does the readiness recommendation match the highest-priority unresolved issue?
+- Did the report avoid creating workflow artifacts or advancing loopx state?

package/plugins/loopx/skills/requirement-analyzer/references/example-reports.md

@@ -0,0 +1,170 @@
+# Example Reports
+
+These examples illustrate the expected output quality and format for requirement analysis reports. They are synthetic but modeled on real-world patterns.
+
+## Example 1: Gap Checklist (Chinese PRD)
+
+Source: "用户积分兑换功能 PRD v0.3"
+
+```markdown
+# 需求缺口清单
+
+## 结论
+
+- 推荐下一步：clarify
+- 阻塞项数量：3 个 P0
+- 主要风险：兑换失败的回滚机制未定义，积分过期规则与兑换时序存在矛盾
+
+## 必须确认
+
+- [ ] 问题：并发兑换时积分不足如何处理？
+      证据：PRD 第 3.2 节仅描述 "扣减积分"，未定义并发锁策略或失败回滚
+      影响：可能导致积分超扣或兑换成功但商品库存不足
+
+- [ ] 问题：积分过期与兑换时序矛盾
+      证据：第 2.1 节 "积分到期日自动清零"，第 3.1 节 "提交兑换后 24 小时内发货"
+      影响：如果用户提交兑换时积分有效，但发货确认时积分已过期，扣减行为未定义
+
+- [ ] 问题："相关人员审核" 的角色和超时未定义
+      证据：第 4.2 节 "高价值兑换需相关人员审核"
+      影响：不知道谁审核、超时多久、超时后是自动通过还是拒绝
+
+## 可以后续完善
+
+- [ ] 问题：兑换记录的展示排序和分页规则
+      证据：第 5.1 节仅说 "展示兑换记录"
+      建议：spec 阶段明确排序字段、分页大小、筛选维度
+
+- [ ] 问题：积分变动通知渠道
+      证据：第 6 节 "及时通知用户"
+      建议：明确是 APP 推送、短信、站内信、还是多渠道，以及延迟容忍度
+```
+
+## Example 2: Analysis Report (English Feature Brief)
+
+Source: "Multi-tenant API Key Management — Feature Brief v1"
+
+```markdown
+# Requirement Analysis
+
+## Summary
+
+- Source: Multi-tenant API Key Management Feature Brief v1
+- Document type: Product requirement (mixed with some technical design)
+- Overall readiness: Not ready for plan-to-exec
+- Highest priority issue: Tenant isolation model for key scopes is undefined
+
+## Readiness Recommendation
+
+Recommended next step: `spec`
+
+Reason: Product intent is clear (tenants manage their own API keys with scoped permissions), but the key-to-permission model, cross-tenant visibility rules, and key rotation impact on active sessions are design decisions that need architecture input before implementation planning.
+
+## P0 Blockers
+
+| Issue | Evidence | Why It Blocks | Question / Decision Needed |
+| --- | --- | --- | --- |
+| Key scope model undefined | Brief says "keys can have limited permissions" but does not define the permission granularity | Cannot design the authorization layer without knowing if scopes are predefined roles, custom permission sets, or resource-level grants | What is the permission model? Predefined roles (admin/read/write) or custom scope sets? |
+| Cross-tenant key visibility | Brief says "admins can view all keys" without defining tenant boundary | In multi-tenant, "all keys" could mean within-tenant or platform-wide — different security models | Does "admin" mean tenant admin (sees own tenant keys) or platform admin (sees all tenant keys)? |
+| Key rotation impact on sessions | Brief says "keys can be rotated" but does not address active sessions | Rotating a key mid-session could break active API consumers or require grace periods | When a key is rotated, do active sessions using the old key get terminated immediately, get a grace period, or continue until natural expiry? |
+
+## P1 Major Risks
+
+| Issue | Evidence | Risk | Suggested Resolution |
+| --- | --- | --- | --- |
+| Rate limiting per key vs per tenant | Brief mentions "rate limiting" without specifying the limit entity | If limits are per-key, a tenant can create many keys to bypass limits; if per-tenant, a single key's traffic can starve others | Decide rate limit entity in spec: per-key, per-tenant, or hierarchical |
+| Audit log retention | Brief says "all key operations are audited" without retention or access rules | Compliance and storage cost implications are unknown | Define retention period, access control for audit logs, and whether they are tenant-visible |
+
+## P2 Improvements
+
+| Issue | Evidence | Improvement |
+| --- | --- | --- |
+| Key naming constraints | Not mentioned | Define max length, allowed characters, uniqueness scope |
+| Bulk key operations | Not mentioned | Consider if tenants need bulk create/revoke for migration scenarios |
+| Key metadata | Brief mentions "description" field only | Consider labels/tags for organizational use |
+
+## Facts
+
+- Tenants can create, list, rotate, and revoke API keys
+- Keys have a name and description
+- Keys can have limited permissions (scope undefined)
+- All key operations are audited
+- Rate limiting applies (entity undefined)
+- Admins can view all keys (boundary undefined)
+
+## Inferences
+
+- Inference: Keys are likely long-lived (not session tokens)
+  Evidence: "rotate" and "revoke" imply persistent credentials, not short-lived tokens
+
+- Inference: Multi-tenant isolation is required
+  Evidence: Feature title says "multi-tenant" and brief mentions "tenant" 12 times
+
+## Assumptions
+
+- Assumption: One key belongs to exactly one tenant
+  Why it matters: If keys can be shared across tenants, the permission and audit model changes significantly
+
+- Assumption: Key creation does not require approval
+  Why it matters: If approval is needed, the workflow, roles, and notification paths must be designed
+
+## Follow-Up Questions
+
+1. What permission model should keys use? (predefined roles vs custom scopes vs resource-level)
+2. Does "admin can view all keys" mean tenant-admin or platform-admin?
+3. What happens to active sessions when a key is rotated?
+4. Is rate limiting applied per-key, per-tenant, or both?
+5. What is the audit log retention period and who can access it?
+
+## Suggested Next Step
+
+Route to `spec` with `api-designer` and `architecture-designer` lenses. The key-to-permission model is an architecture decision that affects API surface, data model, and authorization middleware.
+```
+
+## Example 3: Quick Gap Checklist (Ticket-Level)
+
+Source: JIRA ticket "Add export button to analytics dashboard"
+
+```markdown
+# 需求缺口清单
+
+## 结论
+
+- 推荐下一步：plan-to-exec
+- 阻塞项数量：0
+- 主要风险：大数据量导出的超时和内存问题（P1，不阻塞规划）
+
+## 必须确认
+
+（无 P0 阻塞项）
+
+## 可以后续完善
+
+- [ ] 问题：导出数据量上限
+      证据：ticket 说 "导出当前筛选结果"，但仪表盘数据可能达百万行
+      建议：plan-to-exec 时设计分页导出或异步下载，设定单次导出上限
+
+- [ ] 问题：导出格式
+      证据：ticket 仅说 "导出为 CSV"
+      建议：确认是否需要 Excel (.xlsx) 支持，以及 CSV 编码（UTF-8 BOM for 中文兼容）
+
+## 为什么可以进入 plan-to-exec
+
+- 范围明确：在现有仪表盘页面增加导出按钮
+- 接受标准可测试：点击导出 → 下载包含当前筛选数据的文件
+- 无跨团队依赖：仪表盘前端和 API 由同一团队负责
+- 剩余问题（数据量上限、格式）是实现选择，不影响产品行为决策
+```
+
+## Report Quality Checklist
+
+Before submitting a requirement analysis report, verify:
+
+- [ ] Every P0/P1 cites specific text or section from the source document
+- [ ] Facts, inferences, and assumptions are clearly separated
+- [ ] Follow-up questions are concrete and answerable (not "please clarify further")
+- [ ] Technical design concerns are separated from true requirement gaps
+- [ ] The readiness recommendation matches the highest unresolved priority level
+- [ ] Chinese terms are checked against the ambiguity table when analyzing Chinese documents
+- [ ] The report does not invent business decisions or advance loopx workflow state
+- [ ] Impact is classified as unknown only when evidence is genuinely absent, not when it can be inferred from context

package/plugins/loopx/skills/requirement-analyzer/references/prd-gap-checklist.md

@@ -0,0 +1,167 @@
+# PRD Gap Checklist
+
+Use this checklist when a requirement, PRD, ticket, or feature brief needs a gap review. Do not require every item for every document; apply the sections that match the document's job.
+
+## Business Closure
+
+Check the requirement loop:
+
+```text
+actor -> trigger -> input -> process -> output -> feedback
+```
+
+Look for:
+
+- Primary actor and secondary actors
+- Triggering event or entry point
+- Required input and validation rules
+- Success output and user-visible completion state
+- Failure output and user-visible recovery path
+- Owner of manual decisions, approvals, or exceptions
+- Feedback or notification path after completion
+
+Common blockers:
+
+- The requirement says "support", "sync", "review", or "process" without a completion state.
+- It defines the happy path but not failure handling.
+- It names a system integration but not the source of truth or ownership.
+- It requires approval but does not identify who approves or what happens on rejection.
+
+## Ambiguity
+
+Turn vague terms into answerable questions.
+
+| Vague wording | Ask |
+| --- | --- |
+| "real-time" | What maximum delay is acceptable? |
+| "admin" | Which role, permission, or tenant scope qualifies? |
+| "recent" | What exact time window and timezone? |
+| "all users" | Which user segments, regions, plans, or exclusions? |
+| "failure notification" | Who receives it, by which channel, and with what action? |
+| "compatible" | Which versions, clients, payloads, or migrations must continue working? |
+| "batch" | What size, frequency, retry, and timeout rules? |
+| "configurable" | Who configures it, where, and what are the allowed values and defaults? |
+| "secure" | Which threat model, authentication, authorization, and encryption rules? |
+| "performant" | What specific latency, throughput, or resource target? |
+
+### Chinese Requirement Ambiguity
+
+For Chinese requirements, watch for these terms and convert them to concrete questions:
+
+| 模糊用词 | 需要确认 |
+| --- | --- |
+| "及时" | 具体时间上限是多少？(< 1秒 / < 1分钟 / < 1小时) |
+| "尽快" | 有没有 SLA 或超时后的降级策略？ |
+| "相关人员" | 具体是哪些角色、部门、或权限组？ |
+| "默认" | 默认值是什么？谁可以修改？修改后影响范围？ |
+| "自动" | 触发条件是什么？失败时怎么处理？有没有人工兜底？ |
+| "必要时" | 判断条件是什么？谁来判断？判断错误的后果？ |
+| "支持" | 支持的完整范围是什么？有没有不支持的例外？ |
+| "可配置" | 配置的维度、粒度、权限、生效时机？ |
+| "保持一致" | 一致性的对象、时间窗口、冲突解决规则？ |
+| "合理" | 合理的标准是什么？由谁定义？ |
+| "视情况而定" | 列举所有情况和对应处理方式 |
+| "参考xx系统" | 哪些行为对齐、哪些行为不同、差异的原因？ |
+| "等" / "等等" | 完整枚举是什么？还是真的是开放集合？ |
+
+## Impact
+
+Identify affected surfaces without inventing architecture:
+
+- Users, roles, tenants, plans, regions, or organizations
+- APIs, CLI commands, screens, jobs, events, or integrations
+- Database records, schemas, migrations, backfills, retention, or analytics
+- Permissions, audit logs, compliance, privacy, or legal review
+- Operations, monitoring, alerts, rollout, rollback, and support playbooks
+- Existing behavior that must remain compatible
+
+Classify impact as unknown when the source gives no evidence. Unknown impact is a gap only when it changes design, rollout, or acceptance.
+
+### Impact Assessment Matrix
+
+| Impact Area | Questions to Ask | P0 if... |
+| --- | --- | --- |
+| Data | Schema change? Migration needed? Backward compatible? | Existing data is corrupted or lost without migration |
+| API | Breaking change? New version? Deprecation? | Existing clients break without warning |
+| Permissions | New role? Changed access? Audit implications? | Users gain unintended access |
+| Operations | New alerts? Changed runbooks? New on-call scope? | Failure is undetectable or unrecoverable |
+| Compliance | Privacy review? Legal approval? Data classification? | Non-compliance risk with legal consequences |
+| Rollback | Can this be undone? What is the rollback blast radius? | No rollback path exists for a destructive change |
+
+## Feasibility
+
+Separate requirement risk from implementation difficulty.
+
+Requirement feasibility risks include:
+
+- A dependency or external system is assumed but not available.
+- The requested behavior conflicts with existing product rules or legal constraints.
+- Required data does not exist, is unreliable, or has unclear ownership.
+- A migration, rollout, or rollback path is required but unspecified.
+- A schedule or SLA is stated without scope, load, or operational ownership.
+- A third-party integration is assumed but not contracted or available in the target environment.
+
+Do not mark a requirement defective just because implementation is complex. Mark it as a risk when the requirement assumes an unapproved tradeoff or hides a decision the owner must make.
+
+### Feasibility Red Flags
+
+| Red Flag | Why It Matters |
+| --- | --- |
+| "Same as system X" without specifying differences | System X may have different constraints, scale, or contracts |
+| Timing assumption without load analysis | "Real-time sync of 10M records" may be infeasible |
+| Cross-team dependency without confirmed ownership | The other team may not have capacity or agreement |
+| Compliance claim without legal review | Legal requirements need legal confirmation, not assumption |
+| "No downtime" for schema migration | May require online DDL, dual-write, or phased rollout |
+
+## Development Readiness
+
+Quick checks to determine if the requirement is ready for the next loopx workflow step.
+
+### Ready for `clarify`
+
+- [ ] Scope or non-goals are missing or contradictory
+- [ ] Multiple product interpretations lead to different designs
+- [ ] Key actor, permission, or ownership is undecidable
+- [ ] Competing goals exist without stated priority
+
+### Ready for `spec`
+
+- [ ] Product intent is clear but API/data/state decisions are open
+- [ ] Existing systems or contracts are affected
+- [ ] Rollout, rollback, or operational behavior needs design
+- [ ] Clear enough to compare options but not to write tasks
+
+### Ready for `plan-to-exec`
+
+- [ ] Scope and non-goals are explicit
+- [ ] Acceptance rules are testable
+- [ ] Affected surfaces are discoverable
+- [ ] Remaining choices are local implementation choices
+- [ ] No owner-level decisions are pending
+
+### Blocked
+
+- [ ] A P0 question has no safe default
+- [ ] No local repo evidence can answer the blocking question
+- [ ] The decision requires a specific person (legal, product owner, security)
+
+## Cross-Reference Checks
+
+When the requirement references other documents or systems:
+
+- [ ] Referenced documents exist and are accessible
+- [ ] Referenced behavior is still current (not deprecated or changed)
+- [ ] Contradictions between referenced docs and this requirement are flagged
+- [ ] Version or date of referenced material is noted
+
+## Completeness Signals
+
+A requirement is likely incomplete when:
+
+- It describes only the creation flow but not update, delete, or error flows
+- It mentions a list or collection but not pagination, sorting, or filtering rules
+- It defines a notification but not the channel, template, frequency, or opt-out
+- It references permissions but not the grant, revoke, or audit mechanism
+- It describes a scheduled job but not frequency, retry, timeout, or conflict rules
+- It mentions "sync" but not conflict resolution, source of truth, or failure handling
+- It defines an approval flow but not timeout, escalation, delegation, or rejection recovery

package/plugins/loopx/skills/requirement-analyzer/references/readiness-rubric.md

@@ -0,0 +1,70 @@
+# Development Readiness Rubric
+
+Use this rubric to decide the next loopx recommendation after analyzing a source requirement.
+
+## Ready For `clarify`
+
+Recommend `clarify` when owner answers are needed before design can start.
+
+Signals:
+
+- Scope, non-goals, actor, or acceptance rules are missing or contradictory.
+- Multiple product interpretations are plausible and lead to different designs.
+- Permission, ownership, or failure handling is not decidable from the document.
+- The source mixes competing goals without priority.
+
+Output:
+
+- List P0 questions first.
+- Keep questions concrete and answerable.
+- Do not draft a design or implementation plan.
+
+## Ready For `spec`
+
+Recommend `spec` when product intent is mostly clear but design decisions must be fixed before planning.
+
+Signals:
+
+- API, data, state, permission, migration, compatibility, or architecture choices are open.
+- Existing systems or contracts are affected.
+- Rollout, rollback, or operational behavior needs a design decision.
+- The requirement is clear enough to compare options but not enough to write tasks.
+
+Output:
+
+- State the design decisions that need to be resolved.
+- Identify any support lens that should be used later, such as `api-designer`, `architecture-designer`, `sql-style`, `cli-developer`, `go-style`, or `kratos`.
+
+## Ready For `plan-to-exec`
+
+Recommend `plan-to-exec` only when implementation can be decomposed safely.
+
+Signals:
+
+- Scope and non-goals are explicit.
+- Acceptance rules and user-visible completion states are testable.
+- Affected files, modules, APIs, schemas, commands, or docs are discoverable.
+- Remaining choices are local implementation choices, not product or architecture decisions.
+- Known risks can be handled as implementation tasks with verification.
+
+Output:
+
+- Summarize why no owner-level decisions block planning.
+- Mention any P2 improvements that should be tracked but not block planning.
+
+## Blocked Pending Owner Decisions
+
+Use this when a P0 issue cannot be answered by local repo evidence and has no safe default.
+
+Examples:
+
+- Who is allowed to perform a destructive action?
+- What happens to existing data during migration?
+- Which customer-visible behavior wins when two requirements conflict?
+- What legal, compliance, or privacy rule governs the data?
+
+Output:
+
+- State the blocking decision.
+- Explain what downstream design or implementation would be unsafe without it.
+- Ask the smallest set of questions needed to unblock the next step.

package/plugins/loopx/skills/requirement-analyzer/references/report-template.md

@@ -0,0 +1,83 @@
+# Requirement Analysis Report Template
+
+Use this structure for the default markdown report. Keep it concise; expand only where the requirement has real risk.
+
+```markdown
+# Requirement Analysis
+
+## Summary
+
+- Source:
+- Document type:
+- Overall readiness:
+- Highest priority issue:
+
+## Readiness Recommendation
+
+Recommended next step: `clarify` | `spec` | `plan-to-exec` | blocked pending owner decisions
+
+Reason:
+
+## P0 Blockers
+
+| Issue | Evidence | Why It Blocks | Question / Decision Needed |
+| --- | --- | --- | --- |
+
+## P1 Major Risks
+
+| Issue | Evidence | Risk | Suggested Resolution |
+| --- | --- | --- | --- |
+
+## P2 Improvements
+
+| Issue | Evidence | Improvement |
+| --- | --- | --- |
+
+## Facts
+
+- ...
+
+## Inferences
+
+- Inference:
+  Evidence:
+
+## Assumptions
+
+- Assumption:
+  Why it matters:
+
+## Follow-Up Questions
+
+1. ...
+
+## Suggested Next Step
+
+...
+```
+
+## Gap Checklist Mode
+
+For a compact gap checklist, use:
+
+```markdown
+# 需求缺口清单
+
+## 结论
+
+- 推荐下一步：
+- 阻塞项数量：
+- 主要风险：
+
+## 必须确认
+
+- [ ] 问题：
+      证据：
+      影响：
+
+## 可以后续完善
+
+- [ ] 问题：
+      证据：
+      建议：
+```

package/plugins/loopx/skills/review/SKILL.md

@@ -3,7 +3,7 @@ name: review
 description: "Dispatches a loopx code reviewer subagent against a concrete git range and requirements. Not for implementation, planning, or unresolved review scope."
 when_to_use: "request code review, completed task review, major feature review, pre-merge review, subagent code quality check"
 metadata:
-  version: "0.2.9"
+  version: "0.2.10"
 ---
 
 # Review

package/plugins/loopx/skills/spec/SKILL.md

@@ -3,7 +3,7 @@ name: spec
 description: "Writes software design specs from already-clarified requirements, including solution approach, architecture outline, detailed design, tradeoffs, verification design, and handoff context. Not for unresolved requirements, PRD generation, implementation task planning, or code changes."
 when_to_use: "spec, design spec, technical design, design proposal, detailed design, architecture design, 设计方案, 概要设计, 详细设计, 技术方案"
 metadata:
-  version: "0.2.9"
+  version: "0.2.10"
 ---
 
 # loopx Spec