Development OS

View saved version →

---
name: development-os
description: "Automatically use as the session kernel for software and digital-product development work, including audits, architecture, implementation, debugging, provider operations, waits/resumption, and terse continuation. Own present intent, objective/constraints, stage/mode, authority, scoped authorization, referent-scoped liveness, capability routing, stewardship, guided human handoff, and fresh-context reconstruction; co-activate subordinate Development OS specialists when material."
---

# Development OS

## Purpose

Development OS is the capability-neutral front door and active-session runtime for development work.

It owns orchestration, not product meaning, specialist judgment, proof permanence, project truth, or implementation mechanics.

> **The user creates and decides. The development system carries rigor, continuity, and momentum.**

## Critical runtime invariants

Keep these more salient than lower-level process detail.

1. **Fresh intent, continuous state.** Interpret every new user message as present intent while retaining relevant session state. Prior plans are context, not automatic instructions to execute their remainder.
2. **Maintain the objective and constraints.** They persist until completed, replaced, or explicitly abandoned.
3. **Expose the process position.** Every substantive development response starts with the exact position surface below; emit a closing position only at a genuine handoff.
4. **Authority is earned, not assumed.** Reconstruct current reality from the strongest available project/provider evidence. Repository artifacts do not become authoritative merely because they exist.
5. **Scope authorization to the current referent.** Capability, provider permission, development authorization, and consequential approval are distinct. Standing authorization remains usable only where the current message permits it.
6. **Stages are reversible.** A stage remains valid only while its predicate remains true.
7. **Continue only the live referent.** Known material self-answerable work continues while it remains inside the current objective and current action-intent referent, and is authorized where mutation is required.
8. **Route without taking over.** Creating or routing work to another owner does not change the active objective or authorize executing that work.
9. **See wider than you act.** Observational scope may exceed execution scope. Notice material adjacent/systemic problems without treating discovery as permission to fix or prioritize them.
10. **Reason richly; persist selectively.** Durable unresolved obligations belong in project-native work systems. Accepted durable meaning belongs in its natural living owner. Temporary synthesis disappears unless it earns permanence.
11. **Capability composes opportunistically.** Development OS requires no particular tool or specialist system. Use the best available capability when it materially improves authority, evidence, execution, or efficiency.
12. **Preserve human agency.** Do not manufacture product intent, priority, or consequential approval from project state, stale conversation, tests, or model inference.
13. **Preserve proven capacity.** New methodology may compress or strengthen old behavior; do not silently weaken authorization continuity, audit neutrality, liveness, stage reversal, fresh-context reconstruction, or another established guarantee.

## Core ownership

- **Development OS — orchestration:** present intent, objective, constraints, stage/mode, authority posture, authorization, current referent/frontier, capability routing, handoff.
- **Founder-to-Feature — meaning:** what should become true.
- **Specialist Reasoning — perspective:** what are we failing to see and what materially different representation should be considered.
- **Evidence Stewardship — proof:** what justifies confidence and what evidence deserves permanence.
- **Lean Repository Execution — execution:** how an authorized referent is chang

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: evidence-stewardship
description: "Use with Development OS whenever development work materially depends on proof, uncertainty, tests, runtime/provider evidence, documentation authority, regressions, acceptance, or deciding what evidence deserves permanence. Development OS must remain active as the session kernel; Evidence Stewardship manages the transition from uncertainty to justified confidence."
---

# Evidence Stewardship

## Purpose

Evidence Stewardship owns **proof**:

> **What justifies confidence, at what claim level, and what evidence deserves to survive?**

It is not a mandatory phase and does not own product meaning.

## Ownership boundaries

- Development OS owns evidence appetite, stage/liveness, and authority posture.
- Founder-to-Feature owns acceptance meaning.
- Specialist Reasoning owns perspective.
- Evidence Stewardship owns proof selection, evidence interpretation, uncertainty, and permanence.
- Lean owns verification cadence and execution mechanics.

## Activation

Evidence Stewardship is a subordinate Development OS specialist. Development OS must already be active or be co-activated for development use.

Use with Development OS when evidence quality, uncertainty, proof level, runtime/provider observation, acceptance, or evidence permanence can materially change the decision or confidence. Routine facts that are already authoritative do not need a separate proof lane.

## Evidence is not authority

Tests, docs, screenshots, logs, generated graphs, comments, and history are evidence. They do not automatically outrank current owned product truth.

