如何为产品工作组织 Claude Code

我的产品工作 Claude Code 工作区，是一个几乎不包含代码的文件夹。它有一个 context 文件夹，存放与公司有关的一切：产品、用户、竞品，以及我的工作偏好。每个项目各有一个文件夹，任务和交付物分开存放。有一组技能，每项只负责一类重复性工作：状态更新、PRD 审阅、访谈综合。当我给出一次反馈，它就会写入某个文件并说明原因，因此我再也不必重复给出同样的反馈。这套系统不是我设计出来的，而是我主要通过先做错、再调整，逐渐摸索出来的。

犯错让我学到了贯穿全文的一课。**越过基础阶段后，你在 Claude Code 中的结果，不再取决于你提示得多好，而开始取决于你归档得多好。**一个好提示词只能改善一次会话；一个好文件能改善之后的每一次会话。你已经读过的提示词调优建议，恰恰会在文件归档开始变得重要的那个阶段失去作用。

所以，与其描述我的系统，我把它打包了。**入门工作区已在 GitHub 公开：包括文件夹、上下文模板和五项 PM 技能，只需通过一次设置访谈即可完成个性化。**你不需要具备技术背景也能跟着做；每一步都写得很清楚，包括工具安装。虽然我的示例是产品工作，但同样的架构适用于任何依赖大量上下文的工作：设计负责人的研究资料库、数据团队的指标定义，或创始人包罗万象的工作文件夹。

路线如下。

• **转变。**我会说明聊天模式和 Cowork 无法提供什么，以及为什么对产品经理来说，终端值得使用。

• **入门工作区。**下载它，运行一个设置技能，再交给它一项真实任务：共六步，每一步都会在屏幕上展示。

• **实践方法。**让系统产生复利的六个动作；每个动作都会说明具体要做什么，以及你能得到什么。

• **工作节奏。**展示系统中的一个普通工作日：从第一个简短提示，到两分钟的归档习惯。

回报是具体的。一次专注操作，你就能运行起来：安装工具、下载工作区、完成设置访谈、交付第一项真实任务。**你不再需要每次会话都重新解释公司情况，而你做出的每一项修正都会永久保留。**下面是全部步骤。

是时候打开文件柜了。

---

你今天可能仍通过 Claude 聊天来开展产品工作：浏览器标签页或桌面应用，也许会用 Cowork 执行 Agent 型任务。它确实能用，而这恰恰是陷阱。每段对话都从零开始。你上次上传的战略文档不见了；你耐心解释的上下文，留在一个再也找不回来的对话线程里；你满意的输出被困在对话中，而不是放进文件里。**聊天是思考的好地方，却是积累的糟糕地方。**对于偶尔的问题，这没有关系；但对于每天的产品工作，这意味着你每天早晨都要支付同样的准备成本。

Claude Code 是同一个 Claude，只是换了一个家：它位于你电脑上的一个文件夹里，能够读取、浏览和写入。上下文存在持续保存的文件中。重复性工作存在可按命令运行的技能中。输出会作为你能保留的文档落地，而不是需要滚动查找的消息。**在我的日常使用中，我过去在聊天或 Cowork 中做的所有事情，在这里运行得都更好，因为没有任何内容需要解释两遍。**这是我个人工作中的观察，不是什么普遍规律，但这一点已经持续数月成立。

真正改变我工作的部分，是底层的终端。**Claude Code 原生支持 GitHub，无需连接器：它可以拉取公司的代码仓库并回答有关仓库的问题，也能推送你自己的工作。**让它获取你的产品背后的代码仓库，并解释某个功能开关实际做了什么。把你的工作区推送到私有仓库，团队成员就可以克隆它，并继承你的先发积累。对产品经理而言，这意味着可以直达代码库，也能共享整套系统；而聊天模式两者都做不到。

但没有人会直接交给你那个能让一切产生复利的归档系统。Anthropic 的最佳实践指南按其原话，是为“在各种代码库、语言和环境中使用 Claude Code 的工程师”撰写的；而工程师天然拥有结构：代码库本身就是已经整理好的上下文。现有的 PM 指南中，以Sachin Rekhi 的文章最为知名，它正确地建议你“将所有产品数据和文档存储在本地 Markdown 文件中”，然后就到此为止。该如何组织？如果没有答案就直接尝试，结果会和我当初一样：四十个零散文件和一套过时的设置。**入门工作区就是这个预先构建好的答案。**让我们开始设置。

