@pigcloud/skills 1.0.5 → 1.0.7

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`
 
+

package/skills/technical-design/SKILL.md

@@ -4,7 +4,7 @@ description: 当模块、接口或依赖仍需决策时，在稳定规格基础
 lifecycle_stage: design
 rule_profile: analysis
 dependencies:
-  - spec
+  - spec-refinement
 triggers:
   - architecture decision
   - module split
@@ -12,7 +12,7 @@ triggers:
   - dependency direction
   - design boundary
 inputs:
-  - executable spec
+  - executable spec-refinement
   - selected rules bundle
   - existing module context
 outputs:
@@ -21,7 +21,7 @@ outputs:
   - interface contract
   - implementation constraints
 workflow:
-  - confirm the spec is stable enough for design work
+  - confirm the spec-refinement is stable enough for design work
   - define boundaries, dependencies, and interfaces
   - map design decisions to the rules bundle
   - hand off to feature-build
@@ -42,7 +42,7 @@ refs:
 
 ## Purpose
 
-Turn a stable spec into concrete architecture and implementation boundaries.
+Turn a stable spec-refinement into concrete architecture and implementation boundaries.
 
 ## Suitable / Unsuitable
 
@@ -51,15 +51,15 @@ Turn a stable spec into concrete architecture and implementation boundaries.
 
 ## Quick Start
 
-- Start from the stable spec and isolate the decisions that affect boundaries or dependencies.
+- Start from the stable spec-refinement and isolate the decisions that affect boundaries or dependencies.
 - Load the smallest rules bundle that matches the current task context.
 - Turn design choices into implementation constraints, not code.
-- If the spec is still unstable, stop and return to `spec`.
+- If the spec-refinement is still unstable, stop and return to `spec-refinement`.
 
 ## Inputs / Outputs
 
 - Inputs:
-  - executable spec
+  - executable spec-refinement
   - selected rules bundle
   - existing module context
 - Outputs:
@@ -70,9 +70,9 @@ Turn a stable spec into concrete architecture and implementation boundaries.
 
 ## Workflow
 
-1. Confirm the spec is stable enough for design work.
+1. Confirm the spec-refinement is stable enough for design work.
 2. Define boundaries, dependencies, and interfaces.
-3. Route scope gaps back to `spec` instead of forcing design decisions.
+3. Route scope gaps back to `spec-refinement` instead of forcing design decisions.
 4. Map design decisions to the rules bundle.
 5. Produce implementation constraints for `feature-build`.
 
@@ -89,7 +89,7 @@ Turn a stable spec into concrete architecture and implementation boundaries.
 - Do not skip rule loading when rule constraints matter.
 - Do not output full code or pseudo-code as the design artifact.
 - Do not collapse boundaries just to reduce context.
-- Do not keep working if the spec is not stable enough to design.
+- Do not keep working if the spec-refinement is not stable enough to design.
 
 ## Stop Rules
 
@@ -103,3 +103,4 @@ Turn a stable spec into concrete architecture and implementation boundaries.
 - `skills/references/rule-loading-map.md`
 - `skills/references/flow-test-cases.md`
 - `rules/index.md`
+

package/skills/test-design/SKILL.md

@@ -14,7 +14,7 @@ triggers:
   - verification
 inputs:
   - implementation notes
-  - executable spec
+  - executable spec-refinement
   - design constraints
   - self-test evidence
 outputs:
@@ -89,3 +89,4 @@ Design and validate test coverage for the implemented change.
 - `skills/references/engineering-delivery-method.md`
 - `skills/references/engineering-delivery-template.md`
 - `rules/index.md`
+