My Full Claude Cowork Setup: Mission Control in Five Hours

Before Cowork builds anything useful, it needs to know how to behave. Four sections in your operating instructions determine 80% of output quality. Most people skip this. This page covers exactly what to put in each section and why.

Why operating instructions matter before anything else

Cowork takes on your personality from day one

Your operating instructions live in Cowork settings. Cowork reads them at the start of every session. They define how it thinks, communicates, and decides before you type a single task.

Without them: Cowork guesses what you want, builds things you didn't ask for, and starts long jobs without checking first.

With them: Cowork writes a plan before touching anything, asks the questions it needs to ask, and stops before doing anything hard to undo.

Where to paste them: Claude settings, then Cowork, then paste into the operating instructions field.

Section 1: PRD first, always

Before Cowork builds anything, it writes a product requirements document

This is the most important rule in the entire setup. Before Cowork writes a line of code, creates a file, or runs a workflow, it writes a PRD: a product requirements document that describes exactly what it is about to build.

The PRD includes:

• What problem this solves
• What success looks like
• What is in scope and out of scope
• Any constraints
• A step-by-step build plan

Paste this into your operating instructions:

PRD FIRST, ALWAYS.
Before building, creating, or modifying anything non-trivial, write a Product Requirements Document (PRD) that includes:
- Problem statement: what are we solving and why
- Success criteria: how we will know this is done correctly
- Scope: what is included and explicitly what is not included
- Constraints: technical, time, or resource limits
- Build plan: numbered steps in the order you will execute them

After writing the PRD, ask me any open questions before starting.
Wait for my explicit sign-off before beginning the build.
Do not start building until I say yes.

Why this matters: without a PRD, Cowork can spend an hour building something that isn't what you wanted. With a PRD, you catch the misunderstanding in 2 minutes before any work is done.

Section 2: Push back and clarification

You want Cowork to disagree with you when you're wrong

Most people configure Cowork to be agreeable and fast. This produces bad output. You want Cowork to tell you when your plan is off-strategy, technically wrong, or inconsistent with decisions you made earlier.

Paste this into your operating instructions:

PUSH BACK AND CLARIFICATION.
You are expected to push back when:
- A plan seems technically wrong or will not work as described
- A request is inconsistent with prior decisions in this workspace
- You see a trade-off or risk I have not mentioned
- The approach seems off-strategy given what you know about my goals

When you push back, explain specifically what concerns you and what you would suggest instead.
Ask clarifying questions when a request is ambiguous before attempting it.
Do not proceed with something you believe is wrong just because I asked for it.

Section 3: Aggressive note-taking

Memory management is the long-term performance multiplier

Cowork's memory degrades over time if you don't manage it. The fix is making documentation part of its default behavior from session one.

Paste this into your operating instructions:

NOTE-TAKING.
After completing any significant task, decision, or build:
- Document what was done, what was decided, and why
- Note any constraints, edge cases, or issues encountered
- Update the relevant memory or log file
- If you learn something about my preferences, workflows, or working style, write it down

Do not rely on conversation history to retain important information.
Anything worth knowing twice should be written to a file.

Section 4: Reversibility

Interrupting with a question is always cheaper than silently destroying something

Paste this into your operating instructions:

REVERSIBILITY.
Before any action that is difficult or impossible to undo:
- Stop and confirm with me first
- Describe exactly what you are about to do and what the effect will be
- Wait for explicit approval

This includes: deleting files, overwriting data, sending messages, deploying anything, or making changes to systems outside the current project folder.

If in doubt, stop and ask. Interrupting with a question is always cheaper than silently making an irreversible mistake.

✅ All four sections above can be combined into one operating instructions block. Paste them together in Settings, Cowork, operating instructions.

❌ Do not skip the PRD section. The other three matter, but PRD-first is the one that prevents the most wasted time.

The PRD is the blueprint. Every project, dashboard, skill, and workflow you want Cowork to build starts here. Skip it and Cowork guesses. Write a good one and Cowork executes. This is the most important step in the entire setup.

