naive-framework 0.0.0-stage → 0.2.0

package/governance/skills/business-pillar/SKILL.md

@@ -0,0 +1,96 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, business-pillar]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: business-pillar
+description: >
+  Provide Business pillar context — teams, roles, Tier 1 deliverables (business
+  model, pricing, ops runbooks, metrics framework, sales collateral, contracts,
+  legal posture), per-stage and per-business-model Tier 2 splits, and cross-
+  pillar overlap zones. Auto-loads when working on commercial / operational /
+  legal / financial / sales / partnership / customer success / trust & safety
+  concerns. References venture-template/pillars/business.md as the canonical
+  reference. Per SAD v3.3+ amendment §33.
+  MANDATORY TRIGGERS: business pillar, business work, business model, pricing,
+  sales, COO, CFO, GC, legal, contracts, ops, operations, runbooks, metrics,
+  partnership, customer success, trust & safety, anti-scraping, ToS, privacy
+  policy, app store listing, pitch deck, investor, board, fundraising, finance,
+  hiring, people, procurement, vendor.
+---
+
+# Business Pillar Skill
+
+The context-providing skill for Business-pillar work. Auto-loads when business-pillar concerns surface in conversation.
+
+## What this skill provides
+
+- **Business pillar reference** — [[../../venture-template/pillars/business|venture-template/pillars/business.md]] for the canonical Business pillar description
+- **COO role context** — [[../../venture-template/roles/coo|venture-template/roles/coo.md]]
+- **Per-stage Tier 2 awareness** — pre-revenue / early / growth / mature companies have different Business-pillar deliverable sets
+- **Per-business-model Tier 2 awareness** — subscription / transactional / advertising / OSS+commercial / free models have different deliverable sets
+- **Optional Business-pillar products** — when present (partnership programs, training certifications, sales kits, services tiers, etc.)
+
+## When to invoke
+
+Auto-loads when:
+
+- Business model / pricing work is happening
+- Commercial decisions are being made (sales motion, partnerships, BD)
+- Operational runbooks are being authored (deploy, incident, on-call, vendor management)
+- Legal posture work surfaces (ToS, privacy policy, contracts, IP, regulatory)
+- Financial / fundraising work surfaces (financial model, board deck, investor update)
+- Metrics framework / analytics work surfaces (overlap with Product)
+- Customer success / trust & safety work surfaces
+- Anti-scraping / IP protection work surfaces
+- App store listings, partnership materials, or PR strategy work surfaces
+
+## What this skill emphasizes
+
+When loaded, the AI should keep in mind:
+
+1. **Business is the widest pillar in scope.** It covers commercial, operational, financial, legal, people, customer success, T&S, partnerships, and more. The scope varies dramatically by company stage.
+
+2. **COO is the pillar lead** in most companies, but Business has more specialized C-level roles than the other pillars. CFO owns Finance; CRO owns Sales; CPO owns People; GC owns Legal. COO scope is "whatever's left" — which is still substantial.
+
+3. **Stage matters more than for other pillars.** A pre-revenue Business pillar looks nothing like a growth-stage one. Don't apply mature-stage Tier 2 deliverables to an early-stage project.
+
+4. **Business model matters too.** Subscription / transactional / advertising / OSS+commercial / free models have different operational shapes. Pricing strategy, metric definitions, sales motion all vary.
+
+5. **Brand assets are imported, not duplicated.** When business work uses identity (sales decks, app store listings, partnership materials), wikilink to Brand. Don't redefine brand locally.
+
+6. **Business-pillar products are optional** but common as companies scale. Partnership programs, training certifications, professional services — these are products in their own right, distinct from supporting the canonical Product-pillar product.
+
+## Business authoring posture
+
+Business work tends to land in office-hours mode by default:
+
+- **Pricing decisions** — office-hours; ruthless about what the market will pay
+- **Sales motion design** — office-hours; press on conversion + economics
+- **Legal posture** — office-hours; specificity required
+- **Investor materials** — office-hours initially; friend mode for narrative shape, office-hours for numbers
+- **Ops runbook authoring** — typically friend mode (building the runbook is generative); office-hours when reviewing it
+
+## Cross-pillar overlap behavior
+
+When work crosses pillars:
+
+- **Analytics + instrumentation** (Business × Product) — Business owns metric definitions + dashboards; Product owns instrumentation
+- **Customer success** (Business × Product) — Business owns CS ops; Product owns in-product onboarding
+- **Pricing-as-product** (Business × Product) — Business owns pricing strategy; Product owns paywall UX
+- **Sales collateral** (Business × Brand) — Business owns commercial framing; Brand owns voice + identity
+- **Partnership materials** (Business × Brand) — Business owns terms; Brand owns assets + voice
+- **PR strategy** (Business × Brand) — Business owns analyst / investor relations; Brand owns narrative
+- **Trust & safety** (Business × Product × Brand) — Business owns legal posture; Product owns tooling; Brand owns community standards
+
+## Related skills
+
+- [[../articulation-closure/SKILL|articulation-closure]] — Business-pillar deliverables in the closure inventory
+- [[../friend-mode/SKILL|friend-mode]] / [[../office-hours-mode/SKILL|office-hours-mode]] — posture skills for Business work
+- [[../product-pillar/SKILL|product-pillar]] — companion pillar; analytics + CS + pricing overlap zones
+- [[../brand-pillar/SKILL|brand-pillar]] — companion pillar; sales collateral + PR overlap zones
+
+## Status
+
+- **2026-05-14:** Initial authoring. References venture-template/pillars/business.md as the canonical Business pillar reference.

