decision-workflow

star 18

Create a structured decision workflow for design-heavy repositories. Use when the user needs to compare options with tradeoff analysis, assign a decision owner, and track consequences. Produces a DW-NNN document with options, pros, cons, and tradeoff analysis.

AMDResearch By AMDResearch schedule Updated 4/27/2026

name: decision-workflow description: | Create a structured decision workflow for design-heavy repositories. Use when the user needs to compare options with tradeoff analysis, assign a decision owner, and track consequences. Produces a DW-NNN document with options, pros, cons, and tradeoff analysis.

decision-workflow

Purpose

Produce a decision document that records a pending or completed design decision with enough structure that future readers understand what was decided, why, what was rejected, and what consequences follow.

Required Reads

  • .agents/project.json -- confirm design facet is enabled
  • .agents/pm/pm-decisions.md -- existing project decisions for context and to avoid duplication
  • docs/ directory listing -- locate related design documents
  • .agents/pm/pm-current-state.md -- understand current project state

Procedure

  1. Ask the user to describe the decision topic. Collect: the question being decided, the context or trigger, and the decision owner (person or role responsible for the final call).
  2. Generate a decision ID using the format DW-<NNN> where NNN is the next sequential number based on existing decisions in docs/decisions/.
  3. Create the decision file at docs/decisions/DW-<NNN>-<slug>.md.
  4. Write the document with these sections:
    • Status: one of proposed, accepted, superseded, rejected.
    • Context: what prompted this decision and why it matters now.
    • Options: list each option with a description, pros, and cons.
    • Tradeoff Analysis: compare options on the dimensions that matter (cost, risk, complexity, reversibility).
    • Decision: the chosen option (leave blank if status is proposed).
    • Decision Owner: who makes or made the final call.
    • Rationale: why this option was chosen over the alternatives.
    • Consequences: what changes, follow-up work, or constraints result from this decision.
    • Open Questions: anything unresolved.
  5. If a docs/decisions/ directory does not exist, create it.
  6. Update docs/decisions/index.md (create if missing) to list the new decision.
  7. If the decision is accepted, add a summary entry to .agents/pm/pm-decisions.md.
  8. Present the draft to the user for review.

Output

  • Decision document: docs/decisions/DW-<NNN>-<slug>.md
  • Updated docs/decisions/index.md
  • Updated .agents/pm/pm-decisions.md (if decision is accepted)

Completion Criteria

  • The decision document contains all required sections.
  • At least two options are described with pros and cons.
  • The document is listed in the decisions index.
  • The status field is set correctly.

Error Handling

  • If the design facet is not enabled, warn the user and ask whether to proceed.
  • If a decision with the same topic already exists, show it to the user and ask whether to update the existing record or create a new one.
  • If the user cannot identify at least two options, note this gap explicitly and set status to proposed with an open question about alternatives.
Install via CLI
npx skills add https://github.com/AMDResearch/omniprobe --skill decision-workflow
Repository Details
star Stars 18
call_split Forks 7
navigation Branch main
article Path SKILL.md
More from Creator