@pigcloud/skills 1.0.5 → 1.0.6

package/scripts/ci-validator.sh

@@ -1,12 +1,12 @@
 #!/bin/bash
-# ci-validator.sh - Skills CI 验证脚本
-# 用于验证技能文件的完整性和规范性
+# ci-validator.sh - Skills CI 楠岃瘉鑴氭湰
+# 鐢ㄤ簬楠岃瘉鎶€鑳芥枃浠剁殑瀹屾暣鎬у拰瑙勮寖鎬?
 
 set -e
 
 echo "=== Skills CI Validator ==="
 
-# 1. 检查技能文件完整性
+# 1. 妫€鏌ユ妧鑳芥枃浠跺畬鏁存€?
 echo "[1/5] Checking skill files..."
 SKILLS_DIR="${SKILLS_DIR:-.trae/skills}"
 ERROR_COUNT=0
@@ -14,7 +14,7 @@ ERROR_COUNT=0
 for skill in $(find "$SKILLS_DIR" -name "SKILL.md" -type f); do
     skill_name=$(basename $(dirname "$skill"))
     
-    # 检查 frontmatter
+    # 妫€鏌?frontmatter
     if ! grep -q "^name:" "$skill"; then
         echo "ERROR: Missing 'name' in $skill"
         ERROR_COUNT=$((ERROR_COUNT + 1))
@@ -30,7 +30,7 @@ for skill in $(find "$SKILLS_DIR" -name "SKILL.md" -type f); do
         echo "WARN: Missing 'version' in $skill"
     fi
     
-    # 检查必要章节
+    # 妫€鏌ュ繀瑕佺珷鑺?
     for section in "When to Run" "Workflow"; do
         if ! grep -q "## $section" "$skill"; then
             echo "ERROR: Missing '$section' section in $skill"
@@ -38,21 +38,21 @@ for skill in $(find "$SKILLS_DIR" -name "SKILL.md" -type f); do
         fi
     done
     
-    # 检查 Lifecycle Position（新增）
+    # 妫€鏌?Lifecycle Position锛堟柊澧烇級
     if ! grep -q "## Lifecycle Position" "$skill"; then
         echo "WARN: Missing 'Lifecycle Position' in $skill (recommended)"
     fi
     
-    echo "✓ $skill_name valid"
+    echo "鉁?$skill_name valid"
 done
 
 if [ "$ERROR_COUNT" -gt 0 ]; then
     echo "ERROR: $ERROR_COUNT errors found in skill files"
     exit 1
 fi
-echo "✓ Skill files valid"
+echo "鉁?Skill files valid"
 
-# 2. 检查生命周期映射完整性
+# 2. 妫€鏌ョ敓鍛藉懆鏈熸槧灏勫畬鏁存€?
 echo "[2/5] Checking lifecycle mapping..."
 LIFECYCLE_STAGES="define plan build verify review ship meta"
 for stage in $LIFECYCLE_STAGES; do
@@ -60,11 +60,11 @@ for stage in $LIFECYCLE_STAGES; do
     if [ "$count" -eq 0 ] && [ "$stage" != "meta" ]; then
         echo "WARN: No skill mapped to '$stage' stage"
     else
-        echo "✓ $stage stage has $count skills"
+        echo "鉁?$stage stage has $count skills"
     fi
 done
 
-# 3. 检查技能间依赖一致性
+# 3. 妫€鏌ユ妧鑳介棿渚濊禆涓€鑷存€?
 echo "[3/5] Checking skill dependencies..."
 for skill in $(find "$SKILLS_DIR" -name "SKILL.md" -type f); do
     deps=$(grep "^dependencies:" "$skill" | sed 's/dependencies: //' | tr ',' ' ' 2>/dev/null || echo "")
@@ -81,34 +81,34 @@ if [ "$ERROR_COUNT" -gt 0 ]; then
     echo "ERROR: Dependency errors found"
     exit 1
 fi
-echo "✓ Dependencies valid"
+echo "鉁?Dependencies valid"
 
-# 4. 检查 Reference Checklists
+# 4. 妫€鏌?Reference Checklists
 echo "[4/5] Checking reference checklists..."
-REQUIRED_CHECKLISTS="coding-checklist.md solid-checklist.md security-checklist.md performance-checklist.md anti-rationalization.md"
+REQUIRED_CHECKLISTS="coding-checklist.md solid-checklist.md security-checklist.md performance-auditlist.md anti-rationalization.md"
 for checklist in $REQUIRED_CHECKLISTS; do
     found=$(find "$SKILLS_DIR" -name "$checklist" -type f | wc -l)
     if [ "$found" -eq 0 ]; then
         echo "WARN: Missing reference checklist '$checklist'"
     else
-        echo "✓ Found $checklist"
+        echo "鉁?Found $checklist"
     fi
 done
 
-# 5. 检查 Agent Personas 和 Slash Commands
+# 5. 妫€鏌?Agent Personas 鍜?Slash Commands
 echo "[5/5] Checking agent personas and slash commands..."
 if [ ! -f "$SKILLS_DIR/../references/agent-personas.md" ]; then
     echo "WARN: Missing agent-personas.md"
 else
-    echo "✓ Found agent-personas.md"
+    echo "鉁?Found agent-personas.md"
 fi
 
 if [ ! -f "$SKILLS_DIR/../references/slash-commands.md" ]; then
     echo "WARN: Missing slash-commands.md"
 else
-    echo "✓ Found slash-commands.md"
+    echo "鉁?Found slash-commands.md"
 fi
 
 echo "=== CI Validator Complete ==="
 echo "All checks passed!"
-exit 0
+exit 0

package/scripts/validate-skill-shapes.js

