Prompt file imported from PauloHYBEX/Nexus-TCMS (.windsurf/workflows/decision-log.md). Copyright stays with the author.

Decision Log

Name: decision-log
Author: PauloHYBEX

Capture a decision — architectural choice, library pick, scope trade-off, pattern selection — into .planning/DECISIONS.md. The decision register is the project's institutional memory: it tells future Cascade (and future you) why the project is built the way it is.

Usage: decision-log [description] or just decision-log to capture from recent conversation.

Step 1: Extract Decision Content

With description argument: Use it as the decision title/focus.

Without argument: Analyze recent conversation to extract the decision being made:

What choice was just discussed or made?
What were the alternatives?
What was the rationale?
What does this lock in or foreclose?

Formulate:

title — 3-8 words (e.g., "Use Zustand over Redux for state", "Single-table DynamoDB design")
type — architecture | library | scope | pattern | lesson
context — why this decision was needed (1-2 sentences)
options — alternatives that were considered (list)
choice — what was decided
rationale — why this choice over the alternatives
consequences — what this locks in or makes harder

Step 2: Read Existing DECISIONS.md

cat .planning/DECISIONS.md 2>/dev/null || echo "File does not exist yet."

If it doesn't exist, it will be created. Note the highest existing DEC-XXX number to assign the next ID.

Step 3: Check for Conflicts

Scan existing decisions for any that might conflict with or be superseded by the new one:

grep -i "[key words from title]" .planning/DECISIONS.md 2>/dev/null

If a related decision exists, show it and ask: "This may relate to DEC-[XXX]: [title]. Is this a new decision, or does it update/supersede the existing one?"

New decision → create DEC-[next]
Updates existing → add a note to existing entry, create new entry with supersedes: DEC-[XXX]

Step 4: Read Phase Context

cat .planning/STATE.md | grep "Phase:"

Note the current phase number for the decision record.

Step 5: Write to DECISIONS.md

If DECISIONS.md doesn't exist, create it with header:

# Decisions Register

A living record of architectural, scope, and pattern decisions made during this project.
Each entry captures context, alternatives considered, and rationale — so future sessions
understand *why* the project is built the way it is.

Read this before proposing approaches that may conflict with prior decisions.

---

Append the new entry:

## DEC-[XXX]: [title]

**Date:** [YYYY-MM-DD] | **Phase:** [N] | **Type:** [type]

**Context:** [why this decision was needed]

**Options considered:**
- [option A]: [brief description and trade-off]
- [option B]: [brief description and trade-off]

**Choice:** [what was decided]

**Rationale:** [why this over the alternatives]

**Consequences:** [what this locks in, what it makes harder, what it enables]

**Status:** active

---

Step 6: Commit

git add .planning/DECISIONS.md
git commit -m "docs: log decision — [title]"

Step 7: Confirm

Decision logged: DEC-[XXX]

  [title]
  Type: [type] | Phase: [N]

Decisions register: .planning/DECISIONS.md ([N] total decisions)

Continue with current work, or capture another with decision-log.

Learning Checkpoint

Read learning_mode from .planning/config.json.

If auto: After logging a significant architectural decision:

💡 Decision logged. Want to explore it deeper?

@agentic-learning either-or — Walk through the decision more systematically: what did each option optimize for? What would have to be true for the other option to have been better? This builds the decision-making intuition, not just the record.

If manual: No note (keep it fast — this workflow is meant to be a quick capture).