---

入门工作区是我自己用于产品工作的结构，现已整理成一个模板：包括文件夹、带引导占位符的上下文文件、示例项目，以及五项预装技能。**整套内容免费且公开：claude-code-pm-starter。**只需六步，你就能从零开始完成第一项真实任务；没有任何一步假定你有技术背景。

开始前先说明一个前提条件。使用 Claude Code 需要付费 Claude 订阅。其他一切，包括你将安装的两款工具，都是免费的，并会在步骤中说明。

Claude Code 运行在终端中，而只有终端并不适合产品经理：你看不到文件。解决办法是使用 IDE。**IDE 只是一个编辑器：工作时，它会把你的文件夹显示为文件面板；开发者整天都在用它，而你只是借用其中的文件面板。**下载免费标准工具 VS Code，像安装普通应用一样安装它。你不会在里面写代码。你会在左侧面板看到工作区自行组织起来，这正是聊天模式从未提供的可见性。

VS Code：免费，而且你只会用到其中很小一部分功能。

打开仓库页面，点击绿色的 Code 按钮，然后选择 Download ZIP。不需要 Git，也不需要账号。解压后，将文件夹移动到你平时存放工作内容的位置。这个文件夹即将成为你存放产品工作的地方，所以选一个你之后容易找到的位置，例如主目录中的 work 文件夹。

点击绿色 Code 按钮，然后选择 Download ZIP。不需要 Git。

解压并归档完成：入门文件夹已放在 Work 文件夹中，准备打开。

打开 VS Code，选择 File > Open Folder，然后选中解压后的文件夹。左侧面板现在会显示完整结构：context/、projects/、operations/ 以及各项技能。接着，通过 Terminal > New Terminal 在 VS Code 内打开终端。这里有一个能改变整体体验的小技巧：右键点击终端面板标题栏，选择 Move Panel Right。文件在左，Agent 在右：它不再像命令行，而开始像一位坐在你文档旁边的同事。

终于看见完整结构：技能、上下文、运营、项目和地图文件。

这个技巧：右键点击面板，选择 Move Panel Right。

如果你还没有 Claude Code，现在可按照官方指南安装；只需将一条命令粘贴到该终端。然后输入 claude 并按 Enter。Claude Code 会在这个文件夹中启动，读取地图文件，并从你的第一条消息起就知道所有内容的位置。

文件在左，Agent 在右。

有一个区别能帮初学者避免很多困惑。**终端需要精确命令；Claude 需要自然语言。**在输入 claude 前，你是在和终端对话，那里拼写和语法都很重要。现在 Claude Code 已经运行，你是在和 Claude 对话，体验与聊天应用完全一样。所以先做最自然的事：输入你好，并问它在这个文件夹里能看到什么。它会像一位刚读完你文件的同事那样回答。

第一天有几条值得了解的斜杠命令，直接在 Claude Code 中输入：

• /model - 显示你当前运行的 Claude 模型，并允许你切换。

• /effort - 设置 Claude 在每个回答中投入多少思考；困难工作使用更高 effort，快速草稿使用更低 effort。

• /mcp - 列出你的 MCP，即连接 Jira、Slack 或 Confluence 等工具的实时连接，并允许你管理它们。

• /plugins - 打开插件系统，这项值得花一分钟了解。Claude Code 默认提供 Anthropic 的插件目录，还可以额外添加市场。其中有一个专门为产品经理设计：pm-skills，包含一百多项 PM 技能，覆盖发现、战略、执行和发布；其 README 提供最新安装说明。pm-execution 覆盖 PRD、OKR、路线图和复盘；pm-product-discovery 则增加访谈和假设验证。安装与你工作匹配的两三项，而不是全部九项；每个已安装插件都会成为系统需要携带的上下文。

插件面板：默认就有 Anthropic 的市场。

再介绍一个控制项，你就完成导览了：按 Shift+Tab 可在 Claude Code 的三种模式间循环切换。

