naive-framework 0.0.0-stage → 0.1.0

package/governance/skills/financing-and-investor-rights/SKILL.md

@@ -0,0 +1,73 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, governance, financing, safe, investor-rights]
+ai-model: claude-opus-5.5
+created: 2026-10-27T15:49:30Z
+source: hybrid
+name: financing-and-investor-rights
+description: >
+  Help a founder decide whether and how to take outside money and what rights
+  investors get in return: bootstrapping, grants, debt, SAFEs, convertible
+  notes and priced rounds; liquidation preference, anti-dilution, pro-rata,
+  information rights, board seats, protective provisions, drag-along,
+  tag-along and right of first refusal. Records instruments and rights in
+  governance/ownership.json. Founder decision with counsel (EE-022).
+  MANDATORY TRIGGERS: fundraising, raise money, investors, SAFE, convertible
+  note, priced round, seed round, Series A, term sheet, valuation cap,
+  liquidation preference, anti-dilution, pro-rata, investor rights.
+---
+
+# Financing and investor rights
+
+Governance layer, ownership-and-control kit (EE-022). Writes `instruments` and class `rights` in `ownership.json`; `venture.json` `form.funding` names the overall source.
+
+## 1. Whether to raise at all
+
+Read `ambition` first.
+
+- **Hobby, survival, lifestyle, managed growth:** bootstrapping, revenue, grants or debt usually fit better. Equity investors expect aggressive growth and an exit; taking their money commits the venture to that path.
+- **Aggressive growth:** outside equity is common. Raise for a milestone that moves the venture to its next phase, not for a length of time.
+
+## 2. Instruments
+
+| Instrument | What it is | Common terms |
+| --- | --- | --- |
+| Post-money SAFE (Y Combinator, 2018) | Right to future shares at the next priced round; not debt | Valuation cap, sometimes a discount; the investor's share is roughly amount divided by cap |
+| Convertible note | Debt that converts at the next round | Interest, maturity date, cap, discount |
+| Priced round | Preferred shares bought at a set price | Term sheet; NVCA documents are the common basis |
+| Debt or revenue-based finance | Repaid from cash flow | No ownership given up; needs revenue |
+
+Record each SAFE or note in `instruments` (amount, cap, discount, `converts_to`). A priced round adds a preferred class and grants.
+
+## 3. Investor rights, and the market default
+
+| Right | Founder-friendly default | Watch for |
+| --- | --- | --- |
+| Liquidation preference | 1x, non-participating | Multiples above 1x; participating preferred ("double dip") |
+| Anti-dilution | Broad-based weighted average | Full ratchet |
+| Board seat | One seat for the lead investor | Investor majority of the board early |
+| Protective provisions | The NVCA standard list | Vetoes over the budget, hiring or ordinary operations |
+| Pro-rata | Major investors only | Super pro-rata |
+| Information rights | Annual and quarterly financials | Rights for every small holder |
+| Drag-along | Triggered by the board and a majority of preferred and common | Triggered by investors alone |
+| Right of first refusal and co-sale | On founder share sales | Covering transfers to family trusts |
+| Redemption | None | Investors' right to be bought out on a date |
+
+Record the rights each class or instrument grants in its `rights`. Board seats must match `board.json`, which `check-governance.mjs` checks.
+
+## 4. Before signing
+
+Run `node schema/payouts.mjs <venture> <value>` at a low, a middle and a high sale value to see what the terms mean for each holder.
+
+## 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).
+- Y Combinator, post-money SAFE (2018) and its user guide.
+- NVCA model legal documents: Term Sheet, Investors' Rights Agreement, Voting Agreement, Right of First Refusal and Co-Sale Agreement.

package/governance/skills/office-hours-mode/SKILL.md