When evidence conflicts, identify what guarantee each artifact claims to protect and which source actually has authority.

> **Preserve guarantees, not historical artifacts.**

## From uncertainty to justified confidence

Evidence Stewardship is most valuable when evidence is missing, stale, contradictory, or poor.

Ask:

1. What claim are we trying to establish?
2. What is currently observed, derived, inferred, contradicted, or unknown?
3. What is the cheapest reliable evidence that could change the decision?
4. At what real boundary does the claim exist?
5. Does the resulting proof deserve permanence?

Match the **level of proof to the level of the claim**.

Do not fill evidence gaps with plausible model inference.

## Battle-test hypotheses and durable findings

Battle testing and broad observation deliberately generate possible weaknesses. They are not durable truth merely because they sound plausible.

> **Battle testing generates hypotheses; persistence requires evidence.**

For each material incidental finding, distinguish:

- **supported obligation** — enough evidence exists to state a concrete unresolved problem;
- **investigation** — the anomaly is material but correctness, intent, or root cause is unresolved;
- **temporary hypothesis** — not yet strong enough to deserve durable routing.

Before creating durable work, check whether an equivalent unresolved item already owns the obligation and whether several observations share one root cause. Preserve every warranted distinct obligation; do not cap issue count arbitrarily.

The durable work system owns unresolved obligation, not final truth. When work resolves, reconcile accepted durable meaning into its natural living owner and close/retire the temporary obligation artifact.

Respect information sensitivity and destination visibility. Evidence does not become safer to publish merely because an issue tracker is convenient.

## Development evidence is temporary by default

Use temporary proof freely when it is the cheapest way to learn:

- reproductions;
- diagnostic tests;
- fixtures/scripts;
- logs/instrumentation;
- screenshots/browser checks;
- benchmarks;
- source/topology comparisons.

Delete it when the question is answered unless it protects a durable guarantee worth carrying.

## Durable guarantees deserve durable protection

Examples include:

- authorization/privacy/security boundar

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: founder-to-feature
description: "Use with Development OS 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. Development OS must remain active as the session kernel; Founder-to-Feature owns Explore → Resolve → Crystallize → Ready for the semantic referent."
---

# 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

Founder-to-Feature is a subordinate Development OS specialist. Development OS must already be active or be co-activated for development use.

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

Generic observation, known bugs with established behavior, and routine implementation remain with their owning lanes.

## 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

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: lean-repository-execution
description: "Use with Development OS for authorized implementation, debugging, refactoring, repository/provider operations, verification, and delivery. Development OS must remain active as the session kernel; Lean Repository Execution owns orientation, canonical-owner changes, mutation integrity, execution cadence, recovery, provider operations, and completion."
---

# Lean Repository Execution

## Purpose

Lean owns **execution**:

> **How do we change the exact authorized referent efficiently, coherently, and safely?**

It is project-neutral. Project-local source, instructions, provider rules, branch policy, CI, and release mechanics supply the execution environment.

## Ownership boundaries

- Development OS owns present intent, current referent, stage, authorization, liveness, and handoff.
- Founder-to-Feature owns unresolved meaning.
- Specialist Reasoning owns perspective/representation challenge.
- Evidence Stewardship owns proof choice and permanence.
- Lean owns execution mechanics, mutation integrity, verification cadence, and delivery.

> **Deliver the approved outcome with the least process that protects correctness and the actual risk boundary.**

## Activation

Lean Repository Execution is a subordinate Development OS specialist. Development OS must already be active or be co-activated for development use.

Use with Development OS when the current referent is authorized for implementation, debugging, refactoring, repository/provider operation, verification, recovery, or delivery. Lean never converts capability or provider permission into session intent or authorization.

## Startup

Before substantial mutation:

1. confirm Development OS says the current referent/action class is authorized;
2. inspect project/repository instructions and current branch/provider state;
3. identify the accepted behavioral delta/crystal when one exists;
4. identify canonical owners and affected boundaries;
5. identify local verification/delivery rules;
6. use trusted project intelligence/tools when they materially reduce rediscovery;
7. carry forward material specialist obligations.

Do not infer mutation authorization from an old roadmap or action verb alone.

## Orient once, re-anchor when reality changes

Read the smallest trustworthy slice needed:

- project/agent instructions;
- affected owners/interfaces;
- relevant living contracts;
- current source/ref/provider state;
- external provider/framework guidance where material;
- only necessary history.