• 默认模式会在触及任何文件前征求你的许可。

• 自动接受模式会直接应用编辑，而不再询问。

• 计划模式最值得记住：Claude 会研究并提出计划，在你批准前不会修改任何内容。

**先从默认模式开始；大型工作使用计划模式；自动接受模式则留给你已经学会信任的工作。**除此以外，我找到的最佳单页参考资料是这份社区速查表。

先说一句你好。命令可以等一会儿再用。

输入 /setup-workspace 并按 Enter。该工作区自带一项技能，唯一职责就是将模板个性化：它会访谈你，了解你的公司、产品、用户和工作偏好，然后填充上下文文件，并将示例项目重命名为你最活跃的真实项目。使用自然语言回答即可；它会负责写入，并逐个向你展示文件，让你确认或修改。

**你不必凭记忆回答：直接粘贴链接。**把产品的公开网站、文档页面，或者——如果你在前一步连接了 Atlassian MCP——团队的 Confluence 页面交给它；它会读取这些内容，并基于已有文字构建上下文文件。花十五分钟做这件事，就能彻底摆脱面对空白页的问题。你实际被问到的问题可能会和我略有不同；每次会话都有一些不可预测性，这正是这些模型的工作方式。任何你还不知道的内容都可以跳过；诚实的占位符优于编造的内容。

用自然语言回答，或者粘贴一个链接，让它自行读取。

不要让第一次会话只停留在设置环节；交给它一件你确实欠别人完成的工作。输入 /status-update，看它根据项目的任务文件而非你的记忆起草更新。或者让它处理一项真实交付物：

为[你的项目]起草启动简报。匹配我在 context/preferences.md 中的写作偏好。在得出任何结论前，检查项目 tasks.md 中的开放问题。

**当第一份输出既像你的口吻、又关于你的产品，并且包含项目真实状态时，就是归档体系真正开始奏效的时刻。**文件夹中还有三项技能等着你：用于审阅下一份希望得到严格评估文档的 prd-review，用于下一次用户访谈的 interview-synthesis，以及能让你的修正永久保留的 file-feedback。

这项技能会先读取工作区状态，然后询问这份更新是写给谁的。

这就是开始：一次专注操作就能建立起一个可用系统。让它产生复利的，是你如何持续向其中输入信息，而这正是六项实践要解决的事。

---

这个入门结构编码了我通过不断犯错逐渐形成的实践……

My Claude Code workspace for my product job is a folder with almost no code in it. It holds a context folder with everything about the company: the product, the users, the competitors, how I like to work. One folder per project, with the tasks separated from the deliverables. A set of skills that each do one recurring piece of work: the status update, the PRD review, the interview synthesis. When I give feedback once, it lands in a file with a note on why, and I never give that feedback again. I didn’t design this system. I arrived at it, mostly by getting it wrong first.

Getting it wrong taught me the lesson that runs this whole article. Past the basics, your results in Claude Code stop depending on how well you prompt and start depending on how well you file. A good prompt improves one session; a good file improves every session after it. The prompt-tuning advice you’ve already read stops helping at exactly the point where the filing starts to matter.

So instead of describing my system, I packaged it. Thestarter workspace is public on GitHub: the folders, the context templates, and five PM skills, personalized by one setup interview. You don’t need to be technical to follow along; every step is spelled out, including installing the tools. And while my example is a product job, the same architecture fits any context-heavy work: a design lead’s research library, a data team’s metric definitions, a founder’s everything-folder.

Here’s the route.

• The switch. I’ll show you what chat mode and Cowork can’t give you, and why the terminal is worth it for a product manager.

• The starter workspace. Download it, run one setup skill, and give it a real task: six steps, each shown on screen.

• The practices. Six moves that make the system compound, each one naming the exact thing to do and what you get back.

• The rhythm. Here’s what a normal workday looks like inside the system, from the first short prompt to the two-minute filing habit.

The payoff is concrete. One sitting gets you running: install the tools, download the workspace, answer the setup interview, hand over a first real task. You stop re-explaining your company every session, and every correction you make becomes permanent. Every step is below.

Time to open the filing cabinet.

---

