master-guided-skill-resolver

Master-Guided Skill Resolver

Use this skill for one job: compile source/action facts without desired-skill naming, then resolve them into a deterministic skill-selection snapshot.

1. Read the current Global and Project masters. A master-history-v1 marker identifies exact immutable history: use lifecycle's archive-aware master_index.py or fully read bound backing before claiming complete applicable history; a root-only search is incomplete. The existing inventory_live_masters_v2.py follows that same protocol for structural ID/link coverage, not semantic supersession. Freeze the source-bound objective, every source-clause disposition, authority, scope, and exact finalized job/action/tool facts before resolution.
2. For material work, create mgskill-fact-source-v2 input matching input-schema.md. Every source clause is fact-bearing or no-selection-fact; every emitted or excluded fact has evidence. Source wording may constrain semantics without selecting a skill. Current job/action/tool facts come from the finalized action record and current typed tool schema when available. Prefer python -B scripts/build_skill_fact_input.py --plan <plan.json> --registry <registry.json> --output <source.json>: it reads the authoritative clause document, generates per-clause text and payload hashes, and rejects malformed source/action plans before compilation. It is not a desired-skill selector.
3. Run python -B scripts/compile_skill_facts.py --source <source.json> --registry <registry.json> --output <receipt.json> --resolver-input-output <input.json>. Consume exact/near/no-match results, action finality/schema status, and the completed negative-selection countermodel. UNPROVEN finality/schema holds only the dependent application claim.
4. Run python -B scripts/resolve_skills.py --input <input.json> --registry <registry.json> --user-root <user-skill-root>; add --project-root <project-skill-root> when project skills are in scope. Supply only roots intentionally in scope.
5. Consume every selected and rejected reason. Do not use first-match priority. A missing, stale, conflicting, invalid or unmatched skill blocks only its dependent route; continue under the normal workflow when the receipt says fallback_normal_workflow.
6. Before using a selected skill, re-run the compiler and resolver against unchanged source/action/registry identities and require the same compiler and selection_snapshot_sha256, canonical real path, SKILL.md hash, and linked-resource hashes. A mismatch is stale selection, not permission to use the old copy.
7. For a child job, pass exact source/action/registry/compiler/selection identities, skill ID/version/origin/path, linked hashes, permitted disclosure class, resource claims, and proof ceiling. The parent remains the only semantic master writer.
8. For the primary owner's material selected-skill use, read application-chain-contract.md, then run python -B scripts/skill_application_bridge.py prepare --bundle <bundle.json>. Continue only on GO. The lane is source-bound COORDINATED-WORK with matching task/chat IDs and lease, or an explicit legacy WORK lease. The bridge opens selected non-UI files, checks path/hash and returns BYTES_DELIVERED; caller-authored FULL/issuer/event labels remain rejected absent a configured trusted exporter. Reading is not application, comprehension or benefit. Missing/mismatched evidence holds only the dependent bridge claim.
9. For supported script use, execute through run-powershell or run-script (one selected Python action-script with exact argv, no shell), then bind actual execution/action-result and effect. Before execution bind the capture plan, not a future success. Other typed tools retain their normal workflow evidence route; instruction-only use requires lifecycle v3 action/result and independent observation. The bridge rechecks the bound lane; independent auditors remain read-only, but the unified owner may implement within source authority. BLOCK, ERROR and HOLD do not prove target execution.