@diottodev/runic 1.0.0 → 1.1.0

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

@@ -0,0 +1,110 @@
+---
+name: "cro-review"
+description: "/cs:cro-review <plan> — Pipeline-paranoid interrogation of revenue, win rate, NRR, and ramp time."
+---
+
+# /cs:cro-review — CRO Forcing Questions
+
+**Command:** `/cs:cro-review <plan>`
+
+The pipeline-paranoid operator pressure-tests revenue assumptions. Six questions that surface next-quarter pain this quarter.
+
+## When to Run
+
+- Before committing to a quarterly revenue target
+- Before changing sales motion (PLG ↔ sales-led, mid-market ↔ enterprise)
+- Before hiring a batch of reps
+- When pipeline coverage drops below 3x
+- When NRR is trending down
+
+## The Six CRO Questions
+
+### 1. Pipeline Coverage
+**What is pipeline coverage for the current quarter, by stage?**
+- Inbound-heavy: 3x. Outbound-heavy: 4x. Below either threshold = act now.
+- Stage-weighted, not just total.
+
+### 2. Win Rate Trajectory
+**What's win rate this quarter vs the last 4 — and what's the leak point?**
+- Stage-by-stage conversion.
+- If a single stage softens, identify why before forecasting.
+
+### 3. NRR Decomposition
+**What's gross retention, contraction, and expansion separately?**
+- NRR alone hides churn.
+- A 110% NRR with 95% gross retention is different from 110% with 80%.
+
+### 4. Ramp Time
+**For the last 4 hires, how many days to first deal and to quota?**
+- If ramp > 90 days at growth stage, hiring profile or enablement is broken.
+- Forecasted hires must build in ramp.
+
+### 5. Discount Discipline
+**What's the median discount this quarter vs last 4? Where is it creeping?**
+- Discount creep is the leading indicator of pricing or positioning weakness.
+- Cap discounts by approver tier.
+
+### 6. Pipeline Source Mix
+**What % of pipeline is marketing-sourced, sales-sourced, partner-sourced?**
+- If one source dominates > 80%, you have concentration risk.
+- Cross-check with cs-cmo-advisor.
+
+## Workflow
+
+```bash
+python ../../../skills/cro-advisor/scripts/revenue_forecast_model.py
+python ../../../skills/cro-advisor/scripts/churn_analyzer.py
+```
+
+## Output Format
+
+```markdown
+# CRO Review: <plan>
+**Date:** YYYY-MM-DD
+
+## Pipeline
+- Coverage: X.Xx (target 3x+)
+- Win rate: X% (4Q trend: ↑ / → / ↓)
+- Top leaking stage: <name>
+
+## Retention
+- Gross retention: X%
+- NRR: X%
+- Expansion: X%
+- Contraction: X%
+
+## Ramp
+- New hires last quarter: N
+- Median days to first deal: X
+- Median days to quota: X
+
+## Discount
+- Median discount this quarter: X%
+- Trend vs 4Q ago: <delta>
+
+## Source Mix
+- Marketing: X% | Sales: X% | Partner: X%
+
+## Verdict
+🟢 ON PLAN | 🟡 GAP | 🔴 PIPELINE CRISIS
+
+## Next Steps
+[3 concrete actions]
+```
+
+## Routing
+
+- `/cs:cfo-review` — does this hit the cash plan?
+- `/cs:cmo-review` — is pipeline source-mix healthy?
+- `/cs:execute` — quarterly plan if GREEN
+- `/cs:boardroom` — if RED
+
+## Related
+
+- Agent: [`cs-cro-advisor`](../../agents/cs-cro-advisor.md)
+- Skill: [`cro-advisor`](../../../skills/cro-advisor/SKILL.md)
+- Execution: `../../../../business-growth/`
+
+---
+
+**Version:** 1.0.0

