-
Notifications
You must be signed in to change notification settings - Fork 0
Contributing Skills
This document defines operational contribution principles for Weave Skills.
The repository intentionally favors:
few dense operational overlays
rather than:
many fragmented conceptual overlays
See Architecture for canonical architectural invariants.
A skill should represent a distinct, triggerable operational capability mode — not a taxonomy node, plugin system, or philosophical fragment. Strong skills stabilize trigger behavior, overlap handling, contextual continuity, and workflow survivability.
A skill modifies:
- contextual reasoning
- operational heuristics
- implementation awareness
- continuity behavior
- workflow interpretation
Skills behave as portable operational capabilities inside filesystem-native workflows.
A skill is NOT:
- a runtime
- an orchestration layer
- a command system
- a semantic index
- a graph engine
- a repository ownership model
Skills intentionally remain:
bounded
operational
filesystem-aware
implementation-grounded
Canonical architectural boundaries are defined in:
Current skills intentionally remain small and dense.
| Skill | Responsibility |
|---|---|
knowledge-construction |
durable operational understanding |
implementation-investigation |
evidence-backed implementation investigation |
operational-memory |
survivable continuation state |
locality-recovery |
workspace topology reconstruction |
Contributors SHOULD preserve this density model.
Before introducing a new skill, contributors SHOULD ask:
Does this represent a genuinely distinct operational capability mode?
If unclear, prefer extending an existing skill.
Strong skills are typically:
- operationally specific
- contextually dense
- low-overlap
- implementation-grounded
- triggerable
- workflow-oriented
- composition-safe
Good skills usually modify one of:
- reasoning behavior
- continuity behavior
- contextual interpretation
- operational heuristics
Avoid:
- capability fragmentation (split behaviors belong inside
knowledge-constructionor existing skills) - taxonomy inflation (many narrowly-scoped skill names)
- repository semanticization (global ontology or graph-index skills)
These patterns create overlap, ambiguity, and unstable activation.
Contributors SHOULD minimize:
- overlap
- duplicated semantics
- broad triggers
- conceptual fragmentation
- repository-global activation
- capability contamination
Composition guidance is documented in Skill Composition.
Skills MUST preserve filesystem authority and SHOULD NOT semanticize repositories or replace filesystem organization. Canonical filesystem invariants are defined in Architecture.
Skills MUST respect bounded semantic scope. Recommended semantic root:
.context/notes
Only files inside semantic scope participate in symbolic semantics. Core invariant:
semantic scope != filesystem scope
Canonical semantic scope behavior is defined in Semantic Scope.
Skills intentionally DO NOT preserve runtime invariants or serialize canonical structures. Skills influence contextual reasoning, continuity behavior, implementation grounding, and operational heuristics. Canonical runtime boundaries are defined in Runtime Boundaries.
Contributors SHOULD prioritize implementation-grounded operational continuity rather than abstract semantic knowledge systems. Implementation grounding behavior is documented in Implementation Tracing.
The repository optimizes for long-running engineering operational continuity inside real repositories. Strong skills improve continuity, recovery, traceability, unresolved state survivability, and implementation-aware workflows across sessions and tools.
Recommended repository structure:
skill-name/
└── SKILL.md