Founder's operating cockpit

Founder's operating cockpit. It can brief, triage, and file. It can't send without you.

A system of wired-together Claude Skills — Orchestrator, Drift, Intake, three Triage workers — that pulls from five sources in parallel, scans twenty-two project state notes for staleness, files saved links by type, and renders eight to twelve proposed changes per day behind a per-item approval gate. Read-only on every source. Nothing sends, posts, or replies on the founder's behalf. In daily use since 2026-04-27.

Praxis (founder-operated AI studio)In daily use

The founder needed an ops layer, not a chatbot.

Praxis is a small studio. The studio's own operations had to be run on the same idea as every client engagement: a working system that the operator trusts enough to use daily, not a demo and not a chatbot. The morning briefing was the first piece. The cockpit is the second.

What changed the shape was the moment the daily-ops briefing started surfacing the same project drift two and three days running, with no system noticing it was the same theme. Drift detection couldn't live inside the briefing — it had to live alongside it. Intake (saved links pile-up) had the same problem from the other direction: no one place to put new input. Once those two needs were named, the shape was a system of Skills, not a single workflow.

The non-negotiable was the approval gate. The founder will let the system propose; the founder will not let the system send. Every write — task list edits, project state updates, triage digests — passes through a per-item approval block that the founder paces. The wait between proposal and apply is intentional. The wait is what makes the system trustable.

Stage 01 — Trigger

One phrase, one operator.

The Orchestrator Skill fires from a single phrase the founder types in a Claude session. No schedule in v1; the founder pace is the schedule. Config loaded: voice rules, source list, watched channels, lookback windows. Everything downstream runs from that one fire.

Stage 02 — Sources

Five sources in parallel. Twenty-two project notes scanned.

Email, team chat, calendar, meeting notes (Granola), and the master task list — pulled in parallel. The Drift Skill scans twenty-two project state notes for staleness in the same beat. The Intake Skill absorbs anything new in the saved-links pile and files by type. Read-only on every source. Per-Skill state files prevent double-processing run to run.

Stage 03 — What runs together

Six Skills. One stream. Claude does the reading.

Orchestrator, Drift, Intake, and three sibling Triage Skills run in parallel. Claude reads meeting transcripts for commitments and decisions, reads outbound email and DMs for promises made, and ranks the day's candidate changes against the gathered raw material. The three Triage workers each return their proposals; the Orchestrator merges them into one stream so the founder reads one block, not three.

Stage 04 — Approval gate

Per-item. Founder-paced. The system pauses here.

Eight to twelve candidate changes render as one combined approval block — task-list edits, project-note updates, triage routing. The founder approves per item. Approve. Approve. Skip. Approve. The wait between propose and apply is the editorial center of the system; it's why every write feels chosen rather than executed. Auto-approve is on the roadmap, intentionally not yet shipped.

Stage 05 — Where writes land

Tasks. Notes. Digest. Archive. Attachments out-of-band.

Approved task-list edits and project-note updates land in their respective surfaces. A triage digest posts to the team-chat as a daily record. A dated session log is archived. Email attachments and Drive files route to per-client folders by an attachment worker that runs out-of-band after compose — so the founder isn't waiting on it to finish. Nothing sends. Nothing posts on the founder's behalf.

Six Skills. One operator.

Founder-operated, founder-built. The cockpit was built layer by layer — briefing first, then Drift, then Intake, then triage, then the merge into a single approval block.

PHASE 01

Briefing baseline. Daily-ops briefing already shipped (case study #02). The cockpit starts from that base — same trigger pattern, same voice spec, same read-only stance. Decision: the cockpit lives alongside the briefing as a parallel system, not a replacement.

PHASE 02

Drift Skill.22 project state notes wired up for staleness detection. The Drift Skill runs in the same beat as the source pulls, returns a per-project flag and a one-line proposed update. Per-Skill state file landed so a second daily run doesn't double-flag the same project.

PHASE 03

Intake Skill.Saved-links pile-up absorbed and filed by type — article, doc, screenshot, video. The point isn't deep classification, the point is no new input piles up. The pile being empty by morning is the win condition.

PHASE 04

Three Triage Skills.One reads outbound email and DMs for promises made; one reads meeting transcripts for commitments and decisions; one reads the master task list for what's urgent vs. carryover. Each returns proposals. None apply directly.

PHASE 05

Orchestrator merges. The three Triage outputs plus Drift plus Intake collapse into one combined approval block — eight to twelve candidates rendered as a single per-item approval list. Merging is intentional; the founder reads one stream, not five.

PHASE 06

Apply, archive, attach.Approved writes land in Tasks, project notes, and the team-chat triage digest. Dated session log archived. Attachment worker runs out-of-band post-compose so the founder isn't waiting on file moves. Handed to itself; in daily use since 2026-04-27.

Brief, triage, and file in under three minutes.

Four-plus apps checked every morning is one phrase. The Skills propose; the founder approves per item; the writes land. End to end runs under three minutes — the approval wait is founder-paced and not counted, but it's the part that matters. Auto-approve is on the roadmap, intentionally not yet shipped. The pause is the feature.

Drift detection is what the cockpit added beyond the briefing. Twenty-two project notes get scanned every run; staleness gets named; the founder approves or skips the proposed update. A project that quietly fell off the radar can't hide for three days running anymore.

The founder runs the studio on this system. Every client workflow ships from a studio that runs on this layer. That is the proof.

End-to-end runtime< 3 min (excluding approval wait)

Skills in stack6 · Orchestrator + Drift + Intake + 3 × Triage

Projects watched for drift22 · re-scanned every run

Candidates approved per day8–12 · per-item gate

In daily use since2026-04-27 · founder-operated