@pigcloud/skills 1.0.11 → 1.1.2

package/skills/references/skill-authoring-standard.md

@@ -1,74 +0,0 @@
-# Skill Authoring Standard
-
-## Goal
-Make every skill easy for AI to detect, cheap to read, and hard to misuse.
-
-## Required Shape
-- `name`: one canonical skill name
-- `description`: action + trigger + scope in one sentence
-- `lifecycle_stage`: stable stage label
-- `slash_commands`: only when the skill has a real command surface
-- `dependencies`: only true hard prerequisites
-- `triggers`: exact user phrases and intent keywords
-- `inputs`: what the skill consumes
-- `outputs`: what the skill must produce
-- `workflow`: short ordered steps
-- `gates`: objective completion checks
-- `refs`: where the long detail lives
-- `rule_profile`: optional hint for which rules bundle profile a skill should load
-
-## Template Levels
-- `short`: use [`skill-boundary-template.md`](skill-boundary-template.md) for routing, intake, capture, and other low-complexity skills.
-- `enhanced`: use [`skill-enhanced-template.md`](skill-enhanced-template.md) for design, implementation, review, and other high-density skills.
-- Keep one skill on one level unless the skill clearly crosses into a more complex phase.
-
-## Token Saving Rules
-- Keep the skill body short.
-- Move templates, long examples, and repeated background into `references/`.
-- Keep rule bundles in `rules/` and point `refs` at the smallest needed bundle.
-- Reuse `skills/references/skill-boundary-template.md` for the common skill shape.
-- Write once, reference many.
-- Prefer bullets over paragraphs.
-- Avoid repeating rule bundles in every skill.
-
-## AI Recognition Rules
-- Put trigger words in the first screen.
-- Use one name for one capability.
-- Make `description` concrete: verb + object + outcome.
-- 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.
-- Put hard-stop rules in `gates`, not in prose.
-- Use `Quick Start`, `Inputs / Outputs`, and `Gotchas` only in enhanced skills.
-
-## Canonical Order
-1. Purpose
-2. Suitable / Unsuitable
-3. Quick Start
-4. Inputs / Outputs
-5. Workflow
-6. Replay Signals
-7. Gotchas
-8. Stop Rules
-9. References
-10. Safety
-
-## What Belongs Outside
-- Long tutorials
-- Large examples
-- Repeated rule details
-- External comparison notes
-- Shared templates
-- Negative replay scenarios
-
-## Template Selection
-- 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-boundary-template.md

@@ -1,71 +0,0 @@
-# Skill Boundary Template
-
-Use this template for simple routing, capture, or handoff skills where the body should stay very small. If the skill needs Quick Start, Inputs / Outputs, or Gotchas, it should probably use the enhanced template instead.
-
-## Copyable SKILL.md skeleton
-
-```markdown
----
-name: example-skill
-description: What the skill does and when to use it, written as one clear sentence.
-lifecycle_stage: [routing|capture|scaffold]
-rule_profile: [router|capture|scaffold]
-dependencies:
-  - [only hard prerequisites]
-triggers:
-  - [exact phrases or intent keywords]
-inputs:
-  - [artifacts or facts the skill consumes]
-outputs:
-  - [artifacts the skill must produce]
-workflow:
-  - [step 1]
-  - [step 2]
-  - [step 3]
-gates:
-  - [objective stop condition]
-refs:
-  - [smallest needed reference file]
----
-
-# Example Skill
-
-## Purpose
-
-Describe the skill in one sentence. Keep it narrow.
-
-## Suitable / Unsuitable
-
-- Suitable: [what this skill should handle]
-- Unsuitable: [what this skill should not handle]
-
-## Workflow
-
-1. Identify the request type and boundary.
-2. Do the one bounded step.
-3. Produce the handoff artifact or stop.
-
-## Replay Signals
-
-- Input signal: [what should trigger this skill]
-- Output to verify: [what a correct output should include]
-- Stop signal: [what means the skill has gone too far]
-- Handoff signal: [when to pass control onward]
-
-## Stop Rules
-
-- Stop after the bounded step is complete.
-- Do not expand into adjacent skills.
-- Do not add long background or policy details.
-
-## References
-
-- [skill-authoring-standard.md](skill-authoring-standard.md)
-- [skill-enhanced-template.md](skill-enhanced-template.md)
-```
-
-## When to choose the short template
-
-- Use it for routing-only, capture-only, or single-boundary skills.
-- Keep replay signals and stop rules concise.
-- Move any detailed guidance into `references/` only if it is truly needed.

package/skills/references/skill-enhanced-template.md