package/governance/skills/chief-of-staff/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: chief-of-staff
+type: reference
+source: hybrid
+created: 2026-10-14T05:00:00Z
+ai-model: claude-opus-5.5
+description: "Run the founder's single session as Chief of Staff. Every idea: restate in first principles, rediscover, ask only founder decisions, record them, write role-assigned handoffs (v2), defer the rest. One active idea at a time. Use at the start of every founder session and whenever the owner brings a new idea, says 'chief of staff', 'one session', 'handoff', 'who should do this', or switches topics."
+tags: [skill, chief-of-staff, operating-model, founder-session, handoffs, decision-rights]
+---
+
+# Chief of Staff
+
+Decided in the ratified operating-model decisions. Design: [[FOUNDER_OPERATING_MODEL_CAMPAIGN_2026-10-14]]. Roles and decision rights: `governance/venture-template/AGENT_ROLES_AND_DECISION_RIGHTS.md`.
+
+## Which position you hold
+
+- **Umbrella** (default for the owner's session): across every venture, the methodology, and the owner's own goals and obligations. Ledger: global (G-NNN).
+- **Ecosystem** (one venture or product): when the session is scoped to one. Ledger: the entity's (D-NNN).
+
+Decide at the lowest level that holds the decision; anything touching two entities goes up (the decision-level rule).
+
+## Session start
+
+1. Ground time (time-awareness). Read the global ledger and, if scoped, the entity ledger.
+2. Read the work queue (`<vault>/_meta/registers/work-queue.json`) and open questions (entity registers). Name the **one active idea** and what is waiting.
+3. Run the SAD session opening for the entity in scope (design coverage, methodology assignments, rediscovery step 4d).
+
+## For every idea
+
+1. **Intake.** Restate the idea in first principles: what must be true, what problem it solves, what it is not. Confirm with the owner before going further.
+2. **Rediscover.** Search ledgers, ADR registers and registers, including the source register before researching. Cite what already exists; build on it instead of restating it.
+3. **Derive, then test.** Work from the idea's functions, then check against established practice (the first-principles rule).
+4. **Founder decisions only.** List the decisions in the founder's classes (decision-rights.json: escalate, or founder approves). Recommend an answer for each. Ask. Record each answer in the right ledger the same turn.
+5. **Handoffs.** One per role with work (`execution/handoff-v2.md`), each carrying its decision rights, verifiable done-criteria, and report-to-PR-and-registers. Do not ask for reports back. Fill `session-id` (yours) and `parent-session-id` (the session that assigned the idea, if any). Put the stable parts of a role's context (role skill, decision rights) first and the changing parts after, so hosted prompt caching applies (source S-001).
+6. **Defer.** Anything unfinished becomes an open question or queue entry with an owner role. Nothing is dropped.
+
+## Switching ideas
+
+One active idea. If the owner raises a new one: log it (idea note or queue entry), say where the current idea stands, and ask whether to switch. Switching defers the current idea with its next step written down.
+
+## Don't
+
+- Bring the owner decisions that belong to a role (decision-rights.json).
+- Review work a conformance check can accept (the conformance rule).
+- Start a new session's worth of context for a new idea; the registers hold state.

package/governance/skills/cofounder-structure/SKILL.md

@@ -0,0 +1,64 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, governance, ownership, cofounders]
+ai-model: claude-opus-5.5
+created: 2026-10-27T15:49:30Z
+source: hybrid
+name: cofounder-structure
+description: >
+  Help a founder decide whether to have cofounders, who, in what roles, how to
+  split founder equity, how it vests, and what happens if someone leaves; then
+  record it as holders and grants in governance/ownership.json and a founder
+  agreement (founder-agreement.json plus prose). Reads the venture's phase,
+  ambition, legal form and members. Founder decision with counsel (EE-022).
+  MANDATORY TRIGGERS: cofounder, co-founder, founding team, equity split, founder
+  equity, vesting, cliff, founder agreement, founder leaves, 83(b), solo founder.
+---
+
+# Cofounder structure
+
+Governance layer, ownership-and-control kit (EE-022). Writes `ownership.json` (founder holders and grants) and `founder-agreement.json` with its prose beside it. `node schema/check-governance.mjs` then requires an agreement once two or more founders share ownership.
+
+## 1. Read the venture first
+
+From `venture.json`: `phase`, `ambition`, `form` and `members`.
+
+| State | What it usually needs |
+| --- | --- |
+| Hobby or lifestyle, sole owner | Nothing here. Record the owner as the only holder if the venture is formalized |
+| Managed growth, one founder plus agents | A cap table with one founder and, later, an option pool; no founder agreement |
+| Two or more people building it together | A founder agreement, vesting for every founder, IP assigned to the venture |
+| Aggressive growth, raising venture capital | All of the above, in a form investors expect (in the US usually a Delaware C corporation, shares with vesting, an 83(b) election filed by each founder) |
+
+## 2. The questions, in order
+
+1. **Solo or team?** The trade-off is control against capacity: every cofounder dilutes control and adds skills, time and resilience (Wasserman's "rich versus king": founders who keep control tend to give up some value, and the reverse). Agents now cover much of the work a second founder once did; ask what only a person can bring (selling, a network, a skill, accountability).
+2. **Who, and in what role?** Name each founder's role and time commitment (full-time or part-time). A part-time founder is a common source of later conflict; say so.
+3. **How to split?**
+   - Fixed split at the start, equal or weighted. Many investors and Y Combinator's partners favour near-equal splits among founders who start together, because unequal splits signal unequal commitment.
+   - Dynamic split (Moyer's *Slicing Pie*), where each founder earns equity in proportion to what they put in until the venture is funded or profitable. Fits bootstrapped teams whose contributions are uneven or uncertain.
+   Write the reasoning down; the number matters less than everyone agreeing why.
+4. **Vesting.** The common default is four years with a one-year cliff, monthly after. Vesting protects the founders who stay from one who leaves early. In the US, founders who receive shares subject to vesting usually file an 83(b) election within 30 days of the grant; flag it to counsel.
+5. **Acceleration.** Double-trigger (vesting speeds up only if the company is sold and the founder is let go) is the common default; single-trigger (on sale alone) is rarer and investors resist it.
+6. **Departure.** Good leaver and bad leaver terms, and the buyback of unvested shares (commonly at cost).
+7. **IP.** Every founder assigns to the venture what they have built for it and will build. A missing assignment is a common reason a financing stalls.
+8. **Deadlock.** How two founders who disagree reach a decision (a named tie-breaker by domain, an independent director, or mediation).
+
+## 3. Record it
+
+- `ownership.json`: one holder per founder (`kind: founder`), one grant each with `vesting`.
+- `founder-agreement.json`: the founders, their roles, commitment, `ip_assigned`, departure and deadlock terms, `signed` (null until signed) and `document`.
+- `founder-agreement.md` beside it: the agreement in plain words, or where the signed copy is.
+
+## Guardrails (all five ownership-and-control skills)
+
+- These are **founder decisions made with counsel** (decision class `ownership-or-control`, level escalate). An agent lays out the options, the trade-offs and the sources, drafts the records and documents, and stops. It never signs, files or agrees to anything.
+- Rules differ by country, state and legal form. Everything here is the common US startup default unless it says otherwise; name the jurisdiction before relying on it.
+- The signed documents are the truth. The records in `governance/` summarise them so agents and checks can read them; when the two disagree, fix the record.
+- Sources below are named from the method author's knowledge and still need recording with `find-reference` (URL and checked date) before a default is treated as settled.
+
+## Sources
+
+- Noam Wasserman, *The Founder's Dilemmas* (Princeton University Press, 2012).
+- Mike Moyer, *Slicing Pie* (dynamic equity).
+- Y Combinator guidance on cofounder equity splits.

package/governance/skills/cross-pillar-tradeoff/SKILL.md

@@ -0,0 +1,168 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, cross-pillar-tradeoff]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: cross-pillar-tradeoff
+description: >
+  Surface and frame a cross-pillar tradeoff as a CEO-level (or Chief-of-Staff-
+  surfaced) decision. When work in one pillar creates pressure on another
+  pillar's priorities (e.g., shipping a Product feature requires Brand
+  reconciliation; commercial pricing changes require Product paywall work;
+  legal posture changes affect both Product implementation and Brand voice),
+  the tradeoff needs explicit framing rather than per-pillar resolution.
+  Per CEO + Chief of Staff role responsibilities.
+  MANDATORY TRIGGERS: cross-pillar tradeoff, executive decision, CEO decision,
+  pillar conflict, prioritization across pillars, what should we cut, where
+  should resources go, pillar lead disagreement, strategic call, /tradeoff.
+---
+
+# Cross-Pillar Tradeoff Skill
+
+The CEO-level decision framing skill for tradeoffs that span pillars. Surfaces what's at stake; frames the decision; documents the call.
+
+## Why cross-pillar-tradeoff exists
+
+Per [[../../venture-template/roles/ceo|CEO role]] + [[../../venture-template/roles/chief-of-staff|Chief of Staff role]], the CEO owns cross-pillar tradeoffs and the Chief of Staff often surfaces them. Without an explicit skill for this, tradeoffs get resolved inside individual pillars based on the pillar lead's view — which often produces local optimums but cross-pillar suboptimality.
+
+The discipline: when a decision affects multiple pillars, it gets escalated and framed as a cross-pillar tradeoff explicitly, not resolved silently within one pillar's scope.
+
+## When to invoke
+
+- A Product-pillar decision requires Brand reconciliation (e.g., a new feature needs new visual identity)
+- A Business-pillar decision requires Product implementation (e.g., a pricing change needs paywall UX work)
+- A Brand-pillar decision affects commercial positioning (e.g., a brand evolution shifts target audience)
+- Two pillar leads disagree on prioritization
+- Resource allocation is being decided across pillars
+- A version-spec scope decision requires cross-pillar buy-in
+- The user explicitly asks "what should we prioritize?" or "this affects multiple pillars"
+
+## What cross-pillar-tradeoff produces
+
+A tradeoff framing produces a decision memo with these elements:
+
+### 1. The decision being made
+
+One sentence stating the call:
+
+> "Should we ship V[N] with the current Product scope (accepting Brand reconciliation in V[N].x) or delay V[N] by 4 weeks to complete Brand reconciliation first?"
+
+### 2. The pillar impacts
+
+For each pillar, what's at stake:
+
+```
+| Pillar | Impact under Option A | Impact under Option B |
+|---|---|---|
+| Product | Ships on time; some friction with brand inconsistency in V[N] | Delays 4 weeks; ships brand-consistent |
+| Brand | Identity drift in V[N]; V[N].x patch required | Identity intact; foreshadowing audit clean |
+| Business | Earlier revenue; some marketing-effectiveness loss | Delayed revenue; cleaner narrative arc |
+```
+
+### 3. The principle in play
+
+What does this decision express about how the company prioritizes? Examples:
+
+- "Speed beats polish, because we're pre-PMF and need user signal"
+- "Brand integrity beats time-to-market, because trust is the moat"
+- "Commercial trajectory beats both, because runway is the binding constraint"
+
+The principle informs future decisions of similar shape. Document it.
+
+### 4. The decision + rationale
+
+The CEO's (or CEO-by-extension's) call, with the rationale:
+
+> "We're shipping on time. Rationale: at pre-PMF stage, user signal is the binding constraint. V[N].x brand reconciliation is acceptable cost. The principle: speed beats polish until we have PMF."
+
+### 5. The follow-ups
+
+What does the chosen option require?
+
+- Per-pillar follow-ups (e.g., "Brand pillar: author V[N].x reconciliation plan within 2 weeks")
+- Foreshadowing implications (e.g., "Update V[N] roadmap to mention the upcoming reconciliation so the audience isn't surprised")
+- Decision review date (e.g., "Revisit this principle at V[N+1] articulation")
+
+## How to run a tradeoff framing
+
+When this skill is loaded, the AI should:
+
+### Step 1 — Confirm the tradeoff is genuinely cross-pillar
+
+Probe: "Is this actually cross-pillar, or is it a within-pillar decision that just feels big? If only one pillar's deliverables change, it's not cross-pillar."
+
+If within-pillar, route to the appropriate pillar skill instead.
+
+### Step 2 — Identify the pillars in play
+
+For each affected pillar:
+- What changes under each option?
+- Who's the pillar lead's perspective?
+- What's the cost of each option from this pillar's view?
+
+### Step 3 — Identify the principle
+
+Step back: what does this tradeoff teach us about how the company prioritizes? If there's no principle (it's just an arbitrary call), surface that — arbitrary calls are fine but should be marked as such for future reference.
+
+### Step 4 — Frame the decision
+
+Author the decision memo using the structure above. Surface it to the operator (CEO or Chief of Staff role).
+
+### Step 5 — Record the call
+
+Once the decision is made, document it. Save to:
+
+```
+projects/<entity>/decisions/<date>-<short-name>.md
+```
+
+Or append to the entity's decision log (some projects use a single decisions file rather than per-decision files).
+
+Frontmatter:
+
+```yaml
+---
+type: decision
+decision-type: cross-pillar-tradeoff
+phase: <current-phase>
+pillars-affected: [product, brand, business]
+decision-maker: CEO   # or whichever role owned the call
+recorded-by: chief-of-staff   # or operator
+date: <date>
+tags: [decision, cross-pillar, <entity>]
+---
+```
+
+### Step 6 — Surface to the orchestration HTML
+
+Per [[../../_ideas/build-roadmap-and-html-orchestration-2026-05-12|§32]], the per-project orchestration HTML lists cross-pillar decisions visibly. Update with the new decision + principle.
+
+### Step 7 — Schedule the follow-ups
+
+Each follow-up action gets:
+- An owner (typically the affected pillar lead)
+- A due date
+- A status tracking (per [[../triage/SKILL|triage]] status semantics — OPEN until the follow-up is complete)
+
+## Posture
+
+Cross-pillar-tradeoff runs in **office-hours mode**. Sharp framing on what's at stake. The decision-maker (CEO) needs the most rigorous version of each option's case.
+
+Exception: if the tradeoff has emotional valence for the operator (e.g., killing a beloved feature), briefly shift to friend mode for the surfacing, then return to office-hours for the decision itself.
+
+## What cross-pillar-tradeoff is NOT
+
+- **Not consensus-building.** The skill frames + documents the tradeoff. The decision is one person's call (typically the CEO). Pillar leads provide input; one person decides.
+- **Not a substitute for pillar-lead delegation.** Most decisions stay within pillars. Cross-pillar is reserved for actual cross-pillar tradeoffs.
+- **Not a one-shot.** Decisions get revisited. The principle informs future calls; revisit the principle when context shifts.
+
+## Relationship to other skills
+
+- [[../office-hours-mode/SKILL|office-hours-mode]] — the right posture
+- [[../canonicalize/SKILL|canonicalize]] — decision memos for major calls often become canonical for their concern
+- [[../idea-archive/SKILL|idea-archive]] — when a tradeoff results in killing an idea, that idea moves to the archive
+
+## Status
+
+- **2026-05-14:** Initial authoring.

