agentleFS
Magnus-GilleMagnus-Gille/claude-skills/close/SKILL.md

close

Skill5 starsChanged 33 days agoMITView on GitHub

Close a coding-agent session or produce its final handoff only when the user explicitly asks to close, wrap up, or produce an end-of-session handoff.

26 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use open, reconcile and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • BlockSkill

    open

    Open markdown documents in Penpal for collaborative review. Use when you want a human to review a document, plan, or research artifact.

    Also in 5 projects that use this

  • howellsSkill

    reconcile

    Audit a project against current plugin conventions and offer to update structure.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    validate

    Run the full CI validation workflow locally before submitting a PR. Use this as a final check to ensure all Azure DevOps CI pipeline steps will pass.

    Also in 4 projects that use this

  • AnthropicSkill

    start

    Set up your bio-research environment and explore available tools. Use when first getting oriented with the plugin, checking which literature, drug-discovery, or visualization MCP servers are connected, or surveying available analysis skills before starting a new project.

    Also in 6 projects that use this

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 8 projects that use this

  • OpenAISkill

    bootstrap

    Project bootstrapping orchestrator for repos that depend on Vercel-linked resources (databases, auth, and managed integrations). Use when setting up or repairing a repository so linking, environment provisioning, env pulls, and first-run db/dev commands happen in the correct safe order.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 0 are common, 15 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 21 edited versions we read keep these.

  • 15

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When execution state or project truth changed, read persistence.

    line 11
  2. Distinctive:

    Only for personal notes/workspaces with capture/tasks conventions, read personal-workspace.

    line 12
  3. Distinctive:

    All script paths are relative to the skill root.

    line 16
  4. Distinctive:

    Check if session work requires documentation updates:

    line 20
  5. Distinctive:

    Before reviewing skill improvements, check whether any significant work product from the session exists only in conversation context and …

    line 37
  6. Distinctive:

    If anything is only in the conversation, write it to a file now.

    line 44
  7. Very specific:

    Before deleting any worktree, run git -C <worktree-path> status --short --branch.

    line 70
  8. Distinctive:

    Do not delete dirty worktrees.

    line 71
  9. Distinctive:

    If GitHub API/network is unavailable, document that PR-state verification was skipped rather than guessing.

    line 72
  10. Distinctive:

    Delete disposable cache only when authorized and not needed for resumption.

    line 78
  11. Distinctive:

    Never delete the sole copy of benchmark, incident, or disclosure evidence without approval.

    line 79
  12. Distinctive:

    If deletion is authorized, verify absence without echoing private contents.

    line 82
  13. Distinctive:

    Update the canonical skill source and reconcile installed copies within the authorized task.

    line 86
  14. Distinctive:

    After all mutations and the stable final concurrency comparison, assemble the JSON record described in report-contract, render it, delete …

    line 92
  15. Distinctive:

    Use the same bounded affected-repository set and refresh each tracking remote before classifying status.

    line 101
  16. Distinctive:

    When code-friction capture is explicitly enabled, quick mode may flush records already prepared in the local outbox.

    line 110

“Common” is measured: kept by at least 6 in 10 of the 21 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Close a session

Audit only repositories affected by this session, preserve unrelated work, and complete the authorized handoff. An ordinary reply is not a session close. A close does not authorize publication, deployment, credential operations, or destructive cleanup.

  • For Git/worktree scope, snapshot exceptions, and the mandatory final concurrency check, read git-audit.
  • When execution state or project truth changed, read persistence. Skip state rewrites for read-only inspection.
  • Only for personal notes/workspaces with capture/tasks conventions, read personal-workspace.
  • For every close, read report-contract and return scripts/render-report.py output verbatim. Preserve all fields in quick mode; missing evidence is not a clean result.
  • For explicitly enabled code-friction capture, read code-friction. Full Close may prepare a terminal assessment; quick Close only flushes records already in the local outbox.

All script paths are relative to the skill root. Preserve a reversal recipe and audit event for mutations where required by project policy.

Documentation Review

Check if session work requires documentation updates:

  • AGENTS.md / CLAUDE.md - folder structure, workflows, MCP integrations, skills
  • Skill SKILL.md files - if skill behavior changed
  • README files - in relevant folders
  • Operational/configuration docs - if runtime, deployment, or client assumptions changed
  • Living / generated artifacts - if the project's canonical instruction file defines maintained artifacts (e.g. a generated site/ of HTML status pages, dashboards), follow its documented update contract and refresh them to reflect this session's work. Skip if this session changed no project state.

Questions to consider:

  • Did we add new folders? → Update the repository's canonical instruction file
  • Did we add/modify skills? → Update the canonical instruction file's skills section
  • Did we change workflows? → Update relevant docs
  • Did production/runtime behavior change? → Update deployment or client docs and record config drift
  • Did deployment copy local-only files, require manual cleanup, or change rsync/exclude behavior? → Document the operational fix or verified cleanup location.
  • Does the canonical instruction file define living artifacts (e.g. site/)? → Apply their documented update contract

Unsaved Plans & Artifacts

Before reviewing skill improvements, check whether any significant work product from the session exists only in conversation context and hasn't been persisted to a file:

  • Implementation plans produced by the /plan skill or a Plan agent — save to a plan.md or *-plan.md file in an appropriate location (e.g., debate/, docs/, repo root).
  • Research summaries that aren't already written to your notes/research directory.
  • Decision write-ups that aren't in Munin or a committed file.
  • Debate documents (if the debate-claude skill ran) — verify debate/*-summary.md and debate/*-critique-log.json were written; the raw files are gitignored but summaries and critique logs should persist.

If anything is only in the conversation, write it to a file now. Ask the user where to save if the right location is unclear.

Skill Improvements

Review session for potential skill enhancements:

  • Did we repeat a pattern that could be automated?
  • Did a skill's instructions prove incomplete or unclear?
  • Did we discover better approaches mid-session?

If improvements identified:

  • Note them for the user
  • Offer to update the skill now

Cleanup

Check for:

  • Temporary files to delete
  • Privacy-sensitive temporary artifacts: recordings, transcripts, screenshots, exported mail, settings/config backups, credentials, or user-data samples
  • Test files that shouldn't be committed
  • Stale branches that can be deleted or documented
  • Stale PR worktrees that can be removed or documented
  • Dirty secondary worktrees that must be left untouched and called out

Stale PR cleanup guidance:

  • For squash-merged PRs, use GitHub PR state as the source of truth; the local branch may not be merged by Git ancestry.
  • Before deleting any worktree, run git -C <worktree-path> status --short --branch.
  • Do not delete dirty worktrees. Document exact path and changed files under pending notes.
  • If GitHub API/network is unavailable, document that PR-state verification was skipped rather than guessing.

Temporary artifact guidance:

  • Inventory only artifacts created or consumed in the session; do not sweep unrelated temp trees.
  • Classify each as disposable build/cache data, reproducibility evidence, or privacy-sensitive data.
  • Delete disposable cache only when authorized and not needed for resumption.
  • Never delete the sole copy of benchmark, incident, or disclosure evidence without approval.
  • Without explicit cleanup authorization, retain privacy-sensitive artifacts, report their bounded paths and aggregate size where useful, and request a deliberate keep/delete decision.
  • If deletion is authorized, verify absence without echoing private contents.

Skills Repo Sync

Update the canonical skill source and reconcile installed copies within the authorized task. Preserve intentional harness adapters; inspect unique behavior before replacing any copy with a symlink. Do not modify unrelated installations.

A close or local skill edit does not authorize publication. Commit only scoped changes under the owner's existing authority; push or create a PR only with an explicit owner request and exact target/diff preview, following the repository's branch policy. Report pending publication without blocking an otherwise complete local close.

Render the final report

After all mutations and the stable final concurrency comparison, assemble the JSON record described in report-contract, render it, delete the JSON, and return stdout verbatim. Internal checklist detail, commands, tool logs, discarded alternatives, and potential skill ideas do not belong in the final response unless they produce a concrete warning or pending action.

Quick Mode

/close quick only checks:

Use the same bounded affected-repository set and refresh each tracking remote before classifying status.

  1. Git snapshot for explicitly designated snapshot-mode repos; otherwise audit Git state and run /commit only when committing is already authorized
  2. Dirty secondary worktree warning (git worktree list plus git -C <path> status --short --branch)
  3. Local state file update only for substantive execution-state changes; skip read-only inspection
  4. Final fetch plus final-recheck.sh compare; reconcile once or report active concurrent work
  5. Canonical rendered report using mode: "quick"; all sections remain present

When code-friction capture is explicitly enabled, quick mode may flush records already prepared in the local outbox. It creates no new observation or assessment. This evidence is advisory; report local or remote save status only in the existing Persistence section and do not change Close status or readiness fields because of it.

Skip documentation review, skill improvements, project status updates in Munin, and detailed cleanup. The explicitly enabled code-friction outbox flush above is the only quick-mode Munin write.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.