The right number of Skills is determined by distinct responsibilities, not collection size. Use one Skill for a bounded task, three for a small execution loop, and five only for a repeatable team workflow with separate planning, execution, guardrail, evidence, and maintenance roles.
Published ORIGINAL · SOURCE-AWARE
01
Level 1: one Skill for one bounded outcome
Start with one Skill when the job has a clear input, output, and acceptance check. A single source and permission boundary is easier to understand, especially during the first controlled run.
Add nothing while the first Skill still owns the entire decision. More tools do not fix a vague task definition.
One concrete outcome
One source boundary
One permission budget
One observable acceptance check
02
Level 3: execution, guardrail, and evidence
Move to three only when the work contains three genuinely different questions. The core role creates or changes the artifact. The guardrail checks a known risk. The evidence role proves the relevant behavior or preserves a reproducible result.
The three roles should not approve one another. A test result remains evidence; a static check remains a bounded signal; the final decision remains external to the stack.
03
Level 5: add planning and maintenance
A five-Skill stack becomes reasonable when the same workflow recurs across a team. Add planning to make scope and order reviewable before execution. Add maintenance to preserve the workflow itself: source refresh, reusable instructions, or documented handoff.
If planning is a one-line prompt or maintenance never happens, those are not separate roles. Stay at three.
04
The overlap test
Write one sentence describing the decision each Skill owns. If two sentences are effectively the same, the stack contains overlap. Remove the weaker or broader candidate and run the task again.
Also compare permissions. Two Skills that both need broad shell, network, and write access create a larger combined boundary even when their descriptions sound different.
No duplicated install ID or source package
No duplicated final decision
Every extra permission maps to a distinct output
Removing one Skill produces a visible capability loss
05
When to shrink or expand
Shrink after a workflow stabilizes, when a custom Skill can replace repeated coordination, or when outputs stop being reviewed. Expand only after evidence shows a missing role—not because a new package is popular.
Review the stack after source changes, Agent migrations, repeated failures, or a change in data sensitivity. The correct number can move back from five to three or one.
NEXT STEP
Start at one, earn the right to add more
Build a deterministic one-to-three Skill plan, then expand only when a missing responsibility is observable.