You probably run your product work through Claude’s chat today: a browser tab or the desktop app, maybe Cowork for the agentic tasks. It works, and that’s exactly the trap. Every conversation starts from zero. The strategy doc you uploaded last time is gone, the context you patiently explained lives in a thread you’ll never find again, and the output you liked is trapped inside a conversation instead of sitting in a file. Chat is a great place to think and a terrible place to accumulate. For occasional questions that’s fine. For daily product work, it means paying the same setup cost every single morning.

Claude Code is the same Claude with a different home: a folder on your machine that it can read, navigate, and write to. Context lives in files that persist. Recurring work lives in skills that run on command. Outputs land as documents you keep, not messages you scroll for. In my daily use, everything I used to do in chat or Cowork runs better here, because nothing is ever explained twice. That’s an observation from my own work, not a law, but it’s held for months.

The part that actually changed my job is the terminal underneath. Claude Code speaks to GitHub natively, no connector needed: it can pull a company repository and answer questions about it, and it can push your own work. Ask it to fetch the repo behind your product and explain what a feature flag actually does. Push your workspace to a private repository and a teammate can clone it and inherit your head start. For a product manager, that’s a direct line into the codebase and a way to share your whole system, both of which chat simply doesn’t have.

What nobody hands you is the filing system that makes all this compound. Anthropic’s best-practices guide is written, in its own words, “for engineers using Claude Code across various codebases, languages, and environments,” and engineers get their structure free: the codebase is already organized context. The PM guides that exist, Sachin Rekhi’s being the best known, rightly tell you to “store all of your product data and documentation in local markdown files,” then move on. Organized how? Try it without an answer and you get what I had: forty loose files and a stale setup. The starter workspace is that answer, prebuilt. Let’s set it up.

---

The starter workspace is the structure I run my own product work on, cleaned into a template: the folders, the context files with guided placeholders, an example project, and five skills already installed. The whole thing is free and public:claude-code-pm-starter. Six steps take you from nothing to a first real task, and none of them assume a technical background.

One prerequisites note before you start. You need a paid Claude plan for Claude Code. Everything else, including the two tools you’ll install, is free and covered in the steps.

Claude Code runs in a terminal, and a terminal alone is a bad home for a product manager: you can’t see your files. The fix is an IDE. An IDE is just an editor that shows your folder as a panel of files while you work; developers live in one all day, and you’ll borrow it for the file panel alone. Download VS Code, the free standard, and install it like any app. You won’t write code in it. You’ll watch your workspace organize itself in the left panel, which is exactly the visibility chat mode never gave you.

VS Code: free, and you’ll only use a fraction of it.

Open the repository page, click the green Code button, and choose Download ZIP. No git, no account needed. Unzip it and move the folder wherever you keep your work. This folder is about to become the place your product work lives , so pick somewhere you’ll find it again, like a work folder in your home directory.

The green Code button, then Download ZIP. No git needed.

Unzipped and filed: the starter folder in a Work folder, ready to open.

Open VS Code, choose File > Open Folder, and pick the unzipped folder. The left panel now shows the whole structure: context/, projects/, operations/, the skills. Then open the terminal inside VS Code with Terminal > New Terminal, and here’s the small trick that changes how the whole thing feels: right-click the terminal panel’s header and choose Move Panel Right. Files on the left, agent on the right: it stops feeling like a command line and starts feeling like a colleague sitting next to your documents.

The whole structure, visible at last: the skills, context, operations, projects, and the map.

The trick: right-click the panel, Move Panel Right.

If you don’t have Claude Code yet, install it now from the official guide; it’s one command pasted into that terminal. Then type claude and press Enter. Claude Code starts inside the folder, reads the map file, and knows where everything lives from your first message.

Files on the left, agent on the right.

One distinction saves beginners a lot of confusion. The terminal wants exact commands; Claude wants normal language. Before you typed claude, you were talking to the terminal, where spelling and syntax matter. Now that Claude Code is running, you’re talking to Claude, exactly like in the chat app. So do the natural first thing: type hello and ask it what it can see in this folder. It will answer like a colleague who just read your files.

A few slash commands are worth knowing on day one, typed directly into Claude Code:

• /model - shows which Claude model you’re running and lets you switch.

• /effort - sets how much thinking Claude puts into each answer; higher effort for hard work, lower for quick drafts.

