Lifecycle: draft
Skill Composition and Routing
Purpose and scope
Turn a task and available skill descriptions into a small, coherent working set. This skill governs discovery, ordering, conflict handling, and handoff between skills; it does not override a repository instruction, invent capabilities, or replace the procedures inside selected skills.
Triggers and prerequisites
Trigger when more than one skill appears relevant, a task crosses requirements, implementation, testing, security, maintenance, or review phases, or a skill’s trigger is broad enough to cause accidental activation. Prerequisites: the user’s task, repository context, available skill metadata, and any explicit priority or safety constraints.
Decision criteria
- Select by the task’s actual need and the skill’s trigger, not by keyword similarity or artifact count.
- Prefer the smallest complete set: one skill may own a phase; supporting skills add distinct constraints or evidence.
- Order skills by dependency: clarify the target before implementation, establish safety boundaries before risky actions, implement before verification, and maintenance after a decision exists.
- Resolve conflicts by authority, scope, evidence, and explicit decision boundaries. Do not merge contradictory instructions into vague compromise language.
- A skill is not applicable merely because its subject appears in a file; its trigger and prerequisites must hold.
Procedure
- State the task, desired outcome, affected surface, risk, and current phase. Separate the user’s request from repository instructions and skill suggestions.
- Scan skill metadata first. For each candidate, record trigger match, prerequisites available, phase owned, outputs produced, and known conflicts.
- Classify candidates as primary, supporting, deferred, or irrelevant. Reject candidates whose trigger is only lexical, whose prerequisites are absent, or whose procedure duplicates a selected skill.
- Draw the minimal sequence and handoffs. For example: requirements → implementation/debugging → regression tests → security review → change verification; adapt the sequence to the actual task.
- Check for instruction conflicts. Apply higher-authority repository and user constraints first, then choose the skill with the narrower relevant scope or stronger evidence. If the conflict changes the requested outcome, ask before proceeding.
- Pass only the outputs needed by the next skill: acceptance criteria, observations, hypotheses, changed behavior, test evidence, findings, residual risk, or review triggers. Do not pass assumptions as facts.
- Re-evaluate routing when the task changes, a failure reveals a new risk, or a selected skill’s prerequisite becomes false. Do not continue a stale workflow to preserve momentum.
- At handoff, state which skills were used, why each applied, what each established, what remains unverified, and which skill or human decision owns the next step.
Examples and counterexamples
Good: For an authorization bug, route requirements-to-acceptance first, secure-coding-review for trust boundaries, regression-test-design for denial cases, and repository-change-verification at the end. Defer dependency review because no dependency changed.
Bad: Activate every security, testing, and maintenance skill because the task touches a repository. More instructions can create contradictions and dilute attention.
Good: If evidence-driven-debugging discovers that the issue is actually a dependency vulnerability, hand off to dependency-security-audit and preserve the original observations.
Bad: Keep debugging application code after the evidence shows the vulnerable behavior comes from an unreviewed external package.
Failure modes and recovery
If no skill clearly applies, use the task’s repository guidance and record the gap rather than forcing a poor match. If two skills claim the same phase, compare scope and evidence, then narrow or revise one. If selected skills conflict materially, stop and ask or record the unresolved boundary; never silently apply both. If routing repeatedly causes unnecessary context or steps, simplify the composition and retain the reason.
Validation evidence and provenance
Claims in this skill map to graded findings in docs/research.md:
- Metadata-first loading and on-demand depth (F8): the Agent Skills specification prescribes progressive disclosure; Strong as a format fact, Inferential as an effectiveness claim.
- Fewer, more relevant instructions over more instructions (F3, Moderate): repository-level context evaluation found quality and relevance matter more than raw length.
Source boundary: routing behavior across host agents is not standardized or studied; boundaries defined here are design decisions.
Confidence: high for format conformance; medium for routing boundaries until exercised across neighboring tasks. Freshness: review when the spec or the skill set changes.
Disconfirmation: observed agents activating the wrong skill despite precise triggers, or composed skills producing conflicting instructions in practice, would force re-partitioning.
Related skills and conflicts
Related: every task skill in this library, especially requirements-to-acceptance, epistemic-coding, repository-change-verification, contradiction-resolution, and knowledge-maintenance. This skill does not override a selected skill’s safety boundary or authorize skipping a required phase to reduce context.
1---2name: skill-composition-and-routing3description: Select, order, and combine skills for an AI coding-agent task without activating irrelevant, duplicate, or conflicting guidance. Use when several skills may apply, a workflow spans phases, or a skill library is being extended.4---56Lifecycle: `draft`78# Skill Composition and Routing910## Purpose and scope1112Turn a task and available skill descriptions into a small, coherent working set. This skill governs discovery, ordering, conflict handling, and handoff between skills; it does not override a repository instruction, invent capabilities, or replace the procedures inside selected skills.1314## Triggers and prerequisites1516Trigger when more than one skill appears relevant, a task crosses requirements, implementation, testing, security, maintenance, or review phases, or a skill’s trigger is broad enough to cause accidental activation. Prerequisites: the user’s task, repository context, available skill metadata, and any explicit priority or safety constraints.1718## Decision criteria1920- Select by the task’s actual need and the skill’s trigger, not by keyword similarity or artifact count.21- Prefer the smallest complete set: one skill may own a phase; supporting skills add distinct constraints or evidence.22- Order skills by dependency: clarify the target before implementation, establish safety boundaries before risky actions, implement before verification, and maintenance after a decision exists.23- Resolve conflicts by authority, scope, evidence, and explicit decision boundaries. Do not merge contradictory instructions into vague compromise language.24- A skill is not applicable merely because its subject appears in a file; its trigger and prerequisites must hold.2526## Procedure27281. State the task, desired outcome, affected surface, risk, and current phase. Separate the user’s request from repository instructions and skill suggestions.292. Scan skill metadata first. For each candidate, record trigger match, prerequisites available, phase owned, outputs produced, and known conflicts.303. Classify candidates as primary, supporting, deferred, or irrelevant. Reject candidates whose trigger is only lexical, whose prerequisites are absent, or whose procedure duplicates a selected skill.314. Draw the minimal sequence and handoffs. For example: requirements → implementation/debugging → regression tests → security review → change verification; adapt the sequence to the actual task.325. Check for instruction conflicts. Apply higher-authority repository and user constraints first, then choose the skill with the narrower relevant scope or stronger evidence. If the conflict changes the requested outcome, ask before proceeding.336. Pass only the outputs needed by the next skill: acceptance criteria, observations, hypotheses, changed behavior, test evidence, findings, residual risk, or review triggers. Do not pass assumptions as facts.347. Re-evaluate routing when the task changes, a failure reveals a new risk, or a selected skill’s prerequisite becomes false. Do not continue a stale workflow to preserve momentum.358. At handoff, state which skills were used, why each applied, what each established, what remains unverified, and which skill or human decision owns the next step.3637## Examples and counterexamples3839Good: For an authorization bug, route requirements-to-acceptance first, secure-coding-review for trust boundaries, regression-test-design for denial cases, and repository-change-verification at the end. Defer dependency review because no dependency changed.4041Bad: Activate every security, testing, and maintenance skill because the task touches a repository. More instructions can create contradictions and dilute attention.4243Good: If evidence-driven-debugging discovers that the issue is actually a dependency vulnerability, hand off to dependency-security-audit and preserve the original observations.4445Bad: Keep debugging application code after the evidence shows the vulnerable behavior comes from an unreviewed external package.4647## Failure modes and recovery4849If no skill clearly applies, use the task’s repository guidance and record the gap rather than forcing a poor match. If two skills claim the same phase, compare scope and evidence, then narrow or revise one. If selected skills conflict materially, stop and ask or record the unresolved boundary; never silently apply both. If routing repeatedly causes unnecessary context or steps, simplify the composition and retain the reason.5051## Validation evidence and provenance52Claims in this skill map to graded findings in [`docs/research.md`](../../docs/research.md):5354- Metadata-first loading and on-demand depth (F8): the Agent Skills specification prescribes progressive disclosure; Strong as a format fact, Inferential as an effectiveness claim.55- Fewer, more relevant instructions over more instructions (F3, Moderate): repository-level context evaluation found quality and relevance matter more than raw length.5657Source boundary: routing behavior across host agents is not standardized or studied; boundaries defined here are design decisions.5859Confidence: high for format conformance; medium for routing boundaries until exercised across neighboring tasks. Freshness: review when the spec or the skill set changes.6061Disconfirmation: observed agents activating the wrong skill despite precise triggers, or composed skills producing conflicting instructions in practice, would force re-partitioning.62## Related skills and conflicts6364Related: every task skill in this library, especially `requirements-to-acceptance`, `epistemic-coding`, `repository-change-verification`, `contradiction-resolution`, and `knowledge-maintenance`. This skill does not override a selected skill’s safety boundary or authorize skipping a required phase to reduce context.
ChloeVPin