@diottodev/runic 1.0.0 → 1.1.0

package/c-level/cto-review/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: "cto-review"
+description: "/cs:cto-review <plan> — Architecture and scaling interrogation. Tech debt, scaling cliffs, team scaling, build-vs-buy."
+---
+
+# /cs:cto-review — CTO Forcing Questions
+
+**Command:** `/cs:cto-review <plan>`
+
+Pressure-tests architecture and engineering scaling decisions. Six questions to surface the next scaling cliff before you hit it.
+
+## When to Run
+
+- Before approving a major architecture change
+- Before doubling the engineering team
+- Before a build-vs-buy decision > $100K/year
+- When a system is showing reliability stress (SLOs missed)
+- Before committing to a new platform / language / DB
+
+## The Six CTO Questions
+
+### 1. Scaling Cliff
+**Where does the current architecture break, in terms of users / requests / data volume?**
+- Be specific. "It breaks at 10× current load because the primary DB writes saturate."
+- If you don't know, run a load test before deciding.
+
+### 2. Tech Debt Inventory
+**What's the top tech debt item, what's it costing per week, and when does it become blocking?**
+```bash
+python ../../../skills/cto-advisor/scripts/tech_debt_analyzer.py
+```
+
+### 3. Team Scaling
+**For each open req, what's the ramp time and contribution model?**
+```bash
+python ../../../skills/cto-advisor/scripts/team_scaling_calculator.py
+```
+
+### 4. Build vs Buy
+**Why are we building this instead of buying it — and what's the 3-year TCO of each?**
+- If "we want control" or "it's not that hard" — push back.
+- If the answer is "this is our core moat," build.
+
+### 5. SLO / Reliability
+**What are the SLOs for this system and what's the current error budget burn?**
+- Without an SLO, you can't reason about reliability tradeoffs.
+- See `engineering/slo-architect` for SLO design.
+
+### 6. Security & Compliance Surface
+**What does this expose, and has cs-ciso-advisor signed off?**
+- Architecture decisions are compliance decisions.
+- Loop in cs-ciso-advisor before commit.
+
+## Workflow
+
+1. Run the tech debt analyzer + team scaling calculator
+2. Define the scaling-cliff hypothesis explicitly
+3. Cross-check with cs-ciso-advisor for security implications
+4. Apply the verdict
+
+## Output Format
+
+```markdown
+# CTO Review: <plan>
+**Date:** YYYY-MM-DD
+
+## Scaling Cliff
+- Current capacity: <metric>
+- Break point: <metric>
+- Headroom: X months at current growth
+
+## Tech Debt
+- Top item: <description>
+- Cost per week: $X or N eng-hours
+- Blocking date estimate: <date>
+
+## Team
+- Open reqs: N
+- Median ramp: X months
+- Contribution model: <pairing / squad / area>
+
+## Build vs Buy
+- 3-year build TCO: $X
+- 3-year buy TCO: $X
+- Strategic fit: <core / context>
+- Decision: BUILD | BUY
+
+## Reliability
+- SLO defined: yes / no
+- Error budget burn: X% (target < Y%)
+
+## Security
+- cs-ciso sign-off: ✅ / ❌
+
+## Verdict
+🟢 SHIP | 🟡 SHARPEN | 🔴 BLOCK
+
+## Next Steps
+[3 concrete actions]
+```
+
+## Routing
+
+- `/cs:ciso-review` — mandatory if data surface changes
+- `/cs:cfo-review` — for build-vs-buy > $100K
+- `/cs:execute` — quarterly plan
+- `/cs:boardroom` — for architecture pivots
+
+## Related
+
+- Agent: [`cs-cto-advisor`](../../../../agents/c-level/cs-cto-advisor.md)
+- Skill: [`cto-advisor`](../../../skills/cto-advisor/SKILL.md)
+- SLO: `../../../../engineering/slo-architect/`
+
+---
+
+**Version:** 1.0.0

