How to Set Up Your PM Context Files in Claude Code

Context files are the reason Claude Code produces output that references your actual product instead of generic PM advice. Without them, every session starts from zero. With them, every session starts from knowledge.

If you're not sure what context files are or why they matter, read What Are Context Files? first. This article is the hands-on tutorial: create the files, fill them in, and verify they're working.

There's real setup investment upfront the manual way. The /welcome skill generates drafts automatically — you review and enrich from there.

My own context files went through significant evolution. Early on, I tried to stuff in every detail — every feature spec, every competitor data point, every persona nuance. That actually made things worse. Claude was getting confused by the volume. The key change was distilling the files down to what skills actually need to produce good output. More focused context produced dramatically better results than comprehensive context.

The Five Files

Your context lives in a context/ folder inside your Claude Code project directory:

your-project/
├── context/
│   ├── company.md
│   ├── product.md
│   ├── personas.md
│   ├── competitors.md
│   └── goals.md
├── .claude/
│   └── skills/
└── ...

Each file covers a different dimension of your product. Claude Code reads all of them automatically before running any skill. You create them once and update them as things change.

File 1: company.md

This file tells Claude who you are as a business. Mission, market position, stage, team, and strategic direction.

Template

# Company Context

Company Name

[Your company name]

Mission

[One sentence: why you exist]

What We Do

[2-3 sentences: what problem you solve and for whom]

Market Position

[Where you fit in the landscape — what gap you fill, what category you're in, how you're different]

Stage

[Seed / Series A / Series B / Bootstrapped / etc.]

Team

[Size, structure, any relevant constraints]

Strategic Priorities (This Quarter)

• [Priority 1]
• [Priority 2]
• [Priority 3]

What We Believe

[2-3 beliefs that drive your product decisions — these shape how Claude frames recommendations]

### Good vs. Weak Context

**Weak:** "We're a SaaS company that helps teams collaborate better."

**Good:** "We're a Series A project management tool for construction teams. 15 employees, 800 customers. We win against Procore on price and simplicity. We lose to them on enterprise features. This quarter, we're focused on mobile field reporting because 70% of our users are on job sites."

The difference: Claude can make real decisions with the good version. The weak version produces output that could be about any company.

<div class="callout-tip">

**Tip** — Include what you're NOT doing. "We've explicitly decided not to build time tracking this year" prevents Claude from suggesting time tracking features in PRDs and roadmaps.

</div>

---

## File 2: product.md

This file describes what you're building — features, roadmap, pricing, metrics, and technical architecture.

### Template

```markdown
# Product Context

## Product Name
[Name]

## What It Does
[3-5 sentences: what the product does, how it works,
the core user experience]

## Target Users
[Who uses it — this overlaps with personas.md
and that's fine]

## Current Features
- [Feature 1] — [brief description]
- [Feature 2] — [brief description]
- [Feature 3] — [brief description]

## What's Coming (Next 90 Days)
- [Planned feature 1]
- [Planned feature 2]

## What We're Not Building
- [Explicit decision 1 and why]
- [Explicit decision 2 and why]

## Pricing
[Current pricing model and tiers]

## Key Metrics
- [Primary metric]: [current value]
- [Secondary metric]: [current value]
- [Health metric]: [current value]

## Technical Notes (Optional)
[Anything that affects PM decisions: platform constraints,
API limitations, technical debt that blocks features]

What Matters Most

The sections that improve skill output the most:

1. Current Features — Skills reference what exists when proposing new features
2. What We're Not Building — Prevents hallucinated recommendations
3. Key Metrics — OKRs and success metrics get calibrated to real numbers

File 3: personas.md

This file describes your users — not demographics, but real people with jobs to do, problems to solve, and ways they currently cope.

Template

# User Personas

## Primary Persona: [Name or Archetype]

### Who They Are
- **Job title:** [Title]
- **Company size:** [Range]
- **Reports to:** [Role]
- **Team size:** [How many people they manage or work with]

### What They're Trying to Do
- [Job-to-be-done 1]
- [Job-to-be-done 2]
- [Job-to-be-done 3]

### What Frustrates Them
- [Pain point 1 — be specific]
- [Pain point 2]
- [Pain point 3]

### How They Solve This Today (Without Your Product)
- [Current workaround 1]
- [Current workaround 2]

### What Success Looks Like
[How they'd know your product is working for them —
concrete outcome, not "improved efficiency"]

### Quotes (If You Have Them)
> "[Real quote from an interview that captures their mindset]"

---

## Secondary Persona: [Name or Archetype]
[Same structure]

The Most Common Mistake

Personas that are too abstract. "Marketing Manager at a mid-size company who wants better analytics" could describe a million people. That's not a persona — that's a demographic category.

Better: "Sarah is a solo marketing manager at a 40-person B2B SaaS company. She reports to the CEO, manages one contractor, and owns everything from content to paid ads. Her biggest frustration is spending Monday mornings building a dashboard in Google Sheets that her CEO glances at for 30 seconds. She needs a report she can send in two clicks."

Claude produces radically different output when it knows Sarah exists versus when it has a generic "marketing manager" persona.

File 4: competitors.md

This file maps your competitive landscape. Be opinionated — "they're good at X, we win at Y" is more useful than a neutral feature list.

Template

# Competitive Landscape

## Our Position
[One paragraph: what makes us different and for whom]

## Direct Competitors

### [Competitor 1]
- **What they do:** [Brief description]
- **Their strengths:** [What they're genuinely good at]
- **Their weaknesses:** [Where they fall short]
- **We win when:** [Specific scenarios where we beat them]
- **They win when:** [Specific scenarios where they beat us]
- **Pricing:** [Their pricing model]

### [Competitor 2]
[Same structure]

### [Competitor 3]
[Same structure]

## Indirect Competitors
- **[Alternative 1]:** [e.g., "Spreadsheets — the default choice
  for teams that don't know tools like ours exist"]
- **[Alternative 2]:** [e.g., "Hiring a consultant — more expensive
  but no learning curve"]

## Competitive Dynamics
[What's changing in the market. New entrants, funding rounds,
feature convergence, pricing pressure, etc.]

Why Opinionated > Neutral

A neutral feature matrix doesn't help Claude make decisions. "Both tools have reporting" tells the AI nothing useful.

An opinionated assessment — "Their reporting is deeper but requires a data team to set up. Our reporting is good enough for teams without analysts, which is most of our ICP" — tells Claude exactly how to frame competitive differentiators in PRDs, positioning, and launch messaging.

File 5: goals.md

This file tells Claude what you're trying to accomplish this quarter — your objectives, key results, and the initiatives that matter most right now.

It's the file that makes every other file directional. Without it, Claude knows your product and your users, but not what winning looks like for you this quarter. That gap shows up in subtle ways: skills suggest features optimized for the wrong stage, PRDs miss the right success metrics, roadmap recommendations don't map to what actually needs to ship.

Template

# Goals Context

## This Quarter's Objective
[One sentence: what does winning look like this quarter?]

## Key Results
- [KR1: measurable outcome with a number]
- [KR2: measurable outcome with a number]
- [KR3: measurable outcome with a number]

## Product Goals (What Product Must Deliver)
- [Initiative 1] — [how it connects to the objective]
- [Initiative 2] — [how it connects to the objective]
- [Initiative 3] — [how it connects to the objective]

## What We're Not Prioritizing This Quarter
- [Important thing we're deferring] — [why it's not now]
- [Important thing we're deferring] — [why it's not now]

## Key Dates
- [Date]: [Milestone or deadline]
- [Date]: [Milestone or deadline]

## Biggest Risks
- [Risk 1 — what could derail the objective]
- [Risk 2 — what could derail the objective]

Good vs. Weak Context

Weak: "We want to grow the product and improve retention."

Good: "This quarter's objective is to validate that our team tier can scale to 5+ PMs. Key results: close 2 team-level implementations ($15K+ each), run 15 customer interviews, and ship the shared folder architecture that enables multi-PM delivery. We are explicitly not investing in solo PM acquisition — that funnel is working and doesn't need more attention."

The difference: Claude now knows you're in a validation-and-close phase, not a growth phase. PRDs will be scoped tighter. Roadmap recommendations will exclude "nice to have" improvements. Feature prioritization will favor anything that unblocks team sales.

Why Goals.md Changes Skill Output

Most PM skills make implicit assumptions about where you are. /roadmap-builder without goals context might suggest a balanced portfolio of features. /roadmap-builder with a goals.md that says "retention is the only metric this quarter" will produce a roadmap where every initiative maps to churn reduction.

The same principle applies to /prd-generator, /experiment-designer, /ship-decision, and anything that involves prioritization. Goals give Claude the north star for every recommendation.

The Fast Path: /welcome

If starting from blank templates feels slow, the /welcome skill automates the initial draft. It's included with the Complete PM OS.

How it works:

1. Run /welcome in Claude Code
2. Point it at your company website (or paste your pitch deck, about page, or any product description)
3. It generates all five context files pre-populated with your product context

The output isn't perfect — it's a strong 70% draft that you spend 30-45 minutes enriching. That's faster than writing five files from scratch, and the structure is already in place.

What /welcome catches that you might miss:

• Competitive positioning language from your website's comparison pages
• Feature descriptions in a format Claude can reference
• Persona hints from your "who it's for" sections

What you'll need to enrich manually:

• goals.md — /welcome generates a draft, but it has the least source material to work from. Review it carefully and fill in your real targets, key dates, and what you're explicitly not prioritizing.
• Internal-only strategic priorities
• "What we're not building" decisions
• Real user quotes from interviews
• Opinionated competitive assessments

Verifying Your Context Files Work

After creating your files, test them with a skill run. The best test is /prd-generator — it touches all five context files.

Run /prd-generator with a feature you've already specced manually. Then compare.

Signs your context is working:

• The PRD references your actual product name and features
• User stories mention your persona names, not generic "users"
• The competitive framing reflects your real landscape
• Success metrics are calibrated to your actual scale

Signs your context needs work:

• Output could be about any product in your category
• Personas feel generic ("the user wants to save time")
• No reference to competitive differentiation
• Metrics are round numbers unrelated to your actual data

Fix the weakest file first. The improvement in output quality is immediate.

Keeping Context Files Fresh

Context files are living documents. They don't need daily updates, but they shouldn't go stale.

Update monthly or when something significant changes:

• Strategy pivot or new quarterly priorities
• New persona segment you're targeting
• Competitor launches, funding, or pricing changes
• Major feature ships that change your product description

The easy way: Run /enhance-context after any major event. Feed it the relevant document — a competitor's press release, your updated strategy deck, a research synthesis — and it updates the right context files with the new information.

The manual way: Open the relevant file, update the section, save. It's markdown. There's no special process.

What's Next

Your context files are set up. Every skill you run from here will reference your product, your users, and your market automatically.

Next steps:

1. Run /prd-generator on a real feature to verify context quality
2. Browse the skills directory and install skills for your most common workflows
3. See AI PM Workflows for how to chain skills into end-to-end workflows

Five files. Real setup investment upfront — it pays for itself on the first skill run and compounds from there.

Download the PRD Generator free →

FAQ

How long should each context file be?

500-1,500 words per file. Long enough to be specific, short enough that Claude reads the whole thing every session. If a file is over 2,000 words, you're probably including details that belong in separate documents.

Can I add more than five context files?

Yes. Some teams add brand.md for voice and tone, or a stack.md for technical constraints. But start with the five core files — they cover 90% of what skills need.

What if my product is pre-launch and I don't have metrics or competitors yet?

Write what you know. A company.md with just your mission, stage, and team size is more useful than no file at all. A competitors.md with indirect competitors ("spreadsheets and manual processes") still helps Claude understand the alternative. You can enrich these files as you learn more.

Should different PMs on my team maintain their own context files?

No. Shared context files are one of the biggest benefits. One set of files, one source of truth, consistent output quality across the whole team. Designate one PM (usually the Head of Product) to own updates.

About the Author

Ron Yang is the founder of mySecond — he builds and manages PM Operating Systems for product teams. Prior to mySecond, he led product at Aha! and is a product advisor to 25+ companies.

Browse the skills directory →

Set up Claude Code for PM work →