Glossary

Sorted alphabetically. Each entry expands the term and gives the definition this book uses. Where an entry makes a historical, vendor, or time-bounded claim, it carries a local *Sources:* line. The rest are book-local definitions or cross-references.

AC ID (Acceptance Criterion ID)

A stable, bracketed identifier (format [PREFIX-NNN], e.g. [GV-001], [AUTH-014]) attached to each acceptance scenario in a spec. Prefix is 2-4 letters from the component abbreviation so the component is immediately recognizable. Numbers are monotone: deleted IDs leave a permanent gap and are never reused. Tests carry the ID as a framework tag (e.g. JUnit @Tag("GV-001")), producing traceability from spec to evidence. This is an Intent Engineering convention layered on top of OpenSpec. OpenSpec itself prescribes no ID format. See AC IDs and Coverage.

AC registry

A file (test/ac-registry.md by convention) that maintains one row per component: prefix, component name, and next available number. Allocate IDs from this file and increment the counter atomically with the new scenario. A checker uses the registry to reject prefix overlap and ID reuse, as described in AC IDs and Coverage.

ADLC (Agentic Development Lifecycle)

The discipline of building agents as products: reasoning passes, evals, hallucination budgets, runtime governance (boundaries, policies, escalation paths). Distinct from Intent Engineering, where the agent is the worker rather than the product being shipped. See Introduction.

ADR (Architectural Decision Record)

A document recording a single architectural decision: context, options considered, decision, consequences. The recorded decision is immutable once accepted. Reversing a decision creates a new ADR that supersedes the old one, though status updates and cross-references remain editable. The practice originated in Michael Nygard's 2011 post. The structured-Markdown variant used in this book is MADR. See Document Types.

Sources: Michael Nygard, "Documenting Architecture Decisions" (November 15, 2011), origin of the ADR practice. Kopp, Armbruster, Zimmermann, MADR template and CEUR-WS paper (2018), MADR as the structured Markdown variant used in this book.

Agent instructions

This book's term for the full instruction set the agent loads: AGENTS.md (the entry-point file) and the .agents/ hub it points into (instruction files, skills, and hooks). The entry point is a table of contents. The content lives in .agents/. "Agent instructions" refers to both together. See Agent Instructions.

AGENTS.md

The de-facto entry point for a coding agent at the root of a repository as of the May 2026 snapshot of agents.md. Acts as a table of contents: short, links to detailed instruction files, points the agent at the architecture overview.

Sources: AGENTS.md (ongoing, May 2026 snapshot), the de-facto entry-point convention. AgentPatterns.ai, "AGENTS.md: Project-Level README for AI Coding Agents" (last reviewed June 9, 2026), the TOC pattern described in this book. GitHub Changelog, "Copilot coding agent now supports AGENTS.md custom instructions" (August 28, 2025), current vendor support for the convention.

Agentic Software Engineering (ASE)

The broader discipline of building software with coding agents as active participants in the development process. Intent Engineering sits within agentic software engineering as the specific practice of directing agents by engineering intent rather than writing code.

Behavior-Driven Development (BDD)

The collaboration practice Gherkin's Given/When/Then notation came from: scenarios written with business stakeholders, then bound to step definitions that a tool such as Cucumber executes. This book borrows the notation, not the practice. Its scenarios carry no step-definition layer and no Cucumber runtime, and they are authored before the code exists and compiled to tests by the agent rather than written against code that already runs. See Gherkin and The Spectrum.

Sources: Dan North, "Introducing BDD" (March 2006), origin of Behavior-Driven Development. Cucumber Gherkin reference (ongoing), the scenario notation this book borrows while discarding the step-definition runtime.

Brownfield

A codebase that predates Intent Engineering practices: typically years of code, undocumented decisions, business rules that exist only in institutional memory. Brownfield repos cannot adopt Intent Engineering from intent the way greenfield ones do. They bootstrap with skeleton.md. See Brownfield vs Greenfield.

BFF (Backend for Frontend)

An intermediate service layer that sits between front-end clients and back-end services. The BFF provides a client-specific API (aggregating, transforming, and authorizing calls) so the front-end does not talk directly to back-end services. When using OpenSpec in a multi-tier system, each tier (front-end, BFF, back-end) has its own openspec/ directory. Cross-tier contracts are recorded in ADRs. See OpenSpec Across Stacks.

