The user has confirmed the default policy: keep only the final output, and automatically clean up process files and duplicate delivery copies created by this task that are no longer useful. This policy is limited to resources owned by the current task; it does not expand system permissions or override the user's retention requests for the current instance. There is no need to ask again "should I clean up?".
First identify the output and ownership
The final output is determined by the user's goal: when installing a skill, it is the installation directory and necessary files; when generating a report, the report is the output; when fixing code, the source code, necessary tests, and documentation are all outputs. When the user requests a download package, the download package is also an output. Do not judge something as garbage based on extension, directory name, age, size, Git untracked status, or "can be regenerated".
Determine ownership based on this session's creation records, an explicit task list, or verified handoff information. Prefer task-specific temporary directories; maintain a minimal temporary list only when a long task needs it across stages. Do not scan the whole disk, and do not generate a permanent report just for cleanup. Files with insufficient creation records are retained by default; being located in tmp is not evidence of ownership.
Determine completion and retention boundaries
Wrap up only when the goal has been achieved, necessary verification has ended, and subsequent steps no longer need these resources. A mid-task reply, waiting for confirmation, unverified deployment, or an unresolved failure does not mean the task is complete. In such cases, retain the relevant evidence and state, and do not use the "final reply" as the basis for deletion.
- Automatically clean up: probe scripts, test directories, intermediate outputs, and process logs from this task that are no longer useful.
- Automatically clean up: production copies, ZIPs, duplicate screenshots, and auxiliary acceptance materials whose formal output has been delivered and fully verified; having provided a download link previously is not a reason for permanent retention, but the link's invalidation must be stated.
- Retain: outputs requested by the user, debugging materials explicitly requested to be kept, and files necessary for the output to run, be maintained, or be verified.
- Retain: diagnostic evidence for unresolved problems, files needed to restore the state, and backups still serving a rollback purpose. Do not automatically delete rollback safeguards even if the current round succeeded.
- Do not automatically handle: pre-existing or ownership-unclear files, other tasks' resources, shared caches, and dependencies.
- Outside the default scope: online files, external service resources, Git history, Codex session records, worktree management, and process termination. When handling is truly needed, use the dedicated tools, corresponding rules, and explicit authorization.
Only when an object that cannot be judged affects wrap-up or requires user trade-offs, ask one specific question in a single batch; handle the remaining task-owned files confirmed as useless first. No reply is not consent. Unrelated pre-existing files are simply retained, and no inquiries are created for them.
Execute with limited paths
- Generate a specific cleanup list from resources with verified ownership; first confirm that the formal output exists, is complete in content, and has passed applicable verification. For copy/install scenarios, compare content or hashes as needed.
- Check whether retained scripts, configurations, documentation, build steps, and still-running tasks depend on the candidate resources. Do not leave behind a delivery that cannot run after deletion. If it is merely a necessary dependency, retain it; if paths can reasonably be corrected within the original task's authorization, correct and verify them first, then delete the old resources.
- Before deletion, check the target and parent paths for symbolic links and the actual directory contents. When deleting a temporary link, remove only the link itself and do not traverse the shared target; if a parent path is found to jump outside the verified scope, stop that item first. Before recursively deleting a directory, you must confirm that all its contents fall within the permitted cleanup scope; retain new files of unknown origin and narrow the cleanup scope.
- Delete only the exact paths in the list. Do not use broad wildcards, bulk deletion by time, whole-disk cleanup, or recursive operations that follow links. Do not move files elsewhere to pass as cleanup, and do not create scheduled tasks on your own.
- Verify that the candidates have been removed and that deliverables and protected objects are undamaged. Report permission denials or tool failures truthfully, respect approval boundaries, and do not use other means to bypass them. A partial failure does not prevent handling other safe and authorized items.
Deliver with minimal interruption
When cleanup occurs, state the cleanup category and the retained formal deliverables in one sentence in the final reply. If links already sent have become invalid, mention that as well. Report sizes only after actual measurement, and distinguish logical file bytes from actual freed disk space; there is no need to measure additionally for small cleanups.
When there is nothing to clean up, do not output notices such as "no garbage to clean." Do not falsely report cleanup success, and do not list lengthy routine inventories. If key objects need to be retained or await user selection, state their purpose specifically; do not ask vaguely whether to clean everything.
If this skill causes something to require asking or leaves items unhandled, link this SKILL.md and point out the corresponding retention/ownership rule; distinguish skill judgments from system approval denials.
Accept this skill
Read only when creating, modifying, or evaluating skills: behavioral acceptance scenarios. Record auto-discovery, actual cleanup behavior, and whether permissions allow execution separately; auto-invocation configuration cannot prove that auto-triggering works. Triggering counts only when the skill is actually read under a natural request.