Repo-as-context + the foundational triplet

Why this is Week 1

The single biggest leverage point in AI-native engineering isn’t the AI — it’s where your team’s context lives. If strategy docs are in SharePoint, specs in Word, decisions in Confluence, planning in Jira, meeting notes in OneNote, and tickets in Notion, then every AI session starts from zero. The AI can’t read your context, so you re-explain it every time. That re-explanation cost is what caps most teams at “Claude is occasionally helpful” instead of “Claude is how we ship.”

The flip: context exists for the AI to consume, not for humans to browse. When that flip lands, every other shift in the bootcamp gets easier — because the substrate is now something an AI can actually read.

This week installs three connected principles and one weekly ritual. None of them require new tooling beyond Claude Code and a git repo. Tooling lands in Week 2.

Principle 1 — Repo-as-context

Everything for the AI, not for humans. Strategy, specs, decisions, planning notes, architecture diagrams, onboarding docs, runbooks — all as markdown in the monorepo (or a dedicated docs repo if your monorepo doesn’t exist yet).

Concretely, this means:

• No more SharePoint sites for engineering docs.
• No more Word / OneDrive / Google Docs / Notion for specs.
• No more PowerPoint for technical decisions.
• No more “ask in Slack and someone will dig it up.”
• One repo. Markdown. AI-readable. Human-readable too — but humans are the secondary audience.

The conventional objection is “but humans need to browse this.” Two answers. First, modern devs read markdown in their IDE/editor without friction. Second, when humans do need to read it, they can ask Claude — which will summarise, cross-reference, and answer specific questions better than any wiki search ever did.

What goes out of the repo: anything truly ephemeral (active Slack chatter, calendar events, one-off Loom links). What goes in: anything someone might want to reference more than once, or that the AI needs to do its job.

Principle 2 — Compressed planning cadence

The conventional cadence is quarterly OKRs → sprint planning → daily standup. Each layer adds latency. By the time a quarter’s plan reaches a working stream, the world has moved.

AI-native teams compress this. The artefact that does most of the work is a single NEXT-STEPS.md file in the relevant directory of the repo. It contains:

• What we’re working on right now (this week).
• What’s queued for next (rough order, not commitment).
• What we’ve decided not to do, and why (so the question doesn’t re-open).
• The big rocks (quarter-ish horizon), updated as understanding shifts.

This becomes the single source of truth for “what’s the state of this work-stream?” — for you, for your teammates, and for any Claude session you spin up against the repo. Jira, if you keep it, becomes downstream of NEXT-STEPS.md.

Update cadence: weekly at minimum, day-by-day if a stream is hot. The Friday demo + weekly planning ritual (below) is where the weekly update happens reliably.

Principle 3 — Meetings exist for the transcript

The third leg of the foundational triplet, and the one that changes how teams hold meetings.

Traditional framing: a meeting exists for the conversation; notes (if any) are a side-effect. AI-native framing: we come together to talk for the purpose of the transcript — the transcript exists for the AI.

Practical implication, this week (principle only — tooling is Week 2):

• Decide which meetings should be transcribed. Anything where decisions, design discussion, or architectural context happens. Skip standup-style status meetings.
• Decide where transcripts will live in the repo (suggested: docs/meetings/YYYY-MM-DD-{topic}.md).
• Decide who’s allowed to record — especially with external partners, customers, vendors. Get the policy agreement done before you install the tooling.

Week 2 installs the transcription pipeline itself (local Whisper — the why and how). Week 1’s job is the principle and the policy.

The ritual — Friday demo + weekly planning

One hour. End of every Friday. Each engineer on the team:

1. Demo what shipped this week (5–10 minutes per person). Working software, not slides. If nothing shipped, say so — that’s information.
2. Update NEXT-STEPS.md for the coming week (right there in the meeting, on screen). What’s on, what’s queued, what shifted.
3. Surface anything that’s stuck — especially anything that’s waiting on another team or person, and any decision that needs broader input.

This is the cadence the running-stage practice actually runs on. Once it’s installed, you’ll stop needing daily standup, sprint planning, and most one-off coordination meetings — because the Friday demo + planning meeting is where the team converges, and NEXT-STEPS.md is where async coordination happens between Fridays.

Installed by end of Week 1, run every Friday thereafter through Week 6 and forever after that. The compounding only starts when the ritual is reflexive, not when it’s an exercise.

This week’s assignment

One concrete migration. One ritual installed. Both done on your real repo, not a sandbox.

Self-check — did this week land?

Honest answers, not aspirational ones. If most of these are “not yet,” do the assignments again next week before moving on — the rest of the course compounds on this substrate.

• Can you point to at least one document that used to live outside the repo and now lives inside it as markdown?
• Have you used Claude with the migrated document as context, and got value out of it without re-explaining anything?
• Does NEXT-STEPS.md exist in your work-stream, committed to the repo, with current state?
• Did you run a Friday demo + planning meeting using the three-step structure? (If not, run it before reading Week 2.)
• Has the team (or you, if solo) agreed which meetings will be transcribed and where transcripts will live, even though the tooling isn’t installed yet?

Why we’re not yet installing tooling

You may notice this week is mostly principles, not commands. That’s deliberate. Tooling without the principle leads to a team with a Whisper install and a NEXT-STEPS.md template nobody updates. The order matters: principle & ritual first (this week), then the tooling that makes the principle scale (next week).

Week 2 is “the new operating routines” — transcription pipeline, browser automation, deploy-to-prod as one skill, reflexive GitHub admin, environment hygiene. Six things your team stops doing manually.