skills/founder-to-feature/SKILL.md

---
name: founder-to-feature
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."
---

# Founder to Feature

## Purpose

Founder-to-Feature owns **product meaning**:

> **What should become true?**

Translate natural creator input into implementation-ready meaning without requiring the user to write a PRD or technical contract.

## Ownership boundaries

- Development OS owns present intent, session state, stage validity, authorization, liveness, and handoff.
- Founder-to-Feature owns unresolved product meaning and the Crystallized behavioral contract.
- Specialist Reasoning supplies professional and generative perspective.
- Evidence Stewardship owns proof/permanence.
- Lean Repository Execution owns implementation/delivery.

## Activation

Activate when a materially unresolved decision can change user expectation, product philosophy, ownership, identity, permissions, lifecycle, placement/mental model, ecosystem ownership, or another durable rule.

Do not take over generic observation, known bugs with established behavior, or routine implementation.

## Semantic stages

### Explore

Discover the problem space, desired outcome, Ambition, constraints, and serious representations without prematurely accepting one.

### Resolve

Settle material semantic and technical consequences. Derive engineering implications from accepted product rules instead of asking the user to decide derivable mechanics.

### Crystallize

Reassemble the referent as one coherent product, reconcile specialists, expose material implementation shape, challenge the representation, and compress the result.

If a material contradiction appears, return only the affected lane to Resolve.

### Ready

Ready 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.

Ready is semantic confidence, not Build authorization.

## Behavioral delta

For established products, distinguish:

- **Changes** — what becomes newly true.
- **Preserved** — important behavior, philosophy, ownership, identity, or invariants that intentionally remain.
- **Retired** — behavior, assumptions, workflows, or attractive alternative models that intentionally stop being true.

Preserve a retirement reason only when a fresh agent is likely to rediscover the direction or reconstructing the decision later would be expensive.

## Founder correction synthesis

When the founder materially corrects a concrete proposal, ask whether the correction reveals a durable invariant, Ambition, anti-goal, ownership rule, or quality principle.

Promote only genuinely reusable meaning. Do not turn every preference into doctrine.

## Whole-product reasoning: Depth × Breadth × Time

Resolve only dimensions that can materially change the referent:

- **Purpose / Placement / Experience** — outcome, representation, discoverability, journey, empty/failure/recovery states.
- **System** — canonical owners, identity, durable state, permissions/trust, persistence/data safety, concurrency, performance/scale, provider boundaries, operational cost.
- **Lifecycle** — creation, revision, collaboration, migration, recovery, extension, maintenance, archival/deletion, provider evolution, retirement.
- **Ecosystem** — build vs integrate vs hybrid where it changes burden or product control.

Activate Specialist Reasoning rather than embedding every professional discipline here.

## Local authority

Use the smallest relevant current project truth. History is evidence; current owned project truth is specification.

When 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.

## Deep semantic resolution

Resolve only material:

- **Owners** — canonical owners and any necessary projections/caches/provider-owned state.
- **Identity** — which users/accounts/objects/projects/revisions/sessions are actually the same or different thing.
- **Invariants** — the few truths that must survive implementation changes.
- **Transitions** — state changes capable of changing user expectation.
- **Failure/destructive semantics** — partial success, retry, recovery, irreversibility.
- **Acceptance meaning** — what must observably be true at the product-claim level.

Prefer one native owner. Do not add parallel authorities for convenience.

## Founder decision vs engineering consequence

Ask the founder only for non-derivable product choices. Derive engineering consequences from accepted meaning.

Do not make the founder choose import paths, schema mechanics, retry plumbing, or similar implementation details unless those mechanics materially change product meaning or risk.

## Adversarial reasoning

Challenge transitions and assumptions that can materially change meaning, safety, ownership, lifecycle, or recoverability. Stop when additional cases produce no materially new information.

## Crystallization pass

Before Ready:

1. **Reassemble the whole.** Review the behavioral delta and material product/system/lifecycle/ecosystem choices.
2. **Expose implementation shape.** Surface material language/runtime/framework, repository/package, persistence/authority, provider/tool, deployment/hosting, automation/distribution, credential/permission choices—and intentional absence.
3. **Challenge scope.** Ask whether concepts can disappear, merge, become native, or remain external.
4. **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.
5. **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.
6. **Future-maintainer test.** What will a capable maintainer wish had been decided now?
7. **Fresh-outsider test.** What contradictions, duplicate owners, unexplained concepts, or needless complexity remain?

The goal is not novelty for novelty's sake. Serious alternatives must return to the accepted objective and survive professional evaluation.

## The crystal

When Crystallization passes, compress the referent into:

- **Outcome**
- **Ambition** when material
- **Changes**
- **Preserved**
- **Retired**
- **Product shape**
- **System shape**
- **Implementation shape**
- **Lifecycle**
- **Ecosystem choice**
- **Acceptance meaning**
- **Known constraints / bounded unknowns**

The crystal is working context by default, not a new permanent document.

## Authorization reconciliation

Founder-to-Feature never assumes semantic resolution authorizes mutation.

When meaning materially changes inside an authorized Build session:

1. resolve/crystallize only the affected lane;
2. identify the changed referent;
3. return it to Development OS;
4. let Development OS reconcile present intent and standing authorization;
5. obtain current commitment when the changed referent is not clearly covered.

## Build handoff

After Ready and valid scoped Build authorization:

- hand the behavioral delta/crystal to Development OS + Lean;
- carry forward material specialist obligations;
- let Evidence Stewardship choose proof;
- preserve implementation freedom inside the accepted contract.

If Build exposes a genuinely unresolved product question, return only that question.

## Anti-patterns

Do not:

- convert audits into requirements automatically;
- make every ambiguity a founder question;
- treat existing implementation representation as product intent;
- let tests decide unresolved meaning;
- preserve every brainstorm or rejected idea;
- use professional convention as a ceiling on project-native opportunity;
- treat Crystallization as ceremonial summary;
- treat Ready as Build authorization;
- implement changed meaning under stale authorization.

## Governing maxim

> **Resolve what should become true deeply enough that implementation cannot invent the product, while deliberately considering stronger representations before commitment.**