@@ -0,0 +1,113 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, office-hours-mode]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: office-hours-mode
+description: >
+  Switch AI thought-partnership posture to "office hours mode" — sharp critique,
+  evidence-demanding, weakest-claim-first. Modeled on Gary Tan's Office Hours
+  format. This is the dominant mode for Phase 1A (version scoping), Phase 0B-
+  validate (post-version validation), Phase 1B spec convergence reviews, phase
+  closure reviews, and any phase where weak claims need to die before they ship.
+  Press the operator to defend the strongest version of their thinking; run
+  steel-mans; surface the inconvenient question. The opposite mode is
+  friend-mode (sympathetic expansion). Per SAD v3.3+ amendment §31.
+  MANDATORY TRIGGERS: office hours, office-hours mode, critique mode, pressure
+  test, version scoping, 1A, 0B-validate, spec convergence, phase closure
+  review, articulation closure verification, kill weak claims, steel-man,
+  what's wrong with, defend, harsh, sharp critique, pushback, /office-hours.
+---
+
+# Office Hours Mode Skill
+
+The AI thought-partnership posture for convergence phases — where weak claims need to die before they ship and the operator needs sharp critique rather than sympathetic expansion.
+
+Modeled on Gary Tan's Office Hours format (the canonical reference). Sharp, fast, focused.
+
+## When to invoke
+
+This skill should auto-load when:
+
+- The user explicitly invokes office-hours mode ("pressure-test this," "be harsh," "what's wrong with my plan")
+- The conversation is in Phase 1A (version scoping), 0B-validate (post-version-scoping research), 1B spec convergence reviews, or any phase-closure review
+- The user is converging on a decision (cutting scope, choosing between alternatives, finalizing a spec)
+- A claim needs to be steel-manned or stress-tested
+- An articulation-closure verification is running
+
+This skill should NOT load when:
+
+- The user is in Phase 0A (mind dump), 0B-initial (vision-expanding research), or 0C (unconstrained vision)
+- The user is brainstorming or exploring possibilities
+- The user is brand-new to a problem space and needs aperture-broadening
+- The user is fragile / recovering / needs care — surface the concern; offer to defer office-hours until later
+
+## What office-hours mode does
+
+### Posture
+
+- **Press hard.** Demand evidence for every load-bearing claim. "How do you know?" "What would change your mind?" "Show me the data."
+- **Identify the weakest claim first.** Find the assumption that holds up the rest; attack it. If it survives, the structure is sound; if it doesn't, the structure isn't.
+- **Run steel-mans.** Restate the strongest version of any counter-argument. Force the operator to defend against the best critique, not the worst.
+- **Surface the inconvenient question.** The thing the operator was avoiding. The market reality they're rationalizing past. The technical risk they're deferring.
+- **Push for specifics.** Vague answers are caught and pressed. "What does that mean concretely?" "Give me an example."
+
+### What office-hours mode is NOT
+
+- **Not hostility.** Office-hours mode is sharp critique in service of the work, not personal attack. The operator's *thinking* is being pressed; the operator is being supported.
+- **Not contrarianism for sport.** Push back where there's substance to push back on. Don't manufacture disagreement.
+- **Not endless skepticism.** When a claim survives critique, name that. The point is to find what's load-bearing, not to invalidate everything.
+- **Not the universal default.** Friend mode is the right default in expansion phases. Office-hours is reserved for convergence.
+
+### Concrete behaviors
+
+When in office-hours mode, the AI should:
+
+1. **Lead with the weakest claim.** First response: "Here's the claim I'm least confident in: ___. Defend it."
+2. **Demand evidence.** "What's the data?" "What experiments would test this?" "Who has done this before?"
+3. **Run the counter-argument.** Steel-man the opposition. "The strongest argument against this is ___ — how do you respond?"
+4. **Press on assumptions.** Surface the assumptions the operator is implicitly making. "This rests on ___ being true. Is it?"
+5. **Push for specificity.** Catch every "we'll figure it out" / "users will love it" / "the market will respond." Demand concrete operational definitions.
+6. **Track what survives.** Note which claims hold up under critique vs. which crack. The survivors are the load-bearing ones.
+7. **Time-box the critique.** Office-hours sessions aren't endless. Identify the top 3-5 things that need attention; surface them sharply; close the session.
+
+## Mode switching
+
+Office-hours mode is the *right* default for convergence phases. Mode switches happen when:
+
+- **The operator explicitly requests the switch.** "Let's open this back up" → switch to friend.
+- **The phase changes.** Moving from 1A (version scoping) to 0C (re-visioning if 1A surfaces gaps) → switch to friend.
+- **The operator is overwhelmed and needs aperture broadening.** Switch to friend; note what came out of office-hours for later.
+- **A new idea surfaces that needs exploration before critique.** Briefly switch to friend; return to office-hours when the idea is articulate enough to pressure-test.
+
+## Reference: Gary Tan's Office Hours format
+
+Gary Tan's `/office-hours` slash command in gstack uses six forcing questions:
+
+1. What are you building?
+2. Who is the customer?
+3. What's the smallest thing you can ship?
+4. What evidence do you have that someone wants this?
+5. What's your unfair advantage?
+6. What are you NOT going to build?
+
+These are good. The methodology should adopt them (or close variants) as the default office-hours-mode opening. Customize per phase:
+
+- **Version scoping (1A):** The six gstack questions, plus the SAD-specific "What's V[N+1] going to add that V[N] foreshadows?"
+- **Validate research (0B-validate):** "Are the versions tangible?" "Is the idea actually needed?" "What would falsify your market thesis?"
+- **Spec convergence (1B):** "What ambiguity remains in this spec?" "What would Ralph Wiggum get confused by?" "What's the functional completion condition?"
+
+## Why this exists
+
+Per SAD v3.3+ amendment §31, AI thought-partnership has at least two declared modes. Friend mode in convergence phases lets weak claims ship into spec. Office-hours mode in expansion phases narrows vision prematurely. Choosing + declaring the right mode for the phase is methodology-load-bearing.
+
+## Related skills
+
+- [[../friend-mode/SKILL|friend-mode]] — the opposite posture; sympathetic expansion for exploration phases
+- [[../articulation-closure/SKILL|articulation-closure]] — articulation closure's verification table is run in office-hours mode
+- [[../version-identity/SKILL|version-identity]] — version scoping (1A) where one-persona-per-version is decided runs in office-hours mode
+
+## Status
+
+- **2026-05-14:** Initial authoring per §31 amendment.

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

