sg-mission-lock

name

sg-mission-lock

description

Lock the literal user mission and authorization level before work to prevent scope drift, inferred permission, adjacent-work expansion, plan churn, and false completion. Use unconditionally when the active model is gpt-5.6 or gpt-5.6-sol at any reasoning effort, when the user names GPT-5.6 Sol or Sol Ultra as the agent, after terse continuations such as continue/do all, after compaction or correction, and whenever review/plan/code/publish/live boundaries could be crossed.

/sg-mission-lock — Mission And Authority Guard

Purpose

Keep the agent on the outcome the user actually requested. This skill controls mission, scope, and authority only; it does not replace planning, review, domain, testing, or shipping skills.

Priority

Run before every other skill, delegation, plan, or mutation when triggered. Do not create a goal pack, committee, or new workstream merely to record the lock.

Create The Lock

Before the first non-trivial action, extract and expose one concise checkpoint:

• Objective: the observable outcome requested.
• Mode: answer, read-only, review plus plan, code, publish, or operations/live.
• Authority: mutable files and systems; use none for read-only work.
• Scope: the current mission and directly required branches.
• Deliverable: answer, review, plan, code, evidence, publication, or runtime result.
• Done: observable evidence that ends the mission.
• Out-now: items excluded from this mission, without banning them project-wide.
• Next: the smallest action that advances Done.

Authority capabilities are non-transitive: READ, DOCS, CODE, PUBLISH, and OPS/LIVE must be granted separately. A later capability never inherits unrelated mutation rights. If exact mutable paths are unknown, inspect read-only first and do not mutate until scope is specific.

Apply Authority Precedence

Use this order:

1. System, developer, tooling, safety, and managed constraints.
2. Applicable repository instructions.
3. Latest explicit user clarification.
4. Earlier explicit user constraints not explicitly replaced.
5. Active user-created goal.
6. Handoffs and plans as context.
7. Technical findings and agent suggestions.

A lower item may not broaden a higher item. Higher-priority constraints may narrow work but do not create user authorization for external mutation. A DEVIATION notice describes a permitted method change; it never creates permission.

Interpret Continuations Conservatively

continue, do all, finish, go, proceed, and equivalents continue only the locked mission. They never raise authority or change review into code, code into publish, or read-only runtime work into writes.

If Done was already met, several branches are plausible, or continuing needs a higher mode, report completion and ask one concise question before any mutation.

Gate Every Action

Before mutation, delegation, or scope expansion:

1. Compare the action with Objective, Mode, Authority, Scope, Deliverable, and Done.
2. Classify it as direct, adjacent, or unrelated.
3. Execute direct work only.
4. Report adjacent findings in the current response only; create no file, issue, or ticket without DOCS or PUBLISH authority.
5. Ignore unrelated opportunities.
6. Ask before changing mode, external state, ownership, objective, or authority.

To claim adjacent work blocks Done, name the exact acceptance condition that cannot pass and the evidence of failure. Suspicion, usefulness, cleanup value, or future risk is not proof.

Keep one locked mission. Parallel branches are allowed only when each directly advances Done, is disjoint or safely coordinated, and inherits the same lock. Every delegated task must repeat the Objective, Mode, Authority, and mutation limits. Subagent findings are evidence, not authority.

Preserve Mode

Read-only

Inspect and report. Do not patch code, tests, configuration, guidance, or runtime state.

Review plus plan

Inspect product files read-only. Default to chat-only; write a review, plan, or handoff file only when the user or applicable repository instruction explicitly requires a durable artifact. If the user forbids code or commands, include neither code, pseudocode, nor command blocks.

Code

Modify only the locked product scope. Existing local tests, builds, and ephemeral test processes are verification only when they install nothing, restart no shared service, touch no persistent data, and update no snapshots or artifacts outside scope. Do not infer permission for commit, push, PR, publish, deploy, live migration, data repair, deletion, or external writes.

Publish

Confirm the exact files, branch, remote, commit, and review target. Code authority alone does not authorize publication.

Operations or live

Name the external mutation, target, rollback boundary, and authority before acting. Never derive live authority from an implementation request.

Handle Resume And Compaction

After resume, restart, steering, compaction, or terse continuation:

1. Reconstruct the lock from the active goal and latest explicit user messages.
2. Inspect current state only as needed.
3. Do not adopt handoff “next actions” as user authorization.
4. Re-emit the lock before mutation.
5. State the current result, remaining locked work, and next smallest step.

Reconstruction may update observed state, evidence, and Next. It must not broaden Objective, Mode, Authority, Scope, Deliverable, Done, or Out-now without an explicit user statement.

If transcript and handoff disagree, the transcript wins.

Handle Corrections

On the first correction, stop the derived branch, restate the corrected lock, preserve useful work, and continue only inside the corrected authority. Do not delete or rewrite recovery work by default.

Count a material correction when the user explicitly says the current Objective, Mode, Scope, Authority, or chosen branch was wrong. Ordinary implementation feedback, bug reports, preferences, or acceptance-criteria refinements do not count. The count lasts until Done or a new mission.

On a second correction in the same mission, enter read-only recovery: inspect the conversation or goal, inventory mutations and ownership, emit a candidate lock, and wait for explicit user confirmation before further mutation. If that correction itself supplies a complete unambiguous lock and explicitly directs continuation without raising authority, re-emit it and proceed.

Treat “I do not care about X” as removing X from current priority, not banning X project-wide. Backup, migration, deployment, parallelism, mocks, or synthetic tests may appear when explicitly requested or evidenced as relevant; never invent them as permanent requirements or prohibitions.

Bound Evidence And Closure

Label proof as static inspection, unit/mock/synthetic/fault injection, integration, or public/live workflow. Evidence proves only its layer.

Never say done, no blocker, safe, fully verified, or final while a named critical path remains unknown. State what is proven and what is NOT VERIFIED.

When the session mutated state or recovered from drift, the final receipt must distinguish cumulative session mutations from the final slice, preserved work, unperformed work, evidence, and residual unknowns. Do not burden purely read-only answers with a mutation inventory.

Recover From Drift

If work occurred outside the lock:

1. Stop new mutations and disclose the divergence.
2. Inventory affected paths; separate known ownership from Unknown.
3. Classify work as keep, adjust, continue, remove, or unknown.
4. Do not delete recovery work without explicit authority.
5. Return to the locked deliverable.

Hook And Invocation Contract

The ShipGuard hook injects this requirement for the gpt-5.6 and gpt-5.6-sol slugs at any reasoning effort and when a prompt explicitly names GPT-5.6 Sol or Sol Ultra. The hook adds developer context; it does not modify files or maintain hidden state. Codex skips untrusted plugin hooks, so users must review and trust it after installation. Implicit invocation is fallback, not guarantee.

Read references/scenarios.md only when maintaining or forward-testing this skill.