top of page
Search

The Canonical Intent-Driven Engineering Repository

  • Writer: Mark Kendall
    Mark Kendall
  • 7 hours ago
  • 4 min read



The Canonical Intent-Driven Engineering Repository



The Repository Every New AI Project Should Start From





The Canonical Intent-Driven Engineering Repository



One of the questions I receive most often is surprisingly simple.


“Where do I start?”


Not:


“How do I prompt Claude?”


Not:


“How do I use MCP?”


Not:


“How do I write better agents?”


Instead…


“What should my repository actually look like?”


After building numerous AI-enabled delivery projects and experimenting with different layouts, I’ve settled on a structure that consistently scales—from a single developer to enterprise teams.


This article describes that repository.


Think of it as the official starting point for Intent-Driven Engineering.





Philosophy First



Traditional projects begin with code.


Intent-Driven Engineering begins with understanding.


The repository is organized so that every AI system—Claude Code, Codex, Gemini CLI, Cursor, or future models—can answer four questions before writing a single line of code:


  • Why are we building this?

  • What already exists?

  • What constraints must never be violated?

  • What exactly should happen next?



Everything else is secondary.





Repository Layout


project-root/



.claude/

    CLAUDE.md

    settings.json


intent/

    backlog/

    completed/


context/


skills/


agents/

    qa.md


hooks/

    pre-pr.md


templates/


docs/

    decisions/

    diagrams/


src/


tests/


.github/

    workflows/

Notice something important.


There is very little magic.


Most of the repository is simply organized knowledge.







The README isn’t for GitHub.


It’s for humans and AI.


It should answer:


  • What does this system do?

  • How do I run it?

  • How do I contribute?

  • Where is the intent?



Example

# Customer Portal


Purpose


Modern customer self-service portal.


Primary Intent


See intent/current-feature.md


Architecture


See context/architecture.md


Development


Use Claude Code or your preferred AI coding assistant.





.claude/



This is where Claude-specific configuration lives.

.claude/



settings.json

This directory contains instructions specific to Claude Code.


The rest of the repository remains model-agnostic.


That separation is important.


It means another AI assistant can be swapped in later without reorganizing the project.







Claude should immediately understand:


  • coding standards

  • testing philosophy

  • branching strategy

  • architecture rules

  • forbidden patterns



Example

Never bypass authentication.


Always write tests.


Never duplicate business rules.


Follow repository architecture.


Read current-feature.md before implementing.

Nothing here should describe a feature.


It describes how the AI behaves inside the repository.





intent/



This is the heart of the repository.

intent/




backlog/


completed/

Every implementation starts here.







This document rarely changes.


It answers:


Why does this system exist?


Example

Purpose


Enable customers to manage insurance policies online.


Business Goals


Reduce call center volume


Increase self-service


Improve customer satisfaction







This is what the AI works from.


It replaces enormous prompts.


Example

Feature


Customer Notification Preferences


Business Outcome


Reduce support calls.


Requirements


Allow email preferences


Allow SMS preferences


Persist selections


Constraints


Do not break existing notifications.


Must follow current architecture.


Success Criteria


Existing tests pass.


New integration tests added.

This single document becomes the implementation contract.





context/



Large language models need context.


Not prompts.


Context.


Store permanent project knowledge here.





These documents evolve slowly.


They’re referenced repeatedly.







Describe:


  • major services

  • APIs

  • databases

  • event flows

  • deployment



No implementation details.


Only architecture.







The rules developers constantly forget.


Examples

Premium customers receive priority processing.


Claims older than 90 days require supervisor approval.


Notifications must be logged.







Enterprise language matters.

Subscriber


Policy


Coverage


Agent


Beneficiary

AI should never invent terminology.





skills/



Skills encapsulate repeatable expertise.


Examples




Each skill performs one job exceptionally well.


Small.


Focused.


Reusable.





agents/



Agents coordinate work.


Example


Planner



Developer



Reviewer



QA


Each has one responsibility.


No giant super-agent.





hooks/



Hooks enforce consistency automatically.


Examples


Before implementation:


  • Validate intent

  • Check architecture



Before PR:


  • Run tests

  • Verify documentation

  • Update changelog



Hooks eliminate forgotten steps.





templates/



Never start with a blank document.


Provide templates for:


Feature


Bug


Architecture Decision


API


Database Change


Consistency compounds over time.





docs/



Architecture Decision Records


Design discussions


Reference diagrams


Meeting outcomes


These are long-lived organizational memory—not prompts.





src/



Your application code.


Notice how little attention we’ve given it.


That’s intentional.


The code is an output of the repository, not its organizing principle.





tests/



Every feature should include:


  • Unit tests

  • Integration tests

  • End-to-end tests (when appropriate)



Intent without verification is just documentation.





GitHub Actions



Automate everything possible.


Examples:


  • Intent validation

  • Linting

  • Test execution

  • Security scanning

  • Documentation verification



AI should spend its time solving problems, not remembering checklists.





The Development Workflow



Every feature follows the same lifecycle:


  1. Capture the business intent.

  2. Refine it into intent/current-feature.md.

  3. Review architecture and business context.

  4. Plan the implementation.

  5. Generate code.

  6. Run automated validation.

  7. Review and improve.

  8. Open a pull request.

  9. Merge only after governance checks pass.

  10. Archive the completed intent into intent/completed/.



Notice that prompts are never the primary artifact.


Intent is.





Why This Structure Works



This repository separates stable knowledge from changing work:


  • Intent defines what is being built.

  • Context explains why and how the system works.

  • Skills encode reusable expertise.

  • Agents coordinate specialized work.

  • Hooks enforce quality automatically.

  • Source code becomes the product of this process, not the starting point.



Because these responsibilities are clearly separated, any capable AI coding assistant—not just Claude Code—can understand the project with minimal prompting and produce more consistent, maintainable results.





Clone This Repository and Build



If you’re starting a new AI-enabled software project today, don’t begin with src/.


Begin with intent.


Create the repository structure first. Capture the business outcome before the implementation details. Give your AI assistants durable context instead of rewriting the same prompts every day.


Software projects have always had source code.


The next generation of projects will have source intent.


And that may become the most valuable asset in the entire repository.





 
 
 

Recent Posts

See All
Stop Asking Every Developer to Become an AI Expert

Stop Asking Every Developer to Become an AI Expert Why Enterprise AI Adoption Depends on a Layered Operating Model Over the past several months, I’ve had the opportunity to work with engineering organ

 
 
 

Comments

Rated 0 out of 5 stars.
No ratings yet

Add a rating
Post: Blog2_Post

Subscribe Form

Thanks for submitting!

©2020 by LearnTeachMaster DevOps. Proudly created with Wix.com

bottom of page