Jonathon's AI Wiki

Cowork Mission Control Setup (Tina Huang) — PRD-First Build + Overnight Autonomous Builder

14 min read

Source: YouTube walkthrough by Tina Huang, 2026-05-20, youtube.com/watch?v=gdrPkpXuNks — “My Full Claude Cowork Setup (steal my workflows)”, 9-minute deep-build tour showing a working personal Cowork system: morning digest on Apple Notes + investment dashboard + mission-control dashboard + autonomous overnight builder folder workflow. Sponsored by Hostinger. Auto-caption normalizations: “Co-work” / “Corore” / “Cork” / “Clogco” → Cowork; “claw” → Claude; “openclaw” → OpenClaw; “PR” (in build context) → PRD.

Refreshed 2026-05-31 with Tina’s official Lonely Octopus companion resource doc (ai-research/lonelyoctopus-tina-cowork-mission-control-setup-2026-05-31.md, resource.lonelyoctopus.com) — the public text companion to the same video. Adds the three verbatim stealable prompts (Config / Project Instruction / PRD metaprompts) and the Productivity-plugin build conventions the 9-minute video only narrated, resolving this article’s prior “capture the prompt artifacts” open question.

Tina Huang’s full Cowork setup — distinct from Jeff’s three-level Jarvis pattern in that it centers on PRD-first build discipline + an overnight autonomous-builder folder workflow that drafts/picks-up/builds projects on a 30-minute cron without user interaction. Where Jeff’s pattern is rule-stacking + memory persistence and Eliot Prince’s pattern is seven live-artifact dashboards, Tina’s pattern is plan-then-build-then-poll: every project starts with a Product Requirements Document, Cowork drafts PRDs into a pending/ queue, a scheduled task picks them up every 30 minutes and builds them, output moves through in-progress/ → done/ (or failed/). User wakes up to finished projects.

