@pigcloud/skills 1.0.0

package/skills/references/requirements-separation-map.md

@@ -0,0 +1,71 @@
+# 需求拆分图
+
+## 目标
+
+把需求工作拆成两个互相隔离的 skill：
+
+- 产品侧需求发现
+- 研发侧需求分析
+
+## 产品侧
+
+当任务主要涉及这些内容时，使用 `product-intake`：
+
+- 业务目标
+- 用户需求
+- PRD 收口
+- 范围和优先级
+- 发布规划
+- 会议纪要和需求讨论
+- 当前项目事实的整理
+
+### 产品输出
+
+- 业务目标
+- 用户场景
+- 需求列表
+- 范围和非范围
+- 验收标准
+- 优先级
+- 当前项目事实
+- 给研发的待确认项
+
+### 产品停规则
+
+- 不写实现细节。
+- 不判断框架约束。
+- 不把结果直接写成面向代码的规格。
+- 不把当前项目事实和产品意图混成一句话。
+
+## 研发侧
+
+当任务主要涉及这些内容时，使用 `spec-refinement`：
+
+- 把已确认的产品需求转成可执行规格
+- 细化实现范围
+- 补齐验收缺口
+- 分析影响范围
+- 在设计或实现前准备研发输入
+- 对齐产品需求和当前项目事实
+
+### 研发输出
+
+- 可执行需求规格
+- 验收标准
+- 影响范围
+- 对齐说明
+- 任务计划
+- 实现输入摘要
+
+### 研发停规则
+
+- 不把 PRD 从头重写一遍。
+- 不直接进入代码生成。
+- 不跳过边界检查或当前选定的 rules bundle。
+- 不忽略当前项目事实。
+- 不把任务计划丢给实现阶段临时补。
+
+## 知识交接
+
+- 产品产物和研发产物都沉淀到 `knowledge-capture`。
+- 产品事实和研发事实保持关联，但不要混写。

package/skills/references/rule-loading-map.md