BYOK (Bring Your Own Key)

A design principle where the tool uses the caller's model provider credentials rather than supplying its own. In the iec design, agent-assisted checks use BYOK via MCP: the user's agent connects to the MCP server and runs checks using its own model access. The tool never touches API keys directly.

Capability-class agent

A coding agent with reasoning, tool use, file editing, and a planning mode. The book targets this class rather than one vendor roster. Current time-bounded examples live in Tooling Landscape, while completion-only tools remain out of scope.

Change folder

The unit of work in OpenSpec: a directory under openspec/changes/ named with a slug matching the branch. Contains proposal.md, delta specs under specs/, tasks.md, and optionally design.md. Moves to openspec/changes/archive/ when the PR merges. See Spec Lifecycle.

CSRF (Cross-Site Request Forgery)

A web attack class in which an authenticated user's browser is induced to submit an unintended request to a site they are logged into. Defended against with CSRF tokens, same-site cookies, or origin checks. Listed in What the Scanners Miss.

CVE (Common Vulnerabilities and Exposures)

A public catalog of disclosed security flaws in software, each with a unique identifier (e.g. CVE-2026-12345). Dependency scanners flag direct and transitive dependencies that include packages with open CVEs. See What the Scanners Miss.

Cognitive debt

The agentic-era analogue to technical debt: undocumented decisions and assumptions developers hold implicitly but agents cannot read. Coined by ThoughtWorks Technology Radar Vol 34 (April 2026). See Why Structure Matters.

Sources: ThoughtWorks Technology Radar Vol 34 (April 2026), "cognitive debt" as the named agentic-era failure mode.

Context engineering

The practice of deliberately controlling what enters a model's context window: instructions, retrieved files, tool definitions, conversation history, and other task-relevant information. In this book, context engineering covers part of the Foundation and Agent Instructions work, but not the full Intent Engineering chain of specs, evidence, review, and durable decisions. See The Human-Agent Engineering Mindset.

Context poisoning

A failure mode in which stale, incorrect, or irrelevant documents loaded into the agent's context cause it to act on false premises. The agent treats provided context as authoritative, so an outdated architecture doc, a superseded spec, or wrong instruction files produce wrong output with apparent confidence. See When Intent Engineering Fails.

Dead spec

An un-archived OpenSpec change folder still sitting in openspec/changes/, marked in-flight, for a change that was implemented, abandoned, or pivoted away from. The agent loads it as current intent and acts on instructions that no longer apply. An un-archived spec is a live instruction, not a historical record. See Spec Lifecycle.

Diff

This book uses diff for the line-by-line source-control change set shown in a pull request. Where the distinction matters, code diff names the changed code itself, while diff view names the review surface that presents those changes. See Code Review for Agent-Generated Code.

Engineering memory

The durable codebase context developers and coding agents read before the next change: ADRs, architecture overview, design docs, diagrams, specs, contracts, README files, INDEX files, conventions, and agent instructions. ADRs record decisions inside engineering memory, but they are not the whole memory. See Intent Engineering and the SDLC.

Gherkin

The Given/When/Then (here WHEN/THEN) scenario notation from Cucumber, used in this book as a specification language for acceptance criteria, one scenario per behavior. OpenSpec prescribes the #### Scenario: heading and the WHEN/THEN body. The notation is borrowed. The BDD practice it originates from is not. See The Spectrum and AC IDs and Coverage.

Sources: Cucumber Gherkin reference (ongoing), the Given/When/Then scenario form. OpenSpec FAQ and docs (ongoing), the lightweight #### Scenario: / WHEN/THEN structure used in this book.

Greenfield

A new codebase, or one being built from explicit intent. Greenfield Intent Engineering adoption assumes you write AGENTS.md, ADRs, and specs from requirements, not from reverse-engineering existing code.

Golden test

