Imported from Chisiki1/objective-integrity-framework (runtime/skills/master-guided-skill-lifecycle/SKILL.md). Install upstream with npx skills add Chisiki1/objective-integrity-framework --skill master-guided-skill-lifecycle. Copyright stays with the author.

Master-Guided Skill Lifecycle

Use this skill to change the next necessary operation from its actual result. During material work use in-work.md: internal-job results use work_io consume/build-next; recurring ordinary native operations use operations.md to preserve the actual process result and generate the next real request or complete inactive Skill input. Replace that caller rather than adding a parallel receipt-only path. Each continuing actor reconciles relevant resources at a safe boundary. Read learning-loop.md for the existing queue/history route. No end-of-task wait, Skill quota or extra master is required. The authorized primary owner executes eligible improvements and alone writes shared meaning.

The repository's broader governance and self-improvement guide is optional context, not a required Skill dependency.

At a material job-shape change, use stage-allocation-contract.md and python -B scripts/stage_allocation.py --input <view.json>. This is event-driven allocation, not a fixed model ranking or periodic reselection.

Use scripts/allocation_io.py state for explicit typed orchestration fields and scripts/allocation_io.py run --input <view.json> --evidence <new-result.jsonl> to invoke and consume the allocator without handwritten success-label assertions. The helper preserves raw results and verifies identities; it never grants dispatch authority. Consult each command's --help. A valid SELECTED result may reuse the current context; do not insist that every reuse returns RETAIN_CURRENT. When integrating the Python API into a current transition, pass its independently obtained expected_identity; the CLI alone binds freshness to its explicit input file, not to a later live decision.

When component work accumulates without closing its required consumer connection, a known family recurs, or supporting procedure starts dominating delivery, apply convergence.md in the existing work record. If external evidence could change that method decision, use external-calibration.md there, even without a model/version mismatch. Technical documentation lookup is not external validation of the work method. Carry the chosen concrete change into the next actual action or handoff; unchanged reuse and justified non-adoption remain valid. For a hook-dependent capability decision, the same reference provides an optional pure-reader snapshot, not installation or enforcement. No new Skill, packet, research quota or task-wide waiting phase is required.

Include structural/breakthrough alternatives in that comparison and at other worthwhile reuse or capability opportunities: change the work unit or execution entrypoint, remove/consolidate a mechanism, or replace a representation instead of repeatedly adding reminders. Choose by the same source outcome and total value, not novelty. For repeated bounded internal-job assembly and handoff, use work-entrypoint.md and scripts/work_io.py to generate the actual request and consume its returned artifacts. Replace the corresponding handwritten assembly; do not add a second ticket or use this route for every trivial question. The parent retains semantic judgment, actual dispatch authority, source completion and shared writes.

For implementation whose local verification is outrunning unfinished whole-scope work, apply source-wide-execution.md to the existing work definition. One source-bound scope and state selects the parent's next work and each child job through work_phase.py, owner control, transition admission and work_io v2. Build all required implementation and consumer connections before formal whole-candidate checks; collect safe current-stage findings before grouped correction. Keep bounded decision-essential construction feedback available and preserve later mandatory evidence. This changes the work unit and next action, not the objective or external authority. Do not force product phases onto read-only research or create another semantic ledger.

For an actual operating-condition improvement or blocking condition, read condition-stewardship.md. Reuse the existing queue; the read-only workflow_governance.py checks proposal/reference consistency only. It never grants authority. Exact later user approval can supersede an earlier user condition within scope, while higher-priority rules, independent source review and downstream action authority remain separate. No candidate means no extra governance procedure.

1. Keep the raw Project event intact. Classify its causal family, solution status, applicability and whether an existing generic invariant already handles it.
2. For a new invocation effect, create mgskill-effect-v3 JSON matching lifecycle-contract.md and run python -B scripts/skill_lifecycle.py effect --input <file>. Record planned and actual objective/evidence deltas separately. Use applied, not_applied, unavailable, not_applicable, or false_block as observed rather than inferring benefit from invocation. Every material effect must generate a candidate disposition; equivalent content fingerprints propose merge rather than parallel strengthening. Existing v2 inputs remain lineage-compatible but cannot prove this v3 obligation.
3. prevented requires an observed pre-submission block, preserved rejected candidate and applicable-set equality; it never establishes avoided consumer harm without bounded counterfactual evidence. A known constraint that existed but did not screen the final action is not_applied, not prevented.
4. For create, revise, merge, supersede, or retire, run python -B scripts/skill_lifecycle.py transition --input <file>. Consume the returned Project-event candidate; the parent applies any semantic master write under CAS and creates only a sanitized Global cross-link/aggregate. Materialize the complete needed package with python -B scripts/materialize_skill_candidate.py --input <candidate.json> --candidate-root <inactive-root> --expected-root-manifest-sha256 <sha256> --discovery-root <active-root> --apply (repeat discovery roots). Use the exact v2 resource schema in lifecycle-contract.md for scripts/resources; v1 instruction-only remains supported. The existing isolated adopter consumes the whole verified member set, not just SKILL.md. Bind the real caller and next operation before declaring adoption. This is inactive preparation, not permission to activate; existing source, challenge, evaluation, CAS and recovery requirements remain.
5. Treat recommended dispositions as candidates only: recurrence, misselection or non-application proposes revise/merge; false block proposes narrow/retire; no effect proposes revise/retire. None self-authorizes semantic activation. For an instruction-only Skill, applied requires effect_observation.actual_action=instruction-used, a real action outcome, and an independently identified observation; reading or byte delivery is not application.
6. Do not activate from one event, a fixed recurrence count, popularity, model preference, structural PASS, or unavailable metric. Require the transition-specific baseline, replay or shadow evidence, supported normal-path counterexamples, independent challenge, rollback, identity and proof ceiling.
7. If faithful interpretations or material effects remain ambiguous, return USER-DECISION; do not self-authorize a semantic transition.

Lifecycle state is not discoverability state. Superseded and retired versions must leave active discovery roots, while immutable evidence and lineage remain preserved elsewhere. A changed registry, skill, resource, policy or master is a new five-plane identity cut and must be revalidated only through affected routes.

The script emits a candidate only. It cannot prove objective fidelity, root cause, scenario completeness, independent audit sufficiency, runtime discovery, final-consumer improvement, or rollback success.