---
type: "synthesis"
tags: ["synthesis", "vocabulary"]
spans: ["video", "paper"]
id: "synthesis-skill-equals-stage-contract"
sources: ["cross-day"]
---
# Synthesis: 'Skill' ≅ Stage Contract

The video introduces **skills** as discrete markdown files capturing Goal, Constraints, Assumptions, Sub-goals — see [[framework-skill-creation]] and [[concept-icm-d1]]. The paper never uses the word "skill" but describes the same object under a different name: the **Layer 2 stage contract** — see [[concept-stage-contracts]] and [[concept-five-layer-hierarchy]].

## The vocabulary map

| Video term | Paper term | What it is |
|---|---|---|
| Skill | Stage contract (L2 `CONTEXT.md`) | The role / prompt for one step |
| Folder of skills | Workspace ([[framework-icm-architecture]]) | The pipeline |
| Goal/Constraints/Assumptions/Sub-goals ([[framework-skill-creation]]) | Inputs/processing/outputs (the contract) | The four-part structure |
| Codify dialogue ([[action-codify-voice]]) | Edit source not output ([[concept-edit-source-principle]]) | The maintenance principle |

## Why the rename matters

[[entity-semantic-kernel]] also uses the word "skill" (Microsoft's term for a callable LLM function). Calling ICM stages "skills" muddies the distinction — Semantic Kernel skills are code-invoked; ICM stage contracts are folder-traversed. The paper's neutral term **stage contract** disambiguates.

## Practical consequence

When a video-listener asks "how do I write a skill?" — answer in **paper vocabulary**: write a stage's L2 `CONTEXT.md` declaring the inputs it reads from the previous `output/`, the references it relies on, and the output it produces ([[concept-stage-contracts]]).

See [[synthesis-five-layer-fills-the-gap]], [[synthesis-dialogue-to-context-engineering]].