@pigcloud/skills 1.0.11 → 1.1.2

package/skills/01-discovery/business-analysis/references/prompt-template.md

@@ -0,0 +1,18 @@
+# business-analysis
+
+## Prompt Template
+
+```text
+You are handling the business-analysis skill.
+Goal: Normalize business terms, ownership, and rules into a reusable glossary
+Inputs: the request, supporting evidence, constraints, and existing repository facts.
+Output contract: glossary, business rules, ownership boundaries.
+Stop rule: Do not decide design or implementation details.
+Handoff: ambiguity-detection.
+Keep the response scoped to this stage and do not absorb the work of the next stage.
+```
+
+## Notes
+
+- Keep the template aligned with the local replay case and local assets.
+- Read `cases.md` for the matching replay example.

package/skills/01-discovery/business-analysis/skill-spec.json

@@ -0,0 +1,26 @@
+{
+  "group": "01-discovery",
+  "name": "business-analysis",
+  "description": "Normalize business terms, ownership, and rules into a reusable glossary.",
+  "title": "Business Analysis",
+  "purpose": "Normalize business language into stable terms, ownership boundaries, and decision rules.",
+  "whenToUse": [
+    "The business logic is unclear.",
+    "You need to define terms, rules, workflows, or ownership boundaries.",
+    "Different stakeholders are using different words for the same thing."
+  ],
+  "how": [
+    "Extract canonical terms, then define each term in one sentence.",
+    "Map each term to owner, scope, rule, exception, and evidence.",
+    "Separate user intent, business behavior, and implementation detail.",
+    "Capture success conditions, exclusions, and exceptions, not just the happy path.",
+    "Stop once later stages can reuse the glossary and business rules without re-interpretation."
+  ],
+  "whenToAvoid": [
+    "The glossary and business rules are already stable.",
+    "The request is already technical and needs impact or design work.",
+    "You only need wording cleanup or formatting."
+  ],
+  "caseId": "analysis-business-terms",
+  "source": "bootstrap-from-skill-md"
+}

package/skills/01-discovery/impact-analysis/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: impact-analysis
+description: Evaluate code, data, API, and delivery impact before changing an existing system.
+---
+
+# Impact Analysis
+
+## Purpose
+
+Map the blast radius of an existing-system change before design or implementation starts.
+
+## When to Use
+
+- The change touches existing behavior.
+- You need to know what code, data, interface, test, or release surface could break.
+- The change touches shared modules or reused behavior.
+
+## How
+
+- Trace affected modules, dependencies, contracts, data, tests, and release risks.
+- Separate direct impact from adjacent or downstream impact.
+- Call out compatibility, migration, rollback, and verification surfaces early.
+- Name the smallest set of files, flows, or contracts that deserve focused validation.
+- Stop with an impact map and a go/no-go recommendation for the next stage; do not write implementation.
+
+## When to Avoid
+
+- The change does not touch an existing system surface.
+- The request is already ready for design and impact is known.
+- You only need wording cleanup or formatting.

package/skills/01-discovery/impact-analysis/assets/golden-prompt-suite.current.js

@@ -0,0 +1,22 @@
+#!/usr/bin/env node
+
+module.exports = {
+  "name": "impact-analysis.golden-prompt-suite.current",
+  "skill": "impact-analysis",
+  "description": "Evaluate code, data, API, and delivery impact before changing an existing system.",
+  "cases": [
+    {
+      "id": "impact-existing-system",
+      "prompt": "This change may affect an existing system. Map the impact surface.",
+      "expectedFirstSkill": "impact-analysis",
+      "expectedOutput": [
+        "impact map",
+        "validation surfaces",
+        "release risks"
+      ],
+      "expectedStop": "Do not write implementation.",
+      "expectedHandoff": "architecture-design"
+    }
+  ]
+};
+

package/skills/01-discovery/impact-analysis/references/README.md

@@ -0,0 +1,17 @@
+# impact-analysis References
+
+This directory is local to the skill and is the only reference entry point for this skill.
+
+## Contents
+
+- `../skill-spec.json`: design source for regenerating this skill
+- `prompt-template.md`: reusable prompt wording for this skill
+- `cases.md`: human-readable replay case for this skill
+- `../assets/golden-prompt-suite.current.js`: machine-readable local case fixture
+
+## Guidance
+
+- Keep skill-specific explanation here instead of pushing it into a stage-level shared library.
+- Keep shared hard constraints in `../../../rules/index.md`.
+- Keep canonical names unchanged.
+- Skill summary: Evaluate code, data, API, and delivery impact before changing an existing system.

package/skills/01-discovery/impact-analysis/references/cases.md

