Building a Developer Methodology as a Claude Code Plugin
I got tired of re-explaining my projects to my own development partner.
Every new Claude Code session starts from zero. Your AI doesn't remember what stage your project is in, what was decided last week, or what the team conventions are. You repeat yourself. Context gets lost. The AI gives generic advice because it has no specific grounding.
So I built a system to fix that — a Claude Code plugin called Dev Context Methodology that gives Claude structured, layered context about every project in my workspace. It tracks lifecycle stages, enforces quality gates, manages sprints, logs incidents, and generates cross-project insights.
This is the story of what I built, why, and what I learned about designing software for an AI consumer.
The Problem with Flat Context
Claude Code gives you CLAUDE.md — a markdown file where you can write instructions that get loaded at the start of every session. It's a good start. But as projects grow, a single file becomes a liability.
I had one CLAUDE.md that was 400 lines long. It covered build commands, architecture notes, coding conventions, debugging tips, and a running list of decisions we'd made over weeks of development. Every session, Claude loaded the whole thing. Most of it was irrelevant to the current task.
The real issue isn't the file — it's the assumption that context is flat. It's not. A prep cook needs the recipe, not the business plan. A sous chef needs the menu, not the inventory spreadsheet. Context should be scoped to the role and the moment.
What I needed was layers.
The Five-Layer Context Model
DCM organizes context into five layers, each answering a different question:
| Layer | Question | When Loaded |
|---|---|---|
| Identity | Who am I working with? | Always |
| Workspace | What environment is this? | Session start |
| Project | What project am I in? | When scoped to a project |
| Session | What am I working on right now? | When resuming work |
| Artifact | What file or component matters? | On demand |
The discipline is in the budget. Layers 0 through 2 — the ones that load every session — must stay under 2,000 tokens combined. That's roughly a page of text. Everything else loads on demand, only when relevant.
This matters because context costs tokens. Every word in your CLAUDE.md is a word Claude reads before it writes a single line of code. Managing context isn't housekeeping — it's engineering.
Here's what a workspace-level CLAUDE.md looks like after DCM generates it:
# My Workspace
Development workspace for web projects.
## Operating Rules
- Lazy loading: don't scan subdirectories on startup.
Only load files for the active project.
- Scoped operations: all file ops scoped to active project's directory.
## Working on a Project
1. Scope to project subdirectory
2. Read project's CLAUDE.md
3. Read .tracker/projects/<name>/CONTEXT.md for stage and to-dos
4. If project has .context/sessions/current.md: read for active task state
5. Limit file ops to project folder
6. Update tracker and session state as work progresses
Lean. Procedural. Claude knows exactly what to do when you say "work on wardstone" — and it doesn't load a single byte about wardstone until you ask.
Lifecycle as a Plugin
Every project follows the same lifecycle: Idea → Planning → Setup → Developing → Testing → Paused → Maintaining → Archived. These aren't labels — they're contracts.
Each stage has a gate: a checklist of criteria that must be true before you can advance. Here's what the Idea stage gate looks like:
# Stage 01: Idea
## Process
1. Write a clear project description (what it does, who it's for)
2. Identify the target audience
3. List key features and differentiators
4. Assess feasibility and effort at a high level
5. Make a go/no-go decision
## Gate — Exit Criteria
- [ ] Description written (what and why)
- [ ] Target audience identified
- [ ] Key features listed
- [ ] Go/no-go decision made and documented
And here's the Developing stage — where most of the work happens:
# Stage 04: Developing
## Gate — Exit Criteria
- [ ] All Must items are done
- [ ] All Should items are done or explicitly deferred with reasoning
- [ ] No active impediments
- [ ] Definition of Done met on all completed items
- [ ] Final retrospective completed (if sprints were used)
Why does this matter for AI? Because the stage tells Claude what kind of work is appropriate right now. In the Idea stage, brainstorm freely — explore, diverge, challenge assumptions. In the Testing stage, be rigorous and skeptical — no new features, no scope creep, just verify and ship.
Without stage awareness, every session is a blank slate. Claude doesn't know if you're exploring or shipping. With DCM, it checks the gate, sees where you are, and adjusts.
Hooks: The Nervous System
The context model and lifecycle stages are useful on their own. But they're just documents until something enforces them. That's what hooks do.
Claude Code hooks are shell scripts that fire automatically in response to events — session start, entering plan mode, making edits, running commands. DCM uses three event types:
{
"hooks": {
"SessionStart": [
{ "command": "session-start-router.sh" },
{ "command": "session-start-compliance.sh" },
{ "command": "session-start-scaffold.sh" }
],
"PreToolUse": [
{
"matcher": "EnterPlanMode",
"command": "pre-plan-context.sh"
}
],
"PostToolUse": [
{
"matcher": "Edit|Write",
"command": "post-edit-compliance.sh"
},
{
"matcher": "Bash",
"command": "post-commit-compliance.sh"
}
]
}
}
(Simplified for readability — the actual config uses full paths.)
When a session starts, the compliance hook checks the current project's gate progress and reports it:
[DCM] Gate: 3/8 complete for developing stage (5 remaining)
[DCM] No active sprint — 7 open backlog items. Use /track-sprint to create one.
When you enter plan mode, the context hook injects the project's current stage, active sprint, open to-dos, and recent incidents — so the planner has full situational awareness without having to ask.
When you commit code, the compliance hook checks the message format, reminds you to update sprint items, and logs benchmark events for metrics.
This is the key insight: hooks are what make methodology enforceable rather than aspirational. Without automation, a process document is a wish. With hooks, it's a nervous system — quiet when things are healthy, loud when something needs attention.
What I Learned
Building software for an AI consumer is a different discipline than building for humans.
The "UI" is structured text. There are no buttons, no forms, no visual hierarchy. Your interface is markdown that gets injected into a prompt. Clarity of structure isn't aesthetic — it's functional. A poorly formatted context file doesn't just look bad; it makes Claude misunderstand your project.
If you can't express it as concrete steps, the AI can't follow it. I started with vague instructions like "maintain code quality." Claude ignored them — not out of defiance, but because there's nothing actionable there. The stage contracts work because every gate criterion is a checkbox. Done or not done. No interpretation required.
Methodology without tooling is a wish. Tooling without methodology is chaos. You need both. I could have built the tracker without the lifecycle model, and it would have been a glorified to-do list. I could have written the methodology without hooks, and it would have been a document nobody reads. The combination is what makes it work.
There's a hospitality parallel here that I keep coming back to. In a professional kitchen, "standards" that only exist in the chef's head don't survive the first busy service. You need checklists. Station setups. Mise en place — everything in its place before the first ticket fires. DCM is mise en place for software development. The prep work that makes the actual cooking possible.
Try It Yourself
DCM is available as a Claude Code plugin. Add the marketplace and install:
claude plugin marketplace add alexshaddy/alexshaddy-plugins
claude plugin install dev-context-methodology
Then initialize your workspace:
/dev-context-init
The init skill creates your tracker structure, copies stage contract templates, and generates a workspace CLAUDE.md. From there, onboard your first project with /track-new and start working.
This is opinionated software built for one person's workflow. Fork it. Disagree with it. Build your own. The point isn't that my lifecycle stages are the right ones — it's that having structured context and automated enforcement fundamentally changes how you work with AI.
Closing
There's something strange and new about building tools for your own AI partner. You're not just writing software — you're shaping how an intelligence shows up in your workflow. The context you provide determines whether Claude is a generic assistant or a genuine collaborator who knows your projects, respects your process, and catches things you miss.
That's a new kind of software development. And it's worth thinking carefully about.
The best tools don't just help you work. They help you think about how you work.
View DCM on GitHub