What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
What is your developer-dependent CMS actually costing you? Calculate your costs and get a full report
Vibe Coding
Set up one Markdown repo that people and AI agents share as the source of truth across all your Agility projects: layout, front matter, routines agents can run, and the habits that keep it current.
When every developer manages a team of agents, the agents need shared memory across projects. An ops repo is that memory: one Git repo, mostly Markdown, that people and agents read and update as the source of truth for all your Agility work.
Each project repo holds that project's detail. The ops repo holds the portfolio: what's in flight, what stage each project is at, what you've learned, and how you do things. Any agent session opens it, reads the rules in CLAUDE.md (or AGENTS.md), and updates the dashboard or starts a new project the same way everyone else does.
This article is part of the Vibe Coding with Agility section.
2026-10-29), never "last week". Agents read these files months later.ops/
├── CLAUDE.md the routines every agent session follows
├── README.md "if you want to… go to…"
├── DASHBOARD.md one row per project: status, owner, next action
├── INBOX.md quick capture, triaged later
├── projects/<slug>.md one page per project, with front matter
├── playbooks/ how-to by stage: new project, demo, handoff
├── knowledge/ gotchas, MCP rules, integrations, decisions
├── starter/ your reference implementation: capabilities, drift, backlog
├── templates/ project page, intake, demo script, debrief
└── log/ append-only logs
Each project page starts with front matter an agent can read and update:
---
slug: acme-site
status: building # intake | discovery | building | demo-ready | live | handed-off | archived
owner: Jane Smith (Lead Developer)
repo: https://github.com/<org>/acme-site
instance_guid: 1234abcd-u
last_activity: 2026-10-29
---
CLAUDE.md turns the repo into something agents can run. Write each recurring job as a numbered routine:
**When a project changes stage:**
1. Update projects/<slug>.md (front matter, snapshot, a dated log line).
2. Update its row in DASHBOARD.md.
3. Post a short note to the CRM or ticket, if you use one.
4. New traps go in knowledge/gotchas.md; reusable code goes in starter/backlog.md.
5. Commit and push.
**"Sweep the projects"** (weekly):
1. `gh repo list <org>`; any repo without a page gets one.
2. For each repo: last commit, uncommitted work, new docs since last_activity.
3. Check the reference implementation's history; update the drift table.
4. Summarize what changed and list questions only a person can answer. Commit.
Also write down what agents must never do on their own, such as changing a deal's stage or posting anything customer-facing without a person reviewing it first.
README.md and CLAUDE.md from these rules, adapted to your stages.knowledge/gotchas.md from MCP and Agility Gotchas and your own history.