02.methodology

AI-first context-driven development

The methodology we use, teach, and licence inside engagements. Stack-agnostic, tool-agnostic, and built so AI-assisted delivery stays reviewable, auditable, and accountable to the engineers reading the diff.

// premise

The premise.

Generic AI-assisted development fails for the same reason generic test frameworks failed a decade ago: it doesn't know your codebase, your conventions, your domain invariants, or your review culture. Every shop pretends those don't matter, then re-discovers that they do — usually after an agent merges something the senior engineers would have caught.

Context-Driven Development is the operational answer: ground every agent and every workflow in the team's actual context — code, conventions, review history, runbooks, ADRs — and design the SDLC around the assumption that the AI is a junior engineer with infinite memory and zero judgement, not a senior one with both.

01.layered-context

Layered context

AI agents work better when their context is built in layers — auto-loaded rules, session bootstrap, execution protocol, the step file in front of them. Each layer answers a different question, and the agent never has to guess what the team has already decided.

  • Auto-loaded rules (CLAUDE.md / .github/copilot-instructions.md) — tripwires loaded every turn
  • Session bootstrap — read-once-per-session orientation
  • Execution protocol — TDD loop, task classification, reporting format
  • The step file — the work order itself, with concrete acceptance criteria

02.rule-hierarchy

Rule hierarchy

When guidance conflicts, priority is unambiguous. Tripwires beat ADRs; ADRs beat methodology; methodology beats step-file specifics. The agent is told the priority order up front, so a step file can specialise but cannot override an architectural decision.

  • Tripwires (in CLAUDE.md) — never overridden
  • ADRs — architectural constraints; override methodology suggestions
  • Methodology — the default recipe; specialised by step files
  • Step file — task-level details, within the rules above

03.checklists-and-steps

Checklists + step files

Work is organised as one checklist per feature plus a folder of granular step files. The checklist is the source of truth — the AI ticks it as it works, and the step files give it just enough detail to execute one bounded change at a time without losing the bigger picture.

  • One feature = one checklist + one steps folder + one architecture overview
  • Step file sections — Goal, Track, What Exists, What to Build, Acceptance Criteria, References
  • Architectural decisions live in ADRs, not in code comments
  • Completed work archives cleanly; nothing is lost in commit history

04.bootstrap-to-steady-state

Bootstrap → Steady state

Methodology has two operational modes. Bootstrap is one-time — Discovery, Interview, Apply, with a hard human gate between each phase — and produces the rules, ADRs, and recipes the team will live with. Steady state is checklist-by-checklist execution after that. The most common failure mode is mixing them: bootstrap with creative latitude (ADRs you didn't ask for) or steady-state without rules (the agent re-deciding settled questions every session).

  • Discovery — read-only scan; factual placeholders only
  • Interview — AI proposes; human accepts or rejects each item
  • Apply — strict write of approved values; zero creative latitude
  • Steady state — one feature, one checklist; the AI ticks through

// anatomy of a session

Anatomy of a session.

Each session assembles its working context in layers. Lower layers are universal; higher layers narrow to the task in hand. The agent never has to guess which guidance applies — the layers are explicit.

LAYER 0 ─ ALWAYS PRESENT (auto-loaded)
  CLAUDE.md / .github/copilot-instructions.md
  Hard rules. Every turn.
       │
       ▼
LAYER 1 ─ SESSION BOOTSTRAP (once per session)
  prompts/session-start.md
  Project awareness — what's decided, what exists, what's active.
       │
       ▼
LAYER 2 ─ METHODOLOGY (the recipe)
  docs/methodology/*.md
  Process — HOW to build.
       │
       ▼
LAYER 3 ─ STEP FILE (the work order)
  ongoing-tasks/{feature}/NN-*.md
  Goal · Track · What Exists · What to Build · Acceptance · References

// tool-agnostic

Tool-agnostic by design.

Context-Driven Development is not tied to a single AI vendor. The auto-loaded rules file lives at the path each tool expects — CLAUDE.md for Claude Code, .github/copilot-instructions.md for GitHub Copilot, and the same content mirrored for Cursor, Aider, and Continue. Your team picks the tool; the methodology travels.

// templated

Templated, not bespoke.

This isn't an idea — it's a template repo. CLAUDE.md, the prompts directory, the bootstrap phases, the step-file structure — all of it is a working scaffold.

We use the template internally on every engagement, and engagements include access to it. The methodology travels with the team after we leave.

// in services

How it shows up in engagements.

Every consulting engagement starts with a context diagnostic, not a tooling selection. The roadmap, the agents we deploy, and the review changes we recommend all flow from what we learn about your team's actual context.

Read more about engagements →

// how we use it

Ignix67 is one product built this way.

Your stack is another. Ignix67 — the platform we deliver to clients in private beta — is one example of Context-Driven Development applied end-to-end, but the methodology is stack-agnostic by design. Engagements take the methodology to whatever your team already builds in.

See the platform →

// next step

Want to see the methodology applied to your team? We'll start with a brief diagnostic and tell you, candidly, whether we're the right people to help.

Talk to us →