Below is a complete, paste-ready AGENTS.md template for product managers, plus four sample PM skills in SKILL.md format. It covers product context, decision log conventions, artifact conventions, and tone rules. It works with both Claude Code (via a one-line CLAUDE.md import) and Codex (natively). Free, no email gate.
Copy this into a file called AGENTS.md at the root of your product workspace folder, then fill every bracket. The comments explain what earns its place; delete them when done. Written by a product manager with 8+ years of experience for daily use in 2026, not as a demo.
# AGENTS.md
<!-- Product context for AI agents. Works with Codex (reads this natively)
and Claude Code (add one line to CLAUDE.md: @AGENTS.md).
Fill every [bracket]. Delete sections you don't use.
Keep it under ~120 lines: agents read this every session,
so every line has to earn its place. -->
## Product context
- Product: [name]. [One line: what it does, for whom.]
- Stage: [pre-PMF / growth / scale]. Team: [size]. My role: [PM / Senior PM / Head of Product].
- Primary users: [segment], hiring the product to [job to be done].
- Business model: [how it makes money].
- North-star metric: [metric], currently [value], target [value] by [date].
- This quarter's focus: [the one thing that matters most right now].
## Working on now
<!-- Update weekly. Stale "now" context is worse than none. -->
- [Active initiative 1: goal, status, next milestone]
- [Active initiative 2]
## Artifact conventions
- PRDs live in `prds/`, named `YYYY-MM-DD-short-slug.md`.
- Research (transcripts, notes, synthesis) lives in `research/`.
- Decisions live in `decisions.md` using the decision log format below.
- Stakeholder updates live in `updates/`, one file per week.
- Never overwrite an artifact. Create a new dated version and note what changed.
## Decision log format
Every product decision gets an entry in `decisions.md`:
## YYYY-MM-DD: [decision in one sentence]
- Context: why this came up now
- Options considered: [A], [B], [C]
- Decision: [chosen option], because [reasoning]
- Evidence: [links, files, or "judgment call, no data"]
- Revisit when: [trigger event or date]
When I make a decision in conversation, offer to log it before we move on.
## How to work with me
- Challenge weak reasoning. If my plan has a hole, say so directly.
- Separate facts from assumptions in every artifact. Label assumptions.
- When drafting, ask at most two clarifying questions, then draft with
stated assumptions instead of stalling.
- Use tables for comparisons, prose for narrative, bullets sparingly.
- If scope grows mid-task, push back once. Then do what I ask.
## Tone and writing rules
- Plain language. No corporate filler: no "leverage", "synergies",
"circle back", "align on alignment".
- Short sentences. One idea per paragraph.
- Every claim about users needs a source (interview ID, survey question,
analytics query) or an explicit "hypothesis" label.
- Spelling: [US / UK]. Date format: [YYYY-MM-DD].
## Hard rules (never break)
- Never invent user quotes, data points, or research findings.
- Never state a metric you have not read from a file or tool this session.
- Never send, publish, or share anything externally without my explicit
confirmation in this conversation.
- If context is missing, ask or mark the gap. Do not fill it with
plausible fiction.
Codex reads AGENTS.md natively; no wiring needed. Save the template and start a session.
Claude Code reads CLAUDE.md, which supports imports. Create a CLAUDE.md next to your AGENTS.md with exactly this content:
# CLAUDE.md @AGENTS.md
One source file, two tools. When you switch between Claude Code and Codex, or run both, your product context, decision log conventions, and hard rules travel with you. New to Claude Code? The setup guide for product managers covers install, MCP, and your first workflow.
Skills are how Claude Code learns repeatable PM workflows. Each file below is complete: frontmatter that tells the agent when to invoke it, steps with checkable completion criteria, and anti-invention rules. Save each one into its own folder under .claude/skills/, for example .claude/skills/interview-synthesis/SKILL.md.
These four cover the weekly PM loop: synthesize research, log decisions, red-team the PRD, report to stakeholders. For how to organize a growing collection, see how to organize Claude Code skills as a PM.
Turn raw interview transcripts into an evidence table, ranked pain points, and open questions, with every claim traceable to a quoted line.
---
name: interview-synthesis
description: >-
Use when you have one or more raw user interview transcripts (or call
notes) and need a synthesis: evidence table, ranked pain points, and open
questions, with every claim traced to a quoted source line. Not for
drafting the interview script itself, and not for survey data (different
evidence shape).
---
# Synthesize interviews without inventing evidence
The failure mode of AI synthesis is confident fiction. Every output row in
this skill traces to a quote. No quote, no claim.
## Required inputs
Get the transcript file paths and the research question the interviews were
run against. Ask for the research question if missing; synthesis without a
question drifts into summary.
Done when the files are readable and the question is stated in one sentence.
## Step 1: Extract evidence, verbatim
Read each transcript. Pull every statement relevant to the research question
into an evidence table: participant ID, verbatim quote, your one-line
interpretation, and a tag (pain, workaround, desire, context).
Done when every table row contains a real quote from the transcript, not a
paraphrase presented as one.
## Step 2: Cluster into pain points
Group evidence rows into pain points. For each: a one-line name, which
participants hit it (count), severity signals from the quotes, and current
workarounds observed.
Done when every pain point cites at least two evidence rows, or is
explicitly flagged "single-source, needs validation".
## Step 3: Rank and separate signal from noise
Rank pain points by frequency times severity. List separately: things only
one person said, things participants were prompted into agreeing with, and
contradictions between participants.
Done when the ranked list and the noise list are both present. A synthesis
with no noise list has not looked hard enough.
## Step 4: Name what you still do not know
Write the open questions this round could not answer, and which participant
segment or method would answer each.
Done when every open question names a next research action.
## Output
Ask where to save (default `./research/synthesis-{topic-slug}.md`).
The doc holds: research question, evidence table, ranked pain points,
noise list, open questions. Every claim traceable to a quote.
Capture a product decision the moment it happens: options considered, evidence, reasoning, and a revisit trigger so it can be judged fairly later.
---
name: decision-log
description: >-
Use the moment a product decision is made in conversation or in a
document: capture it as a structured entry in decisions.md with options,
evidence, and a revisit trigger. Not for brainstorming the decision
itself, and not for meeting minutes (broader scope).
---
# Log decisions so future-you can judge them fairly
Decisions get re-litigated because nobody wrote down what was known at the
time. A good entry separates decision quality from outcome quality.
## Required inputs
Get the decision as stated, and the conversation or document context around
it. If the decision is vague ("we should improve onboarding"), reflect it
back sharpened ("cut onboarding to 3 steps by removing X and Y") and confirm
before logging.
Done when the decision fits in one falsifiable sentence.
## Step 1: Reconstruct the options
List the options that were actually on the table, including "do nothing".
If only one option was ever discussed, say so; that is a finding, not a gap
to paper over.
Done when each option has one line on why it was or was not chosen.
## Step 2: Attach the evidence honestly
Link the files, data, or conversations that informed the decision. If there
was no evidence, write "judgment call, no data". Never dress up a hunch as
research.
Done when the evidence line is either a real reference or an honest "none".
## Step 3: Set the revisit trigger
Every decision gets a condition for re-opening it: a date, a metric
threshold, or an event ("if churn exceeds 4%", "when the enterprise deal
closes", "in one quarter"). Decisions without triggers become dogma.
Done when the trigger is checkable by a future reader without asking anyone.
## Step 4: Append to decisions.md
Write the entry in the repository's decision log format (see AGENTS.md).
Newest entries at the top. Never edit past entries; if a decision is
reversed, log the reversal as a new entry that references the old one.
Done when the entry is written to decisions.md and the file still parses as
a clean chronological log.
## Output
The updated `decisions.md`, plus a one-line confirmation of the revisit
trigger so the human can veto it.
Review a PRD draft the way a skeptical engineering lead would: unstated assumptions, missing edge cases, untestable success criteria, and kickoff questions.
---
name: prd-review
description: >-
Use when a PRD draft exists and needs a critical review before circulating:
find unstated assumptions, missing edge cases, untestable success criteria,
and the questions engineering will ask at kickoff. Not for writing the PRD
from scratch, and not for copyediting prose style.
---
# Review PRDs like the skeptical engineer who will build them
A PRD review that says "looks good, minor comments" has failed. The job is
to find the five issues that would otherwise surface in sprint two.
## Required inputs
Get the PRD file and one line of context: who will build this, and when it
is supposed to ship.
Done when the full document has been read, not skimmed.
## Step 1: Hunt unstated assumptions
List every claim the PRD treats as true without evidence: about users, about
technical feasibility, about dependencies, about adoption. For each, note
what happens to the plan if it is false.
Done when each assumption has a consequence attached, not just a label.
## Step 2: Attack the success metrics
For each metric: is there a baseline, is there a target, can it be measured
with tools that exist today, and could it improve while the product gets
worse (vanity check)?
Done when every metric is marked measurable-as-written or flagged with what
is missing.
## Step 3: Walk the edges
For each user flow, list the unhappy paths: empty states, permission
failures, concurrent edits, slow networks, the user who does the steps out
of order. Note which the PRD covers and which it is silent on.
Done when silence on an edge case is recorded as a gap, not assumed handled.
## Step 4: Write the kickoff questions
Draft the questions an engineering lead would ask in the first ten minutes
of kickoff: sequencing, dependencies, what "phase 1" cuts, what is out of
scope. If the PRD answers them, say where. If not, they go in the report.
Done when there are at least five questions and each is specific to this
PRD, not generic.
## Step 5: Rank the top five issues
From everything above, pick the five issues most likely to cause a re-plan
mid-build. One line each: issue, why it bites, cheapest fix now.
Done when the five are ranked by blast radius, not by order found.
## Output
Ask where to save (default `./prds/review-{prd-slug}.md`).
The doc holds: top-five issues, assumption table, metric audit, edge-case
gaps, kickoff questions. Blunt beats polite.
Compress a week of raw notes, tickets, and decisions into the update stakeholders actually read: decisions, risks, asks, and metric movement.
--- name: stakeholder-update description: >- Use at the end of a week (or before a steering meeting) to compress raw working notes, closed tickets, and logged decisions into a stakeholder update: what was decided, what is at risk, what is needed from whom. Not for board decks or release notes (different audience and shape). --- # Write the update stakeholders actually read Stakeholders skim. The update earns trust by surfacing bad news early and asking for specific help, not by listing activity. ## Required inputs Get this week's raw material: working notes, decisions.md entries since the last update, closed and slipped tickets, and metric readings if available. Also get the previous update, so promises made there can be checked. Done when last week's "next steps" have each been located in this week's material as done, slipped, or dropped. ## Step 1: Lead with decisions and changes Open with what changed: decisions made (link the decision log entry), scope changes, and date changes. No throat-clearing, no "great week!". Done when a reader who stops after the first section knows everything that changed. ## Step 2: State risks before being asked List the top risks with trend (new, worsening, improving) and the current mitigation. A risk section that has been empty for three weeks straight is a credibility problem, not an achievement. Done when each risk names an owner and a next checkpoint. ## Step 3: Make the asks specific Each ask names a person or role, the specific thing needed, and the date it blocks something. "Support from leadership" is not an ask; "need legal review of the data-retention change by Friday or the release slips" is. Done when every ask would let the recipient say yes or no without a meeting. ## Step 4: Report metrics without spin Show the north-star and guardrail metrics: value, change since last update, and one line of honest interpretation. If a metric moved for a known mechanical reason, say so before someone else discovers it. Done when every number has a source and no adjective does a number's job. ## Output Ask where to save (default `./updates/YYYY-MM-DD-update.md`). The doc holds: decisions and changes, risks with owners, specific asks, metrics with interpretation, and next week's committed steps (which the next update will be checked against).
Honest answer: for some PMs, this page is enough. The template plus four skills cover the core weekly loop, and free GitHub collections like deanpeters/Product-Manager-Skills add breadth on top. If you enjoy building your own system file by file, start here and keep going.
AI PM OS is for PMs who want the full operating layer without building it: 243 skills across discovery, strategy, and delivery, 11 guided workflows, 12 subagents, and the curation that decides which skill fires when. This template is the starting layer of that system, not a crippled trial of it.
AGENTS.md is a markdown file that tells AI agents about your product, your conventions, and how you want them to work. Codex reads it natively; Claude Code reads it through a one-line import in CLAUDE.md. Without it, every session starts from zero and you re-explain your product daily. With it, the agent knows your users, your artifact conventions, and your hard rules before you type a word.
Yes, by design. Codex reads AGENTS.md directly. For Claude Code, create a CLAUDE.md containing a single line, @AGENTS.md, which imports the shared file. One file drives both tools, so your product context survives switching agents.
It is free and there is no email gate. Copy everything on this page. The honest framing: this template plus the four sample skills are the starting layer, real files I would use myself. AI PM OS is the curated full system, 243 skills, 11 guided workflows, and 12 subagents, for PMs who want the whole operating layer instead of building it file by file. If the free layer is enough for you, use it with my blessing.
Repos like deanpeters/Product-Manager-Skills and phuryn/pm-skills are genuinely good breadth plays: dozens of skills covering many PM tasks. This page is a depth play: one complete AGENTS.md that encodes working conventions (decision logs, artifact naming, anti-invention rules) plus four skills written with explicit completion criteria per step. Use both. The GitHub repos give you coverage; this template gives your agent judgment about how you work.
A skill is a folder containing a SKILL.md file: YAML frontmatter with a name and a description that tells the agent when to use it, then markdown instructions. Claude Code loads skills from .claude/skills/ and invokes them when the description matches your request. The four samples on this page follow that format; save each into its own folder, like .claude/skills/interview-synthesis/SKILL.md.
Treat AGENTS.md like any file in your repo: fine for context your team already shares (product goals, conventions, metrics definitions), wrong for credentials, unreleased financials, or anything you would not commit to version control. Keep secrets in environment variables and out of agent context files.
AI PM OS ships 243 PM skills, 11 guided workflows, and 12 subagents for Claude Code and Codex, curated so the right skill fires at the right moment.
Written by George Nurijanian, Product Manager with 8+ years of experience. For the complete system, see AI PM OS.