Viksya › AI-DLC TRACK · Practitioner Playbook

AI-DLC Context Engineering Playbook

Every Bolt is only as good as the context the AI was given. Is anyone actually building it?

AI-DLC's velocity claims rest on one assumption: that the AI plans and proposes correctly on the first pass. Whether it does is determined almost entirely by the quality of the context it receives — and under traditional methodologies, that knowledge lived informally in people's heads and was never a named responsibility. This playbook treats context engineering as a first-class AI-DLC discipline: five knowledge artifact types, file design patterns, a brownfield extraction method, four anti-patterns, a governance model, a full worked example, and five ready-to-use templates an engineering lead can put to use within the hour.

11 Sections5 Artifact Types5 Ready-to-Use TemplatesWorked ExamplePDF PlaybookFree Companion Skill
Get Instant Access
AI-DLC Context Engineering Playbook
$49 USD · one-time purchase

Delivered as a typeset PDF playbook. Download immediately after purchase.

Format PDF  ·  Sections 11  ·  Templates 5 Included
Get the Context Engineering Playbook → ← Back to all tools

■ Instant download  ·  ■ No software required  ·  ■ Read on any device

Quick Answer

The AI-DLC Context Engineering Playbook is a practitioner guide defining context engineering as a named AI-DLC discipline. It sets out five knowledge artifact types — Design, Architecture, Product, Conventions, and Domain — a recommended file structure (YAML frontmatter plus structured markdown), a brownfield extraction method for teams without existing artifacts, four anti-patterns that quietly degrade AI output (context bloat, stale context, sprawl, and missing domain context), a governance model with named ownership, a full worked example across Inception, Construction, and Operations, and five ready-to-use templates. It is complemented by a free companion agent skill, the AI-DLC Context Pack Builder, which assembles a single Bolt's context pack with an automated pass/fail quality gate.

The Problem

Poor context doesn’t announce itself. It shows up disguised as other problems.

Ritual cadence and governance gate design can be adapted from disciplines an organisation already knows. Context engineering cannot — the knowledge an AI now needs used to live informally in people's heads, transmitted through conversation and time served on the team. Under AI-DLC, that knowledge has to become a written, owned, and maintained artifact, or the AI is guessing.

🔄
ReworkAI proposals fail the human validation gate not because the AI reasoned badly, but because it reasoned from missing or wrong premises — the single largest driver of Rework Rate.
🏗️
Hallucinated architectureAbsent an authoritative Architecture artifact, the AI infers structure from whatever code it can see, and proposes designs that violate boundaries the organisation already paid for.
🔁
Repeated re-explanationWithout persistent artifacts, every session and every new team member re-derives the same background from scratch — paid for repeatedly in the most expensive synchronous time the methodology consumes.
👁
Erosion of trustWhen AI output is repeatedly wrong for context reasons, teams stop distinguishing ‘the AI is unreliable’ from ‘we fed it stale information’ — and drift toward the AI-assisted anti-pattern.

The practical test: if a competent engineer joining the team tomorrow could not answer a question from the written context artifacts alone, neither can the AI — and the AI hits that gap on every single Bolt, not once per new joiner.

The Framework

Five artifact types. One density principle. A named owner for each.

The playbook organises persistent context into five artifact types, each with a different natural owner, update rhythm, and failure mode when neglected. Collapsing them into a single “project context” document is the fastest route to the bloat and sprawl anti-patterns covered in Section 6.

The Five Knowledge Artifact Types · Section 2
01
DesignUI/UX decisions, interaction patterns, style guidance — owned by the Product Designer or UX Lead
Reviewed each Inception
02
ArchitectureSystem structure, component boundaries, integration patterns and the reasoning behind them — owned by the Architect or Engineering Lead
Reviewed per Bolt
03
ProductBusiness intent, user needs, success criteria, explicit out-of-scope decisions — owned by the Product Owner
Each Intent & Mob Elaboration
04
ConventionsCoding standards, naming, testing patterns actually enforced — owned by the Engineering Lead / senior developers
Audited quarterly
05
DomainBusiness-domain terminology, rules, and constraints — owned by the Business Analyst or domain SME
Reviewed each Inception

The semantics-per-token principle. Context quality is not volume, it is information density — the amount of decision-relevant meaning carried per token the AI must process. When in doubt about whether something belongs in a context artifact, the question is not “is this true?” but “would this change what the AI proposes?” If it would not, it is dilution.

Key Terms
Context Steward
A team-level role, often rotating or shared, accountable for the health of the context system as a whole: coverage across all five types, freshness discipline, and resolution of contradictions between artifacts. Works alongside the AI-DLC Coach.
Freshness Window
The period an artifact may go unreviewed before it is treated as suspect, declared in its own frontmatter and set by volatility rather than uniformly — the same window the Governance & Metrics Dashboard's Context Currency indicator tracks.
What’s Inside

Every section, explained.

One PDF playbook, 11 sections, structured to be read once in full and then used as a standing reference.

SEC 1
Introduction
Why context engineering is a named discipline, the cost of poor context, the semantics-per-token principle, ownership
SEC 2
Five Knowledge Artifact Types
Design, Architecture, Product, Conventions, Domain — each with well-formed and poorly-formed examples
SEC 3
The Context Lifecycle
Capture at Inception, near-real-time enrichment at Construction, accumulation at Operations, and persistence
SEC 4
Context File Design Patterns
YAML frontmatter plus structured markdown, naming conventions, versioning, freshness management
SEC 5
Brownfield Context Extraction
A structured four-step extraction approach, and the common traps that undermine it
SEC 6
Anti-Patterns
Context bloat, stale context, context sprawl, missing domain context — symptoms, causes, detection, correction
SEC 7
Governance of Context Artifacts
Ownership assignment, review cadence linked to gate design, audit trail
SEC 8
Worked Example
One Unit of Work followed end to end — the artifacts touched at Inception, Construction, and Operations
SEC 9
Maturity Checklist
A qualitative self-assessment across artifact coverage, ownership, freshness, and brownfield readiness
SEC 10
Templates Appendix
Five ready-to-use context file templates, one per artifact type, copy-paste ready
SEC 11
Cross-References
How this playbook connects to the Dictionary, the free Context Pack Builder skill, Maturity Model, Governance Dashboard, and RACI template
4
Anti-patterns diagnosed — bloat, staleness, sprawl, missing domain context
5
Copy-paste templates, one per artifact type, following the Section 4 frontmatter pattern
1
Full worked example tracing a single Unit of Work across all three AI-DLC phases
15
Maturity checklist items across four categories, for a team working session
Compared

Context Engineering Playbook vs. the rest of the AI-DLC line.

This playbook defines one specific discipline in depth. It is distinct from the vocabulary reference, the operational tracker, and the periodic maturity diagnostic — each answers a different question.

InstrumentQuestion It AnswersFormat
AI-DLC Context Pack Builder (Skill)What's the minimum sufficient context for this one Bolt?Free agent skill
AI-DLC Dictionary of TermsWhat does this term mean?Free web reference
Context Engineering PlaybookHow do we build and govern the context AI-DLC depends on, across every Bolt?PDF playbook
AI-DLC Governance & Metrics DashboardIs anything wrong right now, including context currency?Excel workbook
AI-DLC Maturity Model & BenchmarkingHow mature is our context management overall?Excel workbook (not yet published)
Companion Skill · Free

Not every Bolt needs this playbook’s full depth. Some just need one page, done right.

The AI-DLC Context Pack Builder is a free agent skill Viksya publishes alongside this playbook. It walks you through assembling a single Context Pack for one Bolt or Unit of Work — Intent, scope boundary, architecture touchpoints, contracts and constraints, definition of done, and references — then audits it in both directions against a pass/fail quality gate and won't hand it over until it passes. It is deliberately thin: the assembly procedure and the quality gate, nothing more.

Use the free skill when…You need one Bolt's Context Pack assembled and pass/fail-checked right now, in Claude Code or any agent harness that reads a system prompt.
📖
Use this playbook when…You're building the standing context an entire team or programme relies on across every Bolt — including brownfield extraction, the anti-pattern catalogue, and a governance model.
🔄
Move from skill to playbook when…The skill surfaces a hard case it deliberately won't solve — multi-team context, legacy systems, conflicting constraints — that's this playbook's job.
Who It’s For

For whoever has to make the AI's first proposal the right one.

Engineering Leads & Architects

Structure the Architecture and Conventions artifacts that determine whether AI-proposed code fits the system.

AI-DLC Coaches & Context Stewards

Own the cross-cutting health of the context system — coverage, freshness, and resolving contradictions between artifacts.

Business Analysts & Domain SMEs

Build the Domain artifact that keeps AI output commercially and operationally correct, not just technically correct.

Product Owners

Maintain the Product artifact that anchors every Unit of Work to business intent and explicit out-of-scope decisions.

Teams Inheriting Brownfield Codebases

Follow the structured extraction method in Section 5 instead of assuming the AI can infer years of undocumented decisions.

Key Features

What makes this a practitioner playbook, not a documentation policy.