• /mcp - lists your MCPs, the live connections into tools like Jira, Slack, or Confluence, and lets you manage them.

• /plugins - opens the plugin system, and this one deserves a minute. Claude Code comes with Anthropic’s plugin directory available by default, and marketplaces can be added on top. One is built specifically for product managers: pm-skills, a hundred-plus PM skills across discovery, strategy, execution, and launch; its README has the up-to-date install instructions. pm-execution covers PRDs, OKRs, roadmaps, and retrospectives; pm-product-discovery adds interviews and assumption testing. Install the two or three that match your work, not all nine; every installed plugin is context the system carries.

The plugin panel: Anthropic’s marketplace is there by default.

One more control, then you’re done with the tour: press Shift+Tab to cycle Claude Code’s three modes.

• Default mode asks your permission before touching any file.

• Auto-accept applies edits without asking.

• Plan mode is the one to remember: Claude researches and proposes a plan, and nothing changes until you approve it.

Start in default, use plan mode for anything big, and save auto-accept for work you’ve learned to trust. For everything beyond these, this community cheat sheet is the best one-page reference I’ve found.

Say hello first. The commands can wait a minute.

Type /setup-workspace and press Enter. The workspace ships with a skill whose only job is to personalize the template: it interviews you about your company, your product, your users, and how you like to work, then fills in the context files and renames the example project to your most active real one. Answer in plain language; it does the writing and shows you each file for a yes or a fix.

You don’t have to answer from memory: paste links. Hand it your product’s public site, a documentation page, or, if you connected the Atlassian MCP in the previous step, the Confluence page about your team, and it reads them and builds the context files from what’s already written. Fifteen minutes of this replaces the blank-page problem entirely. Your exact questions will differ a little from mine; each session is a little unpredictable, that’s just how these models work. Skip anything you don’t know yet; an honest placeholder beats invented content.

Answer in plain language, or paste a link and let it read.

Don’t end the first session on setup; hand it something you actually owe someone. Type /status-update and watch it draft your update from the project’s task file instead of your memory. Or point it at a real deliverable:

Draft the kickoff brief for [your project]. Match my writing preferences in context/preferences.md. Check the open questions in the project’s tasks.md before concluding anything.

The first output that sounds like you, about your product, with your project’s real state in it, is the moment the filing clicks. Three more skills wait in the folder: prd-review for the next document you’d like a hard read on, interview-synthesis for your next user conversation, and file-feedback, the one that makes your corrections permanent.

The skill reads the workspace state first, then asks who the update is for.

That’s the start: a working system in one sitting. What makes it compound is how you feed it, and that’s six practices.

---

The starter structure encodes the practices I converged on by getting each one wrong first. They’re not a methodology to obey; they’re the moves that kept earning their place. Each one below names the concrete thing to do and what you get back for it. The first one is the engine; the rest steer.

The single highest-return habit is also the simplest to state: default to the workspace for everything. Each time a task lands on you, open the workspace and do it there with Claude Code, even when chat would feel faster. The first run of a new kind of task takes longer, I won’t pretend otherwise: you explain, you correct, you adjust. But every explanation lands in a file, so the second run starts ahead, and the third barely needs you. It’s like teaching an intern: the first delegation costs you an afternoon, and then the work comes back done. A task kept in chat mode teaches the system nothing; the same task done in the workspace is an investment that pays on every repeat.

The habit has a closing move, and it’s where the compounding actually happens. When a task is done and you’re satisfied with the result, don’t just close the terminal. Ask Claude to bank what it learned: convert the finished task into a skill if it will repeat, confirm the new facts into the context files, and update your preferences file with the feedback you gave along the way. I say it almost in those words: “we’re done, turn this into a skill, and file the corrections I made.” That one sentence at the end of a task is the difference between a tool you use and a system that learns.

The organizing question surprised me. It isn’t “what topic does this belong to?” It’s “how fast does this change?” Everything in your work has a speed: your product’s positioning barely moves, a status summary lasts about a week, a ticket queue changes by the hour. File things by their speed, and stale can never masquerade as fresh. File them by topic, and old truth sits next to current truth, looking identical.