@@ -1,103 +0,0 @@
-# Skill Enhanced Template
-
-Use this template for complex skills that need a clear boundary, explicit replay signals, and a small amount of reusable structure. Keep the final skill body short; move long explanations into `references/`.
-
-## Copyable SKILL.md skeleton
-
-```markdown
----
-name: example-skill
-description: What the skill does and when to use it, written as one clear sentence.
-lifecycle_stage: [routing|refinement|analysis|implementation|testing|capture|scaffold]
-rule_profile: [router|refinement|analysis|implementation|testing|capture|api|scaffold|security|performance|modeling|code]
-dependencies:
-  - [only hard prerequisites]
-triggers:
-  - [exact phrases or intent keywords]
-inputs:
-  - [artifacts or facts the skill consumes]
-outputs:
-  - [artifacts the skill must produce]
-workflow:
-  - [step 1]
-  - [step 2]
-  - [step 3]
-gates:
-  - [objective stop condition]
-refs:
-  - [smallest needed reference file]
----
-
-# Example Skill
-
-## Purpose
-
-Describe the skill in one sentence. State the outcome, not the implementation.
-
-## Suitable / Unsuitable
-
-- Suitable: [what this skill should handle]
-- Unsuitable: [what this skill should not handle]
-
-## Quick Start
-
-- State the first action the model should take.
-- State the first artifact it should inspect or produce.
-- State the handoff point if another skill should continue.
-
-## Inputs / Outputs
-
-- Inputs:
-  - [input 1]
-  - [input 2]
-- Outputs:
-  - [output 1]
-  - [output 2]
-
-## Workflow
-
-1. Identify the request type and the boundary.
-2. Gather only the facts needed for this step.
-3. Produce the step-specific artifact.
-4. Hand off or stop when the boundary is reached.
-
-## Replay Signals
-
-- Input signal: [what should trigger this skill]
-- Output to verify: [what a correct output should include]
-- Stop signal: [what means the skill has gone too far]
-- Handoff signal: [when to pass control onward]
-
-## Gotchas
-
-- [common failure mode 1]
-- [common failure mode 2]
-- [common failure mode 3]
-
-## Stop Rules
-
-- Stop when the step-specific artifact is complete.
-- Do not cross into the next skill's work.
-- Do not add unrelated context or policy details.
-
-## References
-
-- [skill-authoring-standard.md](skill-authoring-standard.md)
-- [skill-boundary-template.md](skill-boundary-template.md)
-- [rule-loading-map.md](rule-loading-map.md)
-```
-
-## How to use this template
-
-- Start with the `description` field. It is the primary trigger.
-- Keep `dependencies` for hard prerequisites only.
-- Put exact trigger phrases in `triggers`.
-- Use `workflow` for the minimal reliable procedure.
-- Put hard stop conditions in `gates` and `Stop Rules`.
-- Keep detailed notes, examples, and variant-specific guidance in `references/`.
-
-## When to choose the enhanced template
-
-- Use it for skills with multiple steps, strict boundaries, or meaningful handoff behavior.
-- Use the short template in `skill-boundary-template.md` for simpler routing or capture tasks.
-- Prefer the smallest possible reference set that still keeps the skill reliable.

package/skills/references/skill-reference-matrix.md

