---
name: decisions
description: >-
  Use when Paved surfaces a decision, blocks a command on user input, or an agent is
  asked to answer, relay, or raise a decision.
---

<!-- Generated by Paved plugin paved@2.0.0 from core.decisions.decisions@0.1.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.

## 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.

## 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. |

## References

No supporting files.


## Paved integration

Use the project-local Paved contract as the source of truth. Discover state with `node "<plugin root>/scripts/paved.mjs" status --json`, load only relevant `.paved/project/` context, and invoke verification with `node "<plugin root>/scripts/paved.mjs" verify --json`. `<plugin root>` is the installed Paved plugin directory, two directories above this SKILL.md. Always run the launcher from the repository being worked on, never from the plugin directory. Do not edit generated integration files or bypass Paved lifecycle and ownership checks.