What a PRD is and why it matters

The blueprint determines the building

A Product Requirements Document is a written spec of what you want built. You give it to Cowork before the build starts. Cowork reads it, asks clarifying questions, and only starts building after you sign off.

Without a PRD: Cowork builds something based on your summary. 30-60 minutes later, the output doesn't match what you wanted. You restart.

With a PRD: Cowork builds exactly what the document describes. Misalignment gets caught in the planning phase, before any work is done.

The PRD covers the full initial Cowork build: your folder structure, your first dashboards, your first skills, and any autonomous workflows you want running in the background.

The data lake analogy

Think of your Cowork setup as a man-made lake

Before you can build anything useful on top of data, you need the data flowing in. Think of it like building a lake:

Hour 1 is digging the lake and setting up the water pipelines. You're setting up the folder structure and making sure data flows in from your connected tools: Gmail, Google Calendar, Slack, and any other sources. Nothing you can look at yet. Just the foundation.

Hours 2, 3, and 4 are building things on the lake. Your dashboards, morning briefs, and skills are all just different ways of transforming the same data and presenting it. An investment dashboard takes financial data and visualises it. A morning brief takes calendar, email, and Slack data and compiles it. A research skill takes a topic and deep-dives it. They're all built on top of the same data layer you set up in hour 1.

Hour 5 is polish. Notifications, end-to-end testing, and cleanup.

When you plan your PRD, think about which data sources you're piping in first, because everything you build after that draws from them.

What your PRD should include

Five sections. All required.

1. Projects to build. List every dashboard, skill, and workflow you want Cowork to set up. For each: a one-sentence description, who it's for (you, your team, your clients), and what data it draws from.

Starter project list that works for most GTM engineers:

• Daily digest: morning brief from Gmail, Google Calendar, Slack, and relevant news
• Campaign dashboard: live view of active client campaigns with key metrics
• Client intelligence brief: pre-meeting brief for any client or prospect
• Skills suite: /today, /research, /prep (covered in detail in the skills page)
• Autonomous builder: overnight build system for new tools and workflows

2. Architecture overview. Describe your folder structure. Most setups use a three-layer system: a root folder, project-specific subfolders, and a data/resources subfolder within each. The PRD maps this out so Cowork builds the exact structure you need from the start.

3. Data connections. List every external tool you want Cowork to connect to. Gmail, Google Calendar, Slack, HubSpot, Notion, whatever you use. The more connections you map in the PRD, the more complete your data layer is in hour 1.

4. Skills to build. List every slash-command skill you want set up. Name the command, describe what it does, what inputs it takes, and what output it produces.

5. Build plan with time allocation. Break the build into hours. Hour 1 is always the data layer foundation. Hours 2-4 are your projects. Hour 5 is polish and testing. Adjust the total hours to however long you have. If you only have 2 hours, scope the projects down, not the data layer.

The meta prompt to generate your PRD

Paste this into Claude Chat to get your personalised PRD

I want to set up Claude Cowork as my primary AI hub. Help me write a detailed Product Requirements Document (PRD) for my initial Cowork build.

Ask me the following questions one at a time and use my answers to build the PRD:

1. What is your primary role and what does your day-to-day work involve?
2. What tools do you use most? (email, calendar, Slack, CRM, etc.)
3. What information do you want to see every morning in a daily brief?
4. What dashboards would help you most? (investments, campaigns, projects, other)
5. What repetitive tasks do you do weekly that could become a slash command skill?
6. Do you want an autonomous builder that works overnight? If yes, what types of things would you want it to build?
7. How many hours do you have for the initial setup?

After I answer all questions, generate a full PRD with these sections:
- Mission and goals
- Projects to build (with descriptions and data sources for each)
- Architecture overview (folder structure, three-layer system)
- Data connections required
- Skills suite (slash command list with inputs and outputs)
- Build plan (hour-by-hour breakdown)
- Success criteria (how we know the build is complete and working)

Format it as a markdown document I can save as PRD-mission-control.md

