How I work
I design it. Agents build it.
I try to break it.
I decide what gets built and whether it's good enough to ship, with twelve years of engineering behind those calls. Agents do the typing. Every change gets a written plan before it starts, an adversarial review when it's done, and a test by hand before it merges.
11
agent skills written
5
lenses on every review
4 of 8
steps in the loop are mine
239
test files added in 2026
The loop
The lit steps are mine. Agents don't start without my plan approval, and I decide what merges.
ScopeI write the issue: what to build, what's out of bounds and how I'll judge it.me
QuestionsThe orchestrator asks what it can't infer, on the issue. I answer there.agent, then me
PlanIt posts an implementation plan as a comment.agent
ApproveI read the plan and change the approach where it's wrong. Nothing is built without the label.me
BuildWorker agents build in parallel, each in its own worktree, with tests.agents
DemoEach pull request arrives with phone and tablet screenshots and recordings.agents
Red-teamI run an adversarial review across five lenses and decide which findings get fixed.me, with review agents
Test and mergeI run it by hand on a real phone and tablet. Then I merge, or send it back.me
What stays with me
- The design: I decide the architecture and the data models before an agent writes a line.
- The plan: every issue gets a written plan. I read it, push back and approve or reject it. A thumbs-up in chat doesn't count; the label does.
- The red-team review: I review each pull request for security, correctness, design system, reuse and senior-engineer judgment. Findings are triaged by payoff and regression risk, and nothing posts without my say.
- The hands-on test: I run changes myself on a real phone and tablet before they merge.
- The tests: changes ship with tests, and data migrations ship with drift checks.
- The taste: a written list of banned patterns keeps the product from looking generated. I enforce it in review.
Skills I've written
A skill is a written procedure an agent follows. These are the ones I wrote and use.
Planning and orchestration
start-orchestratorTurns a session into the issue orchestrator: triage, questions, plans, and dispatch to worker agents in their own worktrees.
create-issueResearches the codebase from a brief and writes an issue an agent can execute, with files, gotchas and tests.
work-on-issuePicks up an issue by number and takes it from plan to implementation.
Review
pr-reviewA five-lens adversarial review that stays inside the diff, then a triage pass that asks whether each finding is worth acting on. It never posts by itself.
address-pr-feedbackValidates each reviewer comment, separates real issues from nitpicks, checks in with me, then fixes in ordered batches and replies with the commit.
merge-mainSorts merge conflicts into mechanical, clear-intent and judgment calls, resolves the first two and stops for me on the third.
Shipping
create-prDrafts a terse pull request from the diff, with a how-to-test checklist, and stops for my approval before opening it.
create-pr-with-demo-and-artifactsCaptures phone and tablet screenshots and recordings, checks each one, and opens the pull request with them at the top.
changelog-entryWrites the in-app changelog entry that every user-facing change needs.
Content
write-adventureTakes a tabletop one-shot adventure from concept to built package.
prose-passA prose gate that keeps generated adventure text from reading as machine-written.
State lives in labels
An agent session ends, but GitHub labels persist, so the next session knows where each issue stands.
Rules I hold agents to
- Questions go on the issue. Decisions live where the work is.
- One agent drives the devices. A lane lock stops two agents fighting over the simulator.
- Owner-only work has a home. Accounts, keys, legal calls and device tests go to a NEEDS-HUMAN folder for me.
- Don't trust training data. For fast-moving frameworks, agents read the versioned docs first.