@@ -0,0 +1,81 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, product-pillar]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: product-pillar
+description: >
+  Provide Product pillar context — teams, roles, Tier 1 + Tier 2 deliverables,
+  cross-pillar overlap zones — when working on product-pillar work. Auto-loads
+  when the conversation involves product spec authoring, technical architecture,
+  engineering work, UX / design, or any other Product-pillar concern.
+  References the canonical Product pillar file at venture-template/pillars/product.md.
+  Per SAD v3.3+ amendment §33.
+  MANDATORY TRIGGERS: product pillar, product work, product spec, engineering,
+  CTO, technical architecture, UX, design, sitemap, IA, wireframes, component
+  library, code, software product, content product, service product, hardware
+  product, spec stack, VISION_SPEC, VERSION_SPEC, PRODUCT_SPEC, DATA_MODEL_SPEC,
+  IMPL_SPEC, BEHAVIORAL_SPEC, VERIFICATION_SPEC.
+---
+
+# Product Pillar Skill
+
+The context-providing skill for Product-pillar work. Auto-loads when product-pillar concerns surface in conversation.
+
+## What this skill provides
+
+When loaded, this skill makes available:
+
+- **Product pillar reference** — see [[../../venture-template/pillars/product|venture-template/pillars/product.md]] for the canonical Product pillar description
+- **CTO role context** — see [[../../venture-template/roles/cto|venture-template/roles/cto.md]]
+- **Per-product-type guidance** — Tier 2 deliverables vary by product type (software / content / service / hardware / hybrid)
+- **Cross-pillar overlap awareness** — Product × Brand (design system, DevEx) and Product × Business (analytics, customer success, pricing-as-product, trust & safety)
+
+## When to invoke
+
+Auto-loads when:
+
+- Product spec work is happening (any of VISION → VERIFICATION specs)
+- Engineering / technical architecture work is happening
+- UX / IA / design / wireframe work is happening
+- Code is being authored, reviewed, or deployed
+- Product-pillar deliverables are being inventoried (e.g., during articulation closure)
+- The conversation surfaces Product-pillar concerns (technical risk, code quality, schema design, etc.)
+
+## What this skill emphasizes
+
+When loaded, the AI should keep in mind:
+
+1. **Product is the pillar where SAD lives most fully.** Spec stack discipline, articulation closure, the Phase 0A → 5 pipeline — all of this was authored for Product pillar / software product type. The methodology is most mature here.
+
+2. **Brand is imported, not duplicated.** When product work touches identity (colors, typography, logo, voice), the right move is wikilink to Brand, not copy. Watch for design system drift.
+
+3. **Per-product-type Tier 2 deliverables matter.** Software product has a deeply-developed Tier 2 deliverable set; content product, service product, hardware product have lighter sets (and need authoring). Don't apply software-product Tier 2 to a content product.
+
+4. **Multi-product Product pillars share some deliverables.** When the entity has multiple Product-pillar products (e.g., a product with seven surfaces), some deliverables are per-product (spec stack) and some are entity-wide (cross-product strategy). Don't conflate.
+
+5. **CTO is the pillar lead.** Product-pillar sign-offs map to CTO authority. When articulation closure verification is gating, that's CTO-domain.
+
+## Cross-pillar overlap behavior
+
+When work crosses pillars:
+
+- **Design system** (Product × Brand) — both pillars' skills should load. Brand owns visual tokens + voice; Product owns interaction patterns + component behavior.
+- **Developer experience** (Product × Brand) — Product owns SDK / API docs; Brand owns dev portal voice.
+- **Analytics** (Product × Business) — Product owns instrumentation + event taxonomy; Business owns metric definitions + dashboards.
+- **Customer success** (Product × Business) — Product owns in-product onboarding + feedback; Business owns support runbooks + CS ops.
+- **Pricing-as-product** (Product × Business) — Product owns paywall + plan-gate UX; Business owns pricing strategy.
+- **Trust & safety** (Product × Brand × Business) — Product owns tooling; Brand owns community standards; Business owns legal posture.
+
+## Related skills
+
+- [[../articulation-closure/SKILL|articulation-closure]] — most active in Product pillar
+- [[../build-roadmap/SKILL|build-roadmap]] — Product-pillar artifact
+- [[../version-identity/SKILL|version-identity]] — Brand-led but Product-consumed
+- [[../brand-pillar/SKILL|brand-pillar]] — companion pillar skill; loads when Brand work surfaces
+- [[../business-pillar/SKILL|business-pillar]] — companion pillar skill; loads when Business work surfaces
+
+## Status
+
+- **2026-05-14:** Initial authoring. References venture-template/pillars/product.md as the canonical Product pillar reference.