The three folders in the workspace are the three speeds. The concrete habit: the next meeting note you take goes into operations/ with the date in the filename, and the paragraph you keep retyping about your product goes into context/product.md. A note was true the day you wrote it, so the date travels in the filename where Claude reads it; the positioning paragraph is true until you change it, so it lives where every session can load it. Projects sit between the two speeds, which is why each project folder splits tasks.md from brief.md.

There’s a third speed, and you already own it.

MCPs, those live connections from Step 4, sit at the fast end of the spectrum: they’re for what changes hourly. Files are for what changes slowly. If you’re pasting live data into a context file, an MCP should own it; if you’re re-fetching stable truth through an MCP every session, a file should own it. If you’ve used PARA, Tiago Forte’s filing method, this rhymes with it, with one difference: PARA sorts by actionability, because a human’s failure mode is losing track of what to act on. This system sorts by rate of change, because an LLM’s failure mode is stale context confidently reused.

CLAUDE.md is the one file every session loads: the map that says who you are, what lives where, and the few rules that always apply. Here’s the honest practice: you almost never touch it by hand. If you’re organizing an existing folder rather than using the starter workspace, the /init command creates it for you: Claude scans the folder and writes the map itself. From then on, maintenance happens as a side effect: when you add a skill or a context file, Claude updates the map to match, and your job is just to say yes.

The one thing worth knowing is why the map stays small. It loads into every session, relevant or not, so every line spends a little of what Anthropic’s context-engineering post calls the “attention budget”; their docs target under 200 lines and warn that bloated files make Claude ignore your actual instructions. The map points, the files carry: knowledge lives incontext/, loaded only when a task needs it. I wrote about this just-in-time principle in How to build an AI helper for your team with Cowork; here, Claude applies it for you.

I carried a doubt about this practice for months. My habit is to look at every recurring piece of work and ask whether it can become a skill, so I give the feedback once and never redo the work again. It felt productive, and I wasn’t sure it was right, because nothing written for product people says where skills end and files begin. The test that settled it: nouns go in files, verbs go in skills. What Claude needs to know is a noun: product facts, user segments, terminology, in context/. What Claude needs to do is a verb: draft, review, synthesize, each one a skill.

In practice, skills come from the closing move of the first practice: you finish a task, you’re satisfied, and you ask Claude to turn what you just did together into a skill. The workspace’s status-update skill shows what one looks like: where it reads from, what shape the output takes, what quality bar it checks. Steps, a quality bar, an output format: that’s what a skill encodes, and that’s why “the roadmap review prep” or “the churn digest” qualify while “that one weird escalation” doesn’t. If you want to build one from scratch instead, How to build your first Claude Code skill walks through it step by step.

The test also catches the two ways things end up in the wrong drawer.

The first mismatch is a “skill” that’s really a fact bucket: product context wearing a skill’s clothes, never doing anything. That becomes a context file. The second is the reverse: a procedure written as notes inside context/, like a “how I run reviews” paragraph nobody can execute. A documented-but-not-executable procedure gets re-explained anyway, which defeats the whole point. That one becomes a skill. The know/do split is how documentation practice has organized itself for a decade (Diátaxis formalizes it); skills just make the “do” side executable.

You know the moment. Claude drafts your status update, and you fix the same phrasing you’ve already fixed once. Here’s the reframe that changed my week-to-week: a correction made in chat is perishable; it’s gone when the session ends. The entire compounding return of the system comes from making corrections permanent, and this is where the practices stop being organization and start being learning.

The simplest version is the one to start with, and it’s the highest-return edit in this article. Opencontext/preferences.mdand write three lines about how you write: sentence length, what your documents open with, the words you ban. From then on, every document Claude drafts comes out aligned with your writing preferences instead of sounding like a press release. That’s one correction, filed once, applied to everything that follows. The oldest entries in my own preferences file are corrections I have never had to give again.

For everything past that first edit, the workspace ships a skill that does the filing for you. When you catch yourself correcting something, run /file-feedback. It routes the correction with four questions.

Was it a one-off slip? Let it go; not everything deserves a file. A missing fact? It goes to the matching context file or the project’s brief. A wrong process? The fix goes into the skill, so it runs correctly every time after. Taste? It becomes a preferences entry, and here’s the detail that matters: each entry gets a line on why and a line on how to apply it, so future sessions can judge edge cases instead of pattern-matching blindly.

