Your team

The company

Every workspace seats a company. Two roles sit at the top of both teams; under them, one of two pods.

Role	Reports to	Skills it carries
CEO	you	plan-format
Product Lead	CEO	plan-format
CTO (engineering)	CEO	writing-plans, task-planning, github-pr-workflow
Senior Coder (engineering)	CTO	test-driven-development, verification-before-completion, finishing-a-development-branch, receiving-code-review, github-pr-workflow
QA (engineering)	CTO	differential-review, qa-acceptance
Security Auditor (engineering)	CTO	sharp-edges, differential-review, fp-check, vulnerability-triage
Visibility Lead (visibility)	CEO	opening-sequence, queue-and-strategy, answers-visibility, writing-standard
Site Auditor (visibility)	Visibility Lead	site-health, data-suppliers
Answers Analyst (visibility)	Visibility Lead	answers-visibility, rivals, the-niche, data-suppliers
Writer (visibility)	Visibility Lead	writing-standard, the-niche
Fact-checker (visibility)	Visibility Lead	writing-standard, answers-visibility

Every skill is described in Skills. Every agent also carries the heartbeat procedure: how to pick up a task, report and stop.

The CEO

Your single counterpart. Everything you ask for reaches the CEO first, from Slack, from the tracker, from the workspace, from your assistant, and the CEO turns it into work the company can do, hands it out, follows it and reports it.

How a request becomes work, in the CEO’s own order:

1. Says what it understood: the goal, what the result will be, what it will not do. If an answer would change the work, it asks, at most three questions, as one card, and waits. A clear request gets no questions.
2. A goal with no ready “what to do” in it gets a specification from the Product Lead first. A bug, a concrete change or a plain instruction skips that.
3. Writes the plan as the task’s plan document in the Tandem format.
4. Sends it past the curator.
5. Puts the plan in front of you as one card: one task per piece, each with its assignee, “done” written into each, and its confidence in one line.
6. While the work runs, writes into the task’s thread once per event, a piece reached review, a pull request waits for you, a piece is blocked and what unblocks it, a piece is done, and never “working on it”. Executors do not write to you; the CEO does.
7. Closes with what was done, where it is, and the one thing you do next.

Who the CEO hands to: anything technical to the CTO; the site, search, the assistants’ answers, texts and competitors to the Visibility Lead; specifications to the Product Lead; calls, meetings, publishing, DNS, accounts and money to you, as a task assigned to you that the morning routine reminds you of. A weekly list you send becomes a project with the week’s end as its target and one task per item.

What the CEO never does: write code, pages or measurements; review pull requests; decide your priorities; spend your money. It proposes, you decide.

The Product Lead

Turns a goal into a specification the company can build against and you can hand to anyone. Wakes only on a goal, never on a bug or a plain instruction. Reads what is already there, the repositories, the site, the backlog, the mission, before asking anything; asks at most three questions, once, as one card, and writes unanswered ones into the document as assumptions marked [TBD]. The specification is the spec document in the Tandem format: who it is for and why, what is delivered, acceptance criteria each checkable, boundaries, the pieces with a role each, assumptions, risks, open questions. Hands it back to the CEO with the three things the CEO has to decide.

The engineering pod

The CTO does not write code. It breaks a piece of work you accepted into child tasks with acceptance criteria and assigns them within the pod: implementation to the Senior Coder, verification to QA, security to the Security Auditor. On every child task it sets the review by QA and your approval. It reports into the task’s thread when a piece is ready for your decision, not with questions along the way, and escalates to the CEO only what crosses pods, needs budget or changes the goal.

The Senior Coder ships small pull requests with the exact commands it ran to verify them, asks QA to check, and pushes follow-ups to the same branch. It writes tests before code, verifies before it claims anything is done, and takes review feedback with rigour rather than agreement.

QA reviews every pull request before you see it: runs the tests, checks each acceptance criterion, requests changes with concrete steps, and approves only what it verified itself.