The folder setup takes under 1 minute. Then you give Cowork the PRD and it builds the rest. This page covers the exact steps and the instructions to paste into your project.

The 1-minute folder setup

Six steps from zero to Cowork running your build

Step 1: Open Finder (Mac) or File Explorer (Windows). Create a new folder. Name it something clear: mission-control or cowork-hub.

Step 2: Open Claude Cowork. Click Projects in the left sidebar. Click New Project.

Step 3: Select Use an Existing Folder. Navigate to the folder you just created. Click Open.

Step 4: In the project instructions field, paste the following:

This project runs the mission control build. Always reference PRD-mission-control.md in this folder for all build decisions. Follow the PRD exactly. Write a PRD before building anything not covered in the existing PRD. Ask for sign-off before starting any new build.

Step 5: Click Create.

Step 6: Go back to your mission-control folder on your computer. Drop in the PRD-mission-control.md file you generated in Step 2.

Then type this in the project chat:

Please start building with the PRD-mission-control.md file in this folder.

Cowork reads the PRD, confirms what it found, tells you the next steps (installing plugins, connectors, setting up skills), and waits for your sign-off before starting.

The three-layer folder architecture

How to structure your Cowork folder for scale

Most effective Cowork setups use a three-layer folder system:

mission-control/
  CLAUDE.md                    # Root operating rules
  memory.md                    # Session memory
  PRD-mission-control.md       # The master build document
  projects/
    daily-digest/
      CLAUDE.md                # Digest-specific rules
      memory.md                # Digest-specific memory
      digest.md                # Today's output
    campaign-dashboard/
      CLAUDE.md
      memory.md
      dashboard.html
    autonomous-builder/
      CLAUDE.md
      memory.md
      pending/                 # PRDs waiting to be built
      in-progress/             # Active builds
      done/                    # Completed builds
      failed/                  # Failed builds
      build-log.md             # Record of everything built
  skills/
    today.md
    research.md
    prep.md
  data/
    connections.md             # List of connected tools
    raw/                       # Cached data from connectors

Layer 1 is the root: operating rules, memory, and the master PRD. Layer 2 is projects: each project has its own CLAUDE.md, memory, and output files. Layer 3 is shared resources: skills, data connections, and raw data cache.

You do not need to create all of this manually. Your PRD maps the folder structure and Cowork builds it in hour 1 of the build.

What happens in hour 1

Hour 1 is the data layer foundation. Cowork:

• Creates the folder structure from your PRD
• Sets up the memory system (root memory.md + per-project memory files)
• Runs /start from the productivity plugin to initialise the memory system
• Configures connections to your external tools
• Verifies data is flowing from each connected source

Nothing visual yet. Just infrastructure. Everything built in hours 2-4 draws from what gets set up here.

❌ Don't skip or rush hour 1 to get to the dashboards faster. A broken data layer produces broken dashboards.

✅ Check that each connector is actually returning data before moving on. Ask Cowork to show you a sample from each source.

The daily digest is the first thing you see every morning. It pulls from every connected tool, compiles what matters, and tells you what to do. No tab switching. No inbox diving. One brief.

What the daily digest contains

Every morning, Cowork pulls from all your connected tools and builds this

The morning brief runs automatically every morning via a scheduled task. By the time you open your laptop, it is already written. The default structure:

Section 1: Day overview. What today looks like. Meetings, deadlines, and any time-sensitive tasks from your task manager.

Section 2: Inbox summary. Emails that need a response or action, flagged by urgency. A draft response suggestion for each important one.

Section 3: Slack summary. Threads and DMs from the last 16 hours that need attention. Anything that looks like a question directed at you.

Section 4: News and signals. Relevant news for your work. For GTM engineers: funding announcements in your ICP, competitor moves, and any LinkedIn activity from target accounts.

Section 5: Action items. Everything from sections 1-4 that requires an action from you today, compiled into one list with priority order.

The brief is delivered wherever you tell it to go: Apple Notes, a file in your workspace folder, Slack DM to yourself, or all three.