A fixed, repeatable task with a known good output, used to detect regressions when something upstream changes. In this book, applied both to code (a stable input with an expected output) and to agent setups (a fixed task with structural properties the agent's output should satisfy). See Agent Evaluation and Regression.

GSD (Get Shit Done)

The lightest structured point on the spec-driven spectrum: structured prompting without a framework. Write a concise intent document, run the agent, commit. It produces a usable artifact but no archive, task log, or traceability trail, which makes it the practical alternative for teams whose risk profile does not warrant OpenSpec's overhead. See The Spectrum.

Hook

A deterministic script wired to a file-system or session event (post-edit, pre-commit, etc.) that runs automatically, independent of agent memory. Hooks enforce rules the agent might otherwise forget to apply. Stored in .agents/hooks/. Distinct from skills (invocable on demand) and instruction files (advisory). See Agent Instruction Hub.

iec

The companion CLI for this book (Intent Engineering Checker). Validates the structural conventions the book describes: docs/ layout, ADR format (MADR), AGENTS.md presence, AC ID traceability, and spec lifecycle. The companion repo also records the MCP/BYOK design for agent-assisted checks. Source at github.com/intent-engineering-for-coding-agents/cli. See Companion Repository.

Inner source

The practice of sharing .agents/ skill and instruction files across team boundaries within an organization, using the same contribution and review patterns as shared libraries. Teams publish useful skills to a shared repository. Other teams pull from it. This book treats packaging and versioning for .agents/ libraries as an unsettled practice in the mid-2026 snapshot. See Cross-Team Coordination.

Intent

What a developer encodes for a coding agent to act on. In this book, intent takes two forms: per-change specs that state what to build right now (the immediate intention), and the permanent architectural decisions and coded conventions that constrain how anything gets built. See Spec-Driven Development for the per-change form. See Foundation and Agent Instructions for the permanent substrate. See Intent Engineering.

Intent Engineering

Intent Engineering is presented here as a paradigm within agentic software engineering. It directs coding agents through maintained engineering intent: durable context and instructions, change-sized specs, evidence, and intent-first review. Prompt engineering remains one local technique inside this larger chain. See Introduction.

LeanSpec

A lightweight spec-driven development framework focused on small, focused specs (lean-spec.dev). Source for the small-spec discipline this book inherits.

Sources: LeanSpec (lean-spec.dev, ongoing), the small-spec framework this book cites as one point on the SDD spectrum.

LLM (Large Language Model)

This book uses LLM for the language model behind a coding agent. The term matters here only when the model is wrapped in tool use and project context.

Load clause

A condition line in an instruction file (or in AGENTS.md) that states when the agent should load it: for example, "Load when working on database migrations" or "Load before writing any spec." The TOC pattern depends on load clauses to enable selective loading. Without them the agent has no basis for choosing what to read and either loads everything or nothing. See AGENTS.md: The Entry Point.

MADR (Markdown Architectural Decision Record)

A specific Markdown template for ADRs developed by Oliver Kopp, Anita Armbruster, and Olaf Zimmermann (2018). Used in docs/decisions/ throughout this book. The structure (context, options, decision, consequences) makes ADRs scan-readable and machine-parseable.

Sources: Kopp, Armbruster, Zimmermann, MADR template and CEUR-WS paper (2018), the MADR format and its structure.

MCP (Model Context Protocol)

The agent-tool bridge protocol documented at modelcontextprotocol.io. In this book, the iec design uses MCP to expose agent-assisted checks through the user's own coding agent (BYOK: bring your own key).

Sources: Model Context Protocol (modelcontextprotocol.io, ongoing), MCP as the agent-tool bridge. intent-engineering-for-coding-agents/cli companion repo (ongoing), MCP used with BYOK in the companion design.

Mutation testing

A technique that introduces small, semantics-changing edits (mutations) into the code under test and re-runs the test suite. A mutation that stays green indicates a gap: the suite did not detect a wrong implementation. The kill rate is a feedback control on whether tests are evidence or decoration. See Tests as Evidence, Not Ritual.

OWASP (Open Worldwide Application Security Project)

A non-profit foundation publishing community-driven security resources for web applications. Best known for the OWASP Top 10, the ten most prevalent web application vulnerability classes. Used in this book as the after-gate review checklist. See What the Scanners Miss.

Sources: OWASP and OWASP Top 10 (ongoing), OWASP as the community-maintained security reference used in this book.

OpenSpec

A spec-driven-development framework (openspec.dev) built around a change-folder pattern: proposal.md, delta specs per capability under specs/, tasks.md, and optional design.md. On archive, delta specs are applied to the canonical openspec/specs/ and the full change folder moves to openspec/changes/archive/. The book uses OpenSpec end-to-end. iec is built with it.

Sources: OpenSpec (openspec.dev and GitHub repo, ongoing), the change-folder pattern and archive flow. intent-engineering-for-coding-agents/cli companion repo (ongoing), the book's worked OpenSpec example.

Prompt engineering

The practice of shaping one prompt or instruction exchange so a model responds usefully. Prompt engineering is a local technique within Intent Engineering. The wider paradigm maintains codebase context, specs, tests, decisions, and review across sessions. See Introduction.

skeleton.md

An agent-generated structural map of an existing codebase: modules, dependencies, data flow, business-rule outline, C4-style views. In this book, skeleton.md is the brownfield bootstrap map, not the file an agent should keep treating as current architecture forever. Its stable findings move into docs/architecture/, docs/design/, and docs/decisions/. After that, the skeleton becomes history or gets retired. See Brownfield vs Greenfield.

Skill

A named, reusable agent workflow stored as a Markdown file in .agents/skills/. Invocable via slash command (/draft-section) or an autonomous trigger in the agent instructions. A skill describes a multi-step procedure: what to load, what to do, what to produce. Distinct from an instruction file (standing rules) and a hook (fires automatically). See Agent Instruction Hub.

Spec

In this book's sense: the canonical specification of system behavior. Acceptance criteria, scenarios, test definitions. Lives under openspec/, written before implementation, archived after. Distinct from a design doc (which describes the approach) and an ADR (which records a decision).

SDD (Spec-Driven Development)

The practice of writing intent as structured, acceptance-criterion-tagged specifications before implementation. Specs are scoped to one change, archived after merge, and serve as the canonical acceptance criteria from which code is generated and checked. The durable source of truth for design is docs/, not the spec. One of the four topics in Intent Engineering. See Spec-Driven Development.

Test-type field

A Test-type: line placed in a spec scenario before the WHEN/THEN block, naming the category of test that verifies the scenario (e.g. unit, integration, e2e). Captures the intended test level at spec-authoring time so the agent generates the right kind of test. Resolved against the project's test strategy document at implementation time. See AC IDs and Coverage.

tasks.md

A checklist file inside an OpenSpec change folder that lists the implementation steps for a change. The agent checks off tasks as it completes them. A change folder with unchecked tasks should not have a PR open. See Document Types.

TBD (Trunk-Based Development)

A source-control discipline in which all developers commit to a single trunk branch frequently, using short-lived feature branches (often less than a day) and avoiding long-running parallel branches. Canonical reference: Paul Hammant, trunkbaseddevelopment.com. In the Intent Engineering context, an OpenSpec change folder maps onto one or two short-lived branches that carry its name: a spec branch followed by an implementation branch for decision-heavy changes, or a single branch when the intent is visible in the code diff. See PR Taxonomy and Trunk-Based Development with Agents.

Sources: Paul Hammant, trunkbaseddevelopment.com and "Trunk-Based Development and Branch by Abstraction" (2020), trunk-based development as the source-control discipline. The change-folder-to-branch mapping is this book's synthesis.

TOC pattern

The table-of-contents approach to writing AGENTS.md: a short file at the repo root that names the project, links to instruction files in .agents/instructions/ each with a clause saying when to load it, and lists available commands and skills. Contrast with loading all context into a single long file, which exhausts the token budget before the agent starts. Named by AgentPatterns.ai. See AGENTS.md: The Entry Point.

Sources: AgentPatterns.ai, "AGENTS.md: Project-Level README for AI Coding Agents" (last reviewed June 9, 2026), the TOC pattern naming and structure. Paula Hingel, "AI Agent Loop Token Costs: How to Constrain Context" (April 6, 2026), context growth as the cost argument behind keeping the entry file short.

Walking skeleton

A thin end-to-end implementation built forward to verify an architecture works. From Alistair Cockburn's "Crystal Clear" (2004). Etymological ancestor of the agentic-era skeleton.md, which reverses the direction by extracting the skeleton from existing code rather than building one forward.

Sources: Alistair Cockburn, "Crystal Clear" (2004), origin of the walking-skeleton pattern. The skeleton.md reversal described here is this book's synthesis.