decisions

<!-- Generated by Paved plugin paved@2.29.0 from core.decisions.decisions@0.2.0; edit Paved Core instead. -->

Conversational decisions

When to use

Use this protocol whenever a Paved command returns decisions or awaiting_input, and when deciding whether a blocking diagnostic can be answered. It applies to command and workflow decisions.

Required context

Read the decision projection returned by Paved, including its id, question, reason, options, recommended, evidence, required, answerChannel, dependsOn and status. Use the diagnostic list and next action from the same result. Do not infer omitted options, evidence, dependencies or approval requirements.

Preconditions

A decision can be answered only when Paved has emitted it and its status is ASKED. If the decision is absent, still PENDING, or its evidence has changed, rerun the same command and use the current projection. A blocking diagnostic without an emitted decision is a constraint to report, not a question to invent.

Procedure

1. Present each emitted decision with what Paved detected, what choice remains, why it matters, every listed option and its consequence, and the evidence cited by Paved.
2. Include Paved's recommendation and its evidence when recommended is present. Label it as a recommendation; never treat it as the user's answer. If the user asks you to choose a material option, explain that you cannot submit the choice for them and ask them to name one of the listed options.
3. Present all currently emitted decisions together. Preserve only ordering expressed by dependsOn; do not imply that independent decisions must be answered in sequence.
4. Collect the user's explicit option for each decision. Resume the same command with --answer <id>=<value> --answered-by <identity>. Repeat --answer for additional decisions and repeat it for each value in a multi-choice answer.
5. Use only the option ids in options. Use only an answering identity the user supplied.
6. If answerChannel is human-authored, explain that a person must author .paved/approvals/<id>.json for this exact decision. Do not create or edit that file. Never write an approval on the user's behalf, even when filesystem access is available.
7. If Paved reports a blocking diagnostic, state its message and next action separately from any emitted optional decision. Make clear that answering the optional decision does not resolve the blocker unless Paved says it does. Do not turn the diagnostic into an option or call decision raise to route around a decision Paved already emitted.
8. After resuming, report Paved's resulting status and any remaining decisions or blockers.
9. Before asking a question of your own, in the conversation or with paved decision raise, triage it. If the answer is observable (current behavior, output, timing, layout, whether a test fails), find it out by reading or running the code instead of asking. Ask only about preferences: product, scope, priority or taste calls that no experiment settles. Raise them with "questionKind": "preference". When an observable question genuinely cannot be observed (no access, no safe way to run it), raise it with "questionKind": "observable" and an "observationBlocker" that says why; Paved rejects an observable question without one. Triage covers only your own questions: every decision Paved emits is still presented, and approvals stay human.

Tools

Use the originating Paved command to refresh a decision or resume it with the user's answer. Use paved decision list and paved decision show <id> when inspecting stored decisions. If a command is unavailable, report that and use the next action Paved gave.

Rules

This skill defines how an agent relays Paved decision records. It does not authorize the agent to select a material option on the user's behalf, provide an identity the user did not give, or create an approval record. Never offer an option Paved did not include in options. Never call decision raise to route around a decision Paved already raised.

Verification

A resumed command result verifies whether Paved accepted and applied an answer. An awaiting_input result means required input remains. A blocking diagnostic remains a blocker until Paved reports otherwise.

Evidence

This skill adds no evidence record of its own. Preserve Paved's decision id, status, answer source and resulting command status when reporting the interaction.

Completion criteria

• The user saw Paved's question, options, consequences and cited evidence.
• Every submitted answer and answering identity came from the user.
• Human-authored approval requirements and blockers were relayed without agent edits.
• The final Paved result and any remaining action were reported.
• No question you asked yourself had an answer you could have observed.

Failure modes

Failure	Signal	Response
Recommendation treated as consent	No explicit user option was collected	Leave the decision unanswered and ask the user to choose.
Agent authors an approval	answerChannel is human-authored	Tell the user where the approval belongs; do not write it.
Blocker is turned into a choice	No matching decision was emitted	Relay the diagnostic and its next action without raising a substitute.
Independent decisions are serialized	No dependency connects them	Present the emitted decisions together.
A fact is asked as a question	The answer could be read from the code or a run	Find it out, then ask only what remains a preference.

References

No supporting files.

Paved integration

Use the project-local Paved contract as the source of truth. Discover state with node "${CLAUDE_PLUGIN_ROOT}/scripts/paved.mjs" status --json, load only relevant .paved/project/ context, and invoke verification with node "${CLAUDE_PLUGIN_ROOT}/scripts/paved.mjs" verify --json. Always run it from the repository being worked on, never from the plugin directory. Do not edit generated integration files or bypass Paved lifecycle and ownership checks.