Update to Development OS

{
  "description": "Automatically use when professional perspective or materially different representations could improve software/product work. Select the smallest sufficient professional team, reason independently before synthesis, distinguish evidence from inference, deliberately diverge before convergence on substantial conceptual work, and return only findings that materially change the owning workflow.",
  "included_files": [
    {
      "relative_path": "references/experience.md",
      "size_in_bytes": 1376
    },
    {
      "relative_path": "references/product-core.md",
      "size_in_bytes": 2376
    },
    {
      "relative_path": "references/risk-business-domain.md",
      "size_in_bytes": 2527
    }
  ],
  "name": "specialist-reasoning",
  "skill_md_contents": "---\nname: specialist-reasoning\ndescription: \"Automatically use when professional perspective or materially different representations could improve software/product work. Select the smallest sufficient professional team, reason independently before synthesis, distinguish evidence from inference, deliberately diverge before convergence on substantial conceptual work, and return only findings that materially change the owning workflow.\"\n---\n\n# Specialist Reasoning\n\n## Purpose\n\nSpecialist Reasoning owns **perspective**:\n\n> **What are we failing to see, and what else could this be?**\n\nIts purpose is useful cognitive diversity without persona theater or committee process.\n\n## Ownership boundaries\n\n- Development OS decides when perspective is needed and keeps the overall work anchored.\n- Founder-to-Feature owns product meaning.\n- Specialist Reasoning owns professional perspective, independent analysis, generative divergence, representation challenge, and synthesis.\n- Evidence Stewardship owns proof/permanence.\n- Lean owns worker/tool coordination during Build.\n\nReal project/domain evidence outranks simulated expertise.\n\n## Activation\n\nActivate when perspective could materially change value, mental model, architecture, reliability, security/privacy, operations, economics, adoption, acceptance, or domain correctness.\n\nRoutine bounded fixes usually need no virtual team.\n\n## Smallest sufficient professional team\n\nSelect only professional disciplines that can materially change the objective.\n\nTypical core perspectives when relevant:\n\n- Product strategy / management\n- User research / behavioral understanding\n- Product / interaction design\n- Technical architecture / staff engineering\n- Quality / reliability\n\nAdd experience, risk, business, operations, developer-experience, legal, or domain perspectives only on a real trigger.\n\n> **Use the smallest sufficient professional team and the smallest useful diversity of thought.**\n\nLoad specialist reference files only when they materially help.\n\n## Independent-first reasoning\n\nDo not blend every discipline into a generic checklist.\n\nGive each activated professional function a short independent pass over:\n\n- opportunity;\n- risk;\n- unsupported assumption;\n- blocker/decision;\n- success signal.\n\nA professional perspective may conclude it has no material finding.\n\n## Evidence, hypothesis, inference\n\nDistinguish:\n\n- **Observed / externally supported**\n- **Project-derived**\n- **Founder hypothesis**\n- **Model inference**\n- **Generative hypothesis**\n\nProfessional reasoning is not evidence by itself. Research current authoritative sources when a high-stakes or changing external fact materially determines the conclusion.\n\n## Cross-functional disagreement\n\nSurface 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.\n\nProductive disagreement matters more than role count.\n\n## Worth-building and countercase\n\nFor substantial new capability, pressure-test whether it deserves complexity:\n\n- What need/outcome justifies it?\n- What simpler alternative solves enough?\n- What opportunity cost does it create?\n- What evidence argues against building it?\n\n## Generative divergence\n\nProfessional reasoning establishes the floor; it must not define the ceiling.\n\nFor substantial Explore or Crystallize work, before declaring saturation, deliberately generate a small set of materially different representations when doing so could improve the outcome.\n\nAt 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.\n\n> **Bad hypotheses are allowed during divergence; bad conclusions are not.**\n\nUseful lenses:\n\n- **Simplifier** — what can disappear, merge, become one owner, or become native?\n- **Enhancer** — what existing capability or small design change materially amplifies the same objective?\n- **Productive ignorance / naive outsider** — what obvious, dumb, category-confused, or seemingly impossible question exposes an assumption?\n- **Inversion** — what if ownership, flow, control, or responsibility ran the opposite direction?\n- **Analogy transfer** — how would a mature unrelated domain represent this shape of problem?\n- **Constraint experiment** — what does forbidding a database/dashboard/second owner/background system reveal?\n- **Architectural runway** — what probable future need has high later migration cost but a cheap neutral seam today?\n\nThese are reasoning lenses, not fictional professionals and not accepted meaning.\n\n## Scope discipline and elasticity\n\nSpecialists operate for the accepted objective, but the accepted objective is not automatically the accepted representation.\n\n> **Leave the frame when needed; do not lose the objective.**\n\nA perspective may inspect beyond the current component, abstraction, or feature boundary when doing so can reveal the real cause or a materially better representation. It must return with demonstrated relevance.\n\nClassify discoveries:\n\n- **Required for the objective** — analyze now.\n- **Adjacent but nonessential** — note/route without expanding the active referent.\n- **Systemic cause of the objective** — inspect far enough to establish it; route wider cleanup separately unless recovery itself is the objective.\n- **Would redefine product intent** — surface to Founder-to-Feature.\n\nDo not use scope discipline to suppress materially better architecture. Do not use innovation to justify unrelated redesign.\n\n## Battle testing\n\nBattle testing is a deep adversarial completeness pass over a candidate conclusion, contract, architecture, document, or implementation.\n\n> **Attack the result across the smallest sufficient set of consequence layers until additional attacks stop revealing material omissions, contradictions, unsafe assumptions, or stronger representations.**\n\nBattle testing is not a generic checklist and not synonymous with exhaustive evidence. Select only layers capable of changing the result, such as:\n\n- meaning and reachable states;\n- representation and abstraction;\n- ownership and authority;\n- lifecycle, migration, deletion, and retirement;\n- failure, interruption, recovery, and rollback;\n- permissions, trust, identity, and external boundaries;\n- scale, time, cost, and operational burden;\n- human comprehension, misuse, recovery, and accessibility;\n- maintenance and fresh-context legibility;\n- external legal/provider/standards reality when materially relevant.\n\nUse materially different attack directions where useful:\n\n- **Omission** — what necessary dimension is absent?\n- **Contradiction** — what accepted statements cannot both remain true?\n- **Reachability** — what valid sequence reaches an unresolved state?\n- **Misuse/adversary** — what happens under error, abuse, or unexpected use?\n- **Change over time** — what breaks after migration, provider change, growth, or organizational change?\n- **Failure/recovery** — can partial or damaged states recover coherently?\n- **Authority/dependency** — what must be true externally, and are we merely assuming it?\n- **Fresh outsider** — what would a capable newcomer question that insiders stopped seeing?\n\nFor substantial Crystallize work, battle-test before declaring Ready. For substantial or high-consequence implementation near acceptance, battle-test the built reality again because a strong contract does not prove the delivered system.\n\nBattle testing generates hypotheses and findings; Evidence Stewardship determines which are supported enough to affect the active referent or earn durable routing.\n\n## Transformative synthesis\n\nAfter professional passes and divergence, synthesize only ideas that could materially improve the work.\n\nAsk especially:\n\n- What is everyone assuming?\n- Which constraint is merely historical?\n- What could disappear rather than be improved?\n- Which separate problems become simpler when modeled together?\n- What project-native capability is underused?\n- If the current solution did not exist, would we invent it this way?\n- Are we improving an abstraction because it deserves to exist or because it already exists?\n- Is there a cheap seam now that avoids an expensive likely migration later?\n\nEvaluate generated alternatives professionally before returning them to the owning workflow.\n\n## Internal vs multi-agent mode\n\nDefault to internal separated reasoning passes.\n\nUse independent agents/subagents only when real independence adds value for substantial or high-consequence work. Do not create permanent agents per profession.\n\n## Output to the owning workflow\n\nReturn a compact synthesis:\n\n- relevant professional team;\n- material opportunities/risks;\n- unsupported assumptions and evidence status;\n- meaningful conflicts and battle-test omissions;\n- serious representation alternatives/simplifications;\n- contract implications;\n- irreducible founder decisions.\n\nDo not create permanent specialist reports by default.\n\n## During Build\n\nReactivate when implementation reveals a newly material professional/domain risk or representation problem that could invalidate the accepted referent, and for a pre-Accept battle test on substantial or high-consequence candidates. Return bounded findings; do not take over execution.\n\n## Saturation\n\nStop when:\n\n- the sufficient professional team covered material risk/opportunity;\n- serious generative alternatives were considered where representation mattered;\n- substantial candidates were battle-tested across the material consequence layers;\n- further perspectives/alternatives/attacks are unlikely to change the objective or quality;\n- remaining uncertainty belongs to evidence, founder decision, bounded implementation freedom, or human taste.\n\nRepeated founder rescue after saturation is evidence that divergence was too weak.\n\n## Anti-patterns\n\nDo not:\n\n- turn roles into personas;\n- load every profession;\n- manufacture findings;\n- treat inference as user/external evidence;\n- create permanent specialist specifications;\n- make scope so tight that the real cause/stronger representation cannot be discovered;\n- let generative hypotheses become conclusions without professional evaluation;\n- generate novelty merely to appear creative;\n- optimize inherited abstractions without asking whether they should exist.\n\n## Governing maxim\n\n> **Establish a professional floor, diverge beyond the inherited frame, battle-test the candidate across material consequence layers, and converge only on conclusions that survive relevance, evidence, and professional scrutiny.**\n\n"
}