package/c-level/cross-eval/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: "cross-eval"
+description: "/cs:cross-eval <memo> — Multi-model consensus on a board memo or strategy brief. Claude + Codex + Gemini cross-review with graceful degradation."
+---
+
+# /cs:cross-eval — Multi-Model Consensus
+
+**Command:** `/cs:cross-eval <memo-or-brief>`
+
+Runs the same memo through multiple model providers and reconciles divergences. Use for **high-stakes, irreversible decisions** where single-model bias is too costly: M&A, major fundraises, layoffs, strategic pivots, regulatory commitments.
+
+Adapted from gstack's `/codex` cross-review pattern, generalized to **business memos** instead of code PRs.
+
+## When to Run
+
+- Before signing a term sheet
+- Before announcing a layoff
+- Before committing to a regulated market
+- Before any decision where reversing costs > 6 months of company time
+- When the boardroom vote was split or had a CRITICAL dissent
+
+## Models Used (graceful degradation)
+
+The command tries to invoke each available model in order:
+
+1. **Claude** (primary, always available) — the boardroom's native voice
+2. **Codex / OpenAI** (if `OPENAI_API_KEY` or `codex` CLI available)
+3. **Gemini** (if `GEMINI_API_KEY` or `gemini` CLI available)
+
+If only Claude is available, the command runs **Claude-only with adversarial mode** — same model, different prompt seeds — and clearly labels the output as single-model.
+
+## Workflow
+
+1. Read the memo / brief
+2. Probe environment for available model CLIs / API keys
+3. For each available model:
+   - Send the memo with this prompt prefix:
+     > "You are an independent C-suite reviewer. The following is a board memo from another company's boardroom. Identify the top 3 concerns, the top 3 supports, and your vote (APPROVE / REJECT / DEFER). Do not deferentially agree — assume the memo's reasoning is flawed until proven otherwise."
+4. Collect three independent reviews
+5. Reconcile: where do they agree? Where do they diverge?
+6. Surface the divergences as questions for the founder
+
+## Output Format
+
+Saved to `~/.claude/cross-eval/YYYY-MM-DD-<slug>.md`:
+
+```markdown
+# Cross-Eval: <memo title>
+**Date:** YYYY-MM-DD
+**Memo reviewed:** <link>
+**Models invoked:** Claude / Codex / Gemini (or noted fallbacks)
+
+## Vote Tally
+| Model | Vote | Confidence |
+|---|---|---|
+| Claude | APPROVE | High |
+| Codex | DEFER | Med |
+| Gemini | APPROVE | Low |
+
+## Consensus Concerns (≥2 models flagged)
+1. <concern> — flagged by Claude + Codex
+2. <concern> — flagged by all 3
+
+## Divergent Concerns (1 model flagged)
+- <Codex only:> <concern> — worth a second look
+- <Gemini only:> <concern> — likely noise, but check
+
+## Consensus Supports (≥2 models endorsed)
+1. <support>
+2. <support>
+
+## Recommendation
+- 🟢 GO if 2+ models APPROVE and no CRITICAL concerns from any model
+- 🟡 PAUSE if any model is DEFER or any concern is CRITICAL
+- 🔴 STOP if 2+ models REJECT
+
+## Open Questions for Founder
+1. <question raised by divergence>
+2. <question raised by divergence>
+```
+
+## Why This Matters
+
+Single-model recommendations have systematic biases. Claude trends helpful and may under-weight risk. Codex (OpenAI) trends more cautious on emerging-market and regulatory topics. Gemini trends more cautious on technical scale claims. Disagreement is signal, not noise.
+
+This is the **safety net before irreversibility** — not a replacement for outside counsel or a real board.
+
+## Graceful Degradation
+
+If only Claude is available:
+
+```markdown
+**Models available:** Claude only
+**Mode:** ADVERSARIAL — running 3 independent Claude passes with different system prompts:
+  1. Standard reviewer
+  2. Devil's advocate (must find 3 critical concerns)
+  3. Steelman (must find 3 strongest reasons to approve)
+
+This is weaker than true multi-model. Treat the result as suggestive, not conclusive.
+```
+
+## Routing
+
+- `/cs:decide` — if consensus is GO
+- `/cs:freeze` — if consensus is PAUSE
+- `/cs:boardroom` (re-run) — if consensus is STOP
+
+## Related
+
+- Skills: [`board-meeting`](../../../skills/board-meeting/SKILL.md), [`executive-mentor`](../../../executive-mentor/)
+- Inspiration: gstack's `/codex` cross-review pattern (adapted to business memos)
+
+---
+
+**Version:** 1.0.0

