Update to Development OS

{
  "description": "Automatically use for authorized implementation, debugging, refactoring, repository/provider operations, verification, and delivery. Own orientation, canonical-owner changes, mutation integrity, execution cadence, verification cadence, recovery, provider operations, and completion while relying on Development OS for intent/authorization and Evidence Stewardship for proof permanence.",
  "included_files": [],
  "name": "lean-repository-execution",
  "skill_md_contents": "---\nname: lean-repository-execution\ndescription: \"Automatically use for authorized implementation, debugging, refactoring, repository/provider operations, verification, and delivery. Own orientation, canonical-owner changes, mutation integrity, execution cadence, verification cadence, recovery, provider operations, and completion while relying on Development OS for intent/authorization and Evidence Stewardship for proof permanence.\"\n---\n\n# Lean Repository Execution\n\n## Purpose\n\nLean owns **execution**:\n\n> **How do we change the exact authorized referent efficiently, coherently, and safely?**\n\nIt is project-neutral. Project-local source, instructions, provider rules, branch policy, CI, and release mechanics supply the execution environment.\n\n## Ownership boundaries\n\n- Development OS owns present intent, current referent, stage, authorization, liveness, and handoff.\n- Founder-to-Feature owns unresolved meaning.\n- Specialist Reasoning owns perspective/representation challenge.\n- Evidence Stewardship owns proof choice and permanence.\n- Lean owns execution mechanics, mutation integrity, verification cadence, and delivery.\n\n> **Deliver the approved outcome with the least process that protects correctness and the actual risk boundary.**\n\n## Startup\n\nBefore substantial mutation:\n\n1. confirm Development OS says the current referent/action class is authorized;\n2. inspect project/repository instructions and current branch/provider state;\n3. identify the accepted behavioral delta/crystal when one exists;\n4. identify canonical owners and affected boundaries;\n5. identify local verification/delivery rules;\n6. use trusted project intelligence/tools when they materially reduce rediscovery;\n7. carry forward material specialist obligations.\n\nDo not infer mutation authorization from an old roadmap or action verb alone.\n\n## Orient once, re-anchor when reality changes\n\nRead the smallest trustworthy slice needed:\n\n- project/agent instructions;\n- affected owners/interfaces;\n- relevant living contracts;\n- current source/ref/provider state;\n- external provider/framework guidance where material;\n- only necessary history.\n\nReuse orientation until ancestry, authority, ownership, provider state, affected scope, or authorization referent changes.\n\nWhen Development OS marks authority degraded, preserve clues and reconstruct enough truth before cleanup.\n\n## Risk and consequence\n\nUse local risk models when present. Otherwise distinguish roughly:\n\n- **Routine** — narrow reversible changes.\n- **Product** — user behavior, data models, compatibility, meaningful refactors.\n- **High consequence** — auth, privacy/security, billing, destructive/irreversible persistence, production migration, legal/binding provider state.\n\nRisk changes proof, recovery, rollout, and approval—not ceremony for its own sake.\n\n## One coherent objective\n\nUse one coherent implementation stream by default.\n\nSplit only at genuinely independent ownership or rollout/revert boundaries.\n\nDo not broaden the active referent merely because adjacent cleanup exists.\n\n## Canonical owner first\n\nWhen changing behavior:\n\n- find the native/canonical owner;\n- fix the owner rather than symptoms;\n- avoid parallel ownership/workarounds;\n- retire superseded active paths when parity and accepted meaning justify it.\n\nCapability growth should not require concept-count growth at the same rate.\n\n## Native-first external boundaries\n\nWhen touching external providers/frameworks:\n\n1. inspect current official/native behavior when needed;\n2. identify the concrete project need native behavior cannot satisfy;\n3. prefer native capability where it satisfies the requirement;\n4. add custom abstraction only for a real product/operational boundary.\n\nDo not recreate provider functionality merely for control.\n\n## Cohesive implementation\n\nImplement the complete current referent, not a succession of model-visible microtasks.\n\nBatch predictable mechanical work. Keep intermediate implementation freedom inside the accepted contract.\n\n## Mutation integrity and recovery\n\nFor substantial multi-step mutation:\n\n- know the last authoritative committed/ref/provider state;\n- prefer atomic/coherent writes where supported;\n- distinguish local/intermediate objects from published authority;\n- never claim publication until the intended branch/ref/provider state moved;\n- after interruption/ambiguous response, re-read authority before retrying;\n- avoid replaying destructive/non-idempotent operations blindly;\n- preserve recoverable authored work before cleanup/reset.\n\nTool failure is not product failure when project truth remains clear.\n\n### Repository recovery execution\n\nWhen repository recovery itself is authorized:\n\n- recover truth before reorganizing structure;\n- establish/consolidate one canonical owner at a time;\n- preserve evidence needed to distinguish active from abandoned paths;\n- delete stale/duplicate implementation and docs only after their unique durable meaning is reconciled;\n- stop when the repository has a trustworthy canonical spine, not when every aesthetic imperfection is gone.\n\n## New meaning during Build\n\nIf implementation exposes a genuinely unresolved product question:\n\n1. stop only the affected semantic lane;\n2. return it through Development OS to Founder-to-Feature;\n3. keep independent authorized work moving when safe;\n4. after resolution, let Development OS re-evaluate present intent and authorization.\n\nA broad refactor/hardening authorization does not automatically authorize new ownership, permission, identity, economics, placement, or product philosophy.\n\n## Agent and worker use\n\nDo not fan out by default.\n\nUse independent workers for independent investigation, specialist review, materially cross-owner review, or isolated implementation lanes after semantic freeze.\n\nDo not parallelize workers that can invent conflicting shared abstractions or product semantics.\n\n## Verification budget\n\nLean owns when/how often checks run; Evidence Stewardship owns what proof is appropriate and what survives.\n\nHonor Development OS Evidence Appetite.\n\nRerun checks only after relevant change or changed external state. Prefer one coherent final/full gate over repeated model-tool-model crossings.\n\n## Evidence permanence\n\nApply Evidence Stewardship automatically. Temporary proof normally disappears; stable high-value guarantees may earn durable protection.\n\nDo not create permanent tests/docs merely because they helped implementation.\n\n## Loop breaker\n\nStop repeated checking when no relevant state changed or the next result cannot materially change the decision, implementation, proof, or confidence.\n\nTake the smallest available action that can answer the real unanswered question. Batch predictable operations.\n\n## Debugging\n\nFor established bugs:\n\n1. reproduce at the smallest useful boundary;\n2. identify the violated accepted guarantee;\n3. localize the canonical owner;\n4. fix the owner;\n5. prove the guarantee at the appropriate level;\n6. decide whether recurrence deserves durable protection.\n\nIf expected behavior is unclear, route that meaning question rather than letting old tests/code decide it.\n\n## Provider and production operations\n\nFor consequential external mutation:\n\n- establish current state;\n- identify the native operation;\n- make the minimum approved mutation;\n- verify once at the real boundary;\n- preserve rollback/recovery where relevant;\n- obey project-local approval/release gates.\n\n## Review\n\nReview the coherent candidate for:\n\n- fidelity to accepted meaning;\n- duplicate ownership/leftover legacy;\n- concurrency/idempotency/provider mistakes;\n- needless complexity or maintainability regression;\n- evidence that freezes implementation instead of guarantees;\n- local proof being overclaimed as product acceptance;\n- methodology-driven ceremony with no decision value.\n\nDo not turn review into a new product workshop without new evidence.\n\nFor substantial or high-consequence candidates approaching acceptance, reactivate Specialist Reasoning for a pre-Accept battle test of the built reality. Evidence Stewardship validates material findings. Resolve supported in-referent defects before acceptance; route supported out-of-referent obligations to the native work system when authorized without expanding the execution referent.\n\n## Completion and delivery\n\nBefore calling execution complete:\n\n- the current authorized referent is implemented;\n- important behavior has appropriate proof;\n- temporary probes are removed or deliberately promoted;\n- obsolete evidence/paths are retired when required;\n- provider/production proof is complete where needed;\n- unresolved material risk is explicit;\n- material battle-test findings are resolved in-scope or durably routed out-of-scope;\n- durable product meaning is reconciled into living owners when it changed;\n- authoritative branch/ref/provider state matches the claim.\n\nFollow the project's actual PR/review/preview/release process. Do not invent generic gates.\n\n## Reporting\n\nReport only meaningful finding, blocker, founder decision, approval boundary, material scope/risk change, or completion.\n\nDevelopment OS owns the process-position surface. Lean returns execution facts into it rather than inventing a parallel status format.\n\n## Anti-patterns\n\nDo not:\n\n- rediscover unchanged context;\n- create status/process files by default;\n- split one coherent change into needless PR chains;\n- fan out workers without independent value;\n- ask again for routine permission already granted;\n- silently widen the referent;\n- treat intermediate artifacts as publication;\n- blindly retry ambiguous provider operations;\n- keep checking unchanged state;\n- use a live frontier to justify low-yield work;\n- equate tests with product authority;\n- reopen settled meaning without evidence.\n\n## Governing maxim\n\n> **Execute the exact authorized referent coherently, change canonical owners rather than symptoms, and preserve authoritative state through interruption and delivery.**\n\n"
}