@@ -0,0 +1,26 @@
+# impact-analysis
+
+## Replay Case
+
+- Case: `impact-existing-system`
+- First skill: `impact-analysis`
+
+### Prompt
+
+```text
+This change may affect an existing system. Map the impact surface.
+```
+
+### Expected Output
+
+- impact map
+- validation surfaces
+- release risks
+
+### Stop Rule
+
+- Do not write implementation.
+
+### Handoff
+
+- architecture-design

package/skills/01-discovery/impact-analysis/references/prompt-template.md

@@ -0,0 +1,18 @@
+# impact-analysis
+
+## Prompt Template
+
+```text
+You are handling the impact-analysis skill.
+Goal: Evaluate code, data, API, and delivery impact before changing an existing system
+Inputs: the request, supporting evidence, constraints, and existing repository facts.
+Output contract: impact map, validation surfaces, release risks.
+Stop rule: Do not write implementation.
+Handoff: architecture-design.
+Keep the response scoped to this stage and do not absorb the work of the next stage.
+```
+
+## Notes
+
+- Keep the template aligned with the local replay case and local assets.
+- Read `cases.md` for the matching replay example.

package/skills/01-discovery/impact-analysis/skill-spec.json

@@ -0,0 +1,26 @@
+{
+  "group": "01-discovery",
+  "name": "impact-analysis",
+  "description": "Evaluate code, data, API, and delivery impact before changing an existing system.",
+  "title": "Impact Analysis",
+  "purpose": "Map the blast radius of an existing-system change before design or implementation starts.",
+  "whenToUse": [
+    "The change touches existing behavior.",
+    "You need to know what code, data, interface, test, or release surface could break.",
+    "The change touches shared modules or reused behavior."
+  ],
+  "how": [
+    "Trace affected modules, dependencies, contracts, data, tests, and release risks.",
+    "Separate direct impact from adjacent or downstream impact.",
+    "Call out compatibility, migration, rollback, and verification surfaces early.",
+    "Name the smallest set of files, flows, or contracts that deserve focused validation.",
+    "Stop with an impact map and a go/no-go recommendation for the next stage; do not write implementation."
+  ],
+  "whenToAvoid": [
+    "The change does not touch an existing system surface.",
+    "The request is already ready for design and impact is known.",
+    "You only need wording cleanup or formatting."
+  ],
+  "caseId": "impact-existing-system",
+  "source": "bootstrap-from-skill-md"
+}

package/skills/01-discovery/requirement-discovery/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: requirement-discovery
+description: Turn a vague request into a bounded problem packet before design starts.
+---
+
+# Requirement Discovery
+
+## Purpose
+
+Turn a vague request into a bounded problem packet with a clear next-stage routing decision.
+
+## When to Use
+
+- The request is incomplete, contradictory, or too broad to start building.
+- You need facts before choosing a design, implementation, or validation path.
+- Stakeholders, constraints, or acceptance criteria are still missing.
+
+## How
+
+- Restate the request as a problem statement, not a solution idea.
+- Capture the minimum packet: problem statement, success target, confirmed facts, unknowns, constraints, and routing recommendation.
+- Ask only the questions that remove a design blocker or make the next stage obvious.
+- Separate what the user asked for, what the repository already proves, and what still needs confirmation.
+- Stop as soon as the request is routeable to business-analysis, ambiguity-detection, or design.
+
+## When to Avoid
+
+- The request is already routeable to design without more discovery.
+- The only missing work is a business glossary, ambiguity scan, or impact map.
+- You only need wording cleanup or formatting.

package/skills/01-discovery/requirement-discovery/assets/golden-prompt-suite.current.js

@@ -0,0 +1,24 @@
+#!/usr/bin/env node
+
+module.exports = {
+  "name": "requirement-discovery.golden-prompt-suite.current",
+  "skill": "requirement-discovery",
+  "description": "Turn a vague request into a bounded problem packet before design starts.",
+  "cases": [
+    {
+      "id": "discovery-clarify-scope",
+      "prompt": "This request is still vague. Clarify the goal, success target, and missing facts first.",
+      "expectedFirstSkill": "requirement-discovery",
+      "expectedOutput": [
+        "problem statement",
+        "success target",
+        "unknowns",
+        "constraints",
+        "routing recommendation"
+      ],
+      "expectedStop": "Do not jump into design or code; stop once the request is routeable.",
+      "expectedHandoff": "business-analysis or ambiguity-detection"
+    }
+  ]
+};
+

package/skills/01-discovery/requirement-discovery/references/README.md