package/c-level/culture-architect/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: "culture-architect"
+description: "Build, measure, and evolve company culture as operational behavior — not wall posters. Covers mission/vision/values workshops, values-to-behaviors translation, culture code creation, culture health assessment, and cultural rituals by stage. Use when building company values, assessing culture health, designing cultural rituals, creating culture codes, handling culture clashes, or when user mentions culture, values, culture debt, founder culture, or culture code."
+license: MIT
+metadata:
+  version: 1.0.0
+  author: Alireza Rezvani
+  category: c-level
+  domain: culture-leadership
+  updated: 2026-03-05
+  frameworks: culture-playbook, culture-code-template
+---
+
+# Culture Architect
+
+Culture is what you DO, not what you SAY. This skill builds culture as an operational system — observable behaviors, measurable health, and rituals that scale.
+
+## Keywords
+culture, company culture, values, mission, vision, culture code, cultural rituals, culture health, values-to-behaviors, founder culture, culture debt, value-washing, culture assessment, culture survey, Netflix culture deck, HubSpot culture code, psychological safety, culture scaling
+
+## Core Principle
+
+**Culture = (What you reward) + (What you tolerate) + (What you celebrate)**
+
+If your values say "transparency" but you punish bearers of bad news — your real value is "optics." Culture is not aspirational. It's descriptive. The work is closing the gap between stated and actual.
+
+## Frameworks
+
+### 1. Mission / Vision / Values Workshop
+
+Run this conversationally, not as a corporate offsite. Three questions:
+
+**Mission** — Why do we exist (beyond making money)?
+- "What would be lost if we disappeared tomorrow?"
+- Mission is present-tense. "We reduce preventable falls in elderly care." Not "to be the leading..."
+
+**Vision** — What does winning look like in 5–10 years?
+- Specific enough to be wrong. "Every care home in Europe uses our system" beats "be the market leader."
+
+**Values** — What behaviors do we actually model?
+- Start with what you observe, not what sounds good. "What did our last great hire do that nobody asked them to?"
+- Keep to 3–5. More than 5 and none of them mean anything.
+
+### 2. Values → Behaviors Translation
+
+This is the work. Every value needs behavioral anchors or it's decoration.
+
+| Value | Bad version | Behavioral anchor |
+|-------|------------|-------------------|
+| Transparency | "We're open and honest" | "We share bad news within 24 hours, including to our manager" |
+| Ownership | "We take responsibility" | "We don't hand off problems — we own them until resolved, even across team boundaries" |
+| Speed | "We move fast" | "Decisions under €5K happen at team level, same day, no approval needed" |
+| Quality | "We don't cut corners" | "We stop the line before shipping something we're not proud of" |
+| Customer-first | "Customers are our priority" | "Any team member can escalate a customer issue to leadership, bypassing normal channels" |
+
+**Workshop exercise:** Write your value. Then ask "How would a new hire know we actually live this on day 30?" If you can't answer concretely, it's not a value — it's an aspiration.
+
+### 3. Culture Code Creation
+
+A culture code is a public document that describes how you operate. It should scare off the wrong people and attract the right ones.
+
+**Structure:**
+1. Who we are (mission + context)
+2. Who thrives here (specific behaviors, not adjectives)
+3. Who doesn't thrive here (honest — this is the useful part)
+4. How we make decisions
+5. How we communicate
+6. How we grow people
+7. What we expect of leaders
+
+See `templates/culture-code-template.md` for a complete template.
+
+**Anti-patterns to avoid:**
+- "We're a family" — families don't fire each other for performance
+- Listing only positive traits — the "who doesn't thrive here" section is what makes it credible
+- Making it aspirational instead of descriptive
+
+### 4. Culture Health Assessment
+
+Run quarterly. 8–12 questions. Anonymous. See `references/culture-playbook.md` for survey design.
+
+**Core areas to measure:**
+1. Psychological safety — "Can I raise a concern without fear?"
+2. Clarity — "Do I know how my work connects to company goals?"
+3. Fairness — "Are decisions made consistently and transparently?"
+4. Growth — "Am I learning and being challenged here?"
+5. Trust in leadership — "Do I believe what leadership tells me?"
+
+**Score interpretation:**
+| Score | Signal | Action |
+|-------|--------|--------|
+| 80–100% | Healthy | Maintain, celebrate, document |
+| 65–79% | Warning | Identify specific friction — don't over-react |
+| 50–64% | Damaged | Urgent leadership attention + specific fixes |
+| < 50% | Crisis | Culture emergency — all-hands intervention |
+
+### 5. Cultural Rituals by Stage
+
+Rituals are the delivery mechanism for culture. What works at 10 people breaks at 100.
+
+**Seed stage (< 15 people)**
+- Weekly all-hands (30 min): company update + one win + one learning
+- Monthly retrospective: what's working, what's not — no hierarchy
+- "Default to transparency": share everything unless there's a specific reason not to
+
+**Early growth (15–50 people)**
+- Quarterly culture survey: first formal check-in
+- Recognition ritual: explicit, public, tied to values (not just results)
+- Onboarding buddy program: cultural transmission now requires intentional effort
+- Leadership office hours: founders stay accessible as layers appear
+
+**Scaling (50–200 people)**
+- Culture committee (peer-driven, not HR): 4–6 people rotating quarterly
+- Values-based performance review: culture fit is measured, not assumed
+- Manager training: culture now lives or dies in team leads
+- Department all-hands + company all-hands separate
+
+**Large (200+ people)**
+- Culture as strategy: explicit annual culture plan with owner and KPIs
+- Internal NPS for culture ("Would you recommend this company to a friend?")
+- Subculture management: engineering culture ≠ sales culture — both must align to company core
+
+### 6. Culture Anti-Patterns
+
+**Value-washing:** Listing values you don't practice. Symptom: employees roll their eyes during values discussions.
+- Fix: Run a values audit. Ask "What did the last person who got promoted demonstrate?" If it doesn't match your values, your real values are different.
+
+**Culture debt:** Accumulating cultural compromises over time. "We'll address the toxic star performer later." Later compounds.
+- Fix: Act on culture violations faster than you think necessary. One tolerated bad behavior destroys what ten good behaviors build.
+
+**Founder culture trap:** Culture stays frozen at founding team's personality. New hires assimilate or leave.
+- Fix: Explicitly evolve values as you scale. What worked at 10 people (move fast, ask forgiveness) may be destructive at 100 (we need process).
+
+**Culture by osmosis:** Assuming culture transmits naturally. It did at 10 people. It doesn't at 50.
+- Fix: Make culture intentional. Document it. Teach it. Measure it. Reward it explicitly.
+
+## Culture Integration with C-Suite
+
+| When... | Culture Architect works with... | To... |
+|---------|---------------------------------|-------|
+| Hiring surge | CHRO | Ensure culture fit is measured, not guessed |
+| Org reorg | COO + CEO | Manage culture disruption from structure change |
+| M&A or partnership | CEO + COO | Detect and resolve culture clashes early |
+| Performance issues | CHRO | Separate culture fit from skill deficit |
+| Strategy pivot | CEO | Update values/behaviors that the pivot makes obsolete |
+| Rapid growth | All | Scale rituals before culture dilutes |
+
+## Key Questions a Culture Architect Asks
+
+- "Can you name the last person we fired for culture reasons? What did they do?"
+- "What behavior got your last promoted employee promoted? Is that in your values?"
+- "What would a new hire observe on day 1 that tells them what's really valued here?"
+- "What do we tolerate that we shouldn't? Who knows and does nothing?"
+- "How does a team lead in Berlin know what the culture is in Madrid?"
+
+## Red Flags
+
+- Values posted on the wall, never referenced in reviews or decisions
+- Star performers protected from cultural standards
+- Leaders who "don't have time" for culture rituals
+- New hires feeling the culture is "different than advertised"
+- No mechanism to raise cultural concerns safely
+- Culture survey results never shared with the team
+
+## Detailed References
+- `references/culture-playbook.md` — Netflix analysis, survey design, ritual examples, M&A playbook
+- `templates/culture-code-template.md` — Culture code document template

