Update to Development OS

{
  "description": "Automatically use when development work contains unresolved product meaning: substantial feature ideas, architecture-affecting behavior, workflow redesign, or audit findings that require deciding what should become true. Own Explore → Resolve → Crystallize → Ready for the semantic referent; do not own session state, proof permanence, or implementation mechanics.",
  "included_files": [],
  "name": "founder-to-feature",
  "skill_md_contents": "---\nname: founder-to-feature\ndescription: \"Automatically use when development work contains unresolved product meaning: substantial feature ideas, architecture-affecting behavior, workflow redesign, or audit findings that require deciding what should become true. Own Explore → Resolve → Crystallize → Ready for the semantic referent; do not own session state, proof permanence, or implementation mechanics.\"\n---\n\n# Founder to Feature\n\n## Purpose\n\nFounder-to-Feature owns **product meaning**:\n\n> **What should become true?**\n\nTranslate natural creator input into implementation-ready meaning without requiring the user to write a PRD or technical contract.\n\n## Ownership boundaries\n\n- Development OS owns present intent, session state, stage validity, authorization, liveness, and handoff.\n- Founder-to-Feature owns unresolved product meaning and the Crystallized behavioral contract.\n- Specialist Reasoning supplies professional and generative perspective.\n- Evidence Stewardship owns proof/permanence.\n- Lean Repository Execution owns implementation/delivery.\n\n## Activation\n\nActivate when a materially unresolved decision can change user expectation, product philosophy, ownership, identity, permissions, lifecycle, placement/mental model, ecosystem ownership, or another durable rule.\n\nDo not take over generic observation, known bugs with established behavior, or routine implementation.\n\n## Semantic stages\n\n### Explore\n\nDiscover the problem space, desired outcome, Ambition, constraints, and serious representations without prematurely accepting one.\n\n### Resolve\n\nSettle material semantic and technical consequences. Derive engineering implications from accepted product rules instead of asking the user to decide derivable mechanics.\n\n### Crystallize\n\nReassemble the referent as one coherent product, reconcile specialists, expose material implementation shape, challenge the representation, and compress the result.\n\nIf a material contradiction appears, return only the affected lane to Resolve.\n\n### Ready\n\nReady means the Crystallized referent is coherent enough that competent implementers should not invent conflicting product behavior, substantial referents have survived an appropriate Specialist Reasoning battle test, and no known self-answerable semantic uncertainty is likely to materially change meaning, ownership, architecture, lifecycle, or user expectation.\n\nReady is semantic confidence, not Build authorization.\n\n## Behavioral delta\n\nFor established products, distinguish:\n\n- **Changes** — what becomes newly true.\n- **Preserved** — important behavior, philosophy, ownership, identity, or invariants that intentionally remain.\n- **Retired** — behavior, assumptions, workflows, or attractive alternative models that intentionally stop being true.\n\nPreserve a retirement reason only when a fresh agent is likely to rediscover the direction or reconstructing the decision later would be expensive.\n\n## Founder correction synthesis\n\nWhen the founder materially corrects a concrete proposal, ask whether the correction reveals a durable invariant, Ambition, anti-goal, ownership rule, or quality principle.\n\nPromote only genuinely reusable meaning. Do not turn every preference into doctrine.\n\n## Whole-product reasoning: Depth × Breadth × Time\n\nResolve only dimensions that can materially change the referent:\n\n- **Purpose / Placement / Experience** — outcome, representation, discoverability, journey, empty/failure/recovery states.\n- **System** — canonical owners, identity, durable state, permissions/trust, persistence/data safety, concurrency, performance/scale, provider boundaries, operational cost.\n- **Lifecycle** — creation, revision, collaboration, migration, recovery, extension, maintenance, archival/deletion, provider evolution, retirement.\n- **Ecosystem** — build vs integrate vs hybrid where it changes burden or product control.\n\nActivate Specialist Reasoning rather than embedding every professional discipline here.\n\n## Local authority\n\nUse the smallest relevant current project truth. History is evidence; current owned project truth is specification.\n\nWhen authority is degraded, let Development OS reconstruct mechanics first. If product purpose or intended behavior remains non-derivable, ask the founder for minimum grounding rather than inferring mission from code shape.\n\n## Deep semantic resolution\n\nResolve only material:\n\n- **Owners** — canonical owners and any necessary projections/caches/provider-owned state.\n- **Identity** — which users/accounts/objects/projects/revisions/sessions are actually the same or different thing.\n- **Invariants** — the few truths that must survive implementation changes.\n- **Transitions** — state changes capable of changing user expectation.\n- **Failure/destructive semantics** — partial success, retry, recovery, irreversibility.\n- **Acceptance meaning** — what must observably be true at the product-claim level.\n\nPrefer one native owner. Do not add parallel authorities for convenience.\n\n## Founder decision vs engineering consequence\n\nAsk the founder only for non-derivable product choices. Derive engineering consequences from accepted meaning.\n\nDo not make the founder choose import paths, schema mechanics, retry plumbing, or similar implementation details unless those mechanics materially change product meaning or risk.\n\n## Adversarial reasoning\n\nChallenge transitions and assumptions that can materially change meaning, safety, ownership, lifecycle, or recoverability. Stop when additional cases produce no materially new information.\n\n## Crystallization pass\n\nBefore Ready:\n\n1. **Reassemble the whole.** Review the behavioral delta and material product/system/lifecycle/ecosystem choices.\n2. **Expose implementation shape.** Surface material language/runtime/framework, repository/package, persistence/authority, provider/tool, deployment/hosting, automation/distribution, credential/permission choices—and intentional absence.\n3. **Challenge scope.** Ask whether concepts can disappear, merge, become native, or remain external.\n4. **Require serious alternatives when design-sensitive.** Reconcile at least one materially different representation generated independently by Specialist Reasoning when such divergence could improve the outcome.\n5. **Battle-test completeness.** Ask Specialist Reasoning to attack the candidate across the smallest sufficient set of material consequence layers. Current-referent omissions return only the affected lane to Resolve; supported out-of-referent findings may be durably routed without takeover.\n6. **Future-maintainer test.** What will a capable maintainer wish had been decided now?\n7. **Fresh-outsider test.** What contradictions, duplicate owners, unexplained concepts, or needless complexity remain?\n\nThe goal is not novelty for novelty's sake. Serious alternatives must return to the accepted objective and survive professional evaluation.\n\n## The crystal\n\nWhen Crystallization passes, compress the referent into:\n\n- **Outcome**\n- **Ambition** when material\n- **Changes**\n- **Preserved**\n- **Retired**\n- **Product shape**\n- **System shape**\n- **Implementation shape**\n- **Lifecycle**\n- **Ecosystem choice**\n- **Acceptance meaning**\n- **Known constraints / bounded unknowns**\n\nThe crystal is working context by default, not a new permanent document.\n\n## Authorization reconciliation\n\nFounder-to-Feature never assumes semantic resolution authorizes mutation.\n\nWhen meaning materially changes inside an authorized Build session:\n\n1. resolve/crystallize only the affected lane;\n2. identify the changed referent;\n3. return it to Development OS;\n4. let Development OS reconcile present intent and standing authorization;\n5. obtain current commitment when the changed referent is not clearly covered.\n\n## Build handoff\n\nAfter Ready and valid scoped Build authorization:\n\n- hand the behavioral delta/crystal to Development OS + Lean;\n- carry forward material specialist obligations;\n- let Evidence Stewardship choose proof;\n- preserve implementation freedom inside the accepted contract.\n\nIf Build exposes a genuinely unresolved product question, return only that question.\n\n## Anti-patterns\n\nDo not:\n\n- convert audits into requirements automatically;\n- make every ambiguity a founder question;\n- treat existing implementation representation as product intent;\n- let tests decide unresolved meaning;\n- preserve every brainstorm or rejected idea;\n- use professional convention as a ceiling on project-native opportunity;\n- treat Crystallization as ceremonial summary;\n- treat Ready as Build authorization;\n- implement changed meaning under stale authorization.\n\n## Governing maxim\n\n> **Resolve what should become true deeply enough that implementation cannot invent the product, while deliberately considering stronger representations before commitment.**\n\n"
}