@@ -6,13 +6,13 @@ const path = require('path');
 const repoRoot = path.join(__dirname, '..');
 const skillsRoot = path.join(repoRoot, 'skills');
 const enhancedTemplateSkills = new Set([
-  'spec',
+  'spec-refinement',
   'technical-design',
   'feature-build',
   'code-review',
-  'security-review',
-  'performance-check',
-  'extract-business-facts',
+  'security-audit',
+  'performance-audit',
+  'business-fact-extraction',
 ]);
 const enhancedSections = [
   '## Quick Start',
@@ -140,3 +140,4 @@ try {
   console.error(error.message);
   process.exitCode = 1;
 }
+

package/skills/{api-docs → api-contract-docs}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: api-docs
-description: 当接口需要可复用参考文档时，记录稳定的 API 行为、请求/响应契约和示例
+name: api-contract-docs
+description: 当接口需要可复用参考文档时，记录稳定的 API 行为、请求、响应契约和示例
 lifecycle_stage: capture
 rule_profile: api
 dependencies:
-  - spec
+  - spec-refinement
 triggers:
   - API docs
   - contract
@@ -36,7 +36,7 @@ refs:
   - rules/index.md
 ---
 
-# API Docs
+# API Contract Docs
 
 ## Purpose
 
@@ -74,3 +74,4 @@ Write clear API documentation and contracts for already defined behavior.
 - `skills/references/prompt-replay-checklist.md`
 - `skills/references/full-chain-replay-scenarios.md`
 - `rules/index.md`
+

package/skills/{extract-business-facts → business-fact-extraction}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: extract-business-facts
-description: Extract business facts, current behaviors, invariants, and terminology from code, tests, logs, and docs when Codex needs to reverse-engineer what the system actually does or prepare evidence-backed input for domain modeling, spec refinement, or knowledge capture.
+name: business-fact-extraction
+description: 当 Codex 需要逆向理解系统真实行为或为领域建模、需求细化或知识沉淀准备证据时，从代码、测试、日志和文档中提取业务事实、当前行为、不变量和术语
 lifecycle_stage: analysis
 rule_profile: modeling
 dependencies: []
@@ -30,7 +30,7 @@ workflow:
   - mark each fact as evidence-backed, inferred, or unknown
   - summarize gaps, contradictions, and open questions
   - choose the destination knowledge-base files before writing the final note
-  - hand off to domain-modeling, spec, or knowledge-capture
+  - hand off to domain-modeling, spec-refinement, or knowledge-capture
 gates:
   - stop at fact extraction
   - do not design a new solution
@@ -43,7 +43,7 @@ refs:
   - docs/codewiki-knowledge-base.md
 ---
 
-# Extract Business Facts
+# Business Fact Extraction
 
 ## Purpose
 
@@ -59,12 +59,12 @@ Turn code-backed evidence into reusable business facts.
 - Start from code paths, tests, docs, runtime traces, and schemas.
 - Produce the output in three stages: code facts, business facts, and CodeWiki updates.
 - Keep evidence, inference, and unknowns distinct.
-- Hand off the result when the facts are stable enough for `domain-modeling`, `spec`, or `knowledge-capture`.
+- Hand off the result when the facts are stable enough for `domain-modeling`, `spec-refinement`, or `knowledge-capture`.
 
 ## Write Back
 
 - When the user wants persistence, render the staged output into a JSON fact pack.
-- Use `skills/extract-business-facts/scripts/write-knowledge-base.js` to write the pack into the knowledge-base files.
+- Use `skills/business-fact-extraction/scripts/write-knowledge-base.js` to write the pack into the knowledge-base files.
 - Keep the pack keyed by target file path under `knowledge-base/`.
 - Write only the smallest matching file for each fact.
 - Treat the script as a writer, not as a second analysis pass.
@@ -251,7 +251,7 @@ Turn code-backed evidence into reusable business facts.
 - 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`
@@ -303,7 +303,7 @@ Turn code-backed evidence into reusable business facts.
 5. Map each section to the exact knowledge-base files it should update.
 6. Mark each fact as evidence-backed, inferred, or unknown.
 7. Summarize gaps, contradictions, and open questions.
-8. Hand off to `domain-modeling`, `spec`, or `knowledge-capture`.
+8. Hand off to `domain-modeling`, `spec-refinement`, or `knowledge-capture`.
 
 ## Replay Signals
 
@@ -334,3 +334,4 @@ Turn code-backed evidence into reusable business facts.
 - `skills/references/skill-reference-matrix.md`
 - `skills/references/rule-loading-map.md`
 - `docs/codewiki-knowledge-base.md`
+

package/skills/{extract-business-facts → business-fact-extraction}/scripts/write-knowledge-base.js

@@ -4,8 +4,8 @@ const fs = require('fs');
 const path = require('path');
 
 const REPO_ROOT = path.join(__dirname, '..', '..', '..');
-const START_MARKER = '<!-- extract-business-facts:start -->';
-const END_MARKER = '<!-- extract-business-facts:end -->';
+const START_MARKER = '<!-- business-fact-extraction:start -->';
+const END_MARKER = '<!-- business-fact-extraction:end -->';
 
 const FILE_FIELD_ORDER = {
   'knowledge-base/realtime-code/modules.md': ['module', 'current responsibility', 'key entry points', 'important constraints', 'last verified'],
@@ -43,7 +43,7 @@ const SAMPLE_PACK = {
         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'
       }
     ],
@@ -225,3 +225,4 @@ try {
   console.error(error.message);
   process.exitCode = 1;
 }
+

package/skills/code-review/SKILL.md

@@ -26,8 +26,8 @@ workflow:
   - lock the review scope
   - identify the tech stack and load the matching review overlay(s)
   - inspect correctness, maintainability, and regression risk
-  - route security-specific issues to `security-review`
-  - route performance-specific issues to `performance-check`
+  - route security-specific issues to `security-audit`
+  - route performance-specific issues to `performance-audit`
   - rank findings by severity
   - produce an actionable review report
 gates:
@@ -63,8 +63,8 @@ Review a change set and return actionable findings.
 - Identify the stack(s) first. This repository may apply Java, Vue, or mixed-stack review overlays.
 - Read the diff with the current rules bundle in mind.
 - Report findings with severity and a concrete fix path.
-- If the issue is clearly about auth, secrets, or exposure, hand off to `security-review`.
-- If the issue is clearly about latency, throughput, or resource usage, hand off to `performance-check`.
+- If the issue is clearly about auth, secrets, or exposure, hand off to `security-audit`.
+- If the issue is clearly about latency, throughput, or resource usage, hand off to `performance-audit`.
 - Keep stack-specific concerns in the matching overlay and keep the core review generic.
 
 ## Report Format
@@ -96,8 +96,8 @@ Review a change set and return actionable findings.
 1. Lock the review scope.
 2. Identify the stack overlays and load the matching review baseline(s) when applicable.
 3. Inspect correctness, maintainability, and regression risk.
-4. Route security-specific issues to `security-review`.
-5. Route performance-specific issues to `performance-check`.
+4. Route security-specific issues to `security-audit`.
+5. Route performance-specific issues to `performance-audit`.
 6. Rank findings by severity.
 7. Produce an actionable review report.
 
@@ -133,3 +133,4 @@ Review a change set and return actionable findings.
 - `rules/review/code.md`
 - `rules/review/java.md`
 - `rules/review/vue.md`
+

package/skills/domain-modeling/SKILL.md

@@ -23,7 +23,7 @@ workflow:
   - extract the core domain terms
   - group concepts by boundary
   - identify aggregates and dependencies
-  - hand off to technical-design or spec
+  - hand off to technical-design or spec-refinement
 gates:
   - stop at domain boundaries
   - do not implement code
@@ -51,14 +51,14 @@ Extract domain boundaries and core concepts from messy input.
 1. Extract the core domain terms.
 2. Group concepts by boundary.
 3. Identify aggregates and dependencies.
-4. Hand off to `technical-design` or `spec`.
+4. Hand off to `technical-design` or `spec-refinement`.
 
 ## Replay Signals
 
 - Input signal: existing business language, product context, code, or documents.
 - Output to verify: domain map, core concepts, boundary notes.
 - Stop signal: implementation code or PRD drafting.
-- Handoff signal: the boundary map is ready for `technical-design` or `spec`.
+- Handoff signal: the boundary map is ready for `technical-design` or `spec-refinement`.
 
 ## Examples
 
@@ -78,3 +78,4 @@ Extract domain boundaries and core concepts from messy input.
 - `skills/references/rule-loading-map.md`
 - `skills/references/prompt-replay-checklist.md`
 - `skills/references/full-chain-replay-scenarios.md`
+

package/skills/feature-build/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: feature-build
-description: 在代码、重构或集成工作需要保持在既定边界内时，实现已批准的设计变更
-lifecycle_stage: build
+description: 在代码、重构或集成工作需要保持在既定边界内时，实现已批准的设计变更
 rule_profile: implementation
 dependencies:
   - technical-design
@@ -14,7 +13,7 @@ triggers:
   - service
   - mapper
 inputs:
-  - executable spec
+  - executable spec-refinement
   - design decisions
   - confirmed task breakdown plan
   - rules bundle
@@ -33,7 +32,7 @@ workflow:
   - hand off to test-design
 gates:
   - stop at implementation
-  - do not rewrite the spec
+  - do not rewrite the spec-refinement
   - do not change the agreed boundaries
   - do not bypass the rules bundle
 refs:
@@ -59,7 +58,7 @@ Implement the approved design without changing the agreed scope.
 
 - Load the selected rules bundle first.
 - Implement only the confirmed scope from the approved design.
-- Split work into small tasks before implementation if the spec is still too coarse.
+- Split work into small tasks before implementation if the spec-refinement is still too coarse.
 - Treat the task as the smallest implementation unit.
 - Validate each task locally before starting the next one.
 - Record evidence immediately after each task is complete.
@@ -68,7 +67,7 @@ Implement the approved design without changing the agreed scope.
 ## Inputs / Outputs
 
 - Inputs:
-  - executable spec
+  - executable spec-refinement
   - design decisions
   - confirmed task breakdown plan
   - rules bundle
@@ -90,14 +89,14 @@ Implement the approved design without changing the agreed scope.
 
 ## Replay Signals
 
-- Input signal: confirmed spec, approved design, confirmed task breakdown plan, and selected rules bundle.
+- Input signal: confirmed spec-refinement, approved design, confirmed task breakdown plan, and selected rules bundle.
 - Output to verify: code changes, implementation notes, validation evidence, self-test evidence, task-level evidence.
-- Stop signal: spec rewrites, scope expansion, or bypassing the rules bundle.
+- Stop signal: spec-refinement rewrites, scope expansion, or bypassing the rules bundle.
 - Handoff signal: implementation is ready for `test-design`.
 
 ## Gotchas
 
-- Do not rewrite the spec while implementing.
+- Do not rewrite the spec-refinement while implementing.
 - Do not expand the boundary because implementation is inconvenient.
 - Do not bypass the rules bundle for convenience.
 - Do not leave validation evidence implicit.
@@ -108,7 +107,7 @@ Implement the approved design without changing the agreed scope.
 ## Stop Rules
 
 - Stop at implementation.
-- Do not rewrite the spec.
+- Do not rewrite the spec-refinement.
 - Do not change the agreed boundaries.
 - Do not skip the rules bundle.
 - Do not bypass the rules bundle.
@@ -120,3 +119,4 @@ Implement the approved design without changing the agreed scope.
 - `skills/references/engineering-delivery-method.md`
 - `skills/references/engineering-delivery-template.md`
 - `rules/index.md`
+

package/skills/feature-build/references/comment-specification.md

@@ -1,4 +1,4 @@
-# 娉ㄩ噴瑙勮寖
+# 娉ㄩ噴瑙勮寖
 
 > 浠ｇ爜娉ㄩ噴鏍囧噯锛岀敤浜庝繚鎸佸彲璇绘€у拰鍙淮鎶ゆ€с€傝繖閲屽彧淇濈暀娉ㄩ噴瀵嗗害銆佹ā鏉垮拰妫€鏌ラ」锛涘叿浣撲笟鍔?鍒嗗眰鍩虹嚎浼樺厛寮曠敤 [rules/overlays/pig-cloud.md](/D:/work/java/pig-skills/rules/overlays/pig-cloud.md) 鍙婂叾瀛愯鍒欍€?
 ## Class Comment

package/skills/knowledge-capture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: knowledge-capture
-description: Capture reusable decisions, requirement knowledge, realtime code facts, CodeWiki facts, and handoff notes; use when an upstream task already produced evidence and you need to normalize it, persist it, or hand it off without redoing analysis.
+description: 当上游任务已经产出证据，需要整理、沉淀或交接而不想重做分析时，提炼可复用的决策、需求知识、实时代码事实、CodeWiki 事实和交接笔记
 lifecycle_stage: capture
 rule_profile: capture
 dependencies: []

package/skills/{performance-check → performance-audit}/SKILL.md

@@ -1,7 +1,6 @@
 ---
-name: performance-check
-description: 当需要性能结论时，对变更中的延迟、吞吐量或资源瓶颈进行审查
-lifecycle_stage: review
+name: performance-audit
+description: 当需要性能结论时，对变更中的延迟、吞吐量或资源瓶颈进行审查
 rule_profile: performance
 dependencies:
   - feature-build
@@ -40,7 +39,7 @@ refs:
   - rules/index.md
 ---
 
-# Performance Check
+# Performance Audit
 
 ## Purpose
 
@@ -115,3 +114,5 @@ Find performance bottlenecks and optimization opportunities.
 - `skills/references/prompt-replay-checklist.md`
 - `skills/references/full-chain-replay-scenarios.md`
 - `rules/index.md`
+
+# Performance Audit

package/skills/project-bootstrap/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: project-bootstrap
-description: 当项目需要初始化时，为新工作区装载合适的技能和规则包
+description: 当项目需要初始化时，为新工作区装载合适的技能和规则包
 lifecycle_stage: scaffold
 rule_profile: scaffold
 dependencies: []
@@ -58,7 +58,7 @@ Create a new workspace with the right skills and rules layout.
 - Input signal: client type, workspace markers, desired rules bundle.
 - Output to verify: starter structure, installed bundle, setup notes.
 - Stop signal: product scope design or application code generation.
-- Handoff signal: the workspace is ready for `workflow-router` or `spec`.
+- Handoff signal: the workspace is ready for `workflow-router` or `spec-refinement`.
 
 ## Examples
 
@@ -78,3 +78,4 @@ Create a new workspace with the right skills and rules layout.
 - `skills/references/prompt-replay-checklist.md`
 - `skills/references/full-chain-replay-scenarios.md`
 - `rules/index.md`
+

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