1. Name the task and observable result
Write the task in one sentence, then name the artifact or behavior that proves completion. 'Improve the project' is too broad; 'review this pull request and identify security-sensitive blast radius with file references' is testable.
If no result can be observed, do not install anything yet. Clarify the decision or split the task first.
- One task, one owner, one bounded surface.
- A result a person can inspect.
- A stop condition and rollback.
2. Assign one distinct role
Choose the missing role: discovery, planning, generation, guardrail, review, or evidence. Compare candidates that own the same role and reject overlap disguised by different branding.
A large collection raises trigger ambiguity and permission surface. Add the next role only after the current one produces a useful, reviewable result.
3. Inspect the complete source
Open SKILL.md and every referenced script, template, executable, and external service. Record the repository and revision reviewed. A short top-level file can still delegate powerful behavior elsewhere.
Prefer a project-scoped installation when the workflow belongs to one repository. Use personal scope only for deliberately shared behavior you are prepared to maintain across projects.
4. Match permissions to the first test
List file reads and writes, commands, browser control, network access, credentials, publishing, and destructive actions. Remove any access that the first small task does not need.
Compatibility is separate from installation. A folder may be discoverable by an Agent while its scripts, hooks, dependencies, or operating-system assumptions still fail.
5. Run a controlled test and record evidence
Use representative but non-sensitive inputs, a reversible environment, explicit checks, and a known starting state. Record what the Skill actually read, wrote, executed, contacted, and produced.
A successful run proves only this source revision, Agent, environment, and task. Retest after meaningful source, model, dependency, permission, or platform changes.
- Expected trigger and unrelated non-trigger both checked.
- Observed access stays within the agreed boundary.
- Output passes the named acceptance check.
- Rollback returns to the starting state.
The remove decision is part of installation
Define removal conditions before adopting the Skill: unused for a review period, duplicated by another role, source becomes unclear, permissions expand, maintenance stops, output quality falls, or a native capability replaces it.
The best stack is not the one with the most options. It is the smallest set whose sources, triggers, permissions, outputs, and owners you can still explain.