Key Takeaways

  • PRD-first is the load-bearing rule. Tina’s Cowork operating-instruction prompt has four sections, but the first one — Building things — is the most prescriptive: “PRD first always”, “include problem articulation, success criteria, scope, constraints, build plans”, “ask any open questions to make sure that Cowork understands what it’s building”, “ask for explicit sign-off before building.” The framing: blueprint-before-house. “You can technically YOLO make a blueprint that’s like not very good and then your building is also going to be not very good and like fall down or something.”
  • Mission Control build PRD — the meta-PRD that scaffolds every other PRD. The setup begins by generating a single very-long PRD called Mission Control Build PRD that specifies the entire personal Cowork architecture (folder structure + initial projects + build plan + skills + memory architecture). Tina ships a prompt (linked in her description) that asks the user clarifying questions and writes the personalized version of this meta-PRD. The meta-PRD is then handed to Cowork as the build target.
  • Five-hour initial build, hour-by-hour structure. Tina explicitly tells Cowork “I have 5 hours to build out all these things” and the meta-PRD lays out a 5-hour build plan: Hour 1 sets up the data layer (folder structure + task pipelines pulling fresh data); Hours 2-3-4 build projects on top of the data lake (investment dashboard, morning brief, autonomous builder); Hour 5 is polish (notifications + end-to-end testing). Tina reports the timing was accurate.
  • The data-lake analogy. Tina’s mental model of Cowork architecture: “You have a big hole, but you got to fill it with water. So you need to set up different pipelines for water to trickle into the lake and for it to be constantly moving.” The water = data. The pipelines = scheduled tasks fetching fresh data from connectors. Hour 1 builds the lake; subsequent hours build “things on top” (dashboards, briefs, generators) that take data from the lake + transform/present it. Useful unifying frame for newer Cowork operators.
  • Three operating-instruction sections beyond PRD-first: pushback, note-taking, reversibility. “I want Claude to push back on me, question what I’m doing and to disagree when the plan seems off-strategy, technically wrong or inconsistent with prior decisions… I am not infallible.” “Take notes aggressively. Memory management is really important when it comes to Cowork.” “Always confirm before doing anything that is hard to reverse. If in doubt, stop and ask. Interrupting with a question is always cheaper than silently destroying something.” All three are encoded as personality traits at the operating-instruction layer so Cowork’s behavior compounds across every project.
  • Three starting skills + autonomous builder. Tina seeds Cowork with three skills on initial build: /today (pulls morning brief on demand + supports updates), /research (deep-dive a specific stock by ticker — updates the investments dashboard), /prep (preps Tina for upcoming meetings — pulls context on attendees from her calendar). Plus the headline pattern — the autonomous-builder skill.
  • Autonomous Builder — pending/ → in-progress/ → done/ → failed/ folder pipeline. This is the novel-pattern contribution. Mechanics:
    1. Tina asks Cowork (or Claude Code, for advanced projects) to brainstorm projects to improve her business/life.
    2. Cowork drafts PRDs for the approved projects, files them in pending/.
    3. A 30-minute scheduled task polls pending/ and picks up any new PRD.
    4. Cowork moves the PRD to in-progress/ and starts building.
    5. On completion, file moves to done/; on failure, to failed/.
    6. Logs are written separately for each build.
    7. Mission Control dashboard renders the queue states visually.
  • Concrete overnight build example. Tina reports waking up that morning to find Cowork had built her a “Resource Hub” project autonomously — drafted as a PRD the night before, picked up by the scheduled task, built end-to-end while she slept. The Cowork Max plan + Hostinger VPS combo is what makes this work (laptop-sleep-is-not-the-end).
  • Hostinger VPS is the always-on enabler — sponsored framing, but the architectural point is real. “The second your laptop sleeps, your agent dies with it… this is the same problem with all local AI agents like OpenClaw, Hermes, and Cowork.” Tina’s deployment runs on a Hostinger KVM 2 plan with Cowork pre-configured as a template. Same architectural choice as the Nate Herk Hostinger setup for Hermes — different agent, same VPS-instead-of-laptop infra reasoning. This is the universal cost of overnight autonomous builds: the agent has to live somewhere that doesn’t sleep.
  • Memory bloat is the real long-term failure mode. “As time goes on, Cowork does start forgetting things. It’s not as bad as OpenClaw if you’ve used OpenClaw before, but your memory system does start bloating.” Tina has implemented a more complex memory system (deferred to a part-three video) — adjacent to the B-tree bootstrap pattern from the Hermes user-stories catalog and to the broader Claude Code memory architecture thesis.
  • Dashboards as a discipline, not a feature. “Dashboards is one of my favorite things to build whenever I do a project because it allows me to visualize things and monitor what’s going on.” Beyond the investment + mission-control dashboards shown, Tina mentions tracking dashboards for health, day-planning, weekly improvements. Sister pattern to Eliot Prince’s seven-dashboard setup — same impulse, different content focus (Eliot: business ops; Tina: personal + investment + meta-build observability).
  • Cowork for small projects, Claude Code for advanced. “I do also give some tasks, some PRDs to Claude Code depending on how advanced the project is.” Same Cowork-vs-Code split as Antoine’s Hermes business setup (uses Hermes for content, Claude Code for heavy build). Confirms the surfaces decision framework empirically across two different operators on two different agent runtimes.

Tina’s four-section operating-instructions block (verbatim summary)

The Cowork → Settings → Cowork operating-instructions field. Tina’s prompt encodes four personality traits that apply across every project:

SectionRule
1. Building thingsPRD first always. Articulate problem, success criteria, scope, constraints, build plans. Ask open questions before building. Ask explicit sign-off.
2. Pushback & clarificationPush back on me. Question what I’m doing. Disagree when the plan is off-strategy / technically wrong / inconsistent with prior decisions. Flag trade-offs I may not have considered.
3. Note-takingDocument everything aggressively. Memory management is part of the agent’s personality, not a one-off behavior.
4. ReversibilityAlways confirm before anything hard-to-reverse. If in doubt, stop and ask. “Interrupting with a question is always cheaper than silently destroying something.”

The full prompt is linked in Tina’s video description; the four-section framing above captures the load-bearing rules.

The stealable prompts + build conventions (Lonely Octopus companion doc)

Tina’s public resource doc publishes the three load-bearing prompts verbatim and the fixed build conventions the 9-minute video only narrated. Copy-paste-ready:

1. Config Metaprompt — run in the Cowork chat tab to generate your Operating Instructions:

Draft an “Operating Instructions” doc for my Claude Cowork preferences. Make you a sharp thinking partner, not a yes-machine. Cover: About Me – Pull from past conversations: name, role, what my company/team does, public work or side projects with specifics, biggest pain points, tools I use. Missing something? Ask – don’t guess. Building anything – PRD first (problem, success criteria, scope, constraints, plan, open questions); get sign-off before building. Check what already exists before proposing custom work. Pushback – Interrogate vague requests. Disagree when something’s off. Flag contradictions before acting – never silently overwrite. No sycophancy. Reversibility – Before anything destructive (deleting, overwriting, comms in my name, financial actions, mass ops): show the plan, flag what’s irreversible, wait for explicit “proceed.” Note-taking – Capture context, decisions, and open threads continuously. Checkpoint before switching domains or when a chat runs long. Working style – Show reasoning, not just conclusions. Breadth and rigor. Skip filler. If I say “things changed,” re-interview me. Show me the draft, then we’ll revise.

2. Project Instruction — paste into the Cowork project’s custom-instructions field (swap the “About Me” for your own):

You are managing my mission control workspace. I’m Tina — CEO of Lonely Octopus, active investor, and creator of @TinaHuang1 on YouTube. This workspace coordinates investment tracking, daily operations, content planning, and code builds. When operating in a specific subfolder (investments/, personal/, etc.), respect that folder’s CLAUDE.md for voice and approach. Default tone: rigorous, direct, no fluff. Cover things properly but don’t pad responses. I value breadth and rigor equally — cast a wide net, do it well. Always reference PRD-mission-control.md at the project root for the authoritative architecture and component specs before making structural changes.

3. PRD Metaprompt — run in claude.ai chat (NOT Cowork) to produce a build-ready PRD-mission-control.md you then hand to Cowork. The full ~600-word text is in the public doc; it interviews you in phases (Phase 0 orient-from-memory → Phase 1 propose domains / confirm environment / ask build-length / fill gaps → Phase 2 architecture sketch + sign-off → Phase 3 produce the PRD). Its Fixed conventions — identical across every PRD it generates, only the domains and build length vary — are the reusable core:

  • Foundation = Cowork’s Productivity plugin. Installed via Cowork → Customize → Plugins → “Productivity”, initialized once with /start, which creates at the project root: CLAUDE.md (cross-cutting working memory), TASKS.md (task list), memory/ (deep-memory dir), dashboard.html. Also provides /update and a create-skill workflow. Never hand-roll a separate memory file, task list, or config — build on the plugin.
  • Block 0 (Setup) precedes any data-layer work: project created + pointed at a local folder → plugin installed → /start run → needed connectors enabled. Only then does Block 1 begin.
  • Fixed root skeleton: ~/cowork/ containing CLAUDE.md, TASKS.md, memory/ (people.md, terminology.md, {domain}/), dashboard.html, PRD-{system}.md, toolbox/ (installable custom skills, source of truth), briefs/ (+ archive/), and one {domain}/ folder per domain.
  • Per-domain folder pattern (identical shape): {domain}/CLAUDE.md (folder-level voice/role) + inputs/ (human-maintained, never auto-overwritten) + data/ (machine-refreshed derived files) + outputs/ (generated artifacts).
  • Three-tier memory: root CLAUDE.md (cross-cutting — people, terminology, shorthand) / memory/{domain}/ (deep per-domain knowledge) / {domain}/CLAUDE.md (role + tone when working inside that domain).
  • Scoping rule (build length sets domain count): ~3h = foundation + 1 domain + a morning brief; ~5h = foundation + 2 domains (or 1 rich domain + the builder pattern); ~8h = foundation + 2–3 domains; never more than ~4 active domains in one window — fully build the highest-priority ones, leave the rest as placeholder folders.
  • PRD §1–§10 structure: executive summary / quick-start handoff into Cowork / goals + non-goals / architecture overview / the data layer (every data file gets an explicit schema with real field names + example values, never “schema TBD”) / component specs / the build plan (opens with Block 0; Block 1 is always the data layer; table columns Block | What gets built | Who runs it | Output | Done when…) / setup + copy-paste prompts (each with a CRITICAL: never write to inputs/ guard) / decision log (~8–15 rows) / out-of-scope.
  • Naming conventions: folders kebab-case; memory files noun.md; data files noun.json; date-stamped files name-YYYY-MM-DD.md. The data layer is local — connectors (Drive/Gmail/Calendar/Notion) are data sources, never storage; the build never creates folders in Google Drive.