Well-Formed vs. Poorly-Formed ExamplesEvery one of the five artifact types is illustrated with a concrete well-formed entry and a poorly-formed one, side by side, not abstract guidance.
Five Ready-to-Use TemplatesCopy-paste YAML-frontmatter templates for all five artifact types, following the recommended naming and versioning pattern.
Brownfield Extraction MethodA bounded, four-step approach — static analysis, historical mining, structured interviews, validation — for teams that inherited undocumented systems.
Four Anti-Patterns, Fully DiagnosedEach anti-pattern is broken down into what it looks like, why it happens, how to detect it, and how to correct it.
Full Worked ExampleOne feature followed end to end across Inception, Construction, and Operations, showing exactly which artifacts change and what a well-formed entry looks like.
Direct Line to the Governance DashboardThe freshness window and Context Currency indicator defined here are the same ones configured in the Governance & Metrics Dashboard's Settings tab.
No Software RequiredA reference document, not a tool — read it, apply the templates directly in your own repository.
Maturity Checklist IncludedA 15-item qualitative self-assessment across four categories, designed for a team working session rather than a scored audit.
Scope

What this playbook is not.

This is a practitioner instruction manual for one AI-DLC discipline. It is not a scored diagnostic, a governance-assignment tool, a vocabulary reference in its own right, or the free single-Bolt skill.

🚫
Not a scored assessmentIt does not benchmark or score a team's context maturity. That is the qualitative checklist's role here, and the scored, benchmarked counterpart is the AI-DLC Maturity Model & Benchmarking Tool.
🚫
Not a governance-assignment toolIt defines what ownership looks like, but formal RACI assignment belongs in the RACI & Governance Gate Design Template.
🚫
Not a terminology dictionaryIt uses AI-DLC vocabulary throughout but is not the authoritative definitions source — that is the free AI-DLC Dictionary of Terms.
🚫
Not a recurring trackerContext currency is measured over time in the Governance & Metrics Dashboard, not in this playbook.
🚫
Not the free single-Bolt skillFor one Bolt's Context Pack with an automated pass/fail gate, use the free AI-DLC Context Pack Builder skill — this playbook is the deeper, standing-practice counterpart it points to for hard cases.
Technical Requirements

What you need to use it.

PDF Reader
Any current PDF viewer, desktop or mobile — no other software required
Not Required
No spreadsheet software, macros, or installation of any kind
Version Control
Recommended for using the five templates as intended — a Git repository or equivalent
One-Time
Purchase — instant download, yours to keep and adapt for internal use
Frequently Asked

Questions buyers ask before their first artifact.

We're greenfield. Is the brownfield extraction section still relevant?

Read it anyway. The four-step approach — static analysis, historical mining, interviews, validation — is written for inherited systems, but the underlying discipline of deliberately building context rather than assuming it applies from day one on a greenfield project too.

What's the difference between this playbook and the free AI-DLC Context Pack Builder skill?

The free skill assembles one Bolt's Context Pack — Intent, scope boundary, architecture touchpoints, contracts and constraints, definition of done, and references — and audits it against a pass/fail quality gate before you start. It is deliberately thin: procedure and gate, nothing more. This playbook is the standing, org-level counterpart: the five artifact types as living team artifacts, file design patterns, brownfield extraction, the full anti-pattern catalogue, and a governance model that survives across every Bolt, not just the one in front of you. Teams who hit a hard case with the skill — multi-team context, legacy systems, conflicting constraints — are exactly who this playbook is for.

How long before a team can produce its first context artifact?

The playbook is written so an engineering lead can structure a team's first artifact within the hour: Section 2 defines what to build, Section 4 defines how to structure it, and the Templates Appendix provides copy-paste starting points.

Do we need all five artifact types from day one?

Coverage should match where Bolts are currently running — the maturity checklist in Section 9 frames this as “all five types exist for every scope where Bolts are running,” not every scope in the organisation. Expand coverage as delivery expands.

How does this relate to the Governance & Metrics Dashboard we already use?

Directly. The Context/Knowledge Artifact Currency indicator in that dashboard tracks the same freshness window this playbook defines in artifact frontmatter (Section 4.4) — a declining currency reading there is the earliest observable signal of the stale-context anti-pattern this playbook diagnoses in Section 6.

Is this only for engineering roles?

No. The Domain and Product artifacts are explicitly designed to be owned by Business Analysts, domain SMEs, and Product Owners — the playbook treats missing domain context as one of the most common and most damaging anti-patterns precisely because it is often left to engineers by default.

What format does it come in, and can I use it internally?

A typeset PDF, delivered as an instant download. It is yours to keep and use for internal team reference and onboarding; it is not licensed for resale or redistribution as a standalone product.

Give the AI something real to reason from.

Structure your first context artifact this week, using the templates and worked example inside.

■ Instant download  ·  ■ PDF playbook  ·  ■ Yours to adapt for internal use

Get the Context Engineering Playbook →