How to set it up

Add this to your PRD under daily digest project

DAILY DIGEST PROJECT

Goal: A morning brief delivered automatically every day before 8am.

Data sources:
- Google Calendar: all events today and tomorrow
- Gmail: unread emails from the last 16 hours
- Slack: unread messages and DMs from the last 16 hours
- Web search: relevant news for [your topic area]

Output format:
- Day overview (meetings, deadlines)
- Inbox summary (emails needing response)
- Slack summary (threads needing attention)
- Signals (relevant news and intel)
- Action items (everything requiring action today, in priority order)

Delivery: Write to daily-digest.md in the daily-digest project folder AND send as a Slack DM to myself.

Schedule: Run at 7:00am every weekday.

Success criteria: By the time I open my laptop I have a complete brief with no manual effort required.

Adapting sections for GTM engineers

Swap the generic sections for GTM-specific intel

The default brief works for anyone. For GTM engineers, replace or add these sections:

Campaign health snapshot. Pull the previous day's campaign metrics for all active clients. Flag any deliverability issues, unusually high or low reply rates, or campaigns that missed send targets.

Positive reply summary. Any new positive replies from the last 24 hours across all client campaigns. Name, company, and the recommended next action for each.

Client communications. Any emails or Slack messages from clients that need a response today. Draft responses suggested for each.

Signal watch. Funding announcements, hiring signals, and competitor moves for your active ICP accounts. Flag anything that creates an outreach angle.

Today's priorities. Three specific actions ranked by impact for today. Not a general to-do list, a prioritised work queue.

Add this section to your daily digest PRD spec:

GTM SECTIONS (add to standard brief):
- Campaign health: pull metrics from [your campaign tool connector]. Flag anything more than 10% below benchmark.
- Positive replies: list all positive replies from the last 24 hours with prospect name, company, and recommended next step.
- Signal watch: search for funding announcements, new SDR job postings, and tech stack changes at our target accounts.
- Today's 3 priorities: given the above, what are the three highest-leverage actions to take today.

The /today skill

Fetch or refresh the morning brief any time during the day

The daily digest runs automatically in the morning. The /today skill gives you on-demand access to it during the day.

What /today does:

• Pulls the current morning brief if you want to review it again
• Regenerates a fresh brief if significant time has passed and new things have come in
• Updates the brief with anything new since the morning run
• Shows you what's changed since the morning brief was generated

Add this to your PRD skills section:

/TODAY SKILL

Invoke: /today
Optional args: /today update (regenerate with fresh data), /today [topic] (pull brief focused on one area)

What it does:
- Reads the current daily-digest.md
- If it's more than 4 hours old, offers to regenerate with fresh data
- Summarises what has changed or been added since morning
- Shows the 3 top priority actions for the rest of the day

Output: Updated daily-digest.md + brief summary in chat

Dashboards are the most useful output from a Cowork build. They turn live data into something you can read in 30 seconds. This page covers how to build a campaign performance dashboard and a mission control dashboard that shows all your active Cowork builds.

Why dashboards first

A dashboard forces you to define what matters before you build anything

Building a dashboard is one of the best first projects in any Cowork build for three reasons.

First: it forces you to define what data matters. Before you can display campaign health, you have to decide what healthy means. Before you can show client status, you have to define what status categories exist. This thinking produces a cleaner data layer.

Second: it gives you something visual to check. During and after the build, you can open the dashboard and immediately see whether data is flowing correctly. Broken pipelines show up fast when there's nothing on the dashboard.

Third: it compounds. A campaign dashboard you build now gets more useful as more data flows into it over time.

Build your dashboard in hour 2 of the initial Cowork build, after the data layer is confirmed working in hour 1.

The campaign performance dashboard

A live view of every active client campaign in one place

Add this to your PRD under dashboards:

CAMPAIGN PERFORMANCE DASHBOARD

Goal: A single HTML dashboard that shows the health of all active client campaigns without me having to open any external tool.