package/governance/skills/equity-and-share-classes/SKILL.md

@@ -0,0 +1,68 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, governance, equity, share-classes, cap-table]
+ai-model: claude-opus-5.5
+created: 2026-10-27T15:49:30Z
+source: hybrid
+name: equity-and-share-classes
+description: >
+  Help a founder decide how ownership is counted and which share types to
+  have, and when: common, preferred, super-voting (dual-class), non-voting, LLC
+  units, the employee option pool, and what each does to control and payouts.
+  Keeps governance/ownership.json, the cap table, in step. Founder decision
+  with counsel (EE-022).
+  MANDATORY TRIGGERS: cap table, shares, stock, share class, common stock,
+  preferred stock, dual-class, super-voting, option pool, ESOP, stock options,
+  units, LLC membership interest, dilution, fully diluted, S corporation stock.
+---
+
+# Equity and share classes
+
+Governance layer, ownership-and-control kit (EE-022). Keeps `ownership.json`. `check-governance.mjs` checks it; `node schema/payouts.mjs <venture>` shows what each class would get in a sale.
+
+## 1. The unit follows the legal form
+
+| Legal form (`venture.json` form.legal_form) | Unit in `ownership.json` | Notes |
+| --- | --- | --- |
+| none, sole proprietorship | none needed | One owner; no cap table |
+| partnership | percent | The partnership agreement sets the split |
+| LLC | units | Classes of units are possible; profits interests replace options |
+| S corporation | shares | **One class of stock only** (US tax rule; classes may differ in votes alone), at most 100 shareholders, no corporate or foreign shareholders. `check-governance.mjs` refuses a second class. Usually rules out venture capital |
+| C corporation | shares | Any number of classes; the usual form for venture capital in the US |
+
+If the ambition is aggressive growth with outside investors, a C corporation is the common choice. Converting later is possible but costs money and can have tax effects; raise it early with counsel.
+
+## 2. Share types, and when each appears
+
+| Type | When | What it does |
+| --- | --- | --- |
+| Common | From day one | Founders, employees and advisors hold it; paid last in a sale |
+| Option pool (reserved common) | Before hiring, or as a condition of a priced round | Reserved for employee options; unissued options are paid nothing. Commonly 10 to 20 percent at seed or Series A, and investors usually ask for it to come out of the founders' share (the "option pool shuffle") |
+| Preferred | At a priced round | Investors' class: liquidation preference, protective provisions and other rights (see `financing-and-investor-rights`) |
+| Super-voting common (dual-class) | When founders must keep control through later rounds or a public listing | Founders' shares carry more than one vote each. Investors and some stock indexes resist it; it is easier to set up early than late |
+| Non-voting | For holders who should share value but not control | Votes per share 0 |
+
+Record each class with `kind`, `votes_per_share`, and for preferred `price_per_share` and `liquidation`.
+
+## 3. Control and dilution
+
+- Control is votes, not value: add up `votes_per_share` times shares by holder, and compare with the board seats each group appoints.
+- Every new grant or round dilutes everyone else's share. Model a round before agreeing to it: the fully diluted cap table after the pool top-up and after any SAFEs convert.
+- Employee equity beyond the pool (profits interests in an LLC, restricted stock, phantom equity) is a further choice; record it as grants of the relevant class.
+
+## 4. Record it
+
+`ownership.json`: `unit`, `classes`, `holders` (including the pool as `kind: pool`), `grants` with vesting. Every change is an `ownership-or-control` decision.
+
+## Guardrails (all five ownership-and-control skills)
+
+- These are **founder decisions made with counsel** (decision class `ownership-or-control`, level escalate). An agent lays out the options, the trade-offs and the sources, drafts the records and documents, and stops. It never signs, files or agrees to anything.
+- Rules differ by country, state and legal form. Everything here is the common US startup default unless it says otherwise; name the jurisdiction before relying on it.
+- The signed documents are the truth. The records in `governance/` summarise them so agents and checks can read them; when the two disagree, fix the record.
+- Sources below are named from the method author's knowledge and still need recording with `find-reference` (URL and checked date) before a default is treated as settled.
+
+## Sources
+
+- Brad Feld and Jason Mendelson, *Venture Deals* (Wiley).
+- NVCA model legal documents: Certificate of Incorporation.
+- US Internal Revenue Code section 1361 (S corporation eligibility).

