My AI Setup: How a Product Person Runs Claude Code

I run scilla.studio from the terminal. This setup (an AI chat on top of a folder of files, a ticket board, and a code-review pipeline) is how we built benchmark.scilla.studio, moved our website from Webflow to Astro, produce the 39 published case studies and the articles on this site, and keep the studio’s records consistent. We treat the studio itself as the product: every process we repeat gets productized, and we are still in the middle of finding out how far that carries, growth-wise. Under it all sits the question we actually want answered: how far can knowledge work be taken when a human and an LLM do it together? I am not a developer; I write instructions in plain language and approve what ships.

flowchart TD
    ME["Me: plain-language instructions + merge approval"]
    CC["Claude Code (AI chat in the terminal)"]
    REPO["Git repository: core/ facts + output/ generated content"]
    LIN["Linear: ticket board"]
    GH["GitHub: branches, pull requests, merges"]
    EXT["Notion / Google Drive / Figma / Mixpanel / web search / browser"]
    LOOP["Autonomous loop: scout, architect, builders, gatekeeper"]
    SITE["Product repo: Astro website + benchmark tool (runs its own copy of this loop)"]

    ME <--> CC
    CC <--> REPO
    CC <--> LIN
    CC <--> GH
    EXT --> CC
    LOOP <--> LIN
    LOOP --> GH
    GH -->|"merge, only on my approval"| REPO
    REPO -->|"manual sync scripts"| SITE

The workspace: one git repository

All data lives in one folder of plain text files, version-tracked with git. Two halves:

• core/ holds facts: 91 client engagements, company profiles, consultant profiles, the brand voice written out as rules, and the customer pains we solve.
• output/ holds everything generated from those facts: case studies, articles, CVs, outreach lists.

One rule connects them: output/ is produced by reading core/, never the reverse. A fact corrected once in core/ is correct in every document generated after it.

Files instead of Notion or Google Docs, for two reasons: AI reads and writes plain files natively, with no copy-paste or exports, and git adds a review step, so nothing counts until a change is approved and merged.

The interface: Claude Code

A chat with an AI that runs in the terminal. It reads and edits the files, runs scripts, and operates the connected tools below. Everything, from drafting a case study to updating the ticket board, happens as instructions in this one conversation.

The terminal sounds like showing off, and the effect has been the opposite: it removed interfaces from my day. I used to learn a new UI for every tool a job needed; now every tool is reachable through the same conversation, and what remains of each one is the outcome it produces. That shift, more than any single feature, is what opened this way of working up for me.

The connected tools

The chat reaches other tools through MCP, a standard that lets an AI operate them directly:

• Linear: the ticket board. Every piece of work starts as a ticket and ends with the ticket closed.
• GitHub: branches, pull requests, review, merge. The change-control layer for all content, the way development teams use it for code.
• Notion and Google Drive: source material, like old client documents, pulled into the workspace.
• Figma: design files.
• Mixpanel: product analytics data.
• Web search and the browser: research, and checking live pages.

Nothing gets copy-pasted between apps; the chat reads from and writes to each tool itself.

Saved procedures

Recurring jobs are written down as procedures the AI runs the same way every time, triggered as commands in the chat:

• /case-from-transcript: interview transcript in, reviewed case-study draft out.
• /pickup: opens a session by reading the state file, which records where everything stands.
• /wrapup: closes a session by writing down what changed.

The procedures are text files in the same repository, so changing a workflow means editing a document.

The review agents

Separate AI agents, each with one job, gate the output. A case study passes a panel of four before I see it: one checks the mechanical writing rules, one checks tone against the brand goals, one checks structure and length, and one reads the draft as the target customer and answers whether a Head of Product would actually email us after reading it. Two review rounds maximum, then the result comes to me.

The autonomous loop

A script starts Claude Code sessions on its own against the ticket board. One iteration: read the board, pick the top ticket, create a branch, do the work, open a pull request, hand it to a gatekeeper agent for review. The roles are split like a team’s: a scout files and prioritizes tickets, an architect designs the larger ones, builders implement, the gatekeeper reviews.

Two constraints hold everything: no change is written to the main copy directly, and no merge happens without my explicit approval. This morning the loop ran for about two hours and shipped five changes (article fixes, an index update, an improvement to its own launcher script). My part was five short reviews and five approvals.

Memory between sessions

A state file records where all work stands, so each session starts oriented instead of briefed from scratch. Corrections I give once are saved as standing rules and applied to all future work. Today’s example: after I flagged filler sentences in a review, the ban went into the writing rules, the review agents, and the drafting procedures the same day.

One job end to end: a case study

From raw material to live site:

1. An interview transcript is dropped into the workspace.
2. /case-from-transcript cleans it and writes a draft from the transcript plus the engagement’s facts in core/.
3. The four review agents run; the draft is revised, at most twice.
4. The measured results are written back into the client’s record in core/.
5. The change goes up as a pull request; I read it and approve the merge.
6. A sync script copies the published file into the website repository, and the site rebuilds.

My hands-on time: reading one draft and one pull request. Building the benchmark tool ran on the same motions in its own repository: tickets, branches, pull requests, my approval; the work just happened to be code instead of prose.

The one seat AI does not hold

Every merge waits for my word; that is the whole human role, and the reason the rest can run without me. To copy one piece of this setup, copy the workspace: facts in one folder, generated content in another, and the AI reads before it writes. Most of the consistency win comes from that split alone. The clearest proof the setup holds is the product it shipped: benchmark.scilla.studio came out of this same loop, and the studio it runs is the next thing we are productizing.