The new operating routines — what you stop doing manually

Why this is Week 2

You can install Week 1’s principles — repo-as-context, compressed planning, meetings-for-the-transcript — and still be a team that does most of the actual work by hand. The principles tell you where context lives. They don’t yet free up the operational hours that compound into throughput.

Week 2 is the “what you stop doing by hand” week. Four routines, each one removing a class of recurring overhead. None are exotic. None require special tooling beyond Claude Code and what your dev environment already has. All of them need policy commitment from you (or your team) more than they need technical work.

The cumulative effect: by end of Week 2, you should be doing noticeably less hand-clicking, hand-deploying, hand-meeting-note-taking, and hand-git-management than you were two weeks ago. The hours you free up are what makes Week 3’s 10×-everything work possible.

Routine 1 — The transcription pipeline

Week 1 established the principle: meetings exist for the transcript. This week installs the pipeline so that principle doesn’t cost anyone an hour of typing per meeting.

What you’re installing:

• Local recording on the meeting host’s machine (Zoom local recording, Teams local capture, or a simple QuickTime / OBS audio capture for unscheduled calls).
• Local Whisper transcription — either via My Transcriber (free local app, drag-and-drop, 99+ languages, GPU-accelerated on Apple Silicon), or via whisper.cpp / openai-whisper if you prefer a CLI.
• A repo convention for where transcripts land (suggested: docs/meetings/YYYY-MM-DD-{topic}.md).
• The hand-off pattern: after each meeting, transcript gets committed to the repo and is then available as Claude context for whatever follow-up work the meeting spawned.

Why local Whisper, not Teams / Zoom built-in?

• Quality. OpenAI’s Whisper large-v3 (and v3-turbo) consistently outperform Teams’ built-in on accented speech, multi-language content, and overlapping voices. The gap matters when the transcript becomes Claude context — bad transcripts produce bad downstream work.
• Privacy. Local means audio never leaves the laptop. Important for sensitive discussions, partner conversations, anything you can’t put through a third-party cloud transcription service.
• Speaker labels. Whisper without diarization gives one long transcript without speaker names. For internal meetings this is usually fine (you can infer from content). For multi-party calls where speaker attribution matters, layer in a diarization pass (pyannote.audio, NVIDIA NeMo) or fall back to a quick manual edit at the top to label the speakers.

Policy work that has to happen alongside the install:

• Recording consent. Most jurisdictions require all-party consent for recordings. Make this explicit at the start of meetings ("I’m recording for transcript — OK with everyone?"). Standardise the opening.
• External partners. Tougher conversation. Some partners will agree if framed as "for my own working memory + AI context"; some will not. Default to asking explicitly; if not, take handwritten notes for that meeting and skip the transcript pipeline for it.
• Which meetings to transcribe. Default ON for design discussions, architectural decisions, partner / customer calls, retros. Default OFF for status updates, standups, casual 1:1s where nothing decision-worthy is happening. Err on the side of transcribing — you can always not feed a transcript to Claude later.

Routine 2 — Browser automation for coordination overhead

The second-biggest source of recurring time loss after meetings: clicking through web UIs that exist for coordination. Partner portals. SaaS dashboards. GitHub UI for routine PR operations. MFA flows. Internal admin tools. Status pages.

The baseline competency this week: you no longer click manually for routine web coordination. Claude drives the browser. You direct, you review, you approve.

What this looks like in practice:

• You open a fresh Claude Code session for a routine task ("check our partner portal for new tickets since yesterday"). Claude opens the browser, navigates, reads, summarises. You read the summary.
• For tasks that need actions (approving a PR via the web UI, clicking through a multi-step admin flow), Claude drives the actions step by step, confirms with you on the irreversible steps.
• For tasks behind MFA: Claude pauses at the MFA prompt, you complete the second factor, Claude continues. You haven’t saved the click-through; you’ve saved the rest of the flow around it.

The tools:

• Claude Code’s built-in browser tools (web_fetch for reads, the browser-automation plugin for clicks).
• Playwright via a skill if you need scripted automation that runs unattended.
• For the deeper "Claude says it can’t, push back" practice — that’s flying-stage territory (AgentHerder Course Week 3). This week is the baseline: you’re not clicking through routine SaaS yourself anymore.

Routine 3 — Reflexive GitHub admin

Preflight (Week 0) had you hand off a single work-stream’s git admin to Claude. This week graduates that from "I tried it once" to "this is how I work across multiple parallel branches at the same time."

What’s in scope:

• Branch creation and naming — Claude picks the convention, you review.
• Worktree management — git worktree add for parallel work-streams, so you don’t lose context switching between them. Claude knows when to create one.
• Rebase + conflict resolution — Claude attempts the rebase, surfaces real conflicts, proposes resolution. You approve the non-trivial ones.
• PR creation — Claude writes the title, body, labels, draft state. You eyeball before publish.
• CI watching — Claude polls the CI status, retries flaky failures, surfaces real ones for your attention.
• Status check / nudging — Claude handles the background coordination work (reviewer nudges, draft toggles, auto-merge eligibility).

The shift you’re going for this week: your hand doesn’t touch the git CLI for routine ops, across at least 3 parallel branches you’re working in. You still use git directly for the occasional surgical commit or inspection; the routine branch-and-PR machinery is delegated.

Routine 4 — Deploy-to-prod as one skill

In a traditional team, deploying to production is an event: pre-deploy checklist, image build, staging validation, e2e run, smoke tests, feature-flag config, migration plan, rollback rehearsal. Often 1–2 person-days of focus per release.

In an AI-native team, deploy-to-prod is one skill — a single Claude Code skill that orchestrates the whole sequence end-to-end. You invoke it. It does the work. You confirm the irreversible steps.

What goes into the skill:

• Image build + verification (the artefact is what you expect, signed if needed).
• Staging deploy + smoke test run.
• E2E test suite execution against staging.
• Browser-automated smoke tests of the critical user paths (this is where Routine 2 pays off — the same browser-automation patterns).
• Feature-flag configuration check (flags are off by default, get flipped on after deploy).
• Database migration plan + rollback readiness.
• Production deploy.
• Post-deploy verification (smoke against prod, monitor the error rate for the first 5 minutes).

First time building this skill takes effort — you’re encoding your team’s deploy process as a structured Claude Code skill, with the exact commands, the exact gates, the exact confirmation prompts. Realistic first-build effort: half a day of focused work, possibly spread across two sessions. After that, deploying is "invoke the skill."

If your team doesn’t have a usable deploy-to-prod sequence today (still mostly manual, no e2e suite, no staging), this assignment becomes a design exercise: write the skill that should exist, with placeholder steps for the pieces not yet automated. That gives you the roadmap for getting there.

Foundation check — Environment hygiene

Not a routine to install this week so much as a foundation to verify. AI velocity without these substrates creates real risk: 10× the PR volume hitting prod with no pre-prod gate is 10× the production fires.

Things to confirm exist:

• Staging separation from production. They share no databases, no shared external services that have prod side-effects, no shared secrets where a leak would matter.
• Pre-prod gates. CI runs on every PR. Tests pass before merge is possible. Reviewers can request changes.
• Feature flags or equivalent dark-launch mechanism. New functionality can land in prod without being on for users.
• Rollback procedure that’s been used at least once (not just documented). "We have a rollback button" without having used it is not a rollback procedure.
• Database migration strategy that supports forward and backward compatibility within at least one deploy window.

If any of these are missing or shaky: this is the week to invest in fixing them, before you scale engineering velocity in Weeks 3–5. The work to make these robust is real, but it’s also the work that stops AI-native velocity from blowing up in production.

Self-check — did this week land?

By end of Week 2 you should be able to point to:

• At least one meeting this week that was transcribed via local Whisper, with the transcript committed to the repo and used as Claude context for follow-up work.
• At least one recurring SaaS / web-UI task you used to do manually that’s now driven by Claude via the browser.
• At least 3 parallel work-streams active this week with Claude handling all routine git operations — your hand on the git CLI only for surgical / inspection work.
• A deploy-to-prod skill file in the repo — either running end-to-end, or a skeleton with mapped gaps in NEXT-STEPS.md.
• Confidence (or a concrete plan) on the five environment hygiene substrates.
• Friday demo + weekly planning still running. Week 2’s demos should already feel different from Week 1’s — less "what I did" and more "what now does itself."

Why we don’t scale all five at once

You may notice the four routines + environment hygiene is a lot for one week. The bootcamp’s real version of Week 2 is roughly five days of focused work; the self-paced version may stretch into 7–10 days for most teams.

What we’re explicitly not doing this week: the deep practice on browser-automation that flying-stage requires (auth at scale, MFA flows, broken-JS recovery, the "Claude says it can’t, push back" routine). That’s AgentHerder Course Week 3. What we’re also not doing: scaling 10× everything in the support functions (QA, monitoring, security, DevOps). That’s our Week 3.

The principle: installation order matters more than installation speed. A team that’s reflexive on the four Week 2 routines is well-positioned for the 10×-everything work. A team that tries to do all of it in parallel typically gets none of it right.