@@ -0,0 +1,108 @@
+# Rule Loading Map
+
+## Goal
+
+Keep rule loading separate from skill routing. Load the smallest rule set that matches the current task, then add the stack-specific overlay only when needed. When changed files are available, prefer them over workspace-wide heuristics.
+
+## Load Order
+
+### 1. Core Layer
+
+Use the core layer when the task is generic, the routing is unclear, or the current workspace does not need more specific rules yet.
+
+- `rules/index.md`
+- `rules/core/index.md`
+- `rules/skill-profile-map.md`
+- `PIG_SKILLS_RULE_SKILL=workflow-router`
+
+### 2. Workflow Layer
+
+Use the workflow layer when the task involves routing, handoff, boundary changes, or stage switching.
+
+- `rules/workflow/index.md`
+- `rules/workflow/refinement.md`
+- `rules/workflow/router.md`
+- `rules/workflow/selection.md`
+- `rules/workflow/stop.md`
+- `PIG_SKILLS_RULE_PROFILE=router|refinement`
+- `PIG_SKILLS_RULE_SKILL=workflow-router|spec-refinement`
+
+### 3. Coding Layer
+
+Use the coding layer when the task involves implementation, refactoring, testing, or scaffolding.
+
+- `rules/coding/index.md`
+- `rules/coding/analysis.md`
+- `rules/coding/implementation.md`
+- `rules/coding/testing.md`
+- `rules/coding/scaffold.md`
+- `rules/coding/boundary.md`
+- `rules/coding/validation.md`
+- `rules/coding/backend/index.md`
+- `rules/coding/backend/database.md`
+- `rules/coding/backend/query.md`
+- `rules/coding/backend/remote.md`
+- `rules/coding/backend/feign.md`
+- `rules/coding/backend/transaction-boundary.md`
+- `rules/coding/backend/transaction-rollback.md`
+- `rules/coding/backend/cache-keying.md`
+- `rules/coding/backend/cache-invalidation.md`
+- `PIG_SKILLS_RULE_PROFILE=analysis|implementation|testing|scaffold`
+- `PIG_SKILLS_RULE_SKILL=technical-design|feature-build|test-design|project-bootstrap|environment-deploy`
+
+### 4. Review Layer
+
+Use the review layer when the task involves code review, security review, performance review, or a quality gate.
+
+- `rules/review/index.md`
+- `rules/review/code.md`
+- `rules/review/java.md`
+- `rules/review/vue.md`
+- `rules/review/ts.md`
+- `rules/review/security.md`
+- `rules/review/performance.md`
+- `rules/review/rubric.md`
+- `rules/review/evidence.md`
+- `PIG_SKILLS_RULE_PROFILE=code|code-java|code-vue|code-ts|security|performance`
+- `PIG_SKILLS_RULE_SKILL=code-review|security-review|performance-check`
+
+`code-review` now resolves to `code` in this repository. The loader keeps the generic review profile first, then auto-adds stack overlays such as `code-java`, `code-vue`, and `code-ts` when the workspace or changed-file signal indicates those stacks.
+
+- `PIG_SKILLS_CHANGED_FILES` can be used to pass changed paths for more precise review overlay routing.
+
+### 5. Product / Docs Layer
+
+Use the product/docs layer when the task involves requirement intake, domain modeling, API docs, knowledge capture, or contract writing.
+
+- `rules/product/index.md`
+- `rules/product/intake.md`
+- `rules/product/modeling.md`
+- `rules/product/briefing.md`
+- `rules/product/acceptance.md`
+- `rules/docs/index.md`
+- `rules/docs/api.md`
+- `rules/docs/capture.md`
+- `rules/docs/reference.md`
+- `rules/docs/decision-log.md`
+- `rules/docs/contract.md`
+- `rules/docs/examples.md`
+- `rules/docs/capture-summary.md`
+- `PIG_SKILLS_RULE_PROFILE=intake|modeling|api|capture`
+- `PIG_SKILLS_RULE_SKILL=product-intake|domain-modeling|api-docs|knowledge-capture`
+
+### 6. Discovery Rules
+
+Do not pull product discovery into the coding bundle. Discovery dependencies should be:
+
+- `skills/references/requirements-separation-map.md`
+- `skills/knowledge-capture/SKILL.md`
+
+## Principles
+
+- Skills should point to this map, then load only the minimum files needed.
+- Do not duplicate rule-layer content inside every skill.
+- Load `core` first, then the matching bundle/profile.
+- `rule_profile` in skill frontmatter is the declaration source; mapping files are only for validation and fallback.
+- In non-production environments, the loader should fail fast when skill metadata and mapping metadata drift apart.
+- A new skill should start from `skills/references/skill-boundary-template.md`, then add only the skill-specific I/O and stop rules.
+- Negative replay tests should use `skills/references/negative-replay-scenarios.md` to validate stop boundaries and handoffs.

package/skills/references/skill-authoring-standard.md

@@ -0,0 +1,73 @@
+# Skill Authoring Standard
+
+## Goal
+Make every skill easy for AI to detect, cheap to read, and hard to misuse.
+
+## Required Shape
+- `name`: one canonical skill name
+- `description`: action + trigger + scope in one sentence
+- `lifecycle_stage`: stable stage label
+- `slash_commands`: only when the skill has a real command surface
+- `dependencies`: only true hard prerequisites
+- `triggers`: exact user phrases and intent keywords
+- `inputs`: what the skill consumes
+- `outputs`: what the skill must produce
+- `workflow`: short ordered steps
+- `gates`: objective completion checks
+- `refs`: where the long detail lives
+- `rule_profile`: optional hint for which rules bundle profile a skill should load
+
+## Template Levels
+- `short`: use [`skill-boundary-template.md`](skill-boundary-template.md) for routing, intake, capture, and other low-complexity skills.
+- `enhanced`: use [`skill-enhanced-template.md`](skill-enhanced-template.md) for design, implementation, review, and other high-density skills.
+- Keep one skill on one level unless the skill clearly crosses into a more complex phase.
+
+## Token Saving Rules
+- Keep the skill body short.
+- Move templates, long examples, and repeated background into `references/`.
+- Keep rule bundles in `rules/` and point `refs` at the smallest needed bundle.
+- Reuse `skills/references/skill-boundary-template.md` for the common skill shape.
+- Write once, reference many.
+- Prefer bullets over paragraphs.
+- Avoid repeating rule bundles in every skill.
+
+## AI Recognition Rules
+- Put trigger words in the first screen.
+- Use one name for one capability.
+- Make `description` concrete: verb + object + outcome.
+- Keep `lifecycle_stage` and `dependencies` stable.
+- Encode hard prerequisites in `dependencies`; keep soft routing hints in `triggers`.
+- When a skill needs rules, declare its preferred `rule_profile` rather than repeating rules in prose.
+- Add `适合 / 不适合` when the skill needs fast routing.
+- Put hard-stop rules in `gates`, not in prose.
+- Use `Quick Start`, `Inputs / Outputs`, and `Gotchas` only in enhanced skills.
+
+## Canonical Order
+1. Purpose
+2. Suitable / Unsuitable
+3. Quick Start
+4. Inputs / Outputs
+5. Workflow
+6. Replay Signals
+7. Gotchas
+8. Stop Rules
+9. References
+10. Safety
+
+## What Belongs Outside
+- Long tutorials
+- Large examples
+- Repeated rule details
+- External comparison notes
+- Shared templates
+- Negative replay scenarios
+
+## Template Selection
+- Short template: `workflow-router`, `product-intake`, `knowledge-capture`, `api-docs`, `test-design`, `domain-modeling`, `project-bootstrap`, `environment-deploy`
+- Enhanced template: `spec-refinement`, `technical-design`, `feature-build`, `code-review`, `security-review`, `performance-check`
+
+## Quality Bar
+- A model should know whether to use the skill in under 10 seconds.
+- A model should know what output to produce in under 20 seconds.
+- A human should be able to maintain the skill without reading half the repo.
+- A reviewer should be able to see the stop boundary and replay signal in one screen.