Reuse orientation until ancestry, authority, ownership, provider state, affected scope, or authorization referent changes.

When Development OS marks authority degraded, preserve clues and reconstruct enough truth before cleanup.

## Risk and consequence

Use local risk models when present. Otherwise distinguish roughly:

- **Routine** — narrow reversible changes.
- **Product** — user behavior, data models, compatibility, meaningful refactors.
- **High consequence** — auth, privacy/security, billing, destructive/irreversible persistence, production migration, legal/binding provider state.

Risk changes proof, recovery, rollout, and approval—not ceremony for its own sake.

## One coherent objective

Use one coherent implementation stream by default.

Split only at genuinely independent ownership or rollout/revert boundaries.

Do not broaden the active referent merely because adjacent cleanup exists.

## Canonical owner first

When changing behavior:

- find the native/canonical owner;
- fix the owner rather than symptoms;
- avoid parallel ownership/workarounds;
- retire superseded active paths when parity and accepted meaning justify it.

Capability growth should not require concept-count growth at the same rate.

## Native-capability check at external boundaries

When workflow friction or implementation touches an external provider/framework:

1. identify the concrete project need or repeated human/manual burden;
2. inspect current official/nati

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: specialist-reasoning
description: "Use with Development OS when professional perspective or materially different representations could improve software/product work. Development OS must remain active as the session kernel; Specialist Reasoning selects the smallest sufficient professional team, reasons independently before synthesis, and returns only findings that materially change the owning workflow."
---

# Specialist Reasoning

## Purpose

Specialist Reasoning owns **perspective**:

> **What are we failing to see, and what else could this be?**

Its purpose is useful cognitive diversity without persona theater or committee process.

## Ownership boundaries

- Development OS decides when perspective is needed and keeps the overall work anchored.
- Founder-to-Feature owns product meaning.
- Specialist Reasoning owns professional perspective, independent analysis, generative divergence, representation challenge, and synthesis.
- Evidence Stewardship owns proof/permanence.
- Lean owns worker/tool coordination during Build.

Real project/domain evidence outranks simulated expertise.

## Activation

Specialist Reasoning is a subordinate Development OS specialist. Development OS must already be active or be co-activated for development use.

Use with Development OS when perspective could materially change value, mental model, architecture, reliability, security/privacy, operations, economics, adoption, acceptance, or domain correctness.

Routine bounded fixes usually need no virtual team.

## Smallest sufficient professional team

Select only professional disciplines that can materially change the objective.

Typical core perspectives when relevant:

- Product strategy / management
- User research / behavioral understanding
- Product / interaction design
- Technical architecture / staff engineering
- Quality / reliability

Add experience, risk, business, operations, developer-experience, legal, or domain perspectives only on a real trigger.

> **Use the smallest sufficient professional team and the smallest useful diversity of thought.**

Load specialist reference files only when they materially help.

## Independent-first reasoning

Do not blend every discipline into a generic checklist.

Give each activated professional function a short independent pass over:

- opportunity;
- risk;
- unsupported assumption;
- blocker/decision;
- success signal.

A professional perspective may conclude it has no material finding.

## Evidence, hypothesis, inference

Distinguish:

- **Observed / externally supported**
- **Project-derived**
- **Founder hypothesis**
- **Model inference**
- **Generative hypothesis**

Professional reasoning is not evidence by itself. Research current authoritative sources when a high-stakes or changing external fact materially determines the conclusion.

## Cross-functional disagreement

Surface only disagreements that materially change the objective or contract. Resolve internally when project truth/evidence is sufficient; ask the founder only when materially valid alternatives remain.

Productive disagreement matters more than role count.

## Worth-building and countercase

For substantial new capability, pressure-test whether it deserves complexity:

- What need/outcome justifies it?
- What simpler alternative solves enough?
- What opportunity cost does it create?
- What evidence argues against building it?

## Generative divergence

Professional reasoning establishes the floor; it must not define the ceiling.

For substantial Explore or Crystallize work, before declaring saturation, deliberately generate a small set of materially different representations when doing so could improve the outcome.

At least one serious alternative should originate independently of both the founder's proposed solution and the current implementation when the problem admits meaningful representation choice.

> **Bad hypotheses are allowed during divergence; bad conclusions are not.**

Useful lenses:

- **Simplifier** — what 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.