Your product owner's reasoning, available to the coding agent while the team works.
talkback is a set of Agent Skills tested with Claude Code and Codex. It gives a coding agent eight written rules about how a team builds its product, with the reasons behind them, and a product file where the product owner writes the values that are theirs: the north star metric, who the users are, what machines they run, the tiers, the fixed rules, and the decisions already taken. A developer asks the agent a product question and gets one recommendation, the flags, and what only the product owner can decide. Talkback is the button in a studio's control room that lets the producer speak to the person in the booth.
Get started · The eight rules · Example proposal · Product file template · Issues
Developers used to bring most product questions to the product owner in chat: where a button goes, which plan a feature belongs to, whether a request from one customer is worth building. An answer in chat settles one case. The reasoning stays with the owner, so the next similar question comes back too.
With the rules in a file the agent reads before a task, routine decisions get made the way the owner would make them, and the decisions that need the owner reach the owner with a recommendation attached. The owner still decides. The difference is that the reasoning behind earlier decisions is available while the team is working.
The rules grew out of building audio post-production tools for people working in Pro Tools. The product file keeps them usable by a team that builds something else.
The example proposal is a real run of the talkback skill on the example project, a small app with a filled-in product file. A developer asks whether to add a per-session loudness target to the export toolbar, because one facility requested it, and whether it belongs in the higher tier. The proposal starts like this (translated from the Italian the developer wrote in):
Wait, and don't build it today. It is one request (one facility, rule 2.1), so it needs validating first: ask three other users whether they change the loudness target between sessions, or read from the usage data how many users changed it more than once in the last 30 days. Meanwhile the customer is not blocked: the target already exists in Settings. If validation says yes, the smallest version is a move, not an addition: the same picker goes from Settings to the export toolbar, and leaves Settings. No tier gate: a picker alone moves nobody to the higher tier, and a freelancer delivering to two broadcasters has the same need as the facility.
Then come the three questions with their evidence, a placement marked Unknown with the usage query that would settle it, and the tier decision handed to the product owner as three lines.
Use Claude Code or Codex. The skills need nothing beyond a shell; Node.js 22 or later is only for the build and checks when you change this repository.
1. Install the skills in your project:
npx skills add simojam93/talkbackThis installs five skills. Add -g for all your projects, or -s talkback for the main skill only. See installation options for agent selection and setup details.
2. Write your product file. Copy the template to PRODUCT.md at the root of your project and fill it in with the product owner. It is a set of questions: who decides, who the users are, the metric the product is judged on, the machines users run and where the usage data lives, the tiers, the style, the fixed rules, and the decisions already taken with their reasons. The example shows a finished one. Without the file, the skills still run, and every check that needs your values comes back as Unknown.
3. Make the agent read it. Add one line to your CLAUDE.md or AGENTS.md:
Before building a feature, a screen, a control or copy, check it with the talkback skill against PRODUCT.md. Routine decisions inside the rules need no further approval.
4. Ask your agent:
Users want to reorder tracks by drag and drop. Should we build it, and where does it go?
To call a skill directly, use /talkback <question> in Claude Code or $talkback <question> in Codex.
Expect one recommendation first, then a verdict per rule, the flags with a smaller alternative each, what goes to the product owner as a three-line recommendation, and what nobody in the task can know.
The product file does not have to be complete on day one. Start with a product question your team has asked more than once. Write down the decision, why you made it, and when someone should bring it back to you, in the Decisions table of the product file:
| Decision | Why | Bring it back when |
|---|---|---|
| "Loudness target" lives in settings, not the toolbar | Usage data, March 2026: changed in 4% of sessions | It rises above 20%, or a new user group appears |
Then check the agent's answer on a real task: did it use the reasoning, identify the missing information, and leave the decision with the right person? That gives the next developer more to work with than the answer buried in an old chat.
- The agent is a colleague, not a gate.
- Three questions before building anything.
- Less is more.
- Everything lives where you'd look for it.
- Which tier.
- Copy and design.
- How we work.
- Before saying "done".
The rules contain numbered checks, each with the reasoning behind it, what evidence settles it, and who decides.
- Flags once, recommends once. A change that goes against a rule gets one flag: the rule, the reason, a smaller alternative. Then the developer decides. Never a menu of equal options.
- Keeps defaults and constraints apart. Developers can challenge a default, and their reason is recorded. A constraint, such as where user data lives or what needs the owner's go, is never overridden inside a task, whatever the argument.
- Leaves the owner's decisions with the owner. A change of concept, a tier placement that is not obvious, new copy users will read, anything that changes the first run, anything public: prepared as a three-line recommendation, not decided.
- Says Unknown instead of guessing. A check that needs usage data or the owner's intent says what would settle it. No invented shares of users, no assumed versions.
- Keeps proven, designed and planned apart, and never calls a change done without proof from the real app on every reference machine.
- Explains less as the developer learns. A developer new to the project gets the reasoning. One who already asks the three questions gets three lines.
- Fits the question to the skill. Choose a full proposal or focus on one area:
| Skill | When to use it | Rules |
|---|---|---|
talkback |
Any product question, or a task with none, where product questions come up in the code. | All eight |
talkback-build |
Should we build this, and what is the smallest version? | 2 and 3 |
talkback-place |
Where does this control, setting or screen go, and in which tier? | 4 and 5 |
talkback-copy |
What should this say, and does this screen fit the style? | 6, with 3 |
talkback-done |
Is this change done, and ready for the owner? | 8 and 7 |
Ask your agent in plain words, or call a skill by name. Each skill includes the rules and the template it needs, so it can be installed on its own.
Each skill is a SKILL.md with its references: the rules it covers, the proposal format, how to read the product file, and the product file template. npm run build generates the five skills from src/skills/, rules/, shared/ and templates/, so the copies cannot drift; npm run check verifies them against the Agent Skills specification. There are no scripts to run at review time: the agent reads the product file and the code, queries usage data when the task gives it a way to, and writes the proposal.
- The rules are one team's. Another team will disagree with some defaults; the product file is where the owner overrides them, and the rules say which ones are defaults.
- Usage data. Checks that depend on how often an action is used, or which versions users run, need the team's analytics or an export. Without them, those checks are Unknown.
- The agent cannot try the app. The done check reads the proof the developer provides. A machine without proof stays not verified.
- Instructions, not guarantees. The skills tell the agent to keep constraints, to say Unknown, and to keep proven and designed apart. They cannot force it.
MIT © Simone Lovera. Propose a check, report a rule that misfires, or share how your product file differs through CONTRIBUTING.md.