Claude Code + Cowork
From prompting an app to directing an agent.
Cohort 3
Week 2 live build
Last week you shipped Pennywise.
You prompted an app builder and got a working app. This week you go under the hood without becoming an engineer.
Today you will:
Direct an agent inside your real project
Add a feature Lovable could not build cleanly
Fix a break yourself
Run the product work around it in Cowork
Two demos, then we build.
Demo 1: Point Claude Code at Pennywise. Ask it to explain your own app back to you.
Demo 2: Ask it to make one small visible change, live.
The point: it read your actual project. Not a prompt. Your code.
Two ways to build with AI.
From "I made a prototype" to "I can extend a real product"
Two tools, one product.
Claude Code → the app. Cowork → around the app. Same posture in both: you direct, you review, you approve.
Claude Code
Cowork
You direct and approve.
An agent is a loop, not a magic answer.
Context → Plan → Act → Review → repeat. You stay in the loop at Review. Nothing lands until you approve it.
Review is your checkpoint
↺ repeat back to Context
You are not learning to write code.
You are learning to read and approve changes.
Good direction: clear ask, right context, plan before build, review the diff.
If you can read a change and say yes or no, you can build.
Connect Claude Code to Pennywise.
The safe path: your project lives in GitHub, Claude Code works there, nothing risky runs on your machine.
You review every change as a diff before it lands.
Open Cowork alongside.
Claude Code has your codebase.
Cowork has your product brain: notes, docs, research, copy.
Two windows, one build.
CSV import, auto-categorise, monthly summary.
Genuinely beyond comfortable prompt-to-app territory. This is where Claude Code earns its place.
By the end, Pennywise does something Lovable could not do cleanly
Point it at the app.
Give the agent the lay of the land before it touches anything.
You are helping me understand my own project before we change anything. Read the full Pennywise codebase and tell me, in plain English for a non-engineer: 1) what the app does end to end, 2) the main files and what each one is responsible for, 3) where and how expense data is stored, 4) anything that looks unfinished, fragile, or likely to cause problems later. Do not change any code. End with a short list of what you would need from me before adding a new feature.
Plan first.
Ask for a plan before any code. This is your steering moment.
I want to add three things to Pennywise: 1) import bank transactions from a CSV file the user uploads, 2) automatically categorise each transaction, 3) a monthly summary view showing total spend per category. Before writing any code, give me a step-by-step build plan. For each step tell me what you will change, which files it touches, and what I will be able to see or test when that step is done. Flag any decisions you need me to make. Keep the steps small enough that I can review each one. Do not write code until I reply 'go'.
Read the plan. If it is wrong, correct it here, not after 200 lines.
Build it, one step at a time.
Let it build. Approve as you go.
Go. Build only step 1 from the plan. When you are done: 1) show me exactly what changed as a diff, 2) explain in one or two plain sentences what this step does, 3) tell me how to test it right now, 4) stop and wait for me before starting step 2. If you hit anything ambiguous, ask me instead of guessing.
Reading a diff.
Green is added, red is removed. Check: does it match what I asked, does it touch anything it should not, does it still make sense.
You do not need to understand every line. You need to spot the wrong ones.
It broke.
That is not a dead end anymore. Describe the symptom, not the fix.
Something is broken. Symptom: when I upload my CSV, the monthly summary shows nothing and I get an error on screen. Here is exactly what I see: [paste the error message and describe what you clicked]. Do not start rewriting yet. First find the most likely cause and explain it to me in plain English. Then propose the smallest fix that solves it. Once I say go, make only that fix, show me the diff, and tell me what the actual problem was so I learn from it.
Closing the loop with Cowork.
You built the feature. Now do the work around it. Build → Document → Research → Position → back to Build.
↺ all agent-assisted · Build hands off from Claude Code into Cowork
Turn what you built into a one-page PRD.
Act as a product lead helping me document a feature I just shipped. The feature: Pennywise now lets a user upload a bank CSV, auto-categorises the transactions, and shows a monthly summary by category. Write a one-page PRD with these sections: Problem, User, What it does, Out of scope, Success (with one or two concrete signals). Keep it under one page, plain language, no jargon. Ask me any question you need before writing.
Research the field.
Research the expense-tracking space for me. Find three real tools that let users import transactions from a bank or CSV. For each one give me: the name, one line on who it is for, one thing it does better than my Pennywise feature, and one thing it does worse or is missing. Use current information. Then in two sentences tell me where a simple, private, self-built tracker like Pennywise actually has an edge.
Write the launch post.
Write a short LinkedIn post announcing that I just built CSV import and a monthly summary into my own expense app, Pennywise, during a bootcamp using Claude Code. Voice: direct, warm, first person, no hype, no em dashes. Structure: a one-line hook, two or three lines on what I built and why it was satisfying, one line on what I learned about directing an AI agent, and a soft invitation to follow along. Keep it under 120 words and give me two versions.
Four prompts you keep forever.
Explain
Read the full codebase. Plain English: what it does, main files, where data lives, what looks fragile. Change nothing.
Plan
Step-by-step plan with files touched and how to test each step. Flag decisions. No code until I say go.
Debug
Symptom and what I see first. Explain the cause, propose the smallest fix, wait for go.
Document
One-page PRD: Problem, User, What it does, Out of scope, Success. Plain language.
Lovable, Claude Code, or Cowork?
| Lovable | Claude Code | Cowork | |
|---|---|---|---|
| Best for | Fast first build, UI | Extend, fix, customise | PRDs, research, copy |
| You give it | A brief | Your repo + direction | Notes, docs, goals |
| You get back | A running app | A diff to approve | Drafts and synthesis |
They are a stack, not rivals.
Where builders trip, and the fix.
Claude Code skills, methods, integrations.
You have felt the basic loop. Here is the layer that makes it repeatable and connected.
All blue today. Lavender accents. Full reference on the syllabus: Skills, Subagents, MCP, Cowork setup.
Open full going deeper guide →Beyond prompting: the Claude Code stack
So far you have been directing Claude Code live. That is the surface. Underneath sit a few pieces that make it repeatable, reliable, and connected.
This is what turns a clever assistant into a system.
CLAUDE.md: your project's rulebook
The one file Claude Code reads every single session. Put in it the things that are always true about your project:
- What the app is and how it is built
- The commands to run it
- Rules it must never break (for example, do not touch the payments code)
You do not write it by hand. Type /init and Claude Code reads your project and drafts it for you.
Why it matters: you stop re-explaining your project every time. It just knows.
Skills: teach it once, reuse forever
A Skill is a saved workflow Claude Code can run on demand. It lives as a SKILL.md file with a name and a description. Two ways it fires:
- Claude reads the description and uses it automatically when it fits
- Or you call it directly, like /add-feature
Example for Pennywise: your Week 2 method, saved once, reused on every feature. They are cheap. Keep many, pay only for the ones you use.
Subagents: workers off to the side
A Subagent is a second Claude Code with its own fresh, separate context. Use it when a job would clutter your main session:
- "Go read all 40 files and summarise how data flows" while your main chat stays clean
- A research worker that gathers, then reports back
A safe default: give workers read-only access, and let the main agent make the actual changes after you approve.
Heavy digging happens off to the side. Your main thread stays focused on the decision.
Connect Claude Code to your real tools
Claude Code does not have to stay inside your files. Through integrations (MCP) it can reach:
- Your GitHub and your Supabase database
- Gmail, Notion, Trello, and hundreds more
- Internal tools and APIs
For Pennywise, the useful ones are your code host and your database, so the agent works on the real thing, not a copy.
One caution: each connection adds weight. Connect what you need, not everything you can.
Which do I reach for?
| When | Reach for |
|---|---|
| Always true about the project | CLAUDE.md |
| A workflow you repeat | Skill |
| A big job that would clutter the chat | Subagent |
| Something outside your files | Integration (MCP) |
| Share it all with your team | Plugin |
You will not use all of these this week. You now know the shape of the system you are growing into.
Prompts, homework, and the syllabus.
Open on your phone or second screen. Copy prompts one tap at a time.
Also on the Week 2 syllabus page under Homework.
Ship your second Pennywise feature
Claude Code from plan to working. Document in Cowork. Create a /new-feature skill. Publish on LinkedIn. Graded on process, not polish.
- Search and filter by name or category
- Budget limit per category with alert
- Export monthly summary as PDF
- Six-month spend chart
- Recurring expense detection
Something Lovable would struggle to do cleanly.
- Plan prompt → go
- Build step by step, review diffs
- Debug prompt if it breaks
- PRD in Cowork
- /new-feature skill, use once
- Publish LinkedIn post
- Feature works in your live app
- Explain one diff in one sentence
- One-page PRD in Cowork
- /new-feature skill created and used
- Before and after in WhatsApp
- LinkedIn post published
Full brief → syllabus homework guide
Stretch: plain-English note in your repo. Time: 60 to 90 min. Stuck 15+ min? WhatsApp.
#BUILDINPUBLIC
A screenshot, three lines, a short walkthrough. Show that you ship AI features. People notice builders.
n8n + Hermes Agents.
Wire Pennywise to the real world. Notifications, monitoring, a briefing that runs without you.
Same posture: you direct, the agent works
Questions in the WhatsApp group.
Recording and slides land after the session.
See you in Week 3