Turn customer feedback into an agent-ready spec by separating evidence from judgment. Preserve the tickets, quotes, observations, and metrics; ask an agent to draft the pattern, objective, and observable outcomes; then have a human challenge and authorize that interpretation. Commit the resulting decision as intent.md while keeping private raw evidence out of the repo.
A team had forty support tickets and a folder of interview notes. Read together, they appeared to show that users could not tell which changes had saved. By the time the work reached the build queue, that interpretation had been flattened into “add a settings page.” The coding agent built the page. It did not solve the observed problem because neither the outcome nor the reasoning behind it reached the repository.
The same feedback contains three different things:
- The evidence — “I can't tell if my change actually saved.”
- A proposed interpretation — users lack confidence that changes persist.
- An authorized outcome — a user can confirm a change persisted without guessing.
Treating those as separate steps matters. Evidence can support several interpretations, and a plausible pattern is not yet a product decision.
A safer path from feedback to intent
- Preserve the source material. Keep provenance, exact wording, dates, and ownership. Do not turn every customer request into a requirement.
- Let the agent propose a synthesis. It can cluster repeated friction, identify contradictions, and draft an objective and observable outcomes. Its claims should remain inspectable assumptions.
- Have a human exercise judgment. Confirm which interpretation matters, reject alternatives, define tradeoffs, and authorize the work.
- Put the decision in
intent.md. Commit the objective, outcomes, constraints, scope, edge cases, and verification beside the code it governs. - Keep private evidence behind the file. The repo can carry stable references while connected Pathmode teams retain sensitive tickets, quotes, named guest feedback, signed-in authorization, and later findings.
Evidence informs the decision. It does not make the decision.
What the coding agent actually needs
The implementation agent rarely needs a dump of every interview transcript. It needs the authorized product decision and enough provenance to understand or challenge it:
- the problem and why it matters;
- observable outcomes rather than a feature list;
- constraints and scope boundaries;
- edge cases with expected behavior;
- concrete verification checks;
- references to the evidence and decisions that shaped the spec.
That is the purpose of the IntentSpec. It is not a machine-generated verdict about customers. It is a reviewable handoff from evidence and human judgment to implementation.
Frequently asked questions
- Why not just summarize the feedback into a prompt myself?
- You can for small work. The risk is not human summarization; it is losing the assumptions and boundaries behind the conclusion. An IntentSpec makes those claims reviewable and gives the repository a durable decision the next agent can read.
- What kinds of feedback can inform a spec?
- Support tickets, interview notes, observed friction, usage patterns, metrics, and explicit requests can all be evidence. None is automatically a requirement. The agent can identify patterns and contradictions, but a human decides what those signals justify building.
- Does the coding agent see the raw feedback, or just the spec?
- In local mode it reads the decision in intent.md and any references you deliberately include. Connected mode can also provide authorized access to private evidence and review context. Raw customer material does not need to be copied into a public or shared repository.
- How is this different from writing a PRD from the feedback?
- A PRD can explain the broader narrative to people. intent.md is a compact, versioned decision for the repository: objective, outcomes, boundaries, edge cases, and verification. Use both when both jobs matter; the IntentSpec does not have to replace the PRD.