package/skills/references/skill-boundary-template.md

@@ -0,0 +1,38 @@
+# Skill 边界模板
+
+这是一份给基础 skill 复用的短模板。正文只保留可执行边界，不写长背景。
+
+## 默认结构
+
+```text
+## Purpose
+一句话说明这个 skill 只负责什么。
+
+## Suitable / Unsuitable
+- Suitable: 该 skill 该接的输入类型
+- Unsuitable: 该 skill 不该碰的工作
+
+## Workflow
+1. 识别输入。
+2. 执行本阶段工作。
+3. 产出本阶段工件。
+4. 交接到下一 skill。
+
+## Replay Signals
+- Input signal: 什么输入会触发这个 skill。
+- Output to verify: 需要检查什么产物。
+- Stop signal: 什么行为说明越界了。
+- Handoff signal: 什么时候交给下一 skill。
+
+## Stop Rules
+- 停在本阶段。
+- 不做下一阶段的工作。
+- 不跳过规则加载。
+```
+
+## 使用原则
+
+- `Replay Signals` 只写可验证的信号。
+- `Stop Rules` 只写硬边界。
+- 两者都要短，不要写成说明文。
+- 复杂 skill 需要升级到 [`skill-enhanced-template.md`](skill-enhanced-template.md)。

package/skills/references/skill-enhanced-template.md

@@ -0,0 +1,53 @@
+# Skill 增强模板
+
+这是一份给复杂 skill 复用的增强模板。它在短边界模板之上补充快速启动、输入输出和常见坑。
+
+## 默认结构
+
+```text
+## Purpose
+一句话说明这个 skill 只负责什么。
+
+## Suitable / Unsuitable
+- Suitable: 该 skill 该接的输入类型
+- Unsuitable: 该 skill 不该碰的工作
+
+## Quick Start
+- 一句话说明怎么进入这个 skill。
+- 一句话说明第一步看什么。
+
+## Inputs / Outputs
+- Inputs: 这个 skill 需要什么输入。
+- Outputs: 这个 skill 要交付什么产物。
+
+## Workflow
+1. 识别输入。
+2. 执行本阶段工作。
+3. 产出本阶段工件。
+4. 交接到下一 skill。
+
+## Replay Signals
+- Input signal: 什么输入会触发这个 skill。
+- Output to verify: 需要检查什么产物。
+- Stop signal: 什么行为说明越界了。
+- Handoff signal: 什么时候交给下一 skill。
+
+## Gotchas
+- 该 skill 最容易犯的 2-4 个错误。
+
+## Stop Rules
+- 停在本阶段。
+- 不做下一阶段的工作。
+- 不跳过规则加载。
+
+## References
+- 该 skill 依赖的最小 references。
+```
+
+## 使用原则
+
+- 增强模板只给复杂 skill。
+- `Quick Start` 先帮模型快速进入任务。
+- `Inputs / Outputs` 让产出更稳定。
+- `Gotchas` 只写最常见、最容易越界的点。
+- `References` 只挂最小必要文件，不要堆背景。

package/skills/references/skill-reference-matrix.md

@@ -0,0 +1,53 @@
+# Skill Reference Matrix
+
+## Borrowed Patterns
+
+| Source | Best Practice | Applies To |
+|---|---|---|
+| GitHub Spec Kit | Define before build | `spec-refinement` |
+| AWS Kiro EARS | Structured requirement writing | `spec-refinement` |
+| RIPER | Research / Innovate / Plan / Execute / Review | `spec-refinement` / routing context |
+| Claude Code | Short, dense prompts | all skills |
+| open-code-review | Deterministic review plus agent review | `code-review` |
+| Skill Reviewer | Rubric-based review gate | `code-review` / `performance-check` / `security-review` |
+| Short boundary template | One screen for Purpose / Workflow / Replay Signals / Stop Rules | low-complexity skills |
+| Enhanced template | Add Quick Start / Inputs / Outputs / Gotchas / References | `spec-refinement` / `technical-design` / `feature-build` / `code-review` / `security-review` / `performance-check` |
+| Negative replay | Use counterexamples to verify stop boundaries | `spec-refinement` / `technical-design` / `feature-build` / `test-design` |
+| Engineering delivery method | Decide complexity first, then split and implement inside `feature-build` | `feature-build` / `test-design` / `code-review` |
+| Engineering delivery template | One-page task card with facts, complexity, tasks, self-test, and validation | `feature-build` / `test-design` |
+
+## Skill Principles
+
+- Collect the boundary first, then expand output.
+- Use verifiable facts instead of guesses.
+- Keep existing boundaries during iteration.
+- Let objective gates take priority over narrative explanation.
+- Move long content into dedicated references.
+- Keep framework rules in `rules/`; do not write them into skill bodies.
+
+## Applicable Skills
+
+- `product-intake`: turn business intent into a PRD-ready brief
+- `spec-refinement`: turn approved requirements into an executable spec
+- `technical-design`: turn complex changes into boundaries, dependencies, and rollback
+- `feature-build`: turn the confirmed spec into code
+- `test-design`: turn implementation results into a validation plan
+- `knowledge-capture`: turn product and engineering facts into requirements knowledge, realtime code facts, CodeWiki entries, and enterprise knowledge
+- `api-docs`: turn confirmed interfaces into docs
+- `domain-modeling`: turn domain language into boundaries
+- `workflow-router`: route the stage
+- `code-review`: output generic review findings
+- `security-review`: output security findings
+- `performance-check`: output performance findings
+
+## Template Selection
+
+- Short template: `workflow-router`, `product-intake`, `knowledge-capture`, `api-docs`, `test-design`, `domain-modeling`, `project-bootstrap`, `environment-deploy`
+- Enhanced template: `spec-refinement`, `technical-design`, `feature-build`, `code-review`, `security-review`, `performance-check`
+
+## Rules Loading
+
+- `rules/` is the only source for framework knowledge.
+- Use `skills/references/rule-loading-map.md` to decide which bundle to load.
+- Load the smallest bundle that covers the task.
+- Skills should reference at least one `rules` bundle when the task touches code.

package/skills/references/slash-commands.md

@@ -0,0 +1,34 @@
+# Canonical Skill Entry Mapping
+
+This page maps older slash-command style entry points to canonical skill names.
+
+## Skill Mapping
+
+| Skill | Use |
+|---|---|
+| `workflow-router` | Stage routing and handoff |
+| `product-intake` | Product intent capture |
+| `spec-refinement` | PRD, facts, and knowledge alignment into executable spec |
+| `technical-design` | Boundaries, dependencies, and interfaces |
+| `feature-build` | Implementation and task-level self-test |
+| `test-design` | Test strategy and regression coverage |
+| `code-review` | Generic code review findings |
+| `security-review` | Security findings only |
+| `performance-check` | Performance findings only |
+| `knowledge-capture` | Decision and artifact capture |
+| `domain-modeling` | Boundary extraction and domain terms |
+| `api-docs` | API contract capture |
+
+## Common Chains
+
+```text
+workflow-router -> product-intake -> spec-refinement -> technical-design -> feature-build -> test-design -> code-review -> knowledge-capture
+product-intake -> spec-refinement
+feature-build -> test-design -> code-review -> knowledge-capture
+```
+
+## Notes
+
+- Canonical skill names take precedence over old slash-command names.
+- Keep framework rules in `rules/`.
+- Keep skill bodies short and stable.

package/skills/security-review/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: security-review
+description: Review a diff, endpoint, or design note for auth, secret, or data exposure risks when security findings are needed
+lifecycle_stage: review
+rule_profile: security
+dependencies:
+  - feature-build
+triggers:
+  - security
+  - injection
+  - secret
+  - permission
+  - auth
+  - data exposure
+  - trust boundary
+inputs:
+  - diff
+  - design notes
+  - endpoint behavior
+outputs:
+  - security findings
+  - risk level
+  - mitigation advice
+  - trust boundary summary
+  - review summary
+workflow:
+  - identify trust boundaries and sensitive flows
+  - inspect input validation and authorization
+  - route generic correctness issues to `code-review`
+  - rank the risks by severity
+  - produce mitigation advice
+gates:
+  - stop at security findings
+  - do not rewrite code
+  - do not turn into a general review
+refs:
+  - skills/references/rule-loading-map.md
+  - skills/references/prompt-replay-checklist.md
+  - skills/references/full-chain-replay-scenarios.md
+  - rules/index.md
+---
+
+# Security Review
+
+## Purpose
+
+Find and rank security risks before release.
+
+## Suitable / Unsuitable
+
+- Suitable: injection, secrets, permissions, auth, data exposure, trust boundary breaks
+- Unsuitable: implementation work, broad code review, requirement discovery, generic correctness review
+
+## Quick Start
+
+- Start by mapping trust boundaries and sensitive flows.
+- Inspect authorization and input validation before anything else.
+- Keep the output focused on findings and mitigation advice.
+- If the issue is only about correctness or maintainability, hand off to `code-review`.
+
+## Report Format
+
+- Use one entry per security finding.
+- Include `location`, `risk level`, `attack path`, `impacted asset`, `evidence`, and `mitigation advice`.
+- Anchor each finding to the smallest relevant security surface:
+  - endpoint, auth flow, permission boundary, secret handling path, or data exposure path
+- State the violated trust boundary when it is clear.
+- Keep the review summary short when no security issue is present.
+- If there are no findings, say what was checked and why the change is acceptable.
+
+## Inputs / Outputs
+
+- Inputs:
+  - diff
+  - design notes
+  - endpoint behavior
+- Outputs:
+  - security findings
+  - risk level
+  - mitigation advice
+  - trust boundary summary
+
+## Workflow
+
+1. Identify trust boundaries and sensitive flows.
+2. Inspect input validation and authorization.
+3. Route generic correctness issues to `code-review`.
+4. Rank the risks by severity.
+5. Produce mitigation advice.
+
+## Replay Signals
+
+- Input signal: diff, design notes, endpoint behavior, or a security concern.
+- Output to verify: security findings, risk level, mitigation advice, trust boundary summary, review summary.
+- Stop signal: rewrite code or turn into a general review.
+- Handoff signal: the findings are ready for `knowledge-capture`.
+
+## Gotchas
+
+- Do not blur security review into generic correctness review.
+- Do not skip trust boundaries.
+- Do not omit risk level when reporting findings.
+- Do not approve changes without explicit evidence.
+- Do not file a generic code-quality issue as a security finding.
+
+## Stop Rules
+
+- Stop at security findings.
+- Do not rewrite code.
+- Do not turn into a general review.
+
+## References
+
+- `skills/references/rule-loading-map.md`
+- `skills/references/prompt-replay-checklist.md`
+- `skills/references/full-chain-replay-scenarios.md`
+- `rules/index.md`

package/skills/spec-refinement/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: spec-refinement
+description: Refine approved demand into an executable spec by aligning product intent, project facts, prototypes, implementation facts, and knowledge-base evidence when acceptance gaps, constraints, or implementation inputs remain
+lifecycle_stage: refinement
+rule_profile: refinement
+dependencies:
+  - product-intake
+triggers:
+  - requirement clarification
+  - acceptance gap
+  - impact analysis
+  - engineering spec
+  - open question
+inputs:
+  - approved product brief
+  - current project facts
+  - prototype notes
+  - implementation facts
+  - scope decisions
+  - open questions
+  - rules bundle
+outputs:
+  - executable spec
+  - execution direction plan
+  - acceptance criteria
+  - impact scope
+  - implementation inputs
+  - alignment notes
+  - task breakdown plan
+  - confirmation package
+workflow:
+  - verify the product brief is approved
+  - compare the brief with current project facts, prototype notes, implementation facts, and knowledge snippets
+  - clarify boundaries, assumptions, and acceptance gaps
+  - identify conflicts between intent and current facts
+  - decide the task execution direction before splitting tasks
+  - extract a task breakdown plan for user confirmation
+  - define implementation-facing constraints and verification inputs
+  - assemble a confirmation package for user sign-off
+  - hand off to technical-design or feature-build only after confirmation
+gates:
+  - stop at spec clarity
+  - do not restart PRD writing
+  - do not generate code
+  - do not skip the selected rules bundle
+refs:
+  - skills/references/requirements-separation-map.md
+  - skills/references/project-requirement-alignment.md
+  - skills/references/engineering-delivery-method.md
+  - skills/references/engineering-delivery-template.md
+  - skills/references/rule-loading-map.md
+  - skills/references/flow-test-cases.md
+  - skills/references/full-chain-replay-scenarios.md
+  - skills/references/prompt-replay-checklist.md
+  - rules/index.md
+---
+
+# Spec Refinement
+
+## Purpose
+
+Turn approved product input into an executable spec for engineering. This skill ends when the scope is clear enough for design or implementation.
+
+## Suitable / Unsuitable
+
+- Suitable: requirement clarification, boundary checks, acceptance gaps, impact analysis, project-fact alignment, prototype alignment, implementation-fact alignment
+- Unsuitable: redoing the PRD, writing code, selecting rule bundles, skipping the rules bundle
+
+## Quick Start
+
+- Start from the approved brief and compare it with current project facts, prototype notes, implementation facts, code, docs, and knowledge snippets.
+- Identify acceptance gaps and fact conflicts before writing any implementation-facing spec.
+- Decide the task execution direction before extracting the task breakdown plan.
+- Extract the task breakdown plan so feature-build can break the work into small tasks.
+- Convert the result into an executable spec that AI can follow without re-interpreting the PRD.
+  - Package the spec, task plan, and acceptance criteria into a confirmation package before execution starts.
+- If scope is still unstable, stop and keep the output at spec clarity.
+
+## Inputs / Outputs
+
+- Inputs:
+  - approved product brief
+  - current project facts
+  - prototype notes
+  - implementation facts
+  - knowledge snippets
+  - scope decisions
+  - open questions
+  - rules bundle
+- Outputs:
+  - executable spec
+  - execution direction plan
+  - acceptance criteria
+  - impact scope
+  - implementation inputs
+  - alignment notes
+  - conflict map
+  - task breakdown plan
+  - confirmation package
+
+## Workflow
+
+1. Verify the product brief is approved.
+2. Compare the brief with current project facts, prototype notes, implementation facts, docs, and known constraints.
+3. Clarify boundaries, assumptions, acceptance gaps, and fact conflicts.
+4. Extract the task breakdown plan for later implementation.
+5. Write the execution direction plan, executable spec, task breakdown plan, conflict map, implementation inputs, and confirmation package.
+6. Hand off to `technical-design` or `feature-build` when the scope is stable and confirmed.
+7. Stop before code generation.
+
+## Replay Signals
+
+- Input signal: approved PRD, open acceptance gaps, or code-to-requirement alignment work.
+- Output to verify: executable spec, execution direction plan, acceptance criteria, impact scope, alignment notes, conflict map, task breakdown plan, implementation input summary, confirmation package.
+- Stop signal: code generation, implementation detail expansion, or redoing the PRD.
+- Handoff signal: the spec is stable enough for `technical-design` or `feature-build`.
+
+## Gotchas
+
+- Do not reopen product discovery.
+- Do not ignore current project facts.
+- Do not ignore knowledge-base evidence.
+- Do not rewrite the PRD when the task is spec refinement.
+- Do not let implementation details leak into the brief.
+- Do not collapse the task breakdown plan into one coarse requirement.
+- Do not skip the selected rules bundle.
+
+## Stop Rules
+
+- Stop at spec clarity.
+- Do not restart PRD writing.
+- Do not rewrite the PRD.
+- Do not jump into implementation.
+- Do not generate code.
+- Do not ignore the selected rules bundle.
+- Do not skip the selected rules bundle.
+
+## References
+
+- `skills/references/requirements-separation-map.md`
+- `skills/references/rule-loading-map.md`
+- `skills/references/flow-test-cases.md`
+- `rules/index.md`