Receber por email
← Voltar para o catálogo

aria-knowledge

Close out a session cleanly when the work is done — no passoff intended. Reviews session work, updates PROGRESS.md / CLAUDE.md / memory, commits changes, captures session knowledge via /extract, and confirms everything is wrapped up, captured, and documented. Use when the task is complete and nothing needs to carry into a next session — not for passing work off to a future session or coworker. Tri

16estrelas
Atualizado há 3 meses

Ver no GitHub ↗ Licença: NOASSERTION

Como adicionar

/plugin marketplace add mikeprasad/aria-knowledge

O comando exato pode variar conforme o repositório. Confira o README no GitHub.

Para o autor da skill

Cole no README do seu repo

Mostra que sua skill está catalogada na Skillteca, gera backlink e tráfego rastreável.

[![Skillteca](https://www.skillteca.com.br/api/badge/aria-knowledge-ms619ms2/svg)](https://www.skillteca.com.br/skills/aria-knowledge-ms619ms2)
#ai

Skills relacionadas

Ver todas de Desenvolvimento →

Alerta por categoria

Receba novas skills de Desenvolvimento toda segunda

1 email curto, só com as skills novas de Desenvolvimento. 4 minutos de leitura, sem spam, cancela com 1 clique.

Você confirma o email no primeiro envio. Sem spam. Cancela com 1 clique.

Ler descrição completa

/wrapup — Session Close-Out

Close out the current session cleanly: review what got done, update project tracking files, commit changes, capture session knowledge, and confirm everything is documented. This is the "I'm done" skill — no next-session opener is produced. For passoff (future-you or a coworker), use /handoff instead.

Three modes:

  • Default (/wrapup) — Per-step gated review. Each tracked surface (session summary, PROGRESS, CLAUDE.md, memory, commit, /extract prompt) prompts for explicit confirmation before writing.
  • auto (/wrapup auto) — Implicit-yes on all gates. Run silently. Apply all drafts and chain /extract without confirmation. Emit final report only. Use when the session is short and unambiguous, or when you've already authorized a combined-go (yes to all, yes to all with extract).
  • snap (/wrapup snap) — Like auto, but archives the raw transcript via /snapshot for later extraction instead of running /extract now. Use when context is high: you still get the full silent close-out + commit, but defer the expensive, compaction-risky knowledge synthesis to a later session (or the next /audit-knowledge digest pass, which reads the snapshot automatically).

snap is auto plus one swap. Everywhere a step below says "If mode = auto (or snap)", snap follows auto's behavior exactly — implicit-yes, silent, apply all drafts, no per-step prompts. The single difference is the capture step (Step 8): snap runs /snapshot (archive the transcript for later) while auto runs /extract (synthesize now). Nothing else differs.

Step 0: Resolve Config and Parse Mode

Read ~/.gemini/antigravity/aria-knowledge.local.md and extract knowledge_folder. If the file doesn't exist, stop: "aria-knowledge is not configured. Run /setup to get started."

Parse the argument:

  • No arg, or arg is empty → mode = gated (default)
  • Arg matches auto (case-insensitive) → mode = auto
  • Arg matches snap (case-insensitive) → mode = snap
  • Any other arg → stop: "Unknown argument '{arg}'. Use '/wrapup', '/wrapup auto', or '/wrapup snap'."

Use {knowledge_folder} as the base path for all file operations in subsequent steps.

Step 1: Identify Project Context

Detect the active project by scanning the working directory for project markers:

  1. Search upward from cwd for PROGRESS.md and CLAUDE.md files
  2. Also check for CODEMAP.md (indicates a mapped codebase)
  3. Check for project-level memory files in ~/.gemini/antigravity/transcripts/ matching the current path

Multi-project-root disambiguation (required for correct SESSION.md placement): if the upward search resolves to a multi-project/workspace root — e.g. ~/Projects, or any directory whose CLAUDE.md indexes multiple child projects rather than describing one project, and which has no project-specific PROGRESS.md — do NOT treat that root as the project (writing SESSION.md there would be wrong). Instead infer the active project from this session's actual work: the files edited, the repos committed to, or the project the user named. Use that project's own root (its nearest CLAUDE.md/PROGRESS.md) for every per-project write, especially SESSION.md. This mirrors the SessionStart re-entry instruction's "which project" signal. If the session genuinely spans no single project, skip the SESSION.md write (Step 6.5) and note it.

Record:

  • Project root — the directory containing PROGRESS.md and/or CLAUDE.md
  • PROGRESS.md path — if it exists
  • CLAUDE.md path(s) — root-level and any subfolder-level ones relevant to the session
  • Memory files — any project_*.md files in the Claude memory directory for this project path
  • Git repos — run git status in any git repositories within the project to detect uncommitted changes

If no PROGRESS.md or CLAUDE.md is found, note this — the session may be in a project that doesn't use these conventions. Continue with the steps that are applicable.

Step 2: Review Session Work

Summarize what was accomplished in this session:

  1. Files changed — list files created, modified, or deleted during this session (from conversation context, not git — git may include changes from before this session)
  2. Key decisions — architectural choices, design decisions, approach selections made during the session
  3. Current state — what's working, what's in progress, what's blocked
  4. Next steps — what the user indicated should happen next, or what logically follows

Present this summary to the user:

## Session Summary

**Project:** [project name/path]
**Focus:** [1-line description of session goal]

**Work completed:**
- [bullet list of what was done]

**Decisions made:**
- [bullet list of key decisions]

**Next steps:**
- [what follows from here]

If mode = auto (or snap): skip the prompt and proceed with the drafted summary as-is.

Otherwise (gated mode): Ask: "Does this summary look right? (yes / edit)"

If the user wants to edit, incorporate their corrections before proceeding.

Step 3: Update PROGRESS.md

If a PROGRESS.md exists for this project:

  1. Read the current PROGRESS.md
  2. Check if a session entry already exists for today's work (the user or a previous /wrapup may have already added one)
  3. If no entry exists, draft a new session entry using the project's existing format (match the heading style, content structure, and level of detail of previous entries)
  4. Show the draft to the user

If mode = auto (or snap): append the drafted entry without prompting (equivalent to yes).

Otherwise (gated mode): Ask: "Add this session entry to PROGRESS.md? (yes / edit / skip)"

  • yes — append the entry
  • edit — let the user modify, then append
  • skip — leave PROGRESS.md as-is

If PROGRESS.md doesn't exist, skip this step and note it in the final report.

Step 4: Check CLAUDE.md Currency

If a CLAUDE.md exists for this project:

  1. Read the CLAUDE.md
  2. Check if anything from this session contradicts, outdates, or is missing from it — examples:
  3. New conventions established that aren't documented
  4. File paths or structures that changed
  5. Known issues that were resolved or new ones discovered
  6. Tool/integration changes
  7. If updates are needed, show the proposed changes

If mode = auto (or snap): apply the drafted CLAUDE.md updates without prompting (equivalent to yes). If no updates are needed, note that in the final report and move on.

Otherwise (gated mode): Ask: "Update CLAUDE.md with these changes? (yes / edit / skip)"

If no updates are needed, say so and move on. Don't force updates for the sake of updating.

Step 5: Update Memory

Check if project memory files (in ~/.gemini/antigravity/transcripts/ for the current project path) need updating:

  1. Read the relevant project_*.md memory file(s)
  2. Compare against the session summary — is the memory's "Current State" still accurate?
  3. If the memory is stale, draft an update

If mode = auto (or snap): apply the drafted memory update without prompting (equivalent to yes). If no memory file exists or no update is needed, note that in the final report and move on.

Otherwise (gated mode): Ask: "Update project memory? (yes / edit / skip)"

If no memory file exists or no update is needed, skip and note it.

Step 6: Commit Prompt

For each git repository detected in Step 1:

  1. Run git status to check for uncommitted changes
  2. If there are changes, show a summary:

``` Uncommitted changes in [repo path]:

  • [N] modified files
  • [N] new files
  • [N] deleted files

[list the file names] ```

If mode = auto (or snap): stage all changes (per-file, not git add -A — exclude anything that looks like a secret or unrelated work-in-progress), draft a conventional commit message from the session work, and commit without prompting. Skip the message-confirmation step. Still **local commit

Compartilhar X LinkedIn