Skills: concrete tasks that execute specific context
If Agents are the "who" and Rules are the "how it's governed," Skills are the "what gets done concretely." They are the element of the tripod that turns vision into action.
A Skill is a self-contained task that an Agent executes while respecting the Rules. It contains all the context needed for the Agent to complete it without ambiguity and without additional information beyond the project-context.md.
The problem of Context Loss
When an Agent executes a Skill, it only "sees" what's in its context window. If relevant information is in another Skill, in a previous conversation, or in a human's head, the Agent makes decisions without it. With total confidence.
The result: Context Debt. Skills that produce correct outputs in isolation but incoherent outputs as a system. The self-containment of each Skill, combined with global Rules, is the antidote.
The five elements of a Skill
| Skill element | What it includes | Connection to Agents and Rules |
|---|---|---|
| Objective | What must be achieved. Not how, but what. | The Agent uses the objective to make decisions when facing ambiguities, within the Rules. |
| Specific context | Extracts from the PRD, architecture. Only what this Skill needs. | Complements global Rules with specific information. The Agent combines both. |
| Acceptance criteria | Verifiable conditions. Written as assertions. | The QA Agent uses these criteria to validate output, applying global quality Rules. |
| Dependencies | Which other Skills must be complete. | Agents don't execute Skills out of sequence. Rules define the order. |
| Specific constraints | Limitations for this task, additional to global Rules. | The Agent applies global Rules + Skill constraints. If there's a conflict, Rules win. |
The hierarchy: Rules > Skills
Each Skill operates within the space defined by the Rules. The relationship is hierarchical and non-negotiable: if the Rules say "all endpoints return JSON { data, error, meta }," a Skill that defines an endpoint inherits that constraint automatically. The Skill doesn't need to repeat it — but the Agent executing it needs to have the Rules loaded.
If a Skill requests something that contradicts a Rule, the Rule wins. Always. The Agent must flag the contradiction to the Context Engineer instead of resolving the conflict on its own. This hierarchy is what protects global coherence.
Types of Skills
| Type | Granularity | Relationship with Agents and Rules | Example |
|---|---|---|---|
| Atomic Skill | One task, one output. | A single Agent executes it. Applies global Rules + its own constraints. | "Create endpoint GET /inventory/{sku}." |
| Composite Skill | Multiple coordinated sub-tasks. | One Agent executes all sub-tasks with shared context. Rules apply to each sub-task. | "Alerts module: model + logic + notification." |
| Integration Skill | Connects outputs from other Skills. | Integration Rules from the project-context.md are especially critical here. | "Integrate inventory with alerts, validate e2e flow." |
The self-containment test: For each Skill: "Can an Agent that only reads this Skill and the project-context.md (Rules) complete the task without asking anything?" If not, context is missing. Add it to the Skill — don't assume the Agent knows it.
What it is: A Skill that doesn't reference the project-context.md. The Agent executing it doesn't load the Rules, or assumes context that isn't written.
What it produces: Inconsistent outputs. The same Skill produces different results depending on which Agent executes it or when, because the Rules weren't present.
How to prevent it: Every Skill includes an explicit reference: "Applicable Rules: see project-context.md." The Agent loads both documents.
A well-written Skill is an act of empathy with the Agent that will execute it. If the Agent needs information that isn't in the Skill or in the Rules, it won't search for it — it will invent it. Self-containment isn't bureaucracy. It's the difference between an output faithful to context and an output that looks correct but isn't.