@@ -0,0 +1,17 @@
+# requirement-discovery References
+
+This directory is local to the skill and is the only reference entry point for this skill.
+
+## Contents
+
+- `../skill-spec.json`: design source for regenerating this skill
+- `prompt-template.md`: reusable prompt wording for this skill
+- `cases.md`: human-readable replay case for this skill
+- `../assets/golden-prompt-suite.current.js`: machine-readable local case fixture
+
+## Guidance
+
+- Keep skill-specific explanation here instead of pushing it into a stage-level shared library.
+- Keep shared hard constraints in `../../../rules/index.md`.
+- Keep canonical names unchanged.
+- Skill summary: Turn a vague request into a bounded problem packet before design starts.

package/skills/01-discovery/requirement-discovery/references/cases.md

@@ -0,0 +1,28 @@
+# requirement-discovery
+
+## Replay Case
+
+- Case: `discovery-clarify-scope`
+- First skill: `requirement-discovery`
+
+### Prompt
+
+```text
+This request is still vague. Clarify the goal, success target, and missing facts first.
+```
+
+### Expected Output
+
+- problem statement
+- success target
+- unknowns
+- constraints
+- routing recommendation
+
+### Stop Rule
+
+- Do not jump into design or code; stop once the request is routeable.
+
+### Handoff
+
+- business-analysis or ambiguity-detection

package/skills/01-discovery/requirement-discovery/references/prompt-template.md

@@ -0,0 +1,18 @@
+# requirement-discovery
+
+## Prompt Template
+
+```text
+You are handling the requirement-discovery skill.
+Goal: Turn a vague request into a bounded problem packet before design starts
+Inputs: the request, supporting evidence, constraints, and existing repository facts.
+Output contract: problem statement, success target, unknowns, constraints, routing recommendation.
+Stop rule: Do not jump into design or code; stop once the request is routeable.
+Handoff: business-analysis or ambiguity-detection.
+Keep the response scoped to this stage and do not absorb the work of the next stage.
+```
+
+## Notes
+
+- Keep the template aligned with the local replay case and local assets.
+- Read `cases.md` for the matching replay example.

package/skills/01-discovery/requirement-discovery/skill-spec.json

@@ -0,0 +1,26 @@
+{
+  "group": "01-discovery",
+  "name": "requirement-discovery",
+  "description": "Turn a vague request into a bounded problem packet before design starts.",
+  "title": "Requirement Discovery",
+  "purpose": "Turn a vague request into a bounded problem packet with a clear next-stage routing decision.",
+  "whenToUse": [
+    "The request is incomplete, contradictory, or too broad to start building.",
+    "You need facts before choosing a design, implementation, or validation path.",
+    "Stakeholders, constraints, or acceptance criteria are still missing."
+  ],
+  "how": [
+    "Restate the request as a problem statement, not a solution idea.",
+    "Capture the minimum packet: problem statement, success target, confirmed facts, unknowns, constraints, and routing recommendation.",
+    "Ask only the questions that remove a design blocker or make the next stage obvious.",
+    "Separate what the user asked for, what the repository already proves, and what still needs confirmation.",
+    "Stop as soon as the request is routeable to business-analysis, ambiguity-detection, or design."
+  ],
+  "whenToAvoid": [
+    "The request is already routeable to design without more discovery.",
+    "The only missing work is a business glossary, ambiguity scan, or impact map.",
+    "You only need wording cleanup or formatting."
+  ],
+  "caseId": "discovery-clarify-scope",
+  "source": "bootstrap-from-skill-md"
+}

package/skills/02-design/api-design/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: api-design
+description: Design request and response contracts, error shapes, and compatibility boundaries.
+---
+
+# API Design
+
+## Purpose
+
+Define stable API contracts that are clear to both implementers and consumers.
+
+## When to Use
+
+- You are introducing or changing an interface.
+- You need to agree on payloads, errors, versioning, or compatibility behavior.
+- Consumers and implementers need the same contract vocabulary.
+
+## How
+
+- Specify request and response shapes, compatibility rules, and edge-case behavior.
+- Include examples for success, validation failure, and empty or partial data.
+- Call out authentication, idempotency, pagination, and versioning when they matter.
+- Name the migration path if the contract changes existing consumers.
+
+## When to Avoid
+
+- The change is already small and local.
+- The system shape is already settled.
+- You only need request-level clarification or implementation detail.

package/skills/02-design/api-design/assets/golden-prompt-suite.current.js

