-
Notifications
You must be signed in to change notification settings - Fork 1
Skill Composition
Skill composition defines how operational capabilities interact inside a workspace.
The repository intentionally favors:
few dense operational capabilities
with:
- low overlap
- bounded activation
- operational specificity
- contextual locality
- and implementation grounding
See Architecture for canonical architectural invariants.
A skill represents:
a distinct operational capability mode
NOT:
- a capability
- a taxonomy category
- a plugin
- or a conceptual fragment
Stable composition depends on preserving clear operational boundaries between overlays.
Composition should preserve:
- operational clarity
- trigger precision
- contextual continuity
- implementation locality
- and bounded activation
Composition SHOULD minimize:
- overlap
- activation ambiguity
- duplicated semantics
- token inflation
- and capability contamination
| Skill | Operational Role |
|---|---|
knowledge-construction |
durable operational understanding |
implementation-investigation |
evidence-backed implementation investigation |
operational-memory |
survivable continuation state |
locality-recovery |
workspace topology reconstruction |
Each capability intentionally represents a distinct operational capability.
Skills compose through:
- operational relevance
- workflow state
- implementation activity
- contextual locality
- and continuity requirements
Skills intentionally avoid:
- repository-global activation
- broad conceptual reasoning
- orchestration-heavy composition
- and repository-wide semantic ownership
Stable composition behavior usually produces:
predictable
bounded
low-overlap
operationally coherent
Unstable composition behavior often produces:
activation ambiguity
context contamination
duplicated semantics
fragmented reasoning
token waste
Composition stability became one of the strongest operational stabilizers of the system.
Skills SHOULD activate only when operationally relevant.
Good activation behavior:
specific
bounded
workflow-aware
implementation-aware
Poor activation behavior:
global
broad
taxonomy-driven
conceptually ambiguous
This distinction is critical for maintaining stable overlay behavior across long-running workflows.
Triggers should remain tightly connected to:
- implementation activity
- operational workflows
- runtime investigation
- continuity behavior
- and contextual authoring
Triggers SHOULD avoid:
- broad conceptual activation
- repository-global reasoning
- vague philosophical interpretation
- and semantic escalation
Overlap was identified as one of the primary long-term stability risks.
The repository intentionally minimizes overlap between:
- implementation reasoning
- continuity preservation
- semantic authoring
- visual operational mapping
- and workspace reasoning
This preserves:
- contextual coherence
- predictable activation
- operational readability
- and composition stability
An agent investigates websocket reconnect failures while preserving contextual continuity.
| Skill | Purpose |
|---|---|
implementation-investigation |
Runtime debugging and grounding |
operational-memory |
Preserving unresolved state |
knowledge-construction |
Safe contextual updates |
| Skill | Reason |
|---|---|
locality-recovery |
No spatial or visual reasoning needed |
The agent:
- reasons about runtime behavior
- preserves implementation locality
- safely updates contextual notes
- and maintains debugging continuity
without activating unrelated overlays.
Poor composition boundaries often produce:
- duplicated contextual reasoning
- repository-global activation
- unstable trigger behavior
- unrelated overlay activation
- and degraded operational continuity
Example:
A debugging workflow accidentally activates
repository-wide semantic traversal overlays,
causing unrelated contextual expansion.
Stable composition avoids this by preserving:
- bounded activation
- implementation locality
- and workflow-specific overlay relevance
The repository intentionally avoids:
Bad examples:
wikilink-skill
metadata-skill
markdown-editing-skill
These belong inside:
knowledge-construction
Bad examples:
backend-runtime-skill
frontend-runtime-skill
database-runtime-skill
These create:
- overlap
- activation ambiguity
- fragmented contextual reasoning
Bad examples:
repository-ontology-skill
semantic-indexing-skill
global-context-ownership-skill
These conflict with canonical architectural invariants defined in Architecture.
Composition SHOULD preserve:
- nearby implementation context
- operational relationships
- workflow continuity
- runtime locality
- and bounded contextual surfaces
The system intentionally avoids:
- repository-global contextual traversal
- detached semantic reasoning
- and graph-authoritative navigation
Composition remains intentionally bounded by:
- filesystem locality
- semantic scope
- operational relevance
- and implementation context
Recommended semantic root:
.context/notes
Core invariant:
semantic scope != filesystem scope
Canonical semantic boundaries are defined in:
Skills intentionally DO NOT:
- preserve invariants
- normalize repositories
- serialize canonical structures
- or replace runtime authority
Skills influence:
- contextual reasoning
- operational heuristics
- continuity behavior
- and implementation grounding
Canonical runtime authority is defined in Runtime Boundaries.
Composition is optimized for:
long-running engineering operational continuity
inside real repositories.
The system prioritizes:
- operational continuity
- implementation grounding
- contextual recovery
- unresolved state survivability
- and stable workflow composition
across long-running engineering workflows.