# Decision Log Capture a decision — architectural choice, library pick, scope trade-off, pattern selection — into `.planning/DECISIONS.md`. The decision register is the project's institutional memory: it tells future Cascade (and future you) *why* the project is built the way it is. **Usage:** `decision-log [description]` or just `decision-log` to capture from recent conversation. ## Step 1: Extract Decision Content **With description argument:** Use it as the decision title/focus. **Without argument:** Analyze recent conversation to extract the decision being made: - What choice was just discussed or made? - What were the alternatives? - What was the rationale? - What does this lock in or foreclose? Formulate: - `title` — 3-8 words (e.g., "Use Zustand over Redux for state", "Single-table DynamoDB design") - `type` — `architecture` | `library` | `scope` | `pattern` | `lesson` - `context` — why this decision was needed (1-2 sentences) - `options` — alternatives that were considered (list) - `choice` — what was decided - `rationale` — why this choice over the alternatives - `consequences` — what this locks in or makes harder ## Step 2: Read Existing DECISIONS.md ```bash cat .planning/DECISIONS.md 2>/dev/null || echo "File does not exist yet." ``` If it doesn't exist, it will be created. Note the highest existing DEC-XXX number to assign the next ID. ## Step 3: Check for Conflicts Scan existing decisions for any that might conflict with or be superseded by the new one: ```bash grep -i "[key words from title]" .planning/DECISIONS.md 2>/dev/null ``` If a related decision exists, show it and ask: "This may relate to DEC-[XXX]: [title]. Is this a new decision, or does it update/supersede the existing one?" - **New decision** → create DEC-[next] - **Updates existing** → add a note to existing entry, create new entry with `supersedes: DEC-[XXX]` ## Step 4: Read Phase Context ```bash cat .planning/STATE.md | grep "Phase:" ``` Note the current phase number for the decision record. ## Step 5: Write to DECISIONS.md If DECISIONS.md doesn't exist, create it with header: ```markdown # Decisions Register A living record of architectural, scope, and pattern decisions made during this project. Each entry captures context, alternatives considered, and rationale — so future sessions understand *why* the project is built the way it is. Read this before proposing approaches that may conflict with prior decisions. --- ``` Append the new entry: ```markdown ## DEC-[XXX]: [title] **Date:** [YYYY-MM-DD] | **Phase:** [N] | **Type:** [type] **Context:** [why this decision was needed] **Options considered:** - [option A]: [brief description and trade-off] - [option B]: [brief description and trade-off] **Choice:** [what was decided] **Rationale:** [why this over the alternatives] **Consequences:** [what this locks in, what it makes harder, what it enables] **Status:** active --- ``` ## Step 6: Commit ```bash git add .planning/DECISIONS.md git commit -m "docs: log decision — [title]" ``` ## Step 7: Confirm ``` Decision logged: DEC-[XXX] [title] Type: [type] | Phase: [N] Decisions register: .planning/DECISIONS.md ([N] total decisions) Continue with current work, or capture another with decision-log. ``` --- ## Learning Checkpoint Read `learning_mode` from `.planning/config.json`. **If `auto`:** After logging a significant architectural decision: > 💡 **Decision logged.** Want to explore it deeper? > > `@agentic-learning either-or` — Walk through the decision more systematically: what did each option optimize for? What would have to be true for the other option to have been better? This builds the decision-making intuition, not just the record. **If `manual`:** No note (keep it fast — this workflow is meant to be a quick capture).

