/cs:decide <memo> — Log a decision to two-layer memory via decision-logger. Approved memo becomes durable; raw transcripts kept for reference. Use when the founder has approved a boardroom memo and the decision must become durable company memory — e.g. right after /cs:boardroom concludes.
cd ~/.claude/skills
git clone https://github.com/alirezarezvani/claude-skills.git claude-skills mkdir -p ~/.claude/skills/decide
curl -fsSL https://raw.githubusercontent.com/alirezarezvani/claude-skills/HEAD/.gemini/skills/decide/SKILL.md \
-o ~/.claude/skills/decide/SKILL.md Command: /cs:decide <memo-path>
Logs the founder’s decision via the decision-logger skill. This is the gate where in-session deliberation becomes durable company memory.
/cs:office-hours → /cs:brief → /cs:boardroom → /cs:decide → /cs:execute → /cs:post-mortem
↑ you are here
The decision-logger skill maintains two layers:
~/.claude/decisions/raw/. Reference only, never feeds back automatically.~/.claude/decisions/approved/. Feeds into future /cs:office-hours and /cs:founder-mode calls.This split prevents the system from “remembering” unresolved debates as if they were decisions.
A board memo file (output of /cs:boardroom).
~/.claude/decisions/approved/<YYYY-MM-DD>-<slug>.md~/company-vault/10-decisions/)# Decision: <title>
**Decided:** YYYY-MM-DD
**By:** <founder name>
**Memo:** <link to boardroom memo>
**Brief:** <link to original brief>
**Review checkpoint:** YYYY-MM-DD (90d default)
## Decision
**Chose:** <option>
**Rejected:** <other options + one-line why>
## Success Criteria (binding)
- <metric, threshold, timeframe>
## Kill Criteria (binding)
- <metric, threshold, action>
## Preserved Dissent
- **<dissenter>:** <unresolved concern>
- (preserved verbatim; dissent never erased)
## Next Action
- `/cs:execute` → 90-day plan due <date>
## Status History
- YYYY-MM-DD: APPROVED
The biggest risk in approved decisions is forgetting why someone disagreed. When the kill criteria trigger, the dissent often turns out to have been correct. Preserving it verbatim — not summarized — keeps the company honest at post-mortem time.
/cs:execute <decision> — build the 90-day plan/cs:freeze <decision> <days> — lock if irreversible/cs:post-mortem <decision> — at 90-day checkpointcs-chief-of-staff runs a weekly stale audit:
/cs:post-mortemdecision-loggercs-chief-of-staff../../references/llm-wiki-bridge.mdVersion: 1.0.0
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when executing implementation plans with independent tasks in the current session
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when implementing any feature or bugfix, before writing implementation code
Use when creating new skills, editing existing skills, or verifying skills work before deployment