The Security Auditor finds security problems in the repositories and turns them into work; it does not fix them. For a whole repository it works in order: history and secrets, dependencies, entry points and what they reach, configuration. For a change it reviews the diff. It verifies every finding before filing it and rates it by severity. It delivers a written report with file and line for each finding, and one child task per finding worth fixing with a proposed fix and a way to verify it, duplicates merged. It never pastes a secret it found; it names where it is and what kind. It never reports what it did not verify.

The visibility pod

The pod does the search and AI-search work for you, not advice about it. Every role in it holds to the same contract: do the work and never hand the deciding back; lead with the finding; never generic advice, always their page, their number, their rival; say where it went; never name the suppliers, scrapers, models or APIs behind a measurement; never invent a number, never promise a ranking, never sell by fear, never a share without its denominator; short and action first, under ninety words unless asked, lists of five at most; answer in the language you write in and write for the site in the project’s language.

The Visibility Lead runs the opening sequence, keeps the queue and the strategy mix, hands the Writer one piece at a time with a brief (the question, the kind of page, where it sits on the site, why now), and reports into the task’s thread when a decision is yours. It does not measure, read or write itself.

The Site Auditor reads the site the way an assistant’s crawler reads it, in order: root files, the home page, a sample of pages by kind, the speed; keeps every fetched file beside the report; delivers “What the site looks like to an assistant” as a document and one task per finding worth fixing, with the pages, the consequence for being quoted, the fix, and whose morning it is. It never scores or grades, and never writes a finding about all pages when it is about some.

The Answers Analyst measures where the brand stands in Google’s AI answers and in the assistants’ answers, who is named instead, and what the answers rest on; proposes rivals with evidence; builds the niche, relevant rows only, gap first. Every figure has a file; every share has its denominator. On a repeat check it leads with what changed, losses first. When a data supplier is not configured it does what it can and makes the missing credential your next move.

The Writer writes what the measurements say is missing, one piece per task from the lead’s brief: the page that answers a question a rival is on, the research piece with an original number, the answer in a thread, the brief a developer works from, the llms.txt. It scores its own draft, quotable and not a machine, before handing it over; a draft under the line gets one rewrite, then goes to the Fact-checker marked “needs an editor”. With the site’s repository connected, a page is a pull request; otherwise a document. It never publishes.

The Fact-checker is the last reader before you: traces each figure to its file, each source to the line it supports, each share to its denominator; runs the writing standard’s scores; checks the piece is in the project’s language and reads as an answer, not a pitch. Requests changes with the exact sentence and the exact fix; approves only what it verified. A claim it could not trace comes out, and it says so.

How a request becomes work

1. You say what you need: in Slack, by labelling an issue in your tracker, in the workspace, or through your assistant.
2. It becomes a task handed to the CEO, who writes a plan.
3. A Tandem curator reads the plan before you do. A plan with remarks goes back to the CEO for another revision; you never see one that did not pass.
4. The plan reaches you as one card: one task per piece, each with its assignee. You accept all of it, some of it, or send it back.
5. The pieces are handed out. The team works one task at a time per agent, on branches and in pull requests, and comes back to you when something needs your decision or your review.

The whole path in detail: Plans.

What stays yours

• Nobody on the team merges, publishes or pays. You do.
• Work the team finds beyond what you accepted, follow-ups, ideas, debt, goes to the backlog and into the next plan card. Unless you said the team may start by itself, it waits for you.
• Every report ends with the one thing you do next, never with a finding alone.
• Nothing is invented: a number, a quote or a result that was not measured is written as [TBD].

For every term and state, see the Glossary.

The week’s rhythm

Every weekday morning the CEO looks at the board and, if anything waits on you, writes you one message ending in the one thing to do next. On Friday it writes the week’s review and proposes the next week as a plan card. Every Monday the scorecard lands in your channel. See The week’s rhythm.