Hand the authorized proposal to your coding agent

The product manager has reviewed the proposal and asked for a change. Before implementation starts, the engineer's agent needs to apply that correction and return the revised proposal for authorization. The handoff is complete when both people and the agent are working from that agreed revision.

This is the engineer’s continuation of the illustrative FN-412 walkthrough. Its decisions are scripted examples, not evidence of a customer result or a completed implementation.

The input

A connected repository with an intent.md, the original request attached to its Pathmode proposal, and a product manager with permission to review and authorize it. If the repository is not connected yet, follow repository setup. A workspace member chooses the product and gives the adoption command to the repository agent, which completes adoption. Installing the MCP server alone does not adopt an existing intent into a workspace.

For local drafting without an account, use your first intent in the repo. Shared corrections and signed-in authorization belong to the connected workflow below.

Give the coding agent the actual ticket or brief. Ask it to draft the proposal from the request and repository, label assumptions, and attach the original wording with attach_original_request. The product manager can also use Attach the request in the review.

The attached text records what was asked. It is not automatically evidence that the user's problem or a proposed outcome is true.

Ask the agent to read the repository intent and the connected review state before continuing. It can use list_intent_change_requests and get_intent_change_request to inspect the requested changes.

In the FN-412 example, the request asks for a Cancel plan button and leaves three choices open. The reviewer requests these answers:

• Access timing: end of the paid period. Keep access active through the period the customer already paid for.
• Resuming: allow it before expiry without skipping or duplicating charges; do not resume after expiry.
• Overdue payments: stop retries and renewal, preserve remaining paid access, and end access immediately if the paid period has expired.

The dependent answers must match the recorded access-timing decision. A submitted answer is a change request, not an applied revision or permission to build.

The agent deliberately applies the correction to the repository intent, or reports why it cannot. A waiting status or a refusal is not a completed correction. Resolve the reported issue with the product manager before proceeding.

Have the product manager inspect the applied change and the rest of the proposal. Their implementation authorization applies to the proposal revision they reviewed. The agent cannot grant itself that authorization with an API key, and guest comments do not grant it either.

A readiness verdict answers a separate question: whether the spec is concrete enough to build and verify. A passing verdict does not authorize implementation. Choosing a suggested correction does not authorize it either.

At the start of the next connected session, ask the coding agent to read the current intent.md and fetch the hosted intent with get_intent. Confirm that the current repository revision matches the authorized revision and that the three decisions are present. A local file may still say pending after hosted authorization; consult the current hosted state rather than inventing an approval or relying on a copied prompt.

Then check readiness and implement within the authorized outcomes, scope, and constraints. get_agent_prompt in execute mode includes the connected review context; read and resolve any open corrections before continuing.

If implementation reveals a false assumption, record an implementation finding and bring the affected decision back for review. Do not silently substitute a different product behavior.

Run the applicable checks from the intent. In the FN-412 example, verify paid access through period close, resuming before expiry without duplicate charges, refusal to resume after expiry, and cancellation of overdue subscriptions with and without remaining paid access. Check repeated cancellation requests too. Receiving the authorized revision proves handoff, not that these behaviors work.

When using the GitHub integration, link the intent to the pull request using the documented reference patterns. Diff-based review provides an additional signal; inspect what it supports alongside the executed checks. A passing test or review score does not by itself establish that the feature met the user's need.

Static exports remain an option

Export to Agent can produce a prompt for Claude Code, Cursor, or Codex, with Draft or Execute modes. Review the copied content before sharing it, including any evidence it contains.

A copied prompt is a snapshot. It does not fetch later corrections or establish that the current proposal is authorized. For ongoing team work, have the connected repository agent read the current intent and review state before implementing.

The output

An authorized repository intent, an implementation checked against its agreed behavior, and any findings returned to the product record. The product manager can follow the correction through to the revision that was built.

See the complete proposal-review example, or use Your First Intent in Pathmode for the full setup-to-review walkthrough.