@@ -0,0 +1,22 @@
+#!/usr/bin/env node
+
+module.exports = {
+  "name": "api-design.golden-prompt-suite.current",
+  "skill": "api-design",
+  "description": "Design request and response contracts, error shapes, and compatibility boundaries.",
+  "cases": [
+    {
+      "id": "api-contract-new-endpoint",
+      "prompt": "Define a new API endpoint. Design the request, response, and compatibility rules.",
+      "expectedFirstSkill": "api-design",
+      "expectedOutput": [
+        "request shape",
+        "response shape",
+        "constraints"
+      ],
+      "expectedStop": "Do not change implementation.",
+      "expectedHandoff": "database-design"
+    }
+  ]
+};
+

package/skills/02-design/api-design/references/README.md

@@ -0,0 +1,17 @@
+# api-design References
+
+This directory is local to the skill and is the only reference entry point for this skill.
+
+## Contents
+
+- `../skill-spec.json`: design source for regenerating this skill
+- `prompt-template.md`: reusable prompt wording for this skill
+- `cases.md`: human-readable replay case for this skill
+- `../assets/golden-prompt-suite.current.js`: machine-readable local case fixture
+
+## Guidance
+
+- Keep skill-specific explanation here instead of pushing it into a stage-level shared library.
+- Keep shared hard constraints in `../../../rules/index.md`.
+- Keep canonical names unchanged.
+- Skill summary: Design request and response contracts, error shapes, and compatibility boundaries.

package/skills/02-design/api-design/references/cases.md

@@ -0,0 +1,26 @@
+# api-design
+
+## Replay Case
+
+- Case: `api-contract-new-endpoint`
+- First skill: `api-design`
+
+### Prompt
+
+```text
+Define a new API endpoint. Design the request, response, and compatibility rules.
+```
+
+### Expected Output
+
+- request shape
+- response shape
+- constraints
+
+### Stop Rule
+
+- Do not change implementation.
+
+### Handoff
+
+- database-design

package/skills/02-design/api-design/references/prompt-template.md

@@ -0,0 +1,18 @@
+# api-design
+
+## Prompt Template
+
+```text
+You are handling the api-design skill.
+Goal: Design request and response contracts, error shapes, and compatibility boundaries
+Inputs: the request, supporting evidence, constraints, and existing repository facts.
+Output contract: request shape, response shape, constraints.
+Stop rule: Do not change implementation.
+Handoff: database-design.
+Keep the response scoped to this stage and do not absorb the work of the next stage.
+```
+
+## Notes
+
+- Keep the template aligned with the local replay case and local assets.
+- Read `cases.md` for the matching replay example.

package/skills/02-design/api-design/skill-spec.json

@@ -0,0 +1,25 @@
+{
+  "group": "02-design",
+  "name": "api-design",
+  "description": "Design request and response contracts, error shapes, and compatibility boundaries.",
+  "title": "API Design",
+  "purpose": "Define stable API contracts that are clear to both implementers and consumers.",
+  "whenToUse": [
+    "You are introducing or changing an interface.",
+    "You need to agree on payloads, errors, versioning, or compatibility behavior.",
+    "Consumers and implementers need the same contract vocabulary."
+  ],
+  "how": [
+    "Specify request and response shapes, compatibility rules, and edge-case behavior.",
+    "Include examples for success, validation failure, and empty or partial data.",
+    "Call out authentication, idempotency, pagination, and versioning when they matter.",
+    "Name the migration path if the contract changes existing consumers."
+  ],
+  "whenToAvoid": [
+    "The change is already small and local.",
+    "The system shape is already settled.",
+    "You only need request-level clarification or implementation detail."
+  ],
+  "caseId": "api-contract-new-endpoint",
+  "source": "bootstrap-from-skill-md"
+}

package/skills/02-design/architecture-design/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: architecture-design
+description: Shape system boundaries, dependencies, and deployment decisions for a change.
+---
+
+# Architecture Design
+
+## Purpose
+
+Define the structure, boundaries, and major trade-offs before implementation begins.
+
+## When to Use
+
+- The change spans multiple modules, services, or release units.
+- You need an agreed architecture before coding.
+- The dependency direction, ownership, or deployment shape is not obvious.
+
+## How
+
+- Define boundaries, dependencies, and tradeoffs at the smallest useful system level.
+- Spell out who owns each boundary and which component is allowed to depend on which.
+- Capture the main options, why one wins, and what risk remains.
+- Note the interfaces, data flow, and rollout implications that downstream work must honor.
+
+## When to Avoid
+
+- The change is already small and local.
+- The system shape is already settled.
+- You only need request-level clarification or implementation detail.

package/skills/02-design/architecture-design/assets/golden-prompt-suite.current.js