Data sources:
- Campaign metrics from [your campaign tool connector or CSV export path]
- Client list from clients/ folder
- Positive replies log from reply-tracker.md

Metrics to display per client:
- Active campaign name
- Sends this week vs target
- Open rate (flag if below 40%)
- Reply rate (flag if below 3%)
- Positive replies this week
- Meetings booked this week
- Deliverability status (green/amber/red)
- Last updated timestamp

Layout:
- Summary row at top: total active campaigns, total positive replies today, total meetings booked this week
- One card per client below, sorted by deliverability status (red first)
- Color coding: green (on track), amber (attention needed), red (action required today)

File: dashboards/campaign-dashboard.html
Update schedule: Every 2 hours during business hours

Success criteria: I can open this file and know the status of every client campaign in under 30 seconds.

The mission control dashboard

See everything Cowork is building, has built, and is scheduled to build

The mission control dashboard is your view into Cowork's autonomous build activity. Once you set up the autonomous builder (Step 7), this is how you see what it built overnight.

Add this to your PRD under dashboards:

MISSION CONTROL DASHBOARD

Goal: A visual overview of all Cowork autonomous builds: what's pending, what's in progress, what's done, and what failed.

Data sources:
- autonomous-builder/pending/ folder (count and titles of pending PRDs)
- autonomous-builder/in-progress/ folder (current active build)
- autonomous-builder/done/ folder (completed builds with dates)
- autonomous-builder/failed/ folder (failed builds with error summaries)
- autonomous-builder/build-log.md

Layout:
- Four status columns: Pending | In Progress | Done | Failed
- Each build shown as a card with: project name, date created, status, one-line description
- Build stats summary at top: total built, success rate, time saved estimate
- Last 7 days of activity shown by default

File: dashboards/mission-control.html
Update schedule: Every 30 minutes

Success criteria: I can wake up, open this dashboard, and immediately see what Cowork built for me overnight.

Other dashboards worth building

Once your data layer is running, these are the next dashboards most GTM engineers find valuable:

Client portfolio dashboard. One view across all clients showing: retainer status, current campaign phase, last communication, next scheduled touchpoint, and upcoming renewal dates.

Pipeline health dashboard. Deals in each stage, days in stage, stall flags, and projected close rate for the month.

Weekly content calendar. All scheduled posts across LinkedIn and other channels, with status (drafted, approved, scheduled, published) and engagement stats on published posts.

Team workload view. Active tasks per team member, current week capacity utilisation, and any tasks approaching their deadline.

Each dashboard follows the same build pattern: define the data sources, define the metrics, define the layout and color coding, write it into your PRD, and Cowork builds it in an hour.

Three skills that most GTM engineers find themselves using daily within the first week of a Cowork setup. Build them in hour 3, after your data layer and dashboards are working. Each one is a reusable slash command that produces consistent output every time.

Why these three first

They cover the three most common daily actions in a GTM operation

/today answers: what is my situation right now?

/research answers: what do I need to know about this company, person, or topic?

/prep answers: what do I need before this call or meeting?

Together they eliminate the three biggest time drains in a GTM engineer's morning: piecing together what happened overnight, manually researching prospects before outreach, and scrambling to prepare for calls.

Build them in this order: /today first (draws from the daily digest you already set up), then /research, then /prep.

/today

Fetch, refresh, or update your morning brief any time

Add this to your PRD skills section:

/TODAY SKILL

File: skills/today.md

Description:
Use this skill when the user types /today or asks about their day, schedule, or current priorities. Also use it when they ask what they should focus on or what needs attention.

Instructions:
1. Read daily-digest.md in the daily-digest project folder
2. If the file is more than 4 hours old: ask the user if they want a fresh version. If yes, regenerate by pulling live data from calendar, Gmail, and Slack
3. Present the current brief summary: today's meetings, inbox items needing response, top 3 priorities
4. Ask: is there anything specific you want to dig into from the brief?

Optional args:
- /today update: regenerate the brief with fresh data regardless of age
- /today [topic]: show only the section of the brief relevant to that topic
- /today [client name]: show everything in the brief related to that client

Output: Brief summary in chat + updated daily-digest.md if regenerated

/research

Deep-dive any company, person, or topic in under 3 minutes

Add this to your PRD skills section:

/RESEARCH SKILL

File: skills/research.md

Description:
Use this skill when the user types /research followed by a company, person, or topic. Also use when they ask to research, investigate, or find information about something before outreach or a call.

Instructions:
1. Read the research target from the user's input: /research [target]
2. Run a comprehensive search covering:
   - For a company: overview, ICP fit against BRAND.md, recent news, funding history, tech stack, key hires, any trigger signals in the last 30 days, LinkedIn activity from leadership
   - For a person: role, background, recent posts, what they care about professionally, mutual connections, any public statements about the problems we solve
   - For a topic: current state, recent developments, key players, what our ICP thinks about it
3. Produce a research brief with: summary, key facts, outreach angle, open questions
4. Save the brief to research/[target-name]-[date].md
5. Ask: do you want me to draft a first-touch message based on this research?

Output: Research brief in chat + saved file in research/ folder

For GTM engineers: this replaces 30-60 minutes of manual prospect research per company. Run it before any outreach, before any discovery call, and before writing new sequences for a segment you haven't targeted before.

/prep

Full context brief for any meeting, before you walk in

Add this to your PRD skills section:

/PREP SKILL

File: skills/prep.md

Description:
Use this skill when the user types /prep followed by a meeting name, person name, or asks for meeting preparation. Also use when they mention an upcoming call or meeting and seem to want context.

Instructions:
1. Read the meeting reference from the user's input: /prep [meeting name or person]
2. Search Google Calendar for the matching event. If multiple matches: ask which one.
3. For the matched meeting, pull:
   - Event title, time, and attendees
   - Company/org for each attendee (from calendar info or web search)
   - LinkedIn profile summary for each external attendee
   - Any prior email threads with these attendees (from Gmail connector)
   - Any prior Slack conversations referencing these names
   - Recent news about their company
   - If an existing client: pull the client brief from clients/ folder
4. Produce a meeting prep brief with: who you're meeting, what they do, any prior context, what the likely agenda is, three suggested questions to ask, and any risks or opportunities to be aware of

Output: Meeting prep brief in chat. Ask if they want it saved to a file.

For GTM engineers: this is particularly useful when external contacts book directly into your calendar and you don't know them. It also means you walk into every client call knowing everything that has happened since the last one.

How to build all three

Add the PRD specs above to your skills section. Cowork builds them in order.

Paste all three skill specs into the skills section of your PRD. During hour 3 of your initial build, Cowork creates each skill file, tests it, and confirms the output matches the spec before moving to the next.

After the build, test each skill immediately:

/today

/research [a company you know well so you can verify the output]

/prep [your next meeting]

If the output from any skill is wrong or incomplete, don't move on. Fix the skill spec and have Cowork rewrite it before building the autonomous builder in hour 4.

The autonomous builder relies on skill output quality. If /research produces weak briefs, the autonomous builder will build things based on weak intel.

The autonomous builder runs while you sleep. You drop a PRD into a folder. A scheduled task picks it up, builds it, and moves it to done. You wake up to finished work. This is hour 4 of the initial build and the most advanced section. You can skip it on your first build and add it later.

How it works

Four folders. One scheduled task. Cowork does the rest.

The system has four folders inside your autonomous-builder project:

pending/ holds PRDs waiting to be built. You drop a markdown file in here and it joins the queue.

in-progress/ holds the PRD that is currently being built. Only one build runs at a time.

done/ holds completed builds. Each entry has a timestamp, a brief description of what was built, and a link to the output.

failed/ holds builds that errored. Each entry has the error summary and what was attempted.

A scheduled task runs every 30 minutes. It checks the pending folder. If there's a PRD there, it moves it to in-progress and starts the build. When the build completes, it moves the PRD to done and logs what was built. If the build fails, it moves to failed with an error note.

