@pigcloud/skills 1.0.11 → 1.1.2

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

@@ -1,415 +0,0 @@
-# Business Fact Extraction
-
-## Goal
-
-Turn code-backed evidence into a three-stage artifact:
-
-1. code facts
-2. business facts
-3. CodeWiki updates
-
-## Evidence Order
-
-Use the strongest source available first:
-
-1. runtime behavior
-2. automated tests
-3. code paths
-4. schema and contracts
-5. docs and runbooks
-6. comments and naming
-
-## Fact Types
-
-- evidence-backed fact: directly supported by code or tests
-- inferred business fact: a reasonable business meaning derived from evidence
-- unknown: the code does not prove it yet
-- contradiction: two sources disagree
-
-## Output Shape
-
-### 1. Code Facts
-
-#### `knowledge-base/realtime-code/modules.md`
-
-- module:
-- current responsibility:
-- key entry points:
-- important constraints:
-- last verified:
-
-#### `knowledge-base/realtime-code/flows.md`
-
-- flow name:
-- trigger:
-- path:
-- output:
-- failure points:
-- notes:
-
-#### `knowledge-base/realtime-code/runtime-notes.md`
-
-- fact:
-- evidence:
-- affected area:
-- date:
-- notes:
-
-### 2. Business Facts
-
-#### `knowledge-base/requirements/decisions.md`
-
-- decision:
-- reason:
-- date or context:
-- affected artifact:
-- notes:
-
-#### `knowledge-base/requirements/acceptance.md`
-
-- requirement:
-- acceptance criteria:
-- out of scope:
-- open questions:
-- confirmed by:
-
-#### `knowledge-base/requirements/conflicts.md`
-
-- conflict:
-- source:
-- impact:
-- resolution:
-- status:
-
-### 3. CodeWiki Update
-
-#### `knowledge-base/codewiki/overview.md`
-
-- one-line summary:
-- what the system does:
-- what changed:
-- why it matters:
-
-#### `knowledge-base/codewiki/architecture.md`
-
-- layers:
-- boundaries:
-- dependencies:
-- major integration points:
-
-#### `knowledge-base/codewiki/modules.md`
-
-- module name:
-- responsibility:
-- main interfaces:
-- related runtime facts:
-
-#### `knowledge-base/codewiki/flows.md`
-
-- request flow:
-- data flow:
-- error flow:
-- handoff flow:
-
-#### `knowledge-base/codewiki/api.md`
-
-- endpoint or contract:
-- request shape:
-- response shape:
-- constraints:
-
-#### `knowledge-base/codewiki/runbook.md`
-
-- startup:
-- verify:
-- troubleshoot:
-- recover:
-
-#### `knowledge-base/codewiki/conventions.md`
-
-- naming:
-- layering:
-- error handling:
-- logging:
-- data handling:
-
-### 4. Enterprise Note
-
-#### `knowledge-base/enterprise/decisions.md`
-
-- decision:
-- reason:
-- scope:
-- date:
-- reusable lesson:
-
-#### `knowledge-base/enterprise/pitfalls.md`
-
-- pitfall:
-- context:
-- why it failed:
-- how to avoid it:
-
-#### `knowledge-base/enterprise/examples.md`
-
-- example:
-- context:
-- lesson:
-- reusable pattern:
-
-#### `knowledge-base/enterprise/ai-coding-rules.md`
-
-- rule:
-- when it applies:
-- why it matters:
-- examples:
-
-## Writing Rules
-
-- Keep one fact per line.
-- Point each fact back to evidence.
-- Separate observed behavior from interpretation.
-- Mark uncertainty explicitly.
-- Do not mix solution ideas into the fact list.
-- Write the three stages in order and keep them visually separate.
-- Update the smallest matching file in each target layer.
-- Keep file targets and file content in the same order.
-
-## Auto-Write Pack
-
-Use `skills/business-fact-extraction/scripts/write-knowledge-base.js` when the staged readout should be written into the knowledge base.
-
-### Input Shape
-
-```json
-{
-  "files": {
-    "knowledge-base/realtime-code/modules.md": [
-      {
-        "module": "order-service",
-        "current responsibility": "creates orders and reserves inventory",
-        "key entry points": "createOrder(), reserveInventory()",
-        "important constraints": "stock must be checked before commit",
-        "last verified": "2026-06-22"
-      }
-    ]
-  }
-}
-```
-
-### Command
-
-```bash
-node skills/business-fact-extraction/scripts/write-knowledge-base.js --input fact-pack.json
-```
-
-### Behavior
-
-- Writes only under `knowledge-base/`
-- Keeps the file-specific field order
-- Replaces the generated block between markers when it already exists
-- Preserves the surrounding manual notes
-- Supports `--dry-run` for preview and `--sample` for a sample pack
-
-## Handoff Targets
-
-- `domain-modeling` when the facts need boundary or concept normalization
-- `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
-
-- code facts: module behavior, entry points, constraints, runtime evidence
-- business facts: decisions, acceptance criteria, conflicts, open questions
-- CodeWiki update: flow, architecture, module, API, runbook, convention deltas
-- enterprise note: pitfalls, examples, reusable rules
-
-## Full Example
-
-### Code Facts
-
-#### `knowledge-base/realtime-code/modules.md`
-
-- module: `order-service`
-- current responsibility: creates orders and reserves inventory
-- key entry points: `createOrder()`, `reserveInventory()`
-- important constraints: stock must be checked before commit
-- last verified: 2026-06-22
-
-#### `knowledge-base/realtime-code/flows.md`
-
-- flow name: checkout order placement
-- trigger: user confirms checkout
-- path: validate stock -> reserve inventory -> create order
-- output: confirmed order or shortage error
-- failure points: stock shortage, reservation failure
-- notes: reservation must happen before the order commit
-
-### Business Facts
-
-#### `knowledge-base/requirements/decisions.md`
-
-- decision: inventory must be reserved before order confirmation
-- reason: avoid overselling
-- date or context: 2026-06-22, order flow review
-- affected artifact: checkout spec-refinement
-- notes: failure should return a clear stock shortage message
-
-#### `knowledge-base/requirements/acceptance.md`
-
-- requirement: checkout must not confirm an order when stock is unavailable
-- acceptance criteria: shortage blocks confirmation and returns a clear message
-- out of scope: backorder design
-- open questions: whether to retry reservation automatically
-- confirmed by: order flow review
-
-### CodeWiki Update
-
-#### `knowledge-base/codewiki/flows.md`
-
-- request flow: checkout -> validate stock -> reserve inventory -> create order
-- data flow: cart snapshot -> reservation record -> order record
-- error flow: stock shortage -> stop checkout -> return shortage reason
-- handoff flow: checkout service hands off to inventory service and order repository
-
-#### `knowledge-base/codewiki/modules.md`
-
-- module name: `order-service`
-- responsibility: coordinates checkout and order creation
-- main interfaces: `createOrder()`, `reserveInventory()`
-- related runtime facts: inventory must be reserved before commit
-
-### Enterprise Note
-
-#### `knowledge-base/enterprise/pitfalls.md`
-
-- pitfall: reservation happens after order creation
-- context: checkout path
-- why it failed: allowed overselling under concurrent requests
-- how to avoid it: reserve before committing the order
-
-## End-to-End Example
-
-### 1. Source Input
-
-- 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
-
-### 2. Extracted Output
-
-- code facts:
-  - `knowledge-base/realtime-code/modules.md`: `order-service` coordinates checkout and inventory reservation
-  - `knowledge-base/realtime-code/flows.md`: checkout -> validate stock -> reserve inventory -> create order
-- business facts:
-  - `knowledge-base/requirements/decisions.md`: reserve inventory before order confirmation
-  - `knowledge-base/requirements/acceptance.md`: shortage blocks confirmation and returns a clear message
-- CodeWiki update:
-  - `knowledge-base/codewiki/flows.md`: document request / data / error / handoff flow
-  - `knowledge-base/codewiki/modules.md`: document `order-service` responsibilities and interfaces
-- enterprise note:
-  - `knowledge-base/enterprise/pitfalls.md`: reservation after order creation causes overselling
-  - `knowledge-base/enterprise/ai-coding-rules.md`: reserve before commit under concurrency
-
-### 3. Fact Pack
-
-```json
-{
-  "files": {
-    "knowledge-base/realtime-code/modules.md": [
-      {
-        "module": "order-service",
-        "current responsibility": "coordinates checkout and inventory reservation",
-        "key entry points": "createOrder(), reserveInventory()",
-        "important constraints": "stock must be checked before commit",
-        "last verified": "2026-06-22"
-      }
-    ],
-    "knowledge-base/requirements/decisions.md": [
-      {
-        "decision": "inventory must be reserved before order confirmation",
-        "reason": "avoid overselling",
-        "date or context": "2026-06-22, checkout review",
-        "affected artifact": "checkout spec-refinement",
-        "notes": "shortage returns a clear error"
-      }
-    ],
-    "knowledge-base/codewiki/flows.md": [
-      {
-        "request flow": "checkout -> validate stock -> reserve inventory -> create order",
-        "data flow": "cart snapshot -> reservation record -> order record",
-        "error flow": "stock shortage -> stop checkout -> return shortage reason",
-        "handoff flow": "checkout service hands off to inventory service and order repository"
-      }
-    ],
-    "knowledge-base/enterprise/pitfalls.md": [
-      {
-        "pitfall": "reservation happens after order creation",
-        "context": "checkout path",
-        "why it failed": "allowed overselling under concurrent requests",
-        "how to avoid it": "reserve before committing the order"
-      }
-    ]
-  }
-}
-```
-
-### 4. Persist
-
-```bash
-node skills/business-fact-extraction/scripts/write-knowledge-base.js --input fact-pack.json
-```
-
-### 5. `knowledge-capture`
-
-- Normalize the extracted note.
-- Link it back to the originating skill.
-- Persist the fact pack only when the note is ready.
-
-#### `knowledge-base/enterprise/ai-coding-rules.md`
-
-- rule: reserve inventory before committing the order
-- when it applies: any checkout flow that can oversell
-- why it matters: keeps business state consistent under concurrency
-- examples: validate stock, reserve, then create the order
-
-## Sample Output
-
-### Code Facts
-
-#### `knowledge-base/realtime-code/modules.md`
-
-- module: `order-service`
-- current responsibility: creates orders and reserves inventory
-- key entry points: `createOrder()`, `reserveInventory()`
-- important constraints: stock must be checked before commit
-- last verified: 2026-06-22
-
-### Business Facts
-
-#### `knowledge-base/requirements/decisions.md`
-
-- decision: inventory must be reserved before order confirmation
-- reason: avoid overselling
-- date or context: 2026-06-22, order flow review
-- affected artifact: checkout spec-refinement
-- notes: failure should return a clear stock shortage message
-
-### CodeWiki Update
-
-#### `knowledge-base/codewiki/flows.md`
-
-- request flow: checkout -> validate stock -> reserve inventory -> create order
-- data flow: cart snapshot -> reservation record -> order record
-- error flow: stock shortage -> stop checkout -> return shortage reason
-- handoff flow: checkout service hands off to inventory service and order repository
-
-### Enterprise Note
-
-#### `knowledge-base/enterprise/pitfalls.md`
-
-- pitfall: reservation happens after order creation
-- 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

@@ -1,64 +0,0 @@
-# Engineering Delivery Method
-
-## Goal
-
-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-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.
-6. Enter `feature-build` and split the work into small tasks.
-7. Implement one task at a time.
-8. Run local self-tests after each task.
-9. Record validation evidence.
-10. Hand off the verified result to `test-design`, then `code-review`.
-
-## Task Split Rules
-
-- Prefer acceptance-item first, then module-boundary refinement.
-- Each task should be small enough to finish and verify independently.
-- Each task should have a clear owner surface, dependency list, and done criteria.
-- Split mixed-stack work by the smallest verifiable implementation unit.
-- Treat task splitting as a working artifact, not as a separate lifecycle stage.
-
-## Task Card Shape
-
-- task goal
-- impacted surface
-- implementation boundary
-- dependencies
-- completion criteria
-- self-test steps
-- evidence to record
-
-## Self-Test Rules
-
-- Verify the smallest relevant unit first.
-- Record the evidence immediately after the task is finished.
-- If a task fails locally, fix it before moving to the next task.
-- Do not wait until the end to discover basic correctness issues.
-
-## Handoff Rules
-
-- `feature-build` hands off code changes plus validation evidence.
-- `test-design` receives implementation notes, self-test results, and coverage gaps.
-- `code-review` receives the validated diff and evidence summary.
-
-## Spec Stage Direction
-
-- Before execution, produce an execution direction plan.
-- Keep the direction explicit enough for a user to confirm.
-- Do not enter `feature-build` until the direction is accepted.
-
-## References
-
-- `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