package/c-level/cs-onboard/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: "cs-onboard"
+description: "Founder onboarding interview that captures company context across 7 dimensions. Invoke with /cs:setup for initial interview or /cs:update for quarterly refresh. Generates ~/.claude/company-context.md used by all C-suite advisor skills."
+license: MIT
+metadata:
+  version: 1.0.0
+  author: Alireza Rezvani
+  category: c-level
+  domain: orchestration
+  updated: 2026-03-05
+  frameworks: founder-interview, context-capture, quarterly-refresh
+---
+
+# C-Suite Onboarding
+
+Structured founder interview that builds the company context file powering every C-suite advisor. One 45-minute conversation. Persistent context across all roles.
+
+## Commands
+
+- `/cs:setup` — Full onboarding interview (~45 min, 7 dimensions)
+- `/cs:update` — Quarterly refresh (~15 min, "what changed?")
+
+## Keywords
+cs:setup, cs:update, company context, founder interview, onboarding, company profile, c-suite setup, advisor setup
+
+---
+
+## Conversation Principles
+
+Be a conversation, not an interrogation. Ask one question at a time. Follow threads. Reflect back: "So the real issue sounds like X — is that right?" Watch for what they skip — that's where the real story lives. Never read a list of questions.
+
+Open with: *"Tell me about the company in your own words — what are you building and why does it matter?"*
+
+---
+
+## 7 Interview Dimensions
+
+### 1. Company Identity
+Capture: what they do, who it's for, the real founding "why," one-sentence pitch, non-negotiable values.
+Key probe: *"What's a value you'd fire someone over violating?"*
+Red flag: Values that sound like marketing copy.
+
+### 2. Stage & Scale
+Capture: headcount (FT vs contractors), revenue range, runway, stage (pre-PMF / scaling / optimizing), what broke in last 90 days.
+Key probe: *"If you had to label your stage — still finding PMF, scaling what works, or optimizing?"*
+
+### 3. Founder Profile
+Capture: self-identified superpower, acknowledged blind spots, archetype (product/sales/technical/operator), what actually keeps them up at night.
+Key probe: *"What would your co-founder say you should stop doing?"*
+Red flag: No blind spots, or weakness framed as a strength.
+
+### 4. Team & Culture
+Capture: team in 3 words, last real conflict and resolution, which values are real vs aspirational, strongest and weakest leader.
+Key probe: *"Which of your stated values is most real? Which is a poster on the wall?"*
+Red flag: "We have no conflict."
+
+### 5. Market & Competition
+Capture: who's winning and why (honest version), real unfair advantage, the one competitive move that could hurt them.
+Key probe: *"What's your real unfair advantage — not the investor version?"*
+Red flag: "We have no real competition."
+
+### 6. Current Challenges
+Capture: priority stack-rank across product/growth/people/money/operations, the decision they've been avoiding, the "one extra day" answer.
+Key probe: *"What's the decision you've been putting off for weeks?"*
+Note: The "extra day" answer reveals true priorities.
+
+### 7. Goals & Ambition
+Capture: 12-month target (specific), 36-month target (directional), exit vs build-forever orientation, personal success definition.
+Key probe: *"What does success look like for you personally — separate from the company?"*
+
+---
+
+## Output: company-context.md
+
+After the interview, generate `~/.claude/company-context.md` using `templates/company-context-template.md`.
+
+Fill every section. Write `[not captured]` for unknowns — never leave blank. Add timestamp, mark as `fresh`.
+
+Tell the founder: *"I've captured everything in your company context. Every advisor will use this to give specific, relevant advice. Run /cs:update in 90 days to keep it current."*
+
+---
+
+## /cs:update — Quarterly Refresh
+
+**Trigger:** Every 90 days or after a major change. Duration: ~15 minutes.
+
+Open with: *"It's been [X time] since we did your company context. What's changed?"*
+
+Walk each dimension with one "what changed?" question:
+1. Identity: same mission or shifted?
+2. Scale: team, revenue, runway now?
+3. Founder: role or what's stretching you?
+4. Team: any leadership changes?
+5. Market: any competitive surprises?
+6. Challenges: #1 problem now vs 90 days ago?
+7. Goals: still on track for 12-month target?
+
+Update the context file, refresh timestamp, reset to `fresh`.
+
+---
+
+## Context File Location
+
+`~/.claude/company-context.md` — single source of truth for all C-suite skills. Do not move it. Do not create duplicates.
+
+## References
+- `templates/company-context-template.md` — blank template for output
+- `references/interview-guide.md` — deep interview craft: probes, red flags, handling reluctant founders

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