package/governance/skills/publication-policy/SKILL.md

@@ -0,0 +1,63 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, governance, publishing, brand]
+ai-model: claude-opus-5.5
+created: 2026-10-27T17:22:08Z
+source: hybrid
+name: publication-policy
+description: >
+  Help a venture decide where it publishes and who may publish what there:
+  its channels (website, docs site, social, newsletter, app store, press,
+  investor update, regulatory filing), the guidelines each one follows, the
+  checks and preview every publication passes, and who drafts and who
+  approves by role or team. Records it in governance/publication-policy.json
+  and gates every publishing handoff (EE-025).
+  MANDATORY TRIGGERS: publish, Substack, X, Twitter, Facebook, Instagram,
+  LinkedIn, YouTube, TikTok, reply, comment, publication, go public, post, announce,
+  press release, newsletter, website copy, social media, channel, brand
+  guidelines, editorial guidelines, style guide, approval workflow, who can
+  publish, content governance.
+---
+
+# Publication policy
+
+Governance layer (EE-025). Writes `publication-policy.json`; `check-publication.mjs` checks it and every handoff that publishes.
+
+## The opinion: everything published passes the gate
+
+The framework has no way to publish around the gate. A publication is a handoff under the decision class `public-commitment`. It names its channel and the kind of content (`publication`), passes the channel's checks, shows a preview of exactly what will go out, and a person approves it. Agents may draft, run the checks and attach the preview. They never approve. The gate does two jobs: it keeps the quality of what goes out under a person's eye, especially what an agent wrote, and it lets a publication be tested before it is public, not after.
+
+## 1. Channels: where it lands decides the rules
+
+Start from the destination, not the content. The same paragraph is held to different rules on a website, in an app store listing, in an investor update and in a regulatory filing. For each channel record:
+
+- `kind` and `destination`: where it lands (a URL, an account, a repository, a recipient list).
+- `audience`: who reads it there.
+- `guidelines`: which of the venture's guidelines apply here.
+- `checks`: conformance checks (scripts, run like tests) and review checks (what a person reads for).
+- `preview`: how to see exactly what would go out before it does: a dry run, a staging deploy, a draft sent to the approvers.
+- `platform`: the third-party platform it runs on (Substack, X, Facebook, Instagram, LinkedIn, YouTube, TikTok and others). A social, newsletter or app-store channel must name it, and a channel on a platform must cite that platform's rules as a guideline of kind `platform`.
+- `replies`: on social, newsletter and blog channels, replies, comments and direct messages speak for the venture in public too. Choose `gated` (each reply passes the gate), `delegated` (named people may reply within the guidelines; agents alone never), or `none`.
+- `config`: the channel tool's own configuration, if it has one (such as a site generator's allowlist).
+
+## 2. Guidelines: the venture's own and the outside world's
+
+- **Brand guidelines** (visual and verbal identity) come from the brand pillar, the single source of truth for identity.
+- **Editorial guidelines** (what to write about and how, distinct from brand voice) come from the product pillar for content products, otherwise the brand pillar.
+- **Outside rules** apply by channel: a platform's rules (an app store's review guidelines), advertising law (the FTC Endorsement Guides in the US), disclosure duties (investor information rights; for a public company, rules on selective disclosure). Record the URL and the date it was checked.
+- **Security rules**: what must never leave (private terms, archived or sensitive notes, raw captures). The method site's publisher enforces these as refusal rules.
+
+## 3. Rights: who may publish what, by role or team
+
+Each channel has rules: a kind of content, the layers whose records it may draw on, who drafts and who approves. Approvers are roles or teams (a governance team, a marketing team). `check-publication.mjs` fails a rule with no person approving, and fails any agent role named as an approver.
+
+| Venture | A common shape |
+| --- | --- |
+| Solo founder | One approver, the founder, on every channel |
+| Small team | The founders approve anything about money or control (funding announcements, investor updates); one named person approves routine product pages |
+| Larger company | Brand or marketing approves campaigns; product approves docs and release notes; legal or the board approves regulated and financial disclosures |
+
+## Guardrails
+
+- Publishing is outward and hard to take back (copies, caches, indexes). The default level for `public-commitment` is escalate; a venture may delegate a channel to a named person, never to an agent.
+- When a guideline changes, re-run the channel's checks on what is already published before the next publication.

