In the live session you felt the basic loop: plan, change, review the diff, keep or roll back. That is the surface. Underneath sits a stack that makes directing code repeatable across sessions and teammates: persistent project memory, reusable workflows (Skills), isolated workers (Subagents), and connections to real tools (MCP). Cowork sits beside this stack for the work *around* the product: PRDs, research, launch copy.

This guide pulls from Anthropic's Claude Code documentation and the Week 2 session. You do not need every piece on day one. You need to know what exists, when to reach for it, and how to set up the basics on Pennywise or your capstone.

1. Set up Claude Code on your project

Claude Code is an agentic coding assistant that reads your whole repo, edits files, runs commands, and shows you diffs. It runs in a terminal (or VS Code / Desktop / Web), pointed at the folder where your code lives.

1. 1

   Install

   On Mac/Linux: `curl -fsSL https://claude.ai/install.sh | bash`. Or install the VS Code / Cursor extension and search for "Claude Code". See Claude Code overview for Windows and other options.

2. 2

   Open your project folder

   If Pennywise (or your capstone) lives in Lovable, export or sync the code to a local folder first. `cd` into that folder. Claude Code works on files on disk, not on Lovable's cloud editor directly.

3. 3

   Start a session

   Run `claude` in the project root. Log in on first use. You now have a coding agent with your repo as context.

4. 4

   Trust the workspace (first time)

   When Claude Code loads project Skills or settings from `.claude/`, it may ask you to trust the folder. Read what is in `.claude/` before accepting, same as you would before running unknown scripts.

2. CLAUDE.md: what the agent always knows

Every Claude Code session starts with a fresh context window. `CLAUDE.md` is how you give Claude persistent instructions that load at the start of every session: what the app is, how to run it, conventions, and rules it must not break.

• Project `./CLAUDE.md` or `./.claude/CLAUDE.md`: shared with your team via git. Architecture, build/test commands, "never touch payments without asking."
• Personal `~/.claude/CLAUDE.md`: your preferences across all projects.
• Local `./CLAUDE.local.md`: personal overrides for this repo (usually gitignored). Sandbox URLs, test accounts.

Treat CLAUDE.md as facts you would otherwise re-type every session. Do not paste long multi-step procedures here; those belong in Skills (loaded only when used). Keep CLAUDE.md concise: specific rules work better than essays.

1. 1

   Generate a draft

   In Claude Code, run `/init`. It reads your codebase and drafts a CLAUDE.md with build commands, test instructions, and conventions it discovers. If one already exists, `/init` suggests improvements instead of overwriting.

2. 2

   Edit what matters

   Add what `/init` missed: "This is a Lovable + Supabase expense app", "Run dev with …", "Do not change auth without explicit approval", "Expense categories are fixed: Food, Transport, …".

3. 3

   Commit it

   Commit `CLAUDE.md` to git so every session (and teammate) gets the same baseline.

3. Skills: workflows you teach once

A Skill is a folder with a `SKILL.md` file: YAML frontmatter (`name`, `description`) plus markdown instructions. Claude discovers Skills automatically when the description matches your task, or you invoke one directly with `/skill-name` (e.g. `/new-feature`).

Skills follow the open Agent Skills standard. Claude Code extends it with invocation control, optional subagent execution, and bundled scripts. Unlike CLAUDE.md, a Skill's body loads only when used, so long checklists cost almost nothing until you need them.

• Personal `~/.claude/skills/<name>/SKILL.md`: available in all your projects.
• Project `.claude/skills/<name>/SKILL.md`: shared with the repo. Best for team workflows and homework.
• Nested `packages/foo/.claude/skills/`: monorepo packages can ship their own skills.

Create a Skill when you keep pasting the same instructions: "plan first", "write tests like this", "deploy staging". Your Week 2 homework asks you to save the plan-first build method as `/new-feature`.

---
name: new-feature
description: Plan a feature step by step before writing code. Use when adding or changing product functionality in this repo.
---
When I ask for a new feature or change:

1. Read the relevant parts of the codebase first. Do not edit yet.
2. Write a step-by-step plan: what changes, which files, how I test each step.
3. Flag decisions you need from me.
4. Wait for me to say "go" before writing code.
5. Build one step at a time. After each step, show the diff and wait for approval.

1. 1

   Create the skill (homework)

   Ask Claude Code: "Create a skill called new-feature that always plans before writing code, builds one step at a time, and shows me the diff before each step. Save it as SKILL.md in this project." Or paste the example above into `.claude/skills/new-feature/SKILL.md` yourself.

2. 2

   Invoke it

   Type `/new-feature` before your next change, or describe the task and let Claude pick it when the description matches.

3. 3

   Test it

   Give a task that should trigger the skill ("add export to CSV"). Confirm it plans before coding. Give a unrelated task ("fix typo in README") and confirm it does not force the full feature workflow unless appropriate.

4. Subagents: workers with their own context

A Subagent is a separate Claude Code instance with a fresh context window. The main session stays focused on your decision; the subagent does heavy reading or research and returns a summary.

Claude delegates automatically when appropriate. You can also spawn workers explicitly. Built-in subagents include:

Custom subagents live in `.claude/agents/` or `~/.claude/agents/` as markdown files with frontmatter: `description`, `tools`, `permissionMode`, optional `skills` preload, and MCP scope.

Skills + Subagents together: a Skill with `context: fork` runs inside a subagent. A subagent with a `skills` field preloads skill content at startup. For homework, a plain project Skill (`/new-feature`) in the main session is enough.

5. MCP: connect Claude Code to real tools

Model Context Protocol (MCP) is an open standard for connecting AI tools to external systems. Through MCP, Claude Code can reach GitHub, Supabase, Slack, Notion, browsers, and hundreds of other services without you copy-pasting data into chat.

Connect MCP when you find yourself copying issue text, schema details, or logs into the terminal. Once connected, Claude reads and acts on the source directly.

• GitHub: open PRs, read issues, comment on reviews from the terminal.
• Supabase / Postgres: inspect schema, run read queries against your Pennywise database (use read-only credentials for exploration).
• Sentry / monitoring: pull error context while debugging.
• Figma / Slack / Gmail: pull design or comms context into a build or PRD workflow.

1. 1

   Browse connectors

   See Anthropic's MCP directory and reviewed connectors. Verify you trust a server before connecting.

2. 2

   Add a server

   In Claude Code: `claude mcp add` or `/mcp` to configure. Project-level config can live in `.mcp.json` (commit team servers) or user-level config for personal tokens.

3. 3

   Start small

   For Pennywise homework, GitHub + Supabase (if you use it) are the highest leverage. Do not connect everything at once; each server adds tools and token overhead.

6. Cowork: setup for knowledge work

Cowork is Anthropic's agentic surface for knowledge work, not repo edits. Where Claude Code changes Pennywise, Cowork drafts PRDs, researches competitors, rewrites launch copy, and organises files. The directing skill is the same: be specific, scope the task, check the output.

1. 1

   Get access

   Cowork runs inside Claude (claude.ai / Claude desktop) for subscribers with access to Cowork features. See Claude help center for current availability in your plan.

2. 2

   Bring context

   Attach or point Cowork at your notes: what you built, screenshots, the PRD sections you need. Paste the Cowork prompts from the session deck or homework sheet.

3. 3

   One repeatable workflow

   Pick one task you repeat: "turn this feature into a one-page PRD", "research three competitors", "draft LinkedIn post from my bullet notes". Save the prompt pattern; reuse every ship.

4. 4

   Publish, do not draft

   Homework requires a published LinkedIn post. Cowork gives you two versions; you pick one, add a screenshot or short video, and post.

7. Which do I reach for?

You will not use all of these in Week 2. You will use the plan-build-debug loop, one Skill, Cowork for a PRD and LinkedIn post, and optionally `/init` for CLAUDE.md. The rest is the system you are growing into for capstone weeks 3 and 4.