@@ -0,0 +1,22 @@
+#!/usr/bin/env node
+
+module.exports = {
+  "name": "architecture-design.golden-prompt-suite.current",
+  "skill": "architecture-design",
+  "description": "Shape system boundaries, dependencies, and deployment decisions for a change.",
+  "cases": [
+    {
+      "id": "architecture-multi-module",
+      "prompt": "This request affects multiple modules. Design the boundaries and tradeoffs.",
+      "expectedFirstSkill": "architecture-design",
+      "expectedOutput": [
+        "architecture decisions",
+        "boundaries",
+        "tradeoffs"
+      ],
+      "expectedStop": "Do not write production code yet.",
+      "expectedHandoff": "api-design"
+    }
+  ]
+};
+

package/skills/02-design/architecture-design/references/README.md

@@ -0,0 +1,17 @@
+# architecture-design References
+
+This directory is local to the skill and is the only reference entry point for this skill.
+
+## Contents
+
+- `../skill-spec.json`: design source for regenerating this skill
+- `prompt-template.md`: reusable prompt wording for this skill
+- `cases.md`: human-readable replay case for this skill
+- `../assets/golden-prompt-suite.current.js`: machine-readable local case fixture
+
+## Guidance
+
+- Keep skill-specific explanation here instead of pushing it into a stage-level shared library.
+- Keep shared hard constraints in `../../../rules/index.md`.
+- Keep canonical names unchanged.
+- Skill summary: Shape system boundaries, dependencies, and deployment decisions for a change.

package/skills/02-design/architecture-design/references/cases.md

@@ -0,0 +1,26 @@
+# architecture-design
+
+## Replay Case
+
+- Case: `architecture-multi-module`
+- First skill: `architecture-design`
+
+### Prompt
+
+```text
+This request affects multiple modules. Design the boundaries and tradeoffs.
+```
+
+### Expected Output
+
+- architecture decisions
+- boundaries
+- tradeoffs
+
+### Stop Rule
+
+- Do not write production code yet.
+
+### Handoff
+
+- api-design

package/skills/02-design/architecture-design/references/prompt-template.md

@@ -0,0 +1,18 @@
+# architecture-design
+
+## Prompt Template
+
+```text
+You are handling the architecture-design skill.
+Goal: Shape system boundaries, dependencies, and deployment decisions for a change
+Inputs: the request, supporting evidence, constraints, and existing repository facts.
+Output contract: architecture decisions, boundaries, tradeoffs.
+Stop rule: Do not write production code yet.
+Handoff: api-design.
+Keep the response scoped to this stage and do not absorb the work of the next stage.
+```
+
+## Notes
+
+- Keep the template aligned with the local replay case and local assets.
+- Read `cases.md` for the matching replay example.

package/skills/02-design/architecture-design/skill-spec.json

@@ -0,0 +1,25 @@
+{
+  "group": "02-design",
+  "name": "architecture-design",
+  "description": "Shape system boundaries, dependencies, and deployment decisions for a change.",
+  "title": "Architecture Design",
+  "purpose": "Define the structure, boundaries, and major trade-offs before implementation begins.",
+  "whenToUse": [
+    "The change spans multiple modules, services, or release units.",
+    "You need an agreed architecture before coding.",
+    "The dependency direction, ownership, or deployment shape is not obvious."
+  ],
+  "how": [
+    "Define boundaries, dependencies, and tradeoffs at the smallest useful system level.",
+    "Spell out who owns each boundary and which component is allowed to depend on which.",
+    "Capture the main options, why one wins, and what risk remains.",
+    "Note the interfaces, data flow, and rollout implications that downstream work must honor."
+  ],
+  "whenToAvoid": [
+    "The change is already small and local.",
+    "The system shape is already settled.",
+    "You only need request-level clarification or implementation detail."
+  ],
+  "caseId": "architecture-multi-module",
+  "source": "bootstrap-from-skill-md"
+}

package/skills/02-design/database-design/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: database-design
+description: Design schemas, indexes, query shapes, and data ownership before database work.
+---
+
+# Database Design
+
+## Purpose
+
+Plan table structure, relationships, indexing, and data access patterns with low risk.
+
+## When to Use
+
+- A new table, column, index, or schema change is needed.
+- Query performance or data consistency matters.
+- Data ownership, cardinality, or retention rules are still unclear.
+
+## How
+
+- Define tables, keys, indexes, and the queries the schema must support.
+- Match the schema to the access pattern instead of forcing the app to compensate.
+- Capture migration, backfill, and rollback expectations before implementation.
+- Note the locking, transaction, and compatibility risks that matter during rollout.
+
+## When to Avoid
+
+- The change is already small and local.
+- The system shape is already settled.
+- You only need request-level clarification or implementation detail.