agentleFS
Nicolas-RigaudyNicolas-Rigaudy/cr-0w/skills/wrap/SKILL.md

wrap

Skill1 starsChanged 6 days agoMITView on GitHub

End-of-session wrap-up. Saves progress, decisions and open threads into the right project docs (logics, repo handoff docs, hub state) so the next session can start fresh. Use when the user says "wrap", "wrap up", "save and close", or is about to end a session.

45 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use start, update and 9 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.
  • 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 5 projects that use this

  • AnthropicSkill

    update

    Sync tasks and refresh memory from your current activity. Use when pulling new assignments from your project tracker into TASKS.md, triaging stale or overdue tasks, filling memory gaps for unknown people or projects, or running a comprehensive scan to catch todos buried in chat and email.

    Also in 3 projects that use this

  • LangChainSkill

    remember

    Review the current conversation and capture valuable knowledge — best practices, coding conventions, architecture decisions, workflows, and user feedback — into persistent memory (AGENTS.md) or reusable skills. Use when the user says: (1) remember this, (2) save what we learned, (3) update memory, (4) capture learnings.

    Also in 3 projects that use this

  • termdockSkill

    recall

    Retrieves cross-session memories about past decisions, lessons, and patterns. Use when user asks about prior work, past decisions, or mentions a feature. Triggers include check memory, what did we decide, how did we solve.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    build

    Build the TypeSpec Rust emitter from source. Run this after cloning the repo, after pulling changes, or when TypeScript source files have been modified.

    Also in 3 projects that use this

  • SentrySkill

    spec

    Produce a verified spec — problem, desired outcome, and acceptance criteria — before building. Use when given a GitHub/Linear issue link, when starting from a fuzzy in-conversation idea, or asked to "figure out what to do" / "scope this" / "what should I build" — whenever the *what* isn't yet pinned down. Grills the ambiguities, checks the premise against the code, and produces acceptance criteria you sign off on — then hands to design-first.

    Also in 3 projects that use this

  • +1 more from anthropics

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 40 edited versions we read keep these.

  • 3

    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:

    Otherwise: update the repo's existing progress doc if there is one.

    line 27
  2. Very specific:

    Commit doc changes following the hub autonomy rules ($CROW_HOME/CLAUDE.md):

    line 29
  3. Distinctive:

    check git config user.email matches the project's scope identity first.

    line 32
  4. Distinctive:

    no AI attribution in commit messages

    line 33

“Common” is measured: kept by at least 6 in 10 of the 40 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

Wrap

Goal: after this runs, the user can close the session and a brand-new session loses nothing. Be thorough but terse. Never invent progress; only record what actually happened in this session.

1. Locate yourself

  • Hub home is $CROW_HOME. If unset, say so and stop.
  • Load $CROW_HOME/local/projects.yaml. Match the current working directory to a project by longest path prefix.
  • Mode: hub if cwd is $CROW_HOME, project if matched, unregistered otherwise (do project-mode steps with no registry info and recommend registering it).
  • State dir: the vault's vault.crow_dir if set, otherwise $CROW_HOME/local/state/.

2. Inventory the session (in your head, then show it)

From the conversation, list:

  • Done: what was completed (with commits, MRs, tickets, docs touched)
  • Decided: decisions and their reasons
  • Open: unfinished work, blockers, questions for the user, each with a concrete next step

3. Save. Project mode

Apply the first matching option, in this order:

  1. Repo has its own wrap/handoff convention (check its CLAUDE.md for "wrap", "handoff", "resume"): follow it. It wins.
  2. Repo uses logics (logics/ dir): for each request/backlog/task touched, record progress with logics-manager (e.g. flow lifecycle moves, sync append-note <doc> --section report|decision --text ...). Create no new docs unless work started that has none; then suggest one instead.
  3. Otherwise: update the repo's existing progress doc if there is one; else put everything in the hub open threads only.

Commit doc changes following the hub autonomy rules ($CROW_HOME/CLAUDE.md):

  • personal: commit (and push if the branch tracks a remote)
  • work: commit on the current branch only if it is not main; never push to main; otherwise leave the changes and report them
  • check git config user.email matches the project's scope identity first; on mismatch, don't commit, report it
  • no AI attribution in commit messages

4. Save. Always (hub state)

In the state dir:

  • activity/YYYY-MM-DD.md: append - HH:MM [project] one-line summary per notable item done (non-git work matters most: meetings, decisions, R&D, ops)
  • open-threads.md (format and rules: runbooks/open-threads.md): put each open item as one line - [ ] YYYY-MM-DD [project] text → next step under ## Me (owner acts), ## Crow (point to the Logics item if any) or ## Waiting (start with the person's name); update a line in place and re-date it when touched. An item finished this session is removed from the file in the same write and logged in activity/ as - HH:MM [project] done: text. Never write a status note here (use status.md, or decisions.md for constraints)
  • decisions.md (only for decisions with lasting impact): ## YYYY-MM-DD [project] title + 1–3 lines of why
  • status.md (hub mode, or if a project's status changed): one row per project: status, current focus, next step, blocked by

Runbooks: if the session worked out a recurring procedure, write the generic steps to runbooks/ (tracked, no project, company, person, vendor, ticket or account names) and the private specifics to local/runbooks/. Never put a private name in a tracked runbook; the pre-commit check is a backstop, not the rule.

In hub mode, also commit $CROW_HOME changes (personal rules apply), and run bin/crow-memory commit so memory saved this session lands in local/.

5. Report

End with exactly this shape, then stop:

## Wrapped: <project or hub>
Saved:     <files/docs updated, commits made>
Not saved: <anything left uncommitted or skipped, and why — or "nothing">
Next:      <the single most useful next step>
Safe to close ✅   (or ⚠️ with the reason it isn't)

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.