04.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
// 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.
// 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 built with this methodology.
Ignix67, the platform we ship to clients in private beta, is itself built using Context-Driven Development. Every feature is a checklist plus step files plus ADRs. We dogfood the methodology so we know where it breaks before clients do.
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 →