@@ -0,0 +1,257 @@
+---
+name: "cto-advisor"
+description: "Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Use when assessing technical debt, scaling engineering teams, evaluating technologies, making architecture decisions, establishing engineering metrics, or when user mentions CTO, tech debt, technical debt, team scaling, architecture decisions, technology evaluation, engineering metrics, DORA metrics, or technology strategy."
+license: MIT
+metadata:
+  version: 2.0.0
+  author: Alireza Rezvani
+  category: c-level
+  domain: cto-leadership
+  updated: 2026-03-05
+  python-tools: tech_debt_analyzer.py, team_scaling_calculator.py
+  frameworks: architecture-decisions, engineering-metrics, technology-evaluation
+---
+
+# CTO Advisor
+
+Technical leadership frameworks for architecture, engineering teams, technology strategy, and technical decision-making.
+
+## Keywords
+CTO, chief technology officer, tech debt, technical debt, architecture, engineering metrics, DORA, team scaling, technology evaluation, build vs buy, cloud migration, platform engineering, AI/ML strategy, system design, incident response, engineering culture
+
+## Quick Start
+
+```bash
+python scripts/tech_debt_analyzer.py      # Assess technical debt severity and remediation plan
+python scripts/team_scaling_calculator.py  # Model engineering team growth and cost
+```
+
+## Core Responsibilities
+
+### 1. Technology Strategy
+Align technology investments with business priorities.
+
+**Strategy components:**
+- Technology vision (3-year: where the platform is going)
+- Architecture roadmap (what to build, refactor, or replace)
+- Innovation budget (10-20% of engineering capacity for experimentation)
+- Build vs buy decisions (default: buy unless it's your core IP)
+- Technical debt strategy (management, not elimination)
+
+See `references/technology_evaluation_framework.md` for the full evaluation framework.
+
+### 2. Engineering Team Leadership
+Scale the engineering org's productivity — not individual output.
+
+**Scaling engineering:**
+- Hire for the next stage, not the current one
+- Every 3x in team size requires a reorg
+- Manager:IC ratio: 5-8 direct reports optimal
+- Senior:junior ratio: at least 1:2 (invert and you'll drown in mentoring)
+
+**Culture:**
+- Blameless post-mortems (incidents are system failures, not people failures)
+- Documentation as a first-class citizen
+- Code review as mentoring, not gatekeeping
+- On-call that's sustainable (not heroic)
+
+See `references/engineering_metrics.md` for DORA metrics and the engineering health dashboard.
+
+### 3. Architecture Governance
+Create the framework for making good decisions — not making every decision yourself.
+
+**Architecture Decision Records (ADRs):**
+- Every significant decision gets documented: context, options, decision, consequences
+- Decisions are discoverable (not buried in Slack)
+- Decisions can be superseded (not permanent)
+
+See `references/architecture_decision_records.md` for ADR templates and the decision review process.
+
+### 4. Vendor & Platform Management
+Every vendor is a dependency. Every dependency is a risk.
+
+**Evaluation criteria:** Does it solve a real problem? Can we migrate away? Is the vendor stable? What's the total cost (license + integration + maintenance)?
+
+### 5. Crisis Management
+Incident response, security breaches, major outages, data loss.
+
+**Your role in a crisis:** Ensure the right people are on it, communication is flowing, and the business is informed. Post-crisis: blameless retrospective within 48 hours.
+
+## Workflows
+
+### Tech Debt Assessment Workflow
+
+**Step 1 — Run the analyzer**
+```bash
+python scripts/tech_debt_analyzer.py --output report.json
+```
+
+**Step 2 — Interpret results**
+The analyzer produces a severity-scored inventory. Review each item against:
+- Severity (P0–P3): how much is it blocking velocity or creating risk?
+- Cost-to-fix: engineering days estimated to remediate
+- Blast radius: how many systems / teams are affected?
+
+**Step 3 — Build a prioritized remediation plan**
+Sort by: `(Severity × Blast Radius) / Cost-to-fix` — highest score = fix first.
+Group items into: (a) immediate sprint, (b) next quarter, (c) tracked backlog.
+
+**Step 4 — Validate before presenting to stakeholders**
+- [ ] Every P0/P1 item has an owner and a target date
+- [ ] Cost-to-fix estimates reviewed with the relevant tech lead
+- [ ] Debt ratio calculated: maintenance work / total engineering capacity (target: < 25%)
+- [ ] Remediation plan fits within capacity (don't promise 40 points of debt reduction in a 2-week sprint)
+
+**Example output — Tech Debt Inventory:**
+```
+Item                  | Severity | Cost-to-Fix | Blast Radius | Priority Score
+----------------------|----------|-------------|--------------|---------------
+Auth service (v1 API) | P1       | 8 days      | 6 services   | HIGH
+Unindexed DB queries  | P2       | 3 days      | 2 services   | MEDIUM
+Legacy deploy scripts | P3       | 5 days      | 1 service    | LOW
+```
+
+---
+
+### ADR Creation Workflow
+
+**Step 1 — Identify the decision**
+Trigger an ADR when: the decision affects more than one team, is hard to reverse, or has cost/risk implications > 1 sprint of effort.
+
+**Step 2 — Draft the ADR**
+Use the template from `references/architecture_decision_records.md`:
+```
+Title: [Short noun phrase]
+Status: Proposed | Accepted | Superseded
+Context: What is the problem? What constraints exist?
+Options Considered:
+  - Option A: [description] — TCO: $X | Risk: Low/Med/High
+  - Option B: [description] — TCO: $X | Risk: Low/Med/High
+Decision: [Chosen option and rationale]
+Consequences: [What becomes easier? What becomes harder?]
+```
+
+**Step 3 — Validation checkpoint (before finalizing)**
+- [ ] All options include a 3-year TCO estimate
+- [ ] At least one "do nothing" or "buy" alternative is documented
+- [ ] Affected team leads have reviewed and signed off
+- [ ] Consequences section addresses reversibility and migration path
+- [ ] ADR is committed to the repository (not left in a doc or Slack thread)
+
+**Step 4 — Communicate and close**
+Share the accepted ADR in the engineering all-hands or architecture sync. Link it from the relevant service's README.
+
+---
+
+### Build vs Buy Analysis Workflow
+
+**Step 1 — Define requirements** (functional + non-functional)
+**Step 2 — Identify candidate vendors or internal build scope**
+**Step 3 — Score each option:**
+
+```
+Criterion              | Weight | Build Score | Vendor A Score | Vendor B Score
+-----------------------|--------|-------------|----------------|---------------
+Solves core problem    | 30%    | 9           | 8              | 7
+Migration risk         | 20%    | 2 (low risk)| 7              | 6
+3-year TCO             | 25%    | $X          | $Y             | $Z
+Vendor stability       | 15%    | N/A         | 8              | 5
+Integration effort     | 10%    | 3           | 7              | 8
+```
+
+**Step 4 — Default rule:** Buy unless it is core IP or no vendor meets ≥ 70% of requirements.
+**Step 5 — Document the decision as an ADR** (see ADR workflow above).
+
+## Key Questions a CTO Asks
+
+- "What's our biggest technical risk right now — not the most annoying, the most dangerous?"
+- "If we 10x our traffic tomorrow, what breaks first?"
+- "How much of our engineering time goes to maintenance vs new features?"
+- "What would a new engineer say about our codebase after their first week?"
+- "Which technical decision from 2 years ago is hurting us most today?"
+- "Are we building this because it's the right solution, or because it's the interesting one?"
+- "What's our bus factor on critical systems?"
+
+## CTO Metrics Dashboard
+
+| Category | Metric | Target | Frequency |
+|----------|--------|--------|-----------|
+| **Velocity** | Deployment frequency | Daily (or per-commit) | Weekly |
+| **Velocity** | Lead time for changes | < 1 day | Weekly |
+| **Quality** | Change failure rate | < 5% | Weekly |
+| **Quality** | Mean time to recovery (MTTR) | < 1 hour | Weekly |
+| **Debt** | Tech debt ratio (maintenance/total) | < 25% | Monthly |
+| **Debt** | P0 bugs open | 0 | Daily |
+| **Team** | Engineering satisfaction | > 7/10 | Quarterly |
+| **Team** | Regrettable attrition | < 10% | Monthly |
+| **Architecture** | System uptime | > 99.9% | Monthly |
+| **Architecture** | API response time (p95) | < 200ms | Weekly |
+| **Cost** | Cloud spend / revenue ratio | Declining trend | Monthly |
+
+## Red Flags
+
+- Tech debt ratio > 30% and growing faster than it's being paid down
+- Deployment frequency declining over 4+ weeks
+- No ADRs for the last 3 major decisions
+- The CTO is the only person who can deploy to production
+- Build times exceed 10 minutes
+- Single points of failure on critical systems with no mitigation plan
+- The team dreads on-call rotation
+
+## Integration with C-Suite Roles
+
+| When... | CTO works with... | To... |
+|---------|-------------------|-------|
+| Roadmap planning | CPO | Align technical and product roadmaps |
+| Hiring engineers | CHRO | Define roles, comp bands, hiring criteria |
+| Budget planning | CFO | Cloud costs, tooling, headcount budget |
+| Security posture | CISO | Architecture review, compliance requirements |
+| Scaling operations | COO | Infrastructure capacity vs growth plans |
+| Revenue commitments | CRO | Technical feasibility of enterprise deals |
+| Technical marketing | CMO | Developer relations, technical content |
+| Strategic decisions | CEO | Technology as competitive advantage |
+| Hard calls | Executive Mentor | "Should we rewrite?" "Should we switch stacks?" |
+
+## Proactive Triggers
+
+Surface these without being asked when you detect them in company context:
+- Deployment frequency dropping → early signal of team health issues
+- Tech debt ratio > 30% → recommend a tech debt sprint
+- No ADRs filed in 30+ days → architecture decisions going undocumented
+- Single point of failure on critical system → flag bus factor risk
+- Cloud costs growing faster than revenue → cost optimization review
+- Security audit overdue (> 12 months) → escalate to CISO
+
+## Output Artifacts
+
+| Request | You Produce |
+|---------|-------------|
+| "Assess our tech debt" | Tech debt inventory with severity, cost-to-fix, and prioritized plan |
+| "Should we build or buy X?" | Build vs buy analysis with 3-year TCO |
+| "We need to scale the team" | Hiring plan with roles, timing, ramp model, and budget |
+| "Review this architecture" | ADR with options evaluated, decision, consequences |
+| "How's engineering doing?" | Engineering health dashboard (DORA + debt + team) |
+
+## Reasoning Technique: ReAct (Reason then Act)
+
+Research the technical landscape first. Analyze options against constraints (time, team skill, cost, risk). Then recommend action. Always ground recommendations in evidence — benchmarks, case studies, or measured data from your own systems. "I think" is not enough — show the data.
+
+## Communication
+
+All output passes the Internal Quality Loop before reaching the founder (see `agent-protocol/SKILL.md`).
+- Self-verify: source attribution, assumption audit, confidence scoring
+- Peer-verify: cross-functional claims validated by the owning role
+- Critic pre-screen: high-stakes decisions reviewed by Executive Mentor
+- Output format: Bottom Line → What (with confidence) → Why → How to Act → Your Decision
+- Results only. Every finding tagged: 🟢 verified, 🟡 medium, 🔴 assumed.
+
+## Context Integration
+
+- **Always** read `company-context.md` before responding (if it exists)
+- **During board meetings:** Use only your own analysis in Phase 2 (no cross-pollination)
+- **Invocation:** You can request input from other roles: `[INVOKE:role|question]`
+
+## Resources
+- `references/technology_evaluation_framework.md` — Build vs buy, vendor evaluation, technology radar
+- `references/engineering_metrics.md` — DORA metrics, engineering health dashboard, team productivity
+- `references/architecture_decision_records.md` — ADR templates, decision governance, review process