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.
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 PRDthat 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:- Tina asks Cowork (or Claude Code, for advanced projects) to brainstorm projects to improve her business/life.
- Cowork drafts PRDs for the approved projects, files them in
pending/. - A 30-minute scheduled task polls
pending/and picks up any new PRD. - Cowork moves the PRD to
in-progress/and starts building. - On completion, file moves to
done/; on failure, tofailed/. - Logs are written separately for each build.
- 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:
| Section | Rule |
|---|---|
| 1. Building things | PRD first always. Articulate problem, success criteria, scope, constraints, build plans. Ask open questions before building. Ask explicit sign-off. |
| 2. Pushback & clarification | Push 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-taking | Document everything aggressively. Memory management is part of the agent’s personality, not a one-off behavior. |
| 4. Reversibility | Always 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.
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:
| Article | Organizing principle | Best for |
|---|---|---|
| Jeff’s Three-Level Jarvis Build | Rule-stacking (root → workstation → project CLAUDE.md) + persistent memory + workstation auto-creation | Personal AIOS — distinct life areas (Email HQ, Personal Finances, Travel) co-existing on one Cowork instance |
| Eliot Prince’s Live Artifacts | Seven 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 observability | Operator 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
- 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.
- Install the four-section operating instructions at Cowork → Settings → Cowork. PRD-first + pushback + note-taking + reversibility. These compound across every project.
- 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).
- 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. - 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.
- 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.
Related
- Jeff’s Three-Level Jarvis Build — complementary Cowork-personal-AIOS pattern (rule-stacking)
- Cowork Live Artifacts (Eliot Prince) — complementary dashboard-centric Cowork pattern
- Cowork Getting Started — Cowork basics that this build assumes
- Claude Cowork product overview — parent surface
- Cowork Plugins — productivity plugin +
/startskill referenced for memory bootstrap - Nate Herk Hermes 1-Hour Course — sister Hostinger-VPS setup pattern on a different agent runtime
- 2026 Claude Code AIOS Pattern — meta-architecture of which Tina’s setup is the Cowork-surface instance
- Claude Surfaces Decision Framework — Cowork-vs-Code split Tina herself uses
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 — Tina links three load-bearing prompts (the operating-instructions meta-prompt, the Mission Control PRD generator, the “please start building with the mission control PRD” project-init line) in her video description. These should be captured into the WEO prompt library if/when Tina makes the templates publicly downloadable.
- 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.