You also get a build-log.md that maintains a running record of everything the autonomous builder has ever built.

The PRD spec for the autonomous builder

Add this to your PRD under autonomous builder project

AUTONOMOUS BUILDER PROJECT

Goal: A system that picks up PRDs from a pending folder and builds them autonomously, usually overnight, without any input from me.

Folder structure:
autonomous-builder/
  pending/          # PRDs waiting to be built
  in-progress/      # Currently active build
  done/             # Completed builds
  failed/           # Failed builds with error notes
  build-log.md      # Running log of all builds
  CLAUDE.md         # Autonomous builder rules

Scheduled task:
- Run every 30 minutes
- Check pending/ for any .md files
- If found: move the first file (oldest by creation date) to in-progress/
- Read the PRD and build according to its instructions
- On completion: move to done/, write a completion summary, update build-log.md
- On failure: move to failed/, write an error summary, update build-log.md
- If pending/ is empty: do nothing, wait for the next 30-minute check

AUTONOMOUS BUILDER RULES (CLAUDE.md for this project):
- Always read the full PRD before starting any build
- If the PRD is ambiguous or missing critical information: move to failed/ with a note explaining what information is needed. Do not guess.
- Do not ask for clarification during a build. The PRD must be self-contained.
- Build in the location specified by the PRD. If no location specified: create a new subfolder in projects/ named after the PRD.
- Document what was built in build-log.md after every build regardless of success or failure.

Success criteria: I can drop a well-written PRD into pending/ before bed and wake up to a completed project in done/.

How to write a PRD for the autonomous builder

The PRD must be self-contained. Cowork cannot ask you questions while you sleep.

Every PRD you drop into the pending folder must have everything Cowork needs to complete the build without asking a single question. The autonomous builder rules explicitly say: if the PRD is ambiguous, move to failed and explain what's missing. Don't guess.

A self-contained autonomous build PRD includes:

# [Project name]

### Problem
[One paragraph: what problem this solves and why it matters now]

### Success criteria
[Numbered list: exactly what done looks like. Be specific. If a file must exist, name it. If a metric must hit a threshold, state the threshold.]

### Scope
In scope:
- [Item 1]
- [Item 2]

Out of scope:
- [Item 1]
- [Item 2]

### Technical requirements
- Output location: [specific folder path]
- Data sources needed: [list each one]
- Dependencies: [any other files, skills, or projects this depends on]
- Output format: [HTML / markdown / Python script / etc.]

### Build steps
1. [Step 1 with enough detail that Cowork doesn't need to interpret]
2. [Step 2]
3. [Step 3]

### Test
[How to verify the build succeeded]

For GTM engineers, good autonomous build candidates: a new client research brief template, a campaign brief generator, a reply classifier for a new ICP segment, a weekly performance summary for a specific client, a skill for a new research type you're doing repeatedly.

The mission control dashboard for the builder

See what was built without opening any folders

The mission control dashboard (built in Step 5) shows you exactly what the autonomous builder has done. When you wake up, you open one HTML file and see:

• What was in progress when you went to bed
• What moved to done overnight
• What moved to failed (and why)
• What is still pending

This means you never need to dig through folders. The dashboard is the view. The folders are the storage.

Once the autonomous builder is running, the most useful habit is to spend 5 minutes every Friday afternoon dropping 2-3 well-written PRDs into the pending folder. By Monday morning, you have 2-3 new tools or workflows ready.

What to build first with the autonomous builder

Good first autonomous builds for GTM engineers:

• A client-specific research brief generator that reads a company's website and LinkedIn and outputs a brief in the standard format
• A weekly campaign health report for a specific client, automatically generated from raw metrics
• A LinkedIn post formatter that takes your rough notes and structures them into your post format
• A prospect signal monitor that checks target accounts for hiring, funding, and tech changes weekly
• A reply classification skill for a new objection type you've started seeing frequently

Start with the simplest possible build. Confirm it works end-to-end. Then increase complexity on subsequent builds.