@@ -1,62 +0,0 @@
-# Skill Reference Matrix
-
-## Governance Context
-
-- Skills are the execution layer.
-- Rules are the constraint layer.
-- Workflow decides routing before execution.
-- For a broader system view, see [docs/agent-governance-overview.md](../../docs/agent-governance-overview.md).
-
-## Borrowed Patterns
-
-| Source | Best Practice | Applies To |
-|---|---|---|
-| 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-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-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` |
-
-## Skill Principles
-
-- Collect the boundary first, then expand output.
-- Use verifiable facts instead of guesses.
-- Keep existing boundaries during iteration.
-- Let objective gates take priority over narrative explanation.
-- Move long content into dedicated references.
-- Keep framework rules in `rules/`; do not write them into skill bodies.
-
-## Applicable Skills
-
-- `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-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-contract-docs`: turn confirmed interfaces into docs
-- `domain-modeling`: turn domain language into boundaries
-- `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-audit`: output security findings
-- `performance-audit`: output performance findings
-
-## Template Selection
-
-- 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
-
-- `rules/` is the only source for framework knowledge.
-- Use `skills/references/rule-loading-map.md` to decide which bundle to load.
-- Load the smallest bundle that covers the task.
-- Skills should reference at least one `rules` bundle when the task touches code.
-
-

package/skills/security-audit/SKILL.md

@@ -1,119 +0,0 @@
----
-name: security-audit
-description: 当需要安全结论时，对 diff、接口或设计说明中的认证、密钥或数据暴露风险进行审查
-lifecycle_stage: review
-rule_profile: security
-dependencies:
-  - feature-build
-triggers:
-  - security
-  - injection
-  - secret
-  - permission
-  - auth
-  - data exposure
-  - trust boundary
-inputs:
-  - diff
-  - design notes
-  - endpoint behavior
-outputs:
-  - security findings
-  - risk level
-  - mitigation advice
-  - trust boundary summary
-  - review summary
-workflow:
-  - identify trust boundaries and sensitive flows
-  - inspect input validation and authorization
-  - route generic correctness issues to `code-review`
-  - rank the risks by severity
-  - produce mitigation advice
-gates:
-  - stop at security findings
-  - do not rewrite code
-  - do not turn into a general review
-refs:
-  - skills/references/rule-loading-map.md
-  - skills/references/prompt-replay-checklist.md
-  - skills/references/full-chain-replay-scenarios.md
-  - rules/index.md
----
-
-# Security Audit
-
-## Purpose
-
-Find and rank security risks before release.
-
-## Suitable / Unsuitable
-
-- Suitable: injection, secrets, permissions, auth, data exposure, trust boundary breaks
-- Unsuitable: implementation work, broad code review, requirement discovery, generic correctness review
-
-## Quick Start
-
-- Start by mapping trust boundaries and sensitive flows.
-- Inspect authorization and input validation before anything else.
-- Keep the output focused on findings and mitigation advice.
-- If the issue is only about correctness or maintainability, hand off to `code-review`.
-
-## Report Format
-
-- Use one entry per security finding.
-- Include `location`, `risk level`, `attack path`, `impacted asset`, `evidence`, and `mitigation advice`.
-- Anchor each finding to the smallest relevant security surface:
-  - endpoint, auth flow, permission boundary, secret handling path, or data exposure path
-- State the violated trust boundary when it is clear.
-- Keep the review summary short when no security issue is present.
-- If there are no findings, say what was checked and why the change is acceptable.
-
-## Inputs / Outputs
-
-- Inputs:
-  - diff
-  - design notes
-  - endpoint behavior
-- Outputs:
-  - security findings
-  - risk level
-  - mitigation advice
-  - trust boundary summary
-
-## Workflow
-
-1. Identify trust boundaries and sensitive flows.
-2. Inspect input validation and authorization.
-3. Route generic correctness issues to `code-review`.
-4. Rank the risks by severity.
-5. Produce mitigation advice.
-
-## Replay Signals
-
-- Input signal: diff, design notes, endpoint behavior, or a security concern.
-- Output to verify: security findings, risk level, mitigation advice, trust boundary summary, review summary.
-- Stop signal: rewrite code or turn into a general review.
-- Handoff signal: the findings are ready for `knowledge-capture`.
-
-## Gotchas
-
-- Do not blur security review into generic correctness review.
-- Do not skip trust boundaries.
-- Do not omit risk level when reporting findings.
-- Do not approve changes without explicit evidence.
-- Do not file a generic code-quality issue as a security finding.
-
-## Stop Rules
-
-- Stop at security findings.
-- Do not rewrite code.
-- Do not turn into a general review.
-
-## References
-
-- `skills/references/rule-loading-map.md`
-- `skills/references/prompt-replay-checklist.md`
-- `skills/references/full-chain-replay-scenarios.md`
-- `rules/index.md`
-
-# Security Audit

package/skills/spec-refinement/SKILL.md

@@ -1,149 +0,0 @@
----
-name: spec-refinement
-description: 当需求需要澄清并在设计或实现前对齐时，将 PRD、原型、项目事实、实现事实和知识库证据整理为可执行的规格说明、任务拆分和确认包
-lifecycle_stage: refinement
-rule_profile: refinement
-dependencies:
-  - workflow-router
-triggers:
-  - spec-refinement
-  - requirement clarification
-  - acceptance gap
-  - engineering spec-refinement
-  - task breakdown
-  - execution direction
-  - confirmation package
-inputs:
-  - approved product brief
-  - current project facts
-  - prototype notes
-  - implementation facts
-  - scope decisions
-  - open questions
-  - rules bundle
-outputs:
-  - executable spec-refinement
-  - execution direction plan
-  - acceptance criteria
-  - impact scope
-  - implementation inputs
-  - alignment notes
-  - task breakdown plan
-  - conflict map
-  - confirmation package
-workflow:
-  - verify the product brief is approved
-  - compare the brief with current project facts, prototype notes, implementation facts, and knowledge snippets
-  - clarify boundaries, assumptions, acceptance gaps, and fact conflicts
-  - decide the task execution direction before splitting tasks
-  - extract a task breakdown plan for user confirmation
-  - define implementation-facing constraints and verification inputs
-  - assemble a confirmation package for user sign-off
-  - hand off to `technical-design` or `feature-build` only after confirmation
-gates:
-  - stop at spec-refinement clarity
-  - do not restart PRD writing
-  - do not generate code
-  - do not skip the selected rules bundle
-refs:
-  - skills/references/requirements-separation-map.md
-  - skills/references/project-requirement-alignment.md
-  - skills/references/engineering-delivery-method.md
-  - skills/references/engineering-delivery-template.md
-  - skills/references/rule-loading-map.md
-  - skills/references/flow-test-cases.md
-  - skills/references/full-chain-replay-scenarios.md
-  - skills/references/prompt-replay-checklist.md
-  - rules/index.md
----
-
-# Spec Refinement
-
-## Purpose
-
-Turn product input, current project facts, and implementation evidence into an executable engineering spec-refinement.
-
-## Suitable / Unsuitable
-
-- Suitable: requirement clarification, boundary checks, acceptance gaps, impact analysis, project-fact alignment, prototype alignment, implementation-fact alignment, task breakdown, user confirmation
-- Unsuitable: redoing the PRD, writing code, selecting rule bundles, skipping the rules bundle, starting implementation before confirmation
-
-## 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-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-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
-
-- Inputs:
-  - approved product brief
-  - current project facts
-  - prototype notes
-  - implementation facts
-  - knowledge snippets
-  - scope decisions
-  - open questions
-  - rules bundle
-- Outputs:
-  - executable spec-refinement
-  - execution direction plan
-  - acceptance criteria
-  - impact scope
-  - implementation inputs
-  - alignment notes
-  - conflict map
-  - task breakdown plan
-  - confirmation package
-
-## Workflow
-
-1. Verify the product brief is approved.
-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-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-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-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 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-refinement clarity.
-- Do not restart PRD writing.
-- Do not rewrite the PRD.
-- Do not jump into implementation.
-- Do not generate code.
-- Do not ignore the selected rules bundle.
-- Do not skip the selected rules bundle.
-
-## References
-
-- `skills/references/requirements-separation-map.md`
-- `skills/references/project-requirement-alignment.md`
-- `skills/references/engineering-delivery-method.md`
-- `skills/references/engineering-delivery-template.md`
-- `skills/references/rule-loading-map.md`
-- `rules/index.md`
-
-

package/skills/technical-design/SKILL.md

@@ -1,106 +0,0 @@
----
-name: technical-design
-description: 当模块、接口或依赖仍需决策时，在稳定规格基础上梳理架构与实现边界
-lifecycle_stage: design
-rule_profile: analysis
-dependencies:
-  - spec-refinement
-triggers:
-  - architecture decision
-  - module split
-  - interface contract
-  - dependency direction
-  - design boundary
-inputs:
-  - executable spec-refinement
-  - selected rules bundle
-  - existing module context
-outputs:
-  - design decisions
-  - dependency map
-  - interface contract
-  - implementation constraints
-workflow:
-  - 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
-gates:
-  - stop at design decisions
-  - do not reopen product discovery
-  - do not produce full code
-  - do not skip rule loading
-refs:
-  - skills/references/rule-loading-map.md
-  - skills/references/flow-test-cases.md
-  - skills/references/full-chain-replay-scenarios.md
-  - skills/references/prompt-replay-checklist.md
-  - rules/index.md
----
-
-# Technical Design
-
-## Purpose
-
-Turn a stable spec-refinement into concrete architecture and implementation boundaries.
-
-## Suitable / Unsuitable
-
-- Suitable: architecture decisions, module split, interfaces, dependency direction, constraint mapping
-- Unsuitable: requirement discovery, code generation, redesigning the PRD, unresolved scope gaps, ignoring the rules bundle
-
-## Quick Start
-
-- 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-refinement is still unstable, stop and return to `spec-refinement`.
-
-## Inputs / Outputs
-
-- Inputs:
-  - executable spec-refinement
-  - selected rules bundle
-  - existing module context
-- Outputs:
-  - design decisions
-  - dependency map
-  - interface contract
-  - implementation constraints
-
-## Workflow
-
-1. Confirm the spec-refinement is stable enough for design work.
-2. Define boundaries, dependencies, and interfaces.
-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`.
-
-## Replay Signals
-
-- Input signal: multi-module change, boundary ambiguity, dependency risk, or compatibility concern.
-- Output to verify: design decisions, dependency map, interface contract, implementation constraints.
-- Stop signal: full code, reopened product discovery, or skipped rules loading.
-- Handoff signal: implementation can start inside `feature-build`.
-
-## Gotchas
-
-- Do not turn unresolved requirement issues into design decisions.
-- 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-refinement is not stable enough to design.
-
-## Stop Rules
-
-- Stop at design decisions.
-- Do not reopen product discovery.
-- Do not produce full code.
-- Do not skip rule loading.
-
-## References
-
-- `skills/references/rule-loading-map.md`
-- `skills/references/flow-test-cases.md`
-- `rules/index.md`
-