Audit, Scope, Verify, Hand Off: A Working Checklist for ChatGPT Work Tools and Skills

The operating model

Inventory available tools and skills before the first prompt. The scope gap is that the operator does not know what the session can call, what the task requires, or how to prove the result.

Work tools and skills are different objects. Tools are callable endpoints; skills are reusable instruction packages that guide how those tools are used. The reference snapshot contains 232 tool interfaces and 44 complete main skill files. Availability can vary by session context, including configuration, permissions, connected apps, and installed plugins.

Stop prompting from memory. Run a session-level checklist. It should cover what is available, what the task is, what the prompt must contain, how the output is verified, and how the work is handed off.

The five-step session checklist

1. Inventory available tools and skills. Before the first prompt, list the tools the session can call and the skills it can load. Do not assume a capability exists because it exists in another workspace. Record the name, the expected input, and the expected return. If a skill page is available, read the definition before use. Skill pages reproduce their complete current SKILL.md source.
2. Classify the task as endpoint call or skill execution. An endpoint call is narrow. It asks for one tool result, one command, one lookup, or one file change. A skill execution is broader. It uses a reusable instruction package to shape a multi-step job. If the task mixes both, split it. Put the endpoint call in one step and the skill-driven workflow in another. This keeps the prompt auditable.
3. Scope the prompt with input, expected artifact, and verification method. The prompt should name the input, the output, and the test. Input means the exact files, data, constraints, and permissions. Expected artifact means the report, patch, command output, ticket update, or summary. Verification method means how you will confirm the result. A prompt without a verification method is a request for confidence, not evidence.
4. Verify output before accepting the result. Verification depends on the tool. The exec_command tool runs a command in a PTY and returns output or a session ID, so treat the returned ID as an open handle, not a finished result. The apply_patch tool can edit files in freeform and should not be wrapped in JSON. If the result is a summary, verify the source. If the result is a command, verify the command result. If the result is a patch, verify the changed lines.
5. Hand off with artifact, owner, next workflow step, and rollback note. A completed task is a transfer, not a chat message. The rollback note should say what to undo if the change fails. If you cannot write the rollback note, the task is not ready to ship.

Rules that keep the checklist honest

• Do not let a confident answer replace verification. The operator needs an artifact, not a tone.
• Do not let a long prompt hide a missing test. If the prompt cannot say how the result will be checked, rewrite it.
• Do not let an open session become a placeholder for completion. An open session is a state, not a deliverable.
• Do not let a patch pass because it applied. A patch can apply and still break the workflow.
• Do not let handoff become a summary. The next owner needs the handoff block.

What to do when the session drifts

Stop the run. Re-read the inventory. Confirm the tool or skill is still in scope. Re-state the input, expected artifact, and verification method. If the session cannot verify the result, do not hand it off. If the session cannot roll back the change, do not mark it complete. If the task needs more than the current session can prove, split it into a smaller task and start the checklist again.

Agent operations are production work. The operator's job is to make the session auditable. Do not hand off without the handoff block.