---
type: "synthesis"
tags: ["spec-engineering", "prompt-engineering", "skills", "intent", "evolution"]
spans_days: ["s01", "s04", "s07", "s12", "s17", "s22", "s23", "s24", "s25", "s35", "s40", "s42", "s43", "s44"]
id: "arc-prompt-to-spec-evolution"
sources: ["cross-day"]
---
# From Prompts to Specs to Skills — The Discipline Evolution

The single most-developed thread across the series is the **steady demotion of prompting and the steady promotion of specification, evaluation, and reusable skill artifacts**. Day-by-day, Nate adds a new layer; by the end of the corpus he has built a four-tier hierarchy of skills atop a load-bearing claim: *implementation is commoditized; specification is the bottleneck.*

## The arc, layer by layer

1. **Spec as the new bottleneck (S01).** [[concept-spec-quality-bottleneck]] is introduced as the central reframe of the [[concept-5-levels-vibe-coding|5 Levels]] framework: at Level 5 (the [[concept-dark-factory]]) a human only writes specs. The most valuable engineering skill becomes hyper-precise spec authorship — closer to legal drafting than syntax production.
2. **Spec + metric + budget = Karpathy Triplet (S04).** [[concept-karpathy-triplet]] operationalizes spec discipline: one editable surface, one metric, one time budget. Without that triplet, an autonomous loop ([[concept-karpathy-loop]]) cannot be deployed safely. Specs become *executable*: [[quote-cannot-automate-score]] — "you cannot automate what you cannot score."
3. **Specification > execution (S07).** [[concept-specification-vs-execution]] generalizes the principle outside code into design: when image execution is solved by [[concept-reasoning-stack-integration|reasoning-stack-integrated]] models, the new ceiling is the brief.
4. **Literal instruction following (S12).** [[concept-literal-instruction-following]] makes the cost of imprecise specs visceral — Opus 4.7 will execute exactly the words written, no charitable inference. The action is [[action-front-load-intent]].
5. **Context Engineering arrives (S22, S23, S24).** [[concept-specification-engineering]] is named as the apex of the [[framework-ai-skill-hierarchy]]; [[concept-context-engineering-d23]] embeds comprehension *into the codebase*; [[concept-context-engineering-d24]] generalizes to the information state of the entire system.
6. **Intent Engineering (S24).** [[concept-intent-engineering]] adds a third tier above context: translating organizational *purpose* into machine-readable parameters and [[concept-machine-readable-okrs]]. The Klarna failure ([[claim-klarna-intent-failure]]) is the canonical anti-example.
7. **Spec-Driven Development (S23).** [[concept-spec-driven-development]] enforces the principle at the coding layer with the slogan [[quote-spec-becomes-eval]] — "the spec becomes the eval."
8. **Outcome-Driven Prompting (S44).** [[concept-outcome-driven-prompting]] is the strongest version: as models cross the [[concept-step-change-ai|step-change]] threshold, even procedural specs become harmful. Specify only the *what* and the constraints; the model picks the *how*. This is the [[concept-bitter-lesson-llms]] applied to prompting.
9. **Skills replace prompts (S40, S43).** [[concept-claude-skills]] and the [[concept-skills-vs-prompts|compounding skills]] thesis introduce a *durable artifact*: version-controlled markdown that compounds. [[concept-skills-as-contracts]] treats them like APIs; [[concept-description-routing-signal]] treats the description itself as the spec.
10. **Specification Precision becomes a hireable skill (S42).** [[concept-specification-precision]] is the #1 skill in the [[framework-7-ai-skills|7 AI Skills]] taxonomy. Talking English to a machine *that takes you literally* (see [[quote-literal-machine]]) is now a job description.

## The composite hierarchy

By S35 + S22 + S24 the implicit hierarchy is:

```
Prompt Engineering        (S40 calls this "the warm-up act")
     ↓
Context Engineering       (S22, S23, S24)
     ↓
Intent Engineering        (S24 — what to want)
     ↓
Specification Engineering (S22, S42 — apex)
```

Reusable artifacts ([[concept-claude-skills]], [[concept-skill-file-format]], [[concept-design-markdown]]) sit *below* this hierarchy as compounding infrastructure that any layer can call.

## Why this matters

- **Career**: [[concept-non-technical-engineering]] (S35) and [[concept-specification-precision]] (S42) say even non-technical roles must adopt this discipline. Marketers, lawyers, ops people now write specs and evals.
- **Org design**: [[concept-shadow-agents]] are what happens when teams *don't* invest in unified spec/intent infrastructure ([[concept-unified-context-infrastructure]]).
- **Failure**: [[concept-specification-drift]] (long-running agents forget their spec) and [[concept-confidently-wrong]] (fluent execution of a wrong spec) are the dominant failure modes — see [[arc-silent-failure-pattern]].

## Open questions

- Will skills standardize into an npm-for-skills registry? See [[question-skill-discovery]].
- Will outcome-driven prompting hold as models scale, or will hybrid pipelines persist? See [[contrarian-intermediate-testing-degrades]].
- Will human judgment itself be the next layer arbitraged away? See [[question-defensibility-of-judgment]] and [[arc-human-role-as-manager]].