Where this fits in the Cowork-pattern landscape

Three Cowork-on-Cowork patterns now catalogued in this wiki — each from a different operator, each with a distinct organizing principle:

ArticleOrganizing principleBest for
Jeff’s Three-Level Jarvis BuildRule-stacking (root → workstation → project CLAUDE.md) + persistent memory + workstation auto-creationPersonal AIOS — distinct life areas (Email HQ, Personal Finances, Travel) co-existing on one Cowork instance
Eliot Prince’s Live ArtifactsSeven dashboard artifacts replacing daily tool-hopping (Competitor Move Tracker, Daily Command Center, Daily Financial Position, SEO Pulse, Support Pulse, Sales Pulse, YouTube Morning Dashboard)Operational business owner who wants morning-tool-hopping replaced with dashboards
This article (Tina’s setup)PRD-first + overnight autonomous-builder + dashboard observabilityOperator who wants Cowork to build new projects autonomously while they sleep, with explicit blueprint-before-build discipline

Tina’s pattern is plan-then-build-then-poll-then-monitor. The others are organizational/operational; Tina’s is generative. Operators can compose all three.

Try It

  1. Generate your Mission Control PRD first. Use Tina’s linked PRD-generator prompt (in her video description) in claude.ai chat. Answer the clarifying questions honestly — the meta-PRD that emerges is your personal Cowork blueprint.
  2. Install the four-section operating instructions at Cowork → Settings → Cowork. PRD-first + pushback + note-taking + reversibility. These compound across every project.
  3. Allocate 5 uninterrupted hours for the initial build. Tina’s timing was accurate. Hour 1 = data layer (folders + scheduled tasks for fresh data); Hours 2-4 = projects + skills (Tina’s pattern: today/research/prep skills + one starter dashboard); Hour 5 = polish (notifications + end-to-end).
  4. Wire the autonomous-builder pipeline only after the data layer is solid. The four-folder workflow (pending/ → in-progress/ → done/ → failed/) needs a 30-minute scheduled task and a mission-control dashboard to be useful. Start by drafting two project PRDs, let Cowork pick one up overnight, see how it goes.
  5. For always-on overnight builds, use a VPS (Hostinger Cowork-template KVM 2 plan is the sponsored option; any always-on Linux box works). Otherwise your laptop sleep kills the run.
  6. Plan ahead for memory bloat. Tina explicitly flags this as the long-term failure mode. Adjacent reading: the B-tree bootstrap pattern for token-cost-optimized AGENTS.md/MEMORY.md structures.

Open Questions

  • Tina’s part-three memory architecture — she defers the “more complex memory system” to a future video. Worth tracking — could become a sister article on Cowork-specific memory patterns adjacent to the Claude Code memory architecture comparison.
  • The autonomous builder failure-rate — Tina says she’s used “a lot” of what got built but skips the rate of failed builds vs successful builds. Worth knowing for operators sizing the pattern.
  • Concrete prompt artifacts — RESOLVED (2026-05-31). The three load-bearing prompts (Config / Operating-Instructions metaprompt, Project Instruction, and the Mission Control PRD metaprompt) are now captured verbatim above (see “The stealable prompts + build conventions”) from Tina’s public Lonely Octopus resource doc. The project-init line is "Please start building with the mission control PRD." The full ~600-word PRD metaprompt remains canonical at the public doc; consider mirroring the trio into the MEGA PROMPT CHEST if a reusable-prompt home is wanted.
  • Scheduled-task implementation detail — the 30-minute poll of pending/ is implemented via Cowork’s scheduled-task surface, but the prompt that drives the poll isn’t shown. The exact body matters for replication.
  • Claude Code vs Cowork PRD routing rule — Tina says she sometimes routes PRDs to Claude Code for “more advanced” projects. The actual decision rule (size? complexity? language? dependency count?) is not specified — would help calibrate operator routing.

Graph View

Backlinks