بنقرة واحدة
decision-capture
Detect decisions in conversation and record them with rationale, alternatives, and outcome tracking.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Detect decisions in conversation and record them with rationale, alternatives, and outcome tracking.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when adding or reviewing tests for Reborn behavior — choosing a test tier, covering a bug fix, testing model/tool-choice behavior, touching tests/integration or tests/fixtures/llm_traces, or when a test needs Postgres, Docker, or a live LLM.
Navigate building a user-facing feature in the Reborn stack (a capability that crosses product_workflow → composition → webui_v2 → runtime/serve → frontend). Use when planning or implementing any new Reborn settings page, endpoint, facade method, or runtime-backed capability — especially before writing code, to avoid rebuilding what already exists and to wire it in one pass instead of layer-by-layer.
Use when asked to "review the open PRs", review a batch or stack of pull requests, or run a recurring PR-review pass on a repo — especially with many PRs, stacked branches, conflicts, or security-sensitive changes. Covers grouping, fan-out to review subagents, verdict synthesis, and posting.
Generate or update the IronClaw architecture overview video using Remotion. Use when asked to update, regenerate, or modify the architecture video, add/remove scenes, or reflect codebase changes in the video.
Use when writing or reviewing a change in crates/ that adds a trait, a crate, a dependency edge, a re-export, or code in ironclaw_reborn_composition — or when deciding whether an abstraction, layer, or crate boundary is justified in the IronClaw Reborn stack.
Use when starting work in the IronClaw repo, deciding where a feature/fix/prompt/doc belongs, tracing how a request flows, looking up which crate owns a subsystem, or when repo docs, the knowledge graph, or component names seem stale, missing, or contradictory.
| name | decision-capture |
| version | 0.2.0 |
| description | Detect decisions in conversation and record them with rationale, alternatives, and outcome tracking. |
| activation | {"keywords":["decided","decision","chose","going with","settled on","picked","landed on","went with","finalized","agreed on","opted for","concluded","confirmed","final answer","made the call","ruling","verdict","record decision"],"exclude_keywords":["undecided","considering","thinking about","tentative","maybe"],"patterns":["(?i)(we|I|team) (decided|chose|went with|picked|settled on|landed on|opted for)","(?i)let's go with","(?i)the (decision|call|verdict) is","(?i)record (this|that) decision","(?i)(instead of|replaced|switched to|migrated to)"],"tags":["commitments","decision-making"],"max_context_tokens":1200} |
When a decision is detected in conversation, record it in the commitments workspace. Decisions are durable knowledge — they explain why a path was chosen and enable outcome tracking over time.
Look for explicit decision language:
Do NOT capture:
When uncertain, ask: "Was that a decision, or still thinking it through?"
This skill is only successful if the decision is actually persisted. Do not just summarize or acknowledge the decision.
Execution order is mandatory:
memory_write for projects/commitments/decisions/<date>-<slug>.mdmemory_write for a follow-on commitment in projects/commitments/open/memory_write for context/intel/<slug>.mdNever say a decision was "captured", "recorded", or "saved" unless the
corresponding memory_write call succeeded.
Write to projects/commitments/decisions/<date>-<slug>.md via memory_write:
---
type: decision
decided_at: <today YYYY-MM-DD>
context: <topic-slug>
participants: [<who was involved>]
confidence: <high if explicit, medium if inferred>
reversible: <true|false>
outcome: null
outcome_positive: null
tags: [<relevant tags>]
---
# <What was decided>
## Context
<Why this decision was needed — 1-2 sentences.>
## Options considered
1. **<Option A>** — <brief pros/cons>
2. **<Option B>** — <brief pros/cons>
## Rationale
<Why this option was chosen.>
## Outcome
<To be filled in later when outcome is known.>
projects/commitments/open/ following the commitment schema.context/intel/<slug>.md with a brief summary: "Decided X on . Rationale: ." This makes the decision searchable as durable knowledge.For explicit requests like "record this decision", "log this decision", or "note the decision", default to doing all required writes immediately rather than asking a follow-up question unless the content is genuinely ambiguous.
The triage mission checks for decisions older than 7 days without an outcome. It prompts: "You decided days ago. How did it turn out?" When the user provides an outcome, update the decision file's outcome and outcome_positive fields.
After the write(s) succeed, briefly confirm: