record-decision

record-decision

Wraps bin/record-decision.sh. Creates one ADR file per invocation under docs/decisions/ (or the profile's configured location). Only MADR format is supported in v1.

1. Collect inputs from the user

• --title (required). Short, imperative headline: "Use Postgres for the primary datastore", "Adopt pnpm over npm". If the user's phrasing is long and prose-y ("I think we should probably go with Postgres because…"), propose a crisp title and confirm.

• --status. proposed (default) when the decision is still up for review; accepted when the user says "we've already decided" or similar. Never default to accepted silently — when unclear, you MUST call the AskUserQuestion tool (not plain text):

  {
    "questions": [
      {
        "question": "What is the status of this decision?",
        "header": "Status",
        "multiSelect": false,
        "options": [
          { "label": "Proposed (Default)", "description": "Decision is open for review" },
          { "label": "Accepted", "description": "Decision has already been agreed upon" }
        ]
      }
    ]
  }
  

• --dir. Default docs/decisions. Override when the repo uses a different location (check the profile's documentation.scaffold_types if uncertain).

• --slug — derived from the title. Review the auto-derived slug with the user when the title contains non-ASCII or unusual punctuation.

2. Check for existing scaffolding

record-decision creates the directory if missing, but doesn't scaffold a README.md or ADR-000. If the directory is empty (no prior ADRs), mention that bootstrap-project scaffolds an introductory ADR-000 and offer to run it first — but proceed with the new ADR either way if the user insists.

3. Dry-run first when the title is non-obvious

Run bin/record-decision.sh --dry-run and read back:

• The target path (which ADR number it'll land at).
• The derived slug.

Confirm before the real run. Single-line "record that we chose X" phrasings can skip confirmation when the title is already explicit.