package/governance/skills/executive-roles/SKILL.md

@@ -0,0 +1,95 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, executive-roles]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: executive-roles
+description: >
+  Provide context for executive-level work — CEO, Founder, Chief of Staff,
+  and pillar leads (CTO, CMO, COO). Auto-loads when conversation surfaces
+  executive-level concerns: strategic decisions, cross-pillar tradeoffs,
+  board materials, exec hiring, fundraising, organizational design. References
+  the per-role files at venture-template/roles/. Companion to the per-pillar
+  skills (which cover pillar leads specifically when pillar work is happening).
+  Per SAD v3.3+ amendment §33.
+  MANDATORY TRIGGERS: CEO, founder, chief of staff, executive team, exec team,
+  strategic decision, board, fundraising, exec hiring, organizational design,
+  C-level, leadership, CTO, CMO, COO, CFO, CRO, CPO, GC, pillar lead.
+---
+
+# Executive Roles Skill
+
+The context-providing skill for executive-level work. Auto-loads when conversation surfaces executive concerns.
+
+## What this skill provides
+
+References to all per-role files in the company template:
+
+- [[../../venture-template/roles/ceo|CEO]] — cross-pillar lead; sets direction
+- [[../../venture-template/roles/founder|Founder]] — pre-CEO state; multi-role
+- [[../../venture-template/roles/chief-of-staff|Chief of Staff]] — CEO force multiplier
+- [[../../venture-template/roles/cto|CTO]] — Product pillar lead
+- [[../../venture-template/roles/cmo|CMO]] — Brand pillar lead
+- [[../../venture-template/roles/coo|COO]] — Business pillar lead
+
+When loaded, the AI can speak to executive-level concerns with reference to specific role contexts.
+
+## When to invoke
+
+Auto-loads when:
+
+- Strategic decisions are being made or framed
+- Cross-pillar tradeoffs surface (invokes [[../cross-pillar-tradeoff/SKILL|cross-pillar-tradeoff]] too)
+- Board materials, all-hands, or investor materials are being authored
+- Executive hiring is being discussed
+- Fundraising work is happening
+- Organizational design questions surface (reporting lines, role splits)
+- The user references C-level roles or executive team work
+
+## What this skill emphasizes
+
+When loaded, the AI should keep in mind:
+
+1. **Roles have responsibilities + non-responsibilities.** Each per-role file has a "What this role is NOT" section. The non-responsibilities matter as much as the responsibilities — they're how the role stays focused.
+
+2. **Role transitions are methodology-relevant.** Founder → CEO is the most common; founder may also evolve into CTO / CPO / CMO. The methodology should support these transitions explicitly. See [[../../venture-template/roles/founder|founder.md]] §"Founder transitions."
+
+3. **Pillar leads sit *under* their pillar; cross-pillar roles sit *above*.** CEO + Founder + Chief of Staff are cross-pillar. CTO + CMO + COO are pillar leads. Don't conflate.
+
+4. **Specialized C-level roles emerge from COO's scope.** CFO emerges from COO's Finance scope; GC emerges from Legal; CRO emerges from Sales; CPO emerges from People. Stage-dependent emergence; the methodology accommodates both COO-broad and specialized-narrow structures.
+
+5. **The CoS role is variable.** Per [[../../venture-template/roles/chief-of-staff|chief-of-staff.md]], the role scope depends heavily on the CEO. Don't over-prescribe; meet the CEO where they are.
+
+## How role context affects the work
+
+When this skill is loaded alongside specific work, it should:
+
+- **For strategic decisions:** route through CEO context. Surface what CEO-level decisions look like; whether the current decision warrants CEO authority or can be made at pillar-lead level.
+- **For cross-pillar tradeoffs:** invoke [[../cross-pillar-tradeoff/SKILL|cross-pillar-tradeoff]]. The tradeoff is a CEO decision; the CoS often surfaces it.
+- **For pillar-specific work:** route through the relevant pillar lead's role context. CTO context for technical decisions; CMO for brand; COO for operational / commercial.
+- **For board / investor materials:** combine [[../stakeholder-update/SKILL|stakeholder-update]] (the composition) with CEO + CFO context (the authority + ownership).
+- **For exec hiring:** the CEO hires pillar leads. The decision shape is "we need a CMO / VP Marketing — what does this hire look like?" Reference the relevant role file.
+
+## Per-role context skills (future)
+
+This composite skill covers the executive layer. If individual per-role skills (`ceo-role`, `cto-role`, `cmo-role`, `coo-role`) become useful as the methodology matures, they can be authored as more specialized children of this skill. The composite covers the common ground; specialization can grow as needed.
+
+## What this skill is NOT
+
+- **Not the org chart.** Role files describe responsibilities, not headcount or reporting graphs. **Org seats** (instances, occupancy, assignments) use [[position-schema]]; templates here remain the “what is a CTO” reference.
+- **Not a hiring rubric.** Hiring rubrics are a Business-pillar deliverable; the role files inform them but aren't them. Human fill path: [[role-and-candidate-authoring]] against a position instance.
+- **Not a substitute for actual exec relationships.** The methodology supports the work; it doesn't replace the conversations between CEO + pillar leads.
+
+## Relationship to other skills
+
+- [[../product-pillar/SKILL|product-pillar]] / [[../brand-pillar/SKILL|brand-pillar]] / [[../business-pillar/SKILL|business-pillar]] — pillar skills auto-load alongside this skill when pillar work is happening
+- [[../cross-pillar-tradeoff/SKILL|cross-pillar-tradeoff]] — CEO-level decision framing
+- [[../stakeholder-update/SKILL|stakeholder-update]] — exec comms
+- [[../office-hours-mode/SKILL|office-hours-mode]] — typical posture for exec-level decisions
+- [[../role-and-candidate-authoring/SKILL|role-and-candidate-authoring]] — when filling a seat with a human
+- [[position-schema]] — position instances vs these role templates; agent vs human occupancy
+
+## Status
+
+- **2026-05-14:** Initial authoring. Composite skill covering 6 per-role files; individual per-role skills can be authored when specialization warrants.