{ "prompt": "# Decision Log\n\nCapture a decision — architectural choice, library pick, scope trade-off, pattern selection — into `.planning/DECISIONS.md`. The decision register is the project's institutional memory: it tells future Cascade (and future you) *why* the project is built the way it is.\n\n**Usage:** `decision-log [description]` or just `decision-log` to capture from recent conversation.\n\n## Step 1: Extract Decision Content\n\n**With description argument:** Use it as the decision title/focus.\n\n**Without argument:** Analyze recent conversation to extract the decision being made:\n- What choice was just discussed or made?\n- What were the alternatives?\n- What was the rationale?\n- What does this lock in or foreclose?\n\nFormulate:\n- `title` — 3-8 words (e.g., \"Use Zustand over Redux for state\", \"Single-table DynamoDB design\")\n- `type` — `architecture` | `library` | `scope` | `pattern` | `lesson`\n- `context` — why this decision was needed (1-2 sentences)\n- `options` — alternatives that were considered (list)\n- `choice` — what was decided\n- `rationale` — why this choice over the alternatives\n- `consequences` — what this locks in or makes harder\n\n## Step 2: Read Existing DECISIONS.md\n\n```bash\ncat .planning/DECISIONS.md 2>/dev/null || echo \"File does not exist yet.\"\n```\n\nIf it doesn't exist, it will be created. Note the highest existing DEC-XXX number to assign the next ID.\n\n## Step 3: Check for Conflicts\n\nScan existing decisions for any that might conflict with or be superseded by the new one:\n\n```bash\ngrep -i \"[key words from title]\" .planning/DECISIONS.md 2>/dev/null\n```\n\nIf a related decision exists, show it and ask: \"This may relate to DEC-[XXX]: [title]. Is this a new decision, or does it update/supersede the existing one?\"\n\n- **New decision** → create DEC-[next]\n- **Updates existing** → add a note to existing entry, create new entry with `supersedes: DEC-[XXX]`\n\n## Step 4: Read Phase Context\n\n```bash\ncat .planning/STATE.md | grep \"Phase:\"\n```\n\nNote the current phase number for the decision record.\n\n## Step 5: Write to DECISIONS.md\n\nIf DECISIONS.md doesn't exist, create it with header:\n\n```markdown\n# Decisions Register\n\nA living record of architectural, scope, and pattern decisions made during this project.\nEach entry captures context, alternatives considered, and rationale — so future sessions\nunderstand *why* the project is built the way it is.\n\nRead this before proposing approaches that may conflict with prior decisions.\n\n---\n```\n\nAppend the new entry:\n\n```markdown\n## DEC-[XXX]: [title]\n\n**Date:** [YYYY-MM-DD] | **Phase:** [N] | **Type:** [type]\n\n**Context:** [why this decision was needed]\n\n**Options considered:**\n- [option A]: [brief description and trade-off]\n- [option B]: [brief description and trade-off]\n\n**Choice:** [what was decided]\n\n**Rationale:** [why this over the alternatives]\n\n**Consequences:** [what this locks in, what it makes harder, what it enables]\n\n**Status:** active\n\n---\n```\n\n## Step 6: Commit\n\n```bash\ngit add .planning/DECISIONS.md\ngit commit -m \"docs: log decision — [title]\"\n```\n\n## Step 7: Confirm\n\n```\nDecision logged: DEC-[XXX]\n\n [title]\n Type: [type] | Phase: [N]\n\nDecisions register: .planning/DECISIONS.md ([N] total decisions)\n\nContinue with current work, or capture another with decision-log.\n```\n\n---\n\n## Learning Checkpoint\n\nRead `learning_mode` from `.planning/config.json`.\n\n**If `auto`:** After logging a significant architectural decision:\n\n> 💡 **Decision logged.** Want to explore it deeper?\n>\n> `@agentic-learning either-or` — Walk through the decision more systematically: what did each option optimize for? What would have to be true for the other option to have been better? This builds the decision-making intuition, not just the record.\n\n**If `manual`:** No note (keep it fast — this workflow is meant to be a quick capture).", "variables": [], "notes": "Capture an architectural or scope decision with its context, alternatives, and rationale into .planning/DECISIONS.md", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/PauloHYBEX/Nexus-TCMS", "path": ".windsurf/workflows/decision-log.md", "ref": "af66d4e66d7443d045e74bafc302cd998ceb5b99", "url": "https://github.com/PauloHYBEX/Nexus-TCMS/blob/af66d4e66d7443d045e74bafc302cd998ceb5b99/.windsurf/workflows/decision-log.md", "key": "PauloHYBEX/Nexus-TCMS/.windsurf/workflows/decision-log.md" } } }

decision-log

About

Decision Log

Step 1: Extract Decision Content

Step 2: Read Existing DECISIONS.md

Step 3: Check for Conflicts

Step 4: Read Phase Context

Step 5: Write to DECISIONS.md

Step 6: Commit

Step 7: Confirm

Learning Checkpoint

Use it

Manifest

Reviews