Plans
Nothing in a workspace starts from a chat. It starts from a request, becomes a plan, and becomes work only when you accept the plan. This page is the whole path.
1. A request arrives
Section titled “1. A request arrives”You send it: a message to the company in Slack, an issue labelled in Linear or Jira, a task filed in the workspace, or send_to_team from your assistant. It becomes a task handed to the CEO. The CEO answers within its run: what it understood, and at most one card of questions if something is missing.
2. The CEO writes a plan
Section titled “2. The CEO writes a plan”The plan is a document on the task, under the key plan, in Tandem’s format: the pieces of work, who does each, what “done” looks like for each, and what you do yourself. The task goes to in_review.
3. A curator reads it
Section titled “3. A curator reads it”Before you see a plan, a person on Tandem’s side reads it. The CEO files a review task for the curator that blocks the plan; the curator passes it or sends remarks. Remarks go onto the plan’s task and the CEO revises the document as a new revision and asks again. You never see a plan that did not pass. A curator who does not answer within the window passes the plan, marked unread, so a plan is never held up.
4. You get a card
Section titled “4. You get a card”The plan reaches you as one card on the task: one proposed task per piece, each with its assignee, and the CEO’s confidence in one line. You accept it all, accept some pieces, or send it back with a reason. Accepting creates the tasks, assigned as planned; sending it back wakes the CEO to revise.
In the workspace the card is on the task; in Slack it is in the thread; from your assistant, what_waits_on_me lists it and answer_card answers it.
5. The pieces are worked
Section titled “5. The pieces are worked”Each piece goes to its pod lead, who breaks it into steps with acceptance criteria and hands them within the pod: in engineering, implementation to the Senior Coder, verification to QA, security to the Security Auditor; in visibility, reading to the Site Auditor, measuring to the Answers Analyst, pages to the Writer, checks to the Fact-checker. One task per agent at a time. Work on code happens on branches, in pull requests.
6. Review, then you
Section titled “6. Review, then you”Every piece of code is reviewed by QA before you see it, and every piece of writing by the Fact-checker; the reviewer runs the tests or traces the figures and requests changes with the exact fix, or approves what it verified itself. Then the piece comes to you for approval: a pull request to merge, a page to publish. Nobody merges, publishes or pays but you.
The gate: what happens to the rest
Section titled “The gate: what happens to the rest”Work always turns up more work: follow-ups, ideas, debt, findings. Where it goes is the one setting you choose at setup and can change later:
- Ask (the default): it waits in the backlog, unassigned, with one line on why. The CEO puts it in the next plan card and you decide.
- Start: pod leads assign it as they file it, one task per agent at a time, worst first, and the plan card shows you what runs.
Rules of a plan
Section titled “Rules of a plan”- Every plan is a document, never only a comment. What you accept is one exact revision.
- 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]. - The method behind a measurement is not named: no supplier, model or mechanism.
The scorecard
Section titled “The scorecard”Every Monday, and when you ask, the team’s numbers land in your channel: tasks closed and by whom, pull requests opened and what you did with them, spend this month by role, and the one move the team recommends. From your assistant, next_action.