package/governance/skills/exit-planning/SKILL.md

@@ -0,0 +1,66 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, governance, exit, preference-stack]
+ai-model: claude-opus-5.5
+created: 2026-10-27T15:49:30Z
+source: hybrid
+name: exit-planning
+description: >
+  Help a founder decide which ways the venture might end it should keep open
+  (acquisition, IPO, secondary sales, merger, management buyout, wind-down, or
+  hold) and see what each owner would get at different sale values from the
+  cap table, using schema/payouts.mjs. Records paths and scenarios in
+  governance/exit.json. Founder decision with counsel (EE-022).
+  MANDATORY TRIGGERS: exit, acquisition, sell the company, IPO, secondary,
+  preference stack, payout, who gets what, liquidation preference
+  outcome, drag-along, wind down, shut down.
+---
+
+# Exit planning
+
+Governance layer, ownership-and-control kit (EE-022). Writes `exit.json`; payouts are never typed, they are computed from `ownership.json` by `node schema/payouts.mjs`.
+
+## 1. Paths follow ambition
+
+| Ambition | Usual paths |
+| --- | --- |
+| Hobby, lifestyle | Hold; sell the business or its assets; wind down |
+| Managed growth | Hold and pay distributions; sale to a buyer or to the team (management buyout) |
+| Aggressive growth with investors | Acquisition or IPO. Investors usually expect one within the life of their fund |
+
+Record each path with a stance: preferred, open or ruled-out. Ruling a path out is a real decision: investors will ask.
+
+## 2. Who gets what
+
+`node schema/payouts.mjs <venture>` runs every scenario in `exit.json`:
+
+- Debt and costs come first. Scenario values are what is left for the owners.
+- Preferred classes take their liquidation preference, highest seniority first. Non-participating preferred converts to common when that pays more.
+- SAFEs and notes take the greater of their amount or their converted share.
+- The rest goes to common, pro rata. The unissued option pool gets nothing.
+
+Model at least three values: a soft landing (near the money raised), a base case and a strong case. At a soft landing the preferences can take most of the money; that is the moment the terms in `financing-and-investor-rights` matter.
+
+## 3. Rights that decide an exit
+
+- Drag-along: who can force everyone to sell.
+- Tag-along and co-sale: who can join a sale someone else makes.
+- Right of first refusal: who may buy shares before an outsider.
+- Board reserved matters: a sale is usually one.
+- Acceleration of vesting on a sale (see `cofounder-structure`).
+
+## 4. Wind-down
+
+If the venture ends without a sale, assets pay debts first, then the preferences, then common. Record the path as `wind-down`, and plan for employees, customers' data and obligations before money runs out.
+
+## Guardrails (all five ownership-and-control skills)
+
+- These are **founder decisions made with counsel** (decision class `ownership-or-control`, level escalate). An agent lays out the options, the trade-offs and the sources, drafts the records and documents, and stops. It never signs, files or agrees to anything.
+- Rules differ by country, state and legal form. Everything here is the common US startup default unless it says otherwise; name the jurisdiction before relying on it.
+- The signed documents are the truth. The records in `governance/` summarise them so agents and checks can read them; when the two disagree, fix the record.
+- Sources below are named from the method author's knowledge and still need recording with `find-reference` (URL and checked date) before a default is treated as settled.
+
+## Sources
+
+- Brad Feld and Jason Mendelson, *Venture Deals* (Wiley), chapters on liquidation preference and exits.
+- NVCA model legal documents: Voting Agreement (drag-along), Right of First Refusal and Co-Sale Agreement.