package/c-level/decide/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: "decide"
+description: "/cs:decide <memo> — Log a decision to two-layer memory via decision-logger. Approved memo becomes durable; raw transcripts kept for reference."
+---
+
+# /cs:decide — Log the Decision
+
+**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.
+
+## Pipeline Position
+
+```
+/cs:office-hours  →  /cs:brief  →  /cs:boardroom  →  /cs:decide  →  /cs:execute  →  /cs:post-mortem
+                                                       ↑ you are here
+```
+
+## Two-Layer Memory Model
+
+The `decision-logger` skill maintains two layers:
+
+1. **Raw transcripts** — every boardroom session, every advisor's Phase 2 position, every dissent. Stored under `~/.claude/decisions/raw/`. Reference only, never feeds back automatically.
+2. **Approved decisions** — only the founder-signed memos. Stored under `~/.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.
+
+## Input
+
+A board memo file (output of `/cs:boardroom`).
+
+## Workflow
+
+1. Read the memo path
+2. Verify it has founder approval (status: APPROVED)
+3. Extract structured decision record:
+   - Decision title
+   - Date decided
+   - Option chosen
+   - Success + kill criteria
+   - Dissent (preserved)
+   - Review checkpoint date
+4. Append to `~/.claude/decisions/approved/<YYYY-MM-DD>-<slug>.md`
+5. Update the raw transcript pointer
+6. If llm-wiki bridge configured, write to vault (`~/company-vault/10-decisions/`)
+7. Schedule auto-revisit (90 days)
+
+## Output Record Format
+
+```markdown
+# 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
+```
+
+## Why Preserved Dissent
+
+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.
+
+## Routing
+
+- `/cs:execute <decision>` — build the 90-day plan
+- `/cs:freeze <decision> <days>` — lock if irreversible
+- (Auto-scheduled) `/cs:post-mortem <decision>` — at 90-day checkpoint
+
+## Stale-Decision Audit
+
+`cs-chief-of-staff` runs a weekly stale audit:
+- Decisions > 90 days without revisit → flag for `/cs:post-mortem`
+- Decisions with kill criteria triggered → flag immediately
+- Decisions whose company-context.md basis has changed → flag for re-examination
+
+## Related
+
+- Skill: [`decision-logger`](../../../skills/decision-logger/SKILL.md)
+- Agent: [`cs-chief-of-staff`](../../agents/cs-chief-of-staff.md)
+- Bridge: [`../../references/llm-wiki-bridge.md`](../../references/llm-wiki-bridge.md)
+
+---
+
+**Version:** 1.0.0

package/c-level/decision-logger/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: "decision-logger"
+description: "Two-layer memory architecture for board meeting decisions. Manages raw transcripts (Layer 1) and approved decisions (Layer 2). Use when logging decisions after a board meeting, reviewing past decisions with /cs:decisions, or checking overdue action items with /cs:review. Invoked automatically by the board-meeting skill after Phase 5 founder approval."
+license: MIT
+metadata:
+  version: 1.0.0
+  author: Alireza Rezvani
+  category: c-level
+  domain: decision-memory
+  updated: 2026-03-05
+  python-tools: scripts/decision_tracker.py
+---
+
+# Decision Logger
+
+Two-layer memory system. Layer 1 stores everything. Layer 2 stores only what the founder approved. Future meetings read Layer 2 only — this prevents hallucinated consensus from past debates bleeding into new deliberations.
+
+## Keywords
+decision log, memory, approved decisions, action items, board minutes, /cs:decisions, /cs:review, conflict detection, DO_NOT_RESURFACE
+
+## Quick Start
+
+```bash
+python scripts/decision_tracker.py --demo             # See sample output
+python scripts/decision_tracker.py --summary          # Overview + overdue
+python scripts/decision_tracker.py --overdue          # Past-deadline actions
+python scripts/decision_tracker.py --conflicts        # Contradiction detection
+python scripts/decision_tracker.py --owner "CTO"      # Filter by owner
+python scripts/decision_tracker.py --search "pricing" # Search decisions
+```
+
+---
+
+## Commands
+
+| Command | Effect |
+|---------|--------|
+| `/cs:decisions` | Last 10 approved decisions |
+| `/cs:decisions --all` | Full history |
+| `/cs:decisions --owner CMO` | Filter by owner |
+| `/cs:decisions --topic pricing` | Search by keyword |
+| `/cs:review` | Action items due within 7 days |
+| `/cs:review --overdue` | Items past deadline |
+
+---
+
+## Two-Layer Architecture
+
+### Layer 1 — Raw Transcripts
+**Location:** `memory/board-meetings/YYYY-MM-DD-raw.md`
+- Full Phase 2 agent contributions, Phase 3 critique, Phase 4 synthesis
+- All debates, including rejected arguments
+- **NEVER auto-loaded.** Only on explicit founder request.
+- Archive after 90 days → `memory/board-meetings/archive/YYYY/`
+
+### Layer 2 — Approved Decisions
+**Location:** `memory/board-meetings/decisions.md`
+- ONLY founder-approved decisions, action items, user corrections
+- **Loaded automatically in Phase 1 of every board meeting**
+- Append-only. Decisions are never deleted — only superseded.
+- Managed by Chief of Staff after Phase 5. Never written by agents directly.
+
+---
+
+## Decision Entry Format
+
+```markdown
+## [YYYY-MM-DD] — [AGENDA ITEM TITLE]
+
+**Decision:** [One clear statement of what was decided.]
+**Owner:** [One person or role — accountable for execution.]
+**Deadline:** [YYYY-MM-DD]
+**Review:** [YYYY-MM-DD]
+**Rationale:** [Why this over alternatives. 1-2 sentences.]
+
+**User Override:** [If founder changed agent recommendation — what and why. Blank if not applicable.]
+
+**Rejected:**
+- [Proposal] — [reason] [DO_NOT_RESURFACE]
+
+**Action Items:**
+- [ ] [Action] — Owner: [name] — Due: [YYYY-MM-DD] — Review: [YYYY-MM-DD]
+
+**Supersedes:** [DATE of previous decision on same topic, if any]
+**Superseded by:** [Filled in retroactively if overridden later]
+**Raw transcript:** memory/board-meetings/[DATE]-raw.md
+```
+
+---
+
+## Conflict Detection
+
+Before logging, Chief of Staff checks for:
+1. **DO_NOT_RESURFACE violations** — new decision matches a rejected proposal
+2. **Topic contradictions** — two active decisions on same topic with different conclusions
+3. **Owner conflicts** — same action assigned to different people in different decisions
+
+When a conflict is found:
+```
+⚠️ DECISION CONFLICT
+New: [text]
+Conflicts with: [DATE] — [existing text]
+
+Options: (1) Supersede old  (2) Merge  (3) Defer to founder
+```
+
+**DO_NOT_RESURFACE enforcement:**
+```
+🚫 BLOCKED: "[Proposal]" was rejected on [DATE]. Reason: [reason].
+To reopen: founder must explicitly say "reopen [topic] from [DATE]".
+```
+
+---
+
+## Logging Workflow (Post Phase 5)
+
+1. Founder approves synthesis
+2. Write Layer 1 raw transcript → `YYYY-MM-DD-raw.md`
+3. Check conflicts against `decisions.md`
+4. Surface conflicts → wait for founder resolution
+5. Append approved entries to `decisions.md`
+6. Confirm: decisions logged, actions tracked, DO_NOT_RESURFACE flags added
+
+---
+
+## Marking Actions Complete
+
+```markdown
+- [x] [Action] — Owner: [name] — Completed: [DATE] — Result: [one sentence]
+```
+
+Never delete completed items. The history is the record.
+
+---
+
+## File Structure
+
+```
+memory/board-meetings/
+├── decisions.md       # Layer 2: append-only, founder-approved
+├── YYYY-MM-DD-raw.md  # Layer 1: full transcript per meeting
+└── archive/YYYY/      # Raw files after 90 days
+```
+
+---
+
+## References
+- `templates/decision-entry.md` — single entry template with field rules
+- `scripts/decision_tracker.py` — CLI parser, overdue tracker, conflict detector

package/c-level/execute/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: "execute"
+description: "/cs:execute <decision> — Generate a 90-day execution plan with weekly milestones, DRIs, and check-in cadence from an approved decision."
+---
+
+# /cs:execute — 90-Day Execution Plan
+
+**Command:** `/cs:execute <decision-path>`
+
+Turns an approved decision into a 90-day plan with weekly milestones, named DRIs, and a check-in cadence. Where most decisions die: between "we decided" and "what's next Monday?"
+
+## Pipeline Position
+
+```
+/cs:office-hours  →  /cs:brief  →  /cs:boardroom  →  /cs:decide  →  /cs:execute  →  /cs:post-mortem
+                                                                       ↑ you are here
+```
+
+## Input
+
+An approved decision record (output of `/cs:decide`).
+
+## Output Plan Format
+
+Saved to `~/.claude/execution/YYYY-MM-DD-<slug>.md`:
+
+```markdown
+# Execution Plan: <decision title>
+**Decision:** <link to /cs:decide record>
+**Owner (Sponsor):** <founder or exec>
+**Start:** YYYY-MM-DD
+**Checkpoint:** YYYY-MM-DD (90d)
+
+## Outcome (binding)
+[Copied from decision: success + kill criteria]
+
+## Workstreams
+| Workstream | DRI | Success Metric | Status |
+|---|---|---|---|
+| <e.g., Pricing rollout> | <name> | <metric, threshold> | Not started |
+| <e.g., Comms> | <name> | <metric> | Not started |
+| <e.g., Eng changes> | <name> | <metric> | Not started |
+
+## Weekly Milestones
+| Week | Milestone | DRI | Definition of Done |
+|---|---|---|---|
+| 1 | <e.g., positioning locked> | <name> | <observable outcome> |
+| 2 | <e.g., draft launched> | <name> | <observable> |
+| 3 | ... | | |
+| 12 | <e.g., checkpoint review> | <name> | <observable> |
+
+## Cadence
+- **Weekly:** Owner reviews status (15 min)
+- **Bi-weekly:** Cross-functional sync (30 min)
+- **Day 30 / 60 / 90:** Checkpoint with cs-chief-of-staff
+
+## Dependencies
+- Internal: <list>
+- External: <vendors, regulators, customers>
+
+## Risk Register
+| Risk | Likelihood | Impact | Owner | Mitigation |
+|---|---|---|---|---|
+| <e.g., delayed legal review> | M | H | <name> | <plan> |
+
+## Kill Criteria Watch
+[Copied from decision; reviewed at every checkpoint]
+- <metric, threshold, action>
+```
+
+## Workflow
+
+1. Read the decision record
+2. Decompose the chosen option into 3-6 workstreams
+3. Name a DRI for each workstream
+4. Reverse-engineer 12 weekly milestones from the checkpoint date
+5. Set the cadence (weekly + bi-weekly + 30/60/90 checkpoints)
+6. Build the risk register (cross-reference original Phase 4 devil's-advocate concerns)
+7. Save and notify DRIs
+
+## Why 90 Days
+
+- Long enough to show real signal (not just activity)
+- Short enough to course-correct before damage compounds
+- Matches quarterly OKR cycle, fundraise sprints, and most board cadences
+
+## Routing
+
+- `/cs:post-mortem <decision>` — at day 90 (or earlier if kill criteria trigger)
+- `/cs:boardroom` — if a checkpoint reveals a need to re-decide
+
+## Related
+
+- Skills: [`coo-advisor`](../../../skills/coo-advisor/SKILL.md), [`strategic-alignment`](../../../skills/strategic-alignment/SKILL.md), [`change-management`](../../../skills/change-management/SKILL.md)
+- Agent: [`cs-coo-advisor`](../../agents/cs-coo-advisor.md)
+
+---
+
+**Version:** 1.0.0