decision-record

Use this Skill, which guides the add_decisions call whenever the user explicitly approves a proposal. It requires a topic_id, domain tags, and a reason field separating the conclusion from its rationale, and strongly recommends a title for list readability.

Record a decision only when explicit user agreement exists, such as approval phrases or a declared choice. Discussion process and outcomes without consensus belong to the recording skill via add_logs, while unresolved points use the [議論中] prefix in add_decisions.

Prefix the decision body with [議論中] and list the candidate options and how far the discussion progressed in the reason field. Trigger this when the topic shifts or the session nears its end; no user agreement is required for these state records.

Precedent sections are optional structured blocks at the end of a reason: rejected alternatives, scope in/out, verification, and adjacent checks. They are parsed into a machine-readable precedent field returned by add_decisions and reflected in get_decisions responses.

Warnings appear when section formatting deviates from the spec, such as missing colons, non-line-start headings, or near-miss headings like 却下例 instead of 却下案. They are soft validation only; the decision is still created and the warning guides future format fixes.

The add_decisions response includes related_decisions showing similar entries in the same topic. If a contradiction or duplicate is noticed, report it immediately with report_signal(kind="contradiction"); retract or supersede decisions are outside this Skill's scope.