@@ -1,81 +0,0 @@
-# Engineering Delivery Template
-
-## How to Use
-
-- 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.
-
-## 1. Current State Alignment
-
-- Product intent:
-- Current project facts:
-- Existing constraints:
-- Conflicts or gaps:
-- Alignment notes:
-
-## 2. Execution Direction Plan
-
-- Preferred execution path:
-- What should be done first:
-- What should be done next:
-- What must wait for confirmation:
-- Why this direction fits the current facts:
-
-## 3. Task Breakdown
-
-| Task | Goal | Impacted surface | Boundary | Dependencies | Done criteria |
-|---|---|---|---|---|---|
-| T1 |  |  |  |  |  |
-| T2 |  |  |  |  |  |
-| T3 |  |  |  |  |  |
-
-Rules:
-
-- Prefer acceptance-item first, then module-boundary refinement.
-- Split mixed-stack work by the smallest verifiable implementation unit.
-- Keep each task finishable in one implementation pass.
-
-## 4. Task-by-Task Implementation
-
-For each task, record:
-
-- Task ID:
-- What changed:
-- Files or surfaces:
-- Rule bundle used:
-- Notes:
-
-## 5. Task-Level Self-Test
-
-For each task, record:
-
-- Task ID:
-- Self-test steps:
-- Expected result:
-- Actual result:
-- Evidence:
-
-Rules:
-
-- Run self-test immediately after the task is done.
-- Fix failures before starting the next task.
-- Record evidence as soon as the task passes.
-
-## 6. Validation and Handoff
-
-- Overall validation result:
-- Coverage gaps:
-- Remaining risks:
-- Handoff target: `test-design`
-- Review target: `code-review`
-
-## Minimum Acceptance
-
-- 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.
-