It turns out the vendor agrees, in almost the same words. Anthropic’s memory docs tell you to write things down when “Claude makes the same mistake a second time” or when “you type the same correction or clarification into chat that you typed last session.” The best-practices guide promises the payoff in one line: “The file compounds in value over time.” So here’s the version I’d put on a sticky note, and the line I’d hand your team: if you’ve said it twice, it belongs in a file.

The last practice removes a blocker that sits in your head, not in your files. You’ll catch yourself assuming a thing is out of reach: too technical, too long, needs a tutorial, needs an engineer. The move is to ask Claude Code first and let the answer surprise you. I wanted to try AWS Amplify, Amazon’s service for building and hosting apps, and my reflex was the old one: follow the guidelines, read the documentation, budget hours I didn’t have. Instead I pasted the documentation link into Claude Code and asked for two things: a working prototype to test the service, and a step-by-step guide written for someone non-technical. In one sitting I had something I could actually release, plus a guide I could follow and understand. The hours I had budgeted were never spent.

The same reflex applies at every scale, not just new tools. Before you summarize the forty-page research report yourself, ask. Before you assume the data question needs an analyst, ask. Before you check every intermediate step, give the whole task with the constraints and verify the result instead. The system you’ve built through the first five practices is exactly what makes asking cheap: the context is filed, the preferences are known, and a wrong answer costs you a correction, which the system then keeps. Six practices, one architecture. Here’s what it feels like on a normal workday.

---

A day inside the system looks less like chatting and more like working with a very fast colleague who reads the files first.

Sessions start in the project folder, not a blank chat. I open the workspace in VS Code, launch claude in the terminal, and the map loads with every file path ready to use. The task file already says where things stand, what’s blocked, and what’s next, because the previous session updated it. My first prompt names the goal and points at files by name, and it stays short on purpose. Prompting shrinks as filing grows. A good prompt in this system has three parts: the goal in one sentence, the non-negotiable constraints, and what to verify before showing you. About a hundred words, often less. The steps live in skills, the background lives in files, and the prompt only has to steer. For bigger work I add one move: switch to plan mode with Shift+Tab and approve the plan before anything runs.

The habit that holds it all together takes two minutes at the end of a session, and the file-feedback skill carries most of it. Three questions: did I correct anything I’ve corrected before, did a new fact surface that isn’t filed anywhere, did a piece of work repeat again? Repeat corrections go through the router; repeated work gets nominated as the next skill. Skip the ceremony when the answer is three nos, which is most sessions.

Every dozen sessions or so, I spend fifteen minutes pruning, and I’d argue this is the least optional part. Stale context is worse than missing context. An expired competitor note or an outdated positioning line doesn’t look stale to Claude; it gets woven into new work with full confidence, and Anthropic’s best-practices guide carries a matching warning: when two rules contradict each other, Claude may pick one arbitrarily. So: date-stamp what’s dated, archive closed projects, delete anything you wouldn’t want quoted back to you in a draft. That’s the whole system, running. What’s left is to start it.

---

What changed for me isn’t that Claude got smarter. It’s that I stopped having the same conversation twice. The company explanation I used to retype lives in context/. The feedback I used to repeat lives in skills and a preferences file. The projects pick up where they left off. The system’s real product is quiet: shorter prompts, fewer corrections, sessions that start in the middle of the work instead of at the beginning of my job description.

The shape travels well beyond product management. A discovery-heavy PM files interview syntheses as dated outputs and lets a skill do the synthesizing. A platform PM’s stable context is API consumers and versioning policy. A founder turns the investor update into a skill fed by a metrics file. A design lead files critique standards once instead of re-explaining them in every review. A data lead’s metric definitions become the context file every teammate’s sessions read. Different jobs, same three drawers, same habit.

Start smaller than feels ambitious. Download the starter workspace, run the setup interview, and add those three lines about how you write. Then bring it your very next task, and the one after that. The next time you catch yourself telling Claude Code something for the second time, you’ll know exactly where it goes. And soon enough, you won’t remember the last time you said it.