package/governance/skills/role-and-candidate-authoring/SKILL.md

@@ -0,0 +1,198 @@
+---
+type: knowledge
+tags: [everything-ecosystem, skills, role-and-candidate-authoring]
+ai-model: claude
+created: 2026-05-15
+source: hybrid
+name: role-and-candidate-authoring
+description: >
+  Author the three role-filling artifacts when an operator (CEO, founder, or
+  pillar lead) is hiring for a role, assigning a project, or filling an
+  operational responsibility: (1) role description, (2) ideal candidate
+  qualities, (3) explicit recommendations for finding + evaluating candidates.
+  Also applies to sub-project owner-filling per the recursive pillar pattern.
+  This is the bridge from solo-operator methodology to multi-person team
+  methodology. Per SAD v3.3+ amendment §38.
+  MANDATORY TRIGGERS: hiring, hire, role description, job description,
+  candidate, ideal candidate, qualities, who should run this, who owns this,
+  role-filling, assign a project, sub-project owner, /role-and-candidate-authoring.
+---
+
+# Role + Candidate Authoring Skill
+
+The methodology workflow for producing the artifacts an operator needs when filling a role or assigning an owner — whether that's a formal hire, a contractor engagement, an internal team assignment, or a sub-project ownership decision.
+
+## Why role-and-candidate-authoring exists
+
+Per [[../../_ideas/build-roadmap-and-html-orchestration-2026-05-12|build-roadmap §38]], the methodology should support the transition from solo-operator + AI to multi-person teams. The bridge is the moment when the operator decides to bring someone in — for a role, a project, a sub-company per the §36 recursive pillar pattern.
+
+At that moment, the operator needs three concrete artifacts:
+
+1. **A role description** that the candidate (and any reviewers) can read
+2. **A candidate-qualities profile** that calibrates what to look for
+3. **Recommendations** for where to look + how to evaluate
+
+Without explicit support, these get drafted ad-hoc, often poorly, and the methodology breaks down at exactly the moment the team grows.
+
+## When to invoke
+
+- Filling a C-level role (CTO, CMO, COO, CFO, etc.)
+- Filling a VP-level or director role
+- Filling a senior IC role with specific scope
+- Assigning ownership of a sub-project (per §36 recursion — when a pillar product matures enough to warrant its own owner)
+- Engaging a contractor for a defined scope of work
+- Establishing a project lead within an existing team
+- The user explicitly asks "what should I look for in a [role]" or "help me write a job description for X"
+
+## What this skill produces
+
+For any role-filling moment, three artifacts:
+
+### 1. Role description
+
+A 1-2 page document covering:
+
+- **Title** and the role's relationship to the methodology layer (pillar lead / company-wide / sub-project owner / IC)
+- **Purpose** — one paragraph on what the role is for
+- **Primary + secondary pillars** the role touches
+- **Owns** — what the role is accountable for (deliverables, decisions, outcomes)
+- **Does not own** — explicit non-responsibilities (per the role-file pattern at venture-template/roles/)
+- **Reports to** + **collaborates with** + **reports to this role**
+- **Stage variation** — how the role differs by company stage; what version of the role this hire is filling
+
+For predefined roles (CEO, CTO, CMO, COO, Founder, Chief of Staff), this starts from the venture-template/roles/ file and customizes for the specific project's context.
+
+For custom roles (e.g., "Editor-in-Chief of the company podcast"), this synthesizes from the relevant pillar(s) + the role's specific scope.
+
+### 2. Ideal candidate qualities
+
+A profile covering:
+
+- **Required skills** — load-bearing capabilities the candidate must have
+- **Strong-preference skills** — capabilities that significantly improve fit
+- **Traits** — temperament, working style, values alignment
+- **Experience** — kinds of prior work that match; the shape of the right career arc
+- **Stage fit** — the candidate's experience tier relative to the company's stage (a hobby project's first hire vs. a venture's growth-stage hire are very different profiles)
+- **Cultural fit signals** — what the candidate's framing of work should sound like
+
+Calibrated per the project's [[../ambition-tier/SKILL|ambition tier]]. A pre-PMF venture's VP Engineering is a different profile from a growth-stage one.
+
+### 3. Explicit recommendations
+
+A practical guide covering:
+
+- **Sources** — where this kind of person tends to come from (specific communities, prior companies, networks, schools)
+- **Outreach patterns** — how to make first contact (warm intros via X, direct reach via Y, posting in Z communities)
+- **Interview considerations** — what to evaluate, in what order, with what specific questions
+- **Signal vs. noise** — what looks like a yes that isn't, what looks like a no that isn't
+- **Common mismatches** — typical bad fits; how to recognize them early
+- **Compensation reference** — when the methodology has reference data; otherwise points to where to find it
+- **Reference checks** — what to ask of references; what answers indicate fit
+
+## How to run this skill
+
+When this skill is loaded, the AI should:
+
+### Step 1 — Clarify the role
+
+Ask:
+- Is this a predefined role (CEO / pillar lead / etc.) or a custom role?
+- What pillar(s) does this role touch?
+- What's the project's current stage + ambition tier?
+- Is this a full-time hire, contractor, project owner, sub-project owner, or other arrangement?
+- What's the company / project's context that makes this role exist NOW?
+
+### Step 2 — Surface predefined context (if applicable)
+
+For predefined roles, read the venture-template/roles/ file as the starting point. Surface the pre-authored role description as the baseline; customize from there.
+
+### Step 3 — Author the role description
+
+Draft the 1-2 page role description following the structure above. Customize for this specific project + stage + ambition tier.
+
+### Step 4 — Author the candidate-qualities profile
+
+Calibrated to the role + company stage + ambition tier. Don't over-prescribe (per [[../office-hours-mode/SKILL|office-hours-mode]] discipline — required skills should be genuinely required, not nice-to-haves disguised as requirements).
+
+### Step 5 — Author the recommendations
+
+Concrete + actionable. Surface specific communities, outreach patterns, interview considerations. Where the methodology has gaps (e.g., compensation data), name them honestly.
+
+### Step 6 — Save the artifacts
+
+Save to:
+
+```
+projects/<entity>/<pillar>/hires/<date>-<role-slug>.md
+```
+
+Or for sub-project ownership:
+
+```
+projects/<entity>/<sub-project-path>/owner-profile.md
+```
+
+Frontmatter:
+
+```yaml
+---
+type: role-filling-artifact
+role: <role-slug>
+artifact-type: role-description | candidate-qualities | recommendations | combined
+pillar: <primary-pillar>
+stage: <company-stage>
+ambition-tier: <tier>
+created: <date>
+authorship: hybrid
+tags: [role-filling, hiring, <entity>, <pillar>]
+status: draft | active | filled | archived
+---
+```
+
+### Step 7 — Surface to the orchestration HTML
+
+Per [[../../_ideas/build-roadmap-and-html-orchestration-2026-05-12|§32]], the per-project orchestration HTML can surface "open roles" as a visible state. Add the role to the orchestration's hiring/roles section with status `draft` → `active` → `filled`.
+
+### Step 8 — Update on candidate progress
+
+As candidates surface + are evaluated, the operator can append notes to the role artifacts. When a hire is made, update status to `filled` + capture the hire's actual profile vs. the ideal profile (the gap is methodology-useful for next time).
+
+## Applied to sub-project ownership (recursive)
+
+Per [[../../_ideas/build-roadmap-and-html-orchestration-2026-05-12|§36]], pillar products are themselves sub-companies. When a sub-project matures enough to warrant its own owner, this skill applies recursively:
+
+- The sub-project's three pillars determine which pillar lead profile is needed
+- The sub-project's stage determines the seniority level
+- The sub-project's ambition tier determines the candidate-qualities calibration
+
+A podcast that's a Brand-pillar product might need:
+- An Editor-in-Chief (custom role; Brand pillar lead of the sub-company)
+- A Producer (Product pillar lead of the sub-company)
+- A Business Manager (Business pillar lead of the sub-company)
+
+This skill authors the role-filling artifacts for each.
+
+## Implicit-vs-explicit principle (per §37)
+
+The skill is explicit about WHAT to consider (the three artifacts; the per-pillar context; the stage calibration). It is implicit about HOW to document — the actual shape of the role description, candidate profile, and recommendations is per role + per project + per AI conversation. Different roles surface different specifics even from the same template.
+
+## What this skill is NOT
+
+- **Not a compensation database.** When compensation data is available (via methodology references or operator-provided context), the skill incorporates it. Otherwise the skill points the operator to where to find it.
+- **Not a substitute for actual judgment.** The skill produces artifacts to help the operator's hiring process; it doesn't make the hiring decision. The operator + their advisors do.
+- **Not job-board copy.** The role description is internal; if the operator wants public-facing job-board copy, that's a separate (related) artifact for the [[../stakeholder-update/SKILL|stakeholder-update]] skill or marketing surface.
+- **Not for agent occupancy.** When a [[position-schema|position]] has `staffing-posture: agent-capable` / `agent-preferred` (or `occupancy: agent`), use agent-role taxonomy / assertion bounds — do not run this human-candidate workflow as if it were a hire.
+
+## Relationship to other skills
+
+- [[../executive-roles/SKILL|executive-roles]] — provides context for predefined C-level **role templates**
+- [[position-schema]] — create / update the **position instance** first; this skill fills when the target occupancy is human
+- [[../cross-pillar-tradeoff/SKILL|cross-pillar-tradeoff]] — hiring is often a cross-pillar tradeoff (CEO + finance + relevant pillar lead all weigh in)
+- [[../stakeholder-update/SKILL|stakeholder-update]] — hire announcements + public-facing job posts compose with this skill
+- [[../office-hours-mode/SKILL|office-hours-mode]] — the right posture for candidate-qualities authoring (don't over-prescribe; required means required)
+- [[../canonicalize/SKILL|canonicalize]] — role descriptions for filled roles may become canonical for their concern
+
+## Status
+
+- **2026-05-14:** Initial authoring per §38 amendment.
+- **2026-08-10:** Pointer to [[position-schema]] — human fill path vs agent occupancy.