Shared skills — tested procedural capability
A shared skill packages a repeatable procedure and its references so an agent can load it when relevant. It is useful only when the procedure is current, bounded, discoverable, and tested. Treat skills as executable documentation: review their instructions and scripts, restrict their authority, test success and failure cases, and retire them when their evidence no longer holds.
Q6 · Shared infrastructure Max-score evidence: versioned and reviewed skills with owners, positive, negative, and boundary fixtures, safe distribution, and usage evidence.
Claude Code documents project skills under .claude/skills, Cursor supports .agents/skills and .cursor/skills, and Codex uses .agents/skills. A portable shared core may still need thin adapters or compatibility tests.
Define a skill contract
Section titled “Define a skill contract”- Trigger: when the skill should and should not load.
- Outcome: the artifact or evidence it produces.
- Inputs: required files, tools, state, and permissions.
- Boundary: prohibited systems, data, side effects, and escalation conditions.
- Procedure: short ordered steps with verification and cleanup.
- Ownership: maintainer, source evidence, last verified version, and retirement trigger.
- Select a repeated task. Use support questions, reviews, failed runs, or incidents as evidence of repetition.
- Write the smallest skill. Keep the entrypoint concise; move detailed references and scripts into supporting files.
- Review dependencies and authority. Pin or verify scripts, inspect network and filesystem access, and exclude secrets.
- Test representative fixtures. Include positive, malformed, out-of-scope, missing-permission, stale-source, and dependency-failure cases.
- Distribute and observe. Use versioned installation, record which version produced an artifact, and measure useful completion rather than invocation count.
Prompts for skill review
Section titled “Prompts for skill review”Turn this repeated procedure into a bounded skill contract with trigger, non-trigger, output, prerequisites, permissions, stop conditions, verification, owner, and retirement trigger.Threat-model this skill and its scripts. Identify untrusted input, network and filesystem access, credential use, external side effects, dependency risk, and controls outside the model.Generate positive, negative, boundary, stale-source, permission-denied, and dependency-failure fixtures. Define the evidence required for each expected result.Acceptance evidence
Section titled “Acceptance evidence”- A fresh supported-tool session discovers the skill only for its intended trigger.
- The skill refuses out-of-scope or insufficiently authorized work with an actionable explanation.
- Scripts and referenced assets receive code review and automated tests.
- Distribution does not overwrite personal files or copy shared secrets.
- Accepted artifacts can be traced to skill version and verification evidence.
Failure pattern: instruction bundle as control
Section titled “Failure pattern: instruction bundle as control”A skill can be ignored, misapplied, or contain malicious scripts. It cannot replace sandboxing, access control, CI, or human approval. Keep authority narrow and make every consequential boundary externally enforceable.
Continue with team context
Section titled “Continue with team context”Use Shared agent rules for repository truth and Knowledge sharing for ownership and retirement.