@pigcloud/skills 1.0.4 → 1.0.6

package/skills/references/business-fact-extraction.md

@@ -177,7 +177,7 @@ Use the strongest source available first:
 
 ## Auto-Write Pack
 
-Use `skills/extract-business-facts/scripts/write-knowledge-base.js` when the staged readout should be written into the knowledge base.
+Use `skills/business-fact-extraction/scripts/write-knowledge-base.js` when the staged readout should be written into the knowledge base.
 
 ### Input Shape
 
@@ -200,7 +200,7 @@ Use `skills/extract-business-facts/scripts/write-knowledge-base.js` when the sta
 ### Command
 
 ```bash
-node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-pack.json
+node skills/business-fact-extraction/scripts/write-knowledge-base.js --input fact-pack.json
 ```
 
 ### Behavior
@@ -214,7 +214,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 ## Handoff Targets
 
 - `domain-modeling` when the facts need boundary or concept normalization
-- `spec` when the facts need to become a user-confirmable spec
+- `spec-refinement` when the facts need to become a user-confirmable spec-refinement
 - `knowledge-capture` when the facts are stable and ready to persist
 
 ## Sample Readout
@@ -252,7 +252,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 - decision: inventory must be reserved before order confirmation
 - reason: avoid overselling
 - date or context: 2026-06-22, order flow review
-- affected artifact: checkout spec
+- affected artifact: checkout spec-refinement
 - notes: failure should return a clear stock shortage message
 
 #### `knowledge-base/requirements/acceptance.md`
@@ -292,7 +292,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 
 ### 1. Source Input
 
-- PRD / spec note: checkout must not confirm when stock is insufficient
+- PRD / spec-refinement note: checkout must not confirm when stock is insufficient
 - code evidence: `order-service` reserves inventory before creating the order
 - runtime evidence: shortage returns a stock error before commit
 
@@ -330,7 +330,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
         "decision": "inventory must be reserved before order confirmation",
         "reason": "avoid overselling",
         "date or context": "2026-06-22, checkout review",
-        "affected artifact": "checkout spec",
+        "affected artifact": "checkout spec-refinement",
         "notes": "shortage returns a clear error"
       }
     ],
@@ -357,7 +357,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 ### 4. Persist
 
 ```bash
-node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-pack.json
+node skills/business-fact-extraction/scripts/write-knowledge-base.js --input fact-pack.json
 ```
 
 ### 5. `knowledge-capture`
@@ -392,7 +392,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 - decision: inventory must be reserved before order confirmation
 - reason: avoid overselling
 - date or context: 2026-06-22, order flow review
-- affected artifact: checkout spec
+- affected artifact: checkout spec-refinement
 - notes: failure should return a clear stock shortage message
 
 ### CodeWiki Update
@@ -412,3 +412,4 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 - context: checkout path
 - why it failed: allowed overselling under concurrent requests
 - how to avoid it: reserve before committing the order
+

package/skills/references/engineering-delivery-method.md

@@ -2,14 +2,14 @@
 
 ## Goal
 
-Help engineering teams turn an approved spec into executable work, decide complexity before coding, implement inside `feature-build`, self-verify locally, and then hand off to validation and review.
+Help engineering teams turn an approved spec-refinement into executable work, decide complexity before coding, implement inside `feature-build`, self-verify locally, and then hand off to validation and review.
 
 Use [`engineering-delivery-template.md`](engineering-delivery-template.md) when you need the copyable one-page form.
 
 ## Flow
 
-1. Start from an approved spec or executable design.
-2. Align the spec with current project facts and selected rules.
+1. Start from an approved spec-refinement or executable design.
+2. Align the spec-refinement with current project facts and selected rules.
 3. Plan the task execution direction before coding.
 4. Decide whether the change is simple or complex before coding.
 5. If the change is complex, produce `technical-design` first.
@@ -61,3 +61,4 @@ Use [`engineering-delivery-template.md`](engineering-delivery-template.md) when
 - `skills/references/project-requirement-alignment.md`
 - `skills/references/flow-test-cases.md`
 - `skills/references/full-chain-replay-scenarios.md`
+

package/skills/references/engineering-delivery-template.md

@@ -2,7 +2,7 @@
 
 ## How to Use
 
-- Start from an approved spec or executable design.
+- Start from an approved spec-refinement or executable design.
 - Fill this page before implementation.
 - Keep each task small enough to implement and self-test independently.
 - Do not add long background text.
@@ -73,8 +73,9 @@ Rules:
 
 ## Minimum Acceptance
 
-- The spec is split into small tasks.
+- The spec-refinement is split into small tasks.
 - The execution direction is explicit before confirmation.
 - Every task has a done criteria and a self-test.
 - The implementation was verified task by task.
 - The handoff includes evidence, not just code.
+

package/skills/references/golden-prompt-suite.js

@@ -16,7 +16,7 @@ const cases = [
     'We have a new request but I am not sure which stage should handle it.',
     ['next skill', 'stage decision', 'handoff note'],
     'Do not perform the target skill\'s work.',
-    'spec',
+    'spec-refinement',
   ),
   makeCase(
     'workflow-router',
@@ -24,7 +24,7 @@ const cases = [
     'The brief is ready. Which stage should receive it next?',
     ['next skill', 'stage decision', 'handoff note'],
     'Do not perform the target skill\'s work.',
-    'spec',
+    'spec-refinement',
   ),
   makeCase(
     'workflow-router',
@@ -36,76 +36,76 @@ const cases = [
   ),
 
   makeCase(
-    'spec',
+    'spec-refinement',
     'product-reminder-feature',
     'We need a reminder feature for inactive users.',
     ['product brief', 'scope', 'acceptance outline', 'open questions'],
     'Do not jump into design or code.',
-    'spec',
+    'spec-refinement',
   ),
   makeCase(
-    'spec',
+    'spec-refinement',
     'product-retention-gap',
     'Users keep missing renewal emails; help me define the product scope.',
     ['product objective', 'scope', 'acceptance outline', 'open questions'],
     'Do not decide implementation details.',
-    'spec',
+    'spec-refinement',
   ),
   makeCase(
-    'spec',
+    'spec-refinement',
     'product-unclear-opportunity',
     'We think there is a retention problem, but the exact feature is unclear.',
     ['product objective', 'scope', 'acceptance outline', 'open questions'],
     'Do not write technical design.',
-    'spec',
+    'spec-refinement',
   ),
 
   makeCase(
-    'spec',
+    'spec-refinement',
     'spec-approved-brief',
-    'The brief is approved; turn it into an executable spec and task breakdown.',
-    ['executable spec', 'task breakdown plan', 'acceptance criteria', 'confirmation package'],
+    'The brief is approved; turn it into an executable spec-refinement and task breakdown.',
+    ['executable spec-refinement', 'task breakdown plan', 'acceptance criteria', 'confirmation package'],
     'Do not generate code or reopen discovery.',
     'feature-build',
   ),
   makeCase(
-    'spec',
+    'spec-refinement',
     'spec-code-alignment',
-    'Compare the PRD with current project facts and implementation evidence, then produce the engineering spec.',
+    'Compare the PRD with current project facts and implementation evidence, then produce the engineering spec-refinement.',
     ['execution direction plan', 'impact scope', 'implementation inputs', 'conflict map'],
     'Do not jump into implementation.',
     'technical-design',
   ),
   makeCase(
-    'spec',
+    'spec-refinement',
     'spec-confirmation-pack',
-    'I need a confirmation package with the spec, tasks, and acceptance criteria before coding.',
-    ['executable spec', 'task breakdown plan', 'confirmation package'],
+    'I need a confirmation package with the spec-refinement, tasks, and acceptance criteria before coding.',
+    ['executable spec-refinement', 'task breakdown plan', 'confirmation package'],
     'Do not write code.',
     'feature-build',
   ),
 
   makeCase(
-    'spec',
+    'spec-refinement',
     'spec-approved-brief',
-    'The brief is approved; turn it into an executable spec.',
-    ['executable spec', 'acceptance criteria', 'impact scope', 'implementation inputs'],
+    'The brief is approved; turn it into an executable spec-refinement.',
+    ['executable spec-refinement', 'acceptance criteria', 'impact scope', 'implementation inputs'],
     'Do not rewrite the PRD or code the change.',
     'feature-build',
   ),
   makeCase(
-    'spec',
+    'spec-refinement',
     'spec-code-gap',
     'Compare the PRD with the current code and identify gaps.',
-    ['executable spec', 'impact scope', 'implementation inputs'],
+    ['executable spec-refinement', 'impact scope', 'implementation inputs'],
     'Do not jump into implementation.',
     'feature-build',
   ),
   makeCase(
-    'spec',
+    'spec-refinement',
     'spec-align-with-code',
     'The requirement is messy; align it with existing behavior and make it engineer-ready.',
-    ['executable spec', 'acceptance criteria', 'implementation input summary'],
+    ['executable spec-refinement', 'acceptance criteria', 'implementation input summary'],
     'Do not rewrite the PRD.',
     'technical-design',
   ),
@@ -138,7 +138,7 @@ const cases = [
   makeCase(
     'feature-build',
     'build-approved-spec',
-    'Implement the approved spec in the controller and service.',
+    'Implement the approved spec-refinement in the controller and service.',
     ['code changes', 'implementation notes', 'validation evidence'],
     'Do not expand scope or rewrite requirements.',
     'test-design',
@@ -156,7 +156,7 @@ const cases = [
     'build-simple-refactor',
     'This controller needs a simple refactor that does not change behavior.',
     ['code changes', 'implementation notes', 'validation evidence'],
-    'Do not rewrite the spec.',
+    'Do not rewrite the spec-refinement.',
     'test-design',
   ),
 
@@ -236,7 +236,7 @@ const cases = [
   ),
 
   makeCase(
-    'api-docs',
+    'api-contract-docs',
     'api-profile-docs',
     'Document the user profile endpoints with request and response shapes.',
     ['API document', 'contract notes', 'examples'],
@@ -244,7 +244,7 @@ const cases = [
     'knowledge-capture',
   ),
   makeCase(
-    'api-docs',
+    'api-contract-docs',
     'api-payment-contract',
     'Write the contract for this payment endpoint with examples.',
     ['API document', 'contract notes', 'examples'],
@@ -252,7 +252,7 @@ const cases = [
     'knowledge-capture',
   ),
   makeCase(
-    'api-docs',
+    'api-contract-docs',
     'api-openapi-notes',
     'Capture the OpenAPI notes for a new endpoint.',
     ['API document', 'contract notes', 'examples'],
@@ -282,19 +282,19 @@ const cases = [
     'Extract ubiquitous language from the current product notes.',
     ['domain map', 'core concepts', 'boundary notes'],
     'Do not write implementation code.',
-    'spec',
+    'spec-refinement',
   ),
 
   makeCase(
-    'extract-business-facts',
-    'extract-business-facts-from-code',
+    'business-fact-extraction',
+    'business-fact-extraction-from-code',
     'Extract the business facts expressed by this order-processing code and explain the current behavior.',
     ['code fact map', 'business fact map', 'codewiki delta'],
     'Do not design a new solution.',
     'knowledge-capture',
   ),
   makeCase(
-    'extract-business-facts',
+    'business-fact-extraction',
     'extract-business-invariants',
     'From these service methods and tests, identify the business invariants and open questions.',
     ['code fact map', 'business fact map', 'codewiki delta'],
@@ -302,16 +302,16 @@ const cases = [
     'domain-modeling',
   ),
   makeCase(
-    'extract-business-facts',
+    'business-fact-extraction',
     'extract-code-backed-terms',
     'Turn this controller, service, and database flow into a terminology map with evidence.',
     ['code fact map', 'business fact map', 'codewiki delta'],
     'Do not generate code.',
-    'spec',
+    'spec-refinement',
   ),
 
   makeCase(
-    'security-review',
+    'security-audit',
     'security-injection-auth',
     'Check this change for injection, auth, and secret handling issues.',
     ['security findings', 'risk level', 'mitigation advice'],
@@ -319,7 +319,7 @@ const cases = [
     'knowledge-capture',
   ),
   makeCase(
-    'security-review',
+    'security-audit',
     'security-permissions',
     'Review permission boundaries and data exposure risks.',
     ['security findings', 'risk level', 'mitigation advice'],
@@ -327,7 +327,7 @@ const cases = [
     'knowledge-capture',
   ),
   makeCase(
-    'security-review',
+    'security-audit',
     'security-bypass-check',
     'Find any auth bypass or sensitive-data leaks in this diff.',
     ['security findings', 'risk level', 'mitigation advice'],
@@ -336,7 +336,7 @@ const cases = [
   ),
 
   makeCase(
-    'performance-check',
+    'performance-audit',
     'perf-slow-endpoint',
     'This endpoint is slow; inspect query cost, cache, and concurrency.',
     ['performance findings', 'bottleneck map', 'optimization advice'],
@@ -344,7 +344,7 @@ const cases = [
     'knowledge-capture',
   ),
   makeCase(
-    'performance-check',
+    'performance-audit',
     'perf-hot-path',
     'Find bottlenecks in the hot path and suggest improvements.',
     ['performance findings', 'bottleneck map', 'optimization advice'],
@@ -352,7 +352,7 @@ const cases = [
     'knowledge-capture',
   ),
   makeCase(
-    'performance-check',
+    'performance-audit',
     'perf-memory-latency',
     'Review memory pressure and response latency risks.',
     ['performance findings', 'bottleneck map', 'optimization advice'],
@@ -382,7 +382,7 @@ const cases = [
     'Bootstrap a fresh repository scaffold and hand it off.',
     ['starter structure', 'installed bundle', 'setup notes'],
     'Do not start feature implementation.',
-    'spec',
+    'spec-refinement',
   ),
 
   makeCase(
@@ -411,10 +411,10 @@ const cases = [
   ),
 
   makeCase(
-    'spec',
+    'spec-refinement',
     'negative-direct-code',
     'Just code it, the PRD is small.',
-    ['executable spec'],
+    ['executable spec-refinement'],
     'Do not jump directly into implementation.',
     'feature-build',
   ),
@@ -433,3 +433,4 @@ module.exports = {
   purpose: 'Golden prompt set for replay testing the full skill chain.',
   cases,
 };
+

package/skills/references/project-requirement-alignment.md

@@ -16,7 +16,7 @@ Use this guide when a task needs both product intent and current project facts.
 2. Summarize what the current project already does or guarantees.
 3. Mark what is unchanged, what must change, and what is still unknown.
 4. Record conflicts between product demand and current project facts.
-5. Turn the result into either a product brief or an executable spec, depending on the stage.
+5. Turn the result into either a product brief or an executable spec-refinement, depending on the stage.
 
 ## Output Shape
 
@@ -39,3 +39,4 @@ Use this guide when a task needs both product intent and current project facts.
 
 - `skills/references/requirements-separation-map.md`
 - `docs/engineering-workflow.md`
+

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

@@ -33,7 +33,7 @@ Use the workflow layer when the task involves routing, handoff, boundary changes
 - `rules/workflow/selection.md`
 - `rules/workflow/stop.md`
 - `PIG_SKILLS_RULE_PROFILE=router|refinement`
-- `PIG_SKILLS_RULE_SKILL=workflow-router|spec`
+- `PIG_SKILLS_RULE_SKILL=workflow-router|spec-refinement`
 
 ### 3. Coding Layer
 
@@ -72,7 +72,7 @@ Use the review layer when the task involves code review, security review, perfor
 - `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`
+- `PIG_SKILLS_RULE_SKILL=code-review|security-audit|performance-audit`
 
 `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.
 
@@ -96,7 +96,7 @@ Use the product/docs layer when the task involves requirement intake, reverse-en
 - `rules/docs/examples.md`
 - `rules/docs/capture-summary.md`
 - `PIG_SKILLS_RULE_PROFILE=intake|modeling|api|capture`
-- `PIG_SKILLS_RULE_SKILL=spec|domain-modeling|extract-business-facts|api-docs|knowledge-capture`
+- `PIG_SKILLS_RULE_SKILL=spec-refinement|domain-modeling|business-fact-extraction|api-contract-docs|knowledge-capture`
 
 ### 6. Discovery Rules
 
@@ -114,3 +114,4 @@ Do not pull product discovery into the coding bundle. Discovery dependencies sho
 - 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

@@ -38,7 +38,7 @@ Make every skill easy for AI to detect, cheap to read, and hard to misuse.
 - 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.
+- 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.
 
@@ -63,11 +63,12 @@ Make every skill easy for AI to detect, cheap to read, and hard to misuse.
 - Negative replay scenarios
 
 ## Template Selection
-- Short template: `workflow-router`, `knowledge-capture`, `api-docs`, `test-design`, `domain-modeling`, `project-bootstrap`, `environment-deploy`
-- Enhanced template: `spec`, `technical-design`, `feature-build`, `code-review`, `security-review`, `performance-check`, `extract-business-facts`
+- Short template: `workflow-router`, `knowledge-capture`, `api-contract-docs`, `test-design`, `domain-modeling`, `project-bootstrap`, `environment-deploy`
+- Enhanced template: `spec-refinement`, `technical-design`, `feature-build`, `code-review`, `security-audit`, `performance-audit`, `business-fact-extraction`
 
 ## 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-reference-matrix.md

@@ -11,15 +11,15 @@
 
 | Source | Best Practice | Applies To |
 |---|---|---|
-| GitHub Spec Kit | Define before build | `spec` |
-| AWS Kiro EARS | Structured requirement writing | `spec` |
-| RIPER | Research / Innovate / Plan / Execute / Review | `spec` / routing context |
+| 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` |
+| Skill Reviewer | Rubric-based review gate | `code-review` / `performance-audit` / `security-audit` |
 | 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` / `technical-design` / `feature-build` / `code-review` / `security-review` / `performance-check` |
-| Negative replay | Use counterexamples to verify stop boundaries | `spec` / `technical-design` / `feature-build` / `test-design` |
+| Enhanced template | Add Quick Start / Inputs / Outputs / Gotchas / References | `spec-refinement` / `technical-design` / `feature-build` / `code-review` / `security-audit` / `performance-audit` |
+| 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` |
 
@@ -34,23 +34,23 @@
 
 ## Applicable Skills
 
-- `spec`: turn product input, current facts, and implementation evidence into an executable spec
+- `spec-refinement`: turn product input, current facts, and implementation evidence into an executable spec-refinement
 - `technical-design`: turn complex changes into boundaries, dependencies, and rollback
-- `feature-build`: turn the confirmed spec into code
+- `feature-build`: turn the confirmed spec-refinement 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, enterprise knowledge, and persisted knowledge-base packs
-- `api-docs`: turn confirmed interfaces into docs
+- `api-contract-docs`: turn confirmed interfaces into docs
 - `domain-modeling`: turn domain language into boundaries
-- `extract-business-facts`: turn code-backed evidence into code facts, business facts, CodeWiki deltas, and file targets
+- `business-fact-extraction`: turn code-backed evidence into code facts, business facts, CodeWiki deltas, and file targets
 - `workflow-router`: route the stage
 - `code-review`: output generic review findings
-- `security-review`: output security findings
-- `performance-check`: output performance findings
+- `security-audit`: output security findings
+- `performance-audit`: output performance findings
 
 ## Template Selection
 
-- Short template: `workflow-router`, `knowledge-capture`, `api-docs`, `test-design`, `domain-modeling`, `project-bootstrap`, `environment-deploy`
-- Enhanced template: `spec`, `technical-design`, `feature-build`, `code-review`, `security-review`, `performance-check`, `extract-business-facts`
+- Short template: `workflow-router`, `knowledge-capture`, `api-contract-docs`, `test-design`, `domain-modeling`, `project-bootstrap`, `environment-deploy`
+- Enhanced template: `spec-refinement`, `technical-design`, `feature-build`, `code-review`, `security-audit`, `performance-audit`, `business-fact-extraction`
 
 ## Rules Loading
 
@@ -59,3 +59,4 @@
 - Load the smallest bundle that covers the task.
 - Skills should reference at least one `rules` bundle when the task touches code.
 
+

package/skills/{security-review → security-audit}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: security-review
+name: security-audit
 description: 当需要安全结论时，对 diff、接口或设计说明中的认证、密钥或数据暴露风险进行审查
 lifecycle_stage: review
 rule_profile: security
@@ -40,7 +40,7 @@ refs:
   - rules/index.md
 ---
 
-# Security Review
+# Security Audit
 
 ## Purpose
 
@@ -115,3 +115,5 @@ Find and rank security risks before release.
 - `skills/references/prompt-replay-checklist.md`
 - `skills/references/full-chain-replay-scenarios.md`
 - `rules/index.md`
+
+# Security Audit

package/skills/{spec → spec-refinement}/SKILL.md

@@ -1,15 +1,15 @@
 ---
-name: spec
-description: Turn PRDs, prototypes, current project facts, implementation facts, and knowledge-base evidence into an executable engineering spec, task breakdown, and confirmation package; use when requirements must be clarified and aligned before design or implementation.
+name: spec-refinement
+description: 当需求需要澄清并在设计或实现前对齐时，将 PRD、原型、项目事实、实现事实和知识库证据整理为可执行的规格说明、任务拆分和确认包
 lifecycle_stage: refinement
 rule_profile: refinement
 dependencies:
   - workflow-router
 triggers:
-  - spec
+  - spec-refinement
   - requirement clarification
   - acceptance gap
-  - engineering spec
+  - engineering spec-refinement
   - task breakdown
   - execution direction
   - confirmation package
@@ -22,7 +22,7 @@ inputs:
   - open questions
   - rules bundle
 outputs:
-  - executable spec
+  - executable spec-refinement
   - execution direction plan
   - acceptance criteria
   - impact scope
@@ -41,7 +41,7 @@ workflow:
   - assemble a confirmation package for user sign-off
   - hand off to `technical-design` or `feature-build` only after confirmation
 gates:
-  - stop at spec clarity
+  - stop at spec-refinement clarity
   - do not restart PRD writing
   - do not generate code
   - do not skip the selected rules bundle
@@ -57,11 +57,11 @@ refs:
   - rules/index.md
 ---
 
-# Spec
+# Spec Refinement
 
 ## Purpose
 
-Turn product input, current project facts, and implementation evidence into an executable engineering spec.
+Turn product input, current project facts, and implementation evidence into an executable engineering spec-refinement.
 
 ## Suitable / Unsuitable
 
@@ -71,12 +71,12 @@ Turn product input, current project facts, and implementation evidence into an e
 ## 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.
+- Identify acceptance gaps and fact conflicts before writing any implementation-facing spec-refinement.
 - 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.
+- Convert the result into an executable spec-refinement that AI can follow without re-interpreting the PRD.
+- Package the spec-refinement, task plan, and acceptance criteria into a confirmation package before execution starts.
+- If scope is still unstable, stop and keep the output at spec-refinement clarity.
 
 ## Inputs / Outputs
 
@@ -90,7 +90,7 @@ Turn product input, current project facts, and implementation evidence into an e
   - open questions
   - rules bundle
 - Outputs:
-  - executable spec
+  - executable spec-refinement
   - execution direction plan
   - acceptance criteria
   - impact scope
@@ -106,30 +106,30 @@ Turn product input, current project facts, and implementation evidence into an e
 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.
+5. Write the execution direction plan, executable spec-refinement, 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.
+- Output to verify: executable spec-refinement, 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`.
+- Handoff signal: the spec-refinement 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 rewrite the PRD during 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.
+- Stop at spec-refinement clarity.
 - Do not restart PRD writing.
 - Do not rewrite the PRD.
 - Do not jump into implementation.
@@ -146,3 +146,4 @@ Turn product input, current project facts, and implementation evidence into an e
 - `skills/references/rule-loading-map.md`
 - `rules/index.md`
 
+