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-ms61ai1p/svg)](https://www.skillteca.com.br/skills/aria-knowledge-ms61ai1p)
#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.

Runtime Gate (per ADR-094)

Canonical resolution: This is the Claude Code variant. When both plugin-claude-code and plugin-claude-cowork are loaded in the same session (most common in Claude Desktop), bare /wrapup resolves to this skill — aria-knowledge (Code) is the canonical owner of all 24 dual-port skills per ADR-094 §Part 1. The Cowork variant is namespaced-only: /aria-cowork:wrapup.

Before Step 0: Check that the Bash tool is available in this session. If Bash is NOT available (you are running in Claude Cowork or another non-Code runtime), surface the following notification and wait for explicit user confirmation:

⚠️ Runtime mismatch — you invoked aria-knowledge's /wrapup from a non-Code runtime.
This variant runs git status / git commit via Bash, which isn't available here. For the Cowork-native variant (emits a copy-paste commit message instead, skips ADR-005 tracked-artifacts check), use /aria-cowork:wrapup.
Use /aria-cowork:wrapup instead? (y / n)

Wait for an explicit reply:

  • y / yes — Use the Skill tool to invoke aria-cowork:wrapup with the same arguments the user provided to this invocation. Do not proceed with this skill's steps; the cowork variant takes over and runs to completion. This is the default-yes path — auto-redirect is the helpful action.
  • n / no — Proceed with this (aria-knowledge) variant anyway despite the runtime mismatch. The user has explicitly opted in.
  • No response / any other reply — Treat as "do not proceed" and exit cleanly without running either variant.

This gate applies even when mode = auto or mode = snap per ADR-094 §Part 3. Auto/snap's "implicit-yes on all gates" rule is suspended for the runtime-mismatch check — they trust that the user invoked the correct variant, and this gate enforces that precondition. All other auto/snap-mode gates remain bypassed. The friction cost is now low: on y, the auto-redirect runs the correct variant with the original args. (snap especially depends on Bash — its /snapshot capture step runs save-transcript.sh — so the gate is load-bearing for snap.)

If Bash is available, proceed to Step 0.

Step 0: Resolve Config and Parse Mode

Read ~/.claude/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 ~/.claude/projects/ 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

Compartilhar X LinkedIn