From dev-workflow
Review the current session for learnings and self-improvement signals. Surfaces memory candidates and improvement opportunities for user-confirmed application. Use after completing work to review the session for learnings and improvement signals.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dev-workflow:dev-wrapupThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Review the current session for learnings worth persisting and self-improvement signals.
Review the current session for learnings worth persisting and self-improvement signals.
This skill analyzes and suggests. It does NOT apply changes without explicit user confirmation.
Run the discovery script:
bash "$DISCOVER" root
Where $DISCOVER is the absolute path to scripts/discover.sh within this skill's directory.
Path safety — shell state does not persist between tool calls, so you must provide full script paths on each call:
$HOME instead of the literal home directory (e.g., bash "$HOME/code/…/discover.sh", not bash "/Users/name/…/discover.sh"). This prevents username hallucination.$PROJECT_ROOT), copy it verbatim from that command's output. Never retype a path from memory.Store the output as $PROJECT_ROOT. If the command fails, inform the user and stop.
Before analyzing, read these files to avoid surfacing items already documented:
$PROJECT_ROOT/CLAUDE.md (or equivalent project docs: AGENTS.md, GEMINI.md) — whichever exists, store its name as $PROJECT_DOCS for use in routing targets later$PROJECT_ROOT/.claude/rules/ (or equivalent scoped rules directory) — if it exists, read all files in the directory; store the path as $SCOPED_RULES_DIR$PROJECT_ROOT/CLAUDE.local.md (or equivalent personal project docs) — if it exists, store its path as $PERSONAL_PROJECT_DOCS~/.claude/CLAUDE.md (or equivalent user global docs) — if it exists, store its path as $USER_GLOBAL_DOCSCheck if $PROJECT_ROOT/.dev/wrapup-feedback.json exists. If it does, read it and analyze the patterns before scanning the conversation.
The feedback file contains records from previous wrapup sessions. It can exist in two formats:
Simple format (early sessions) — a flat array of session records:
[ { "session": "...", "findings": [...] }, ... ]
Compacted format (after 30+ sessions) — aggregate stats plus recent raw records:
{
"aggregate": {
"sessions_summarized": 35,
"total_findings": 142,
"skip_rates": { "convention": 0.82, "friction": 0.65, "gotcha": 0.25 },
"accept_rates": { "preference": 0.88, "gotcha": 0.70 },
"reroute_map": {
"gotcha→scoped_rules": { "actual": "user_global", "frequency": 0.85 },
"convention→project_docs_add": { "actual": "personal_memory", "frequency": 0.60 }
}
},
"recent": [ /* last 20 raw records */ ]
}
If the file has ≥30 raw records (simple format), compact it before proceeding:
skip_rates: for each finding type, count skips ÷ total proposalsaccept_rates: for each finding type, count accepts ÷ total proposalsreroute_map: for each type→proposed_dest pair that was rerouted more than once, record the most common actual_dest and its frequencysessions_summarized: number of sessions folded into the aggregatetotal_findings: total findings across summarized sessionsrecentIf already in compacted format and recent has ≥30 records, re-compact:
recent (first 10 in the array)aggregate:
skip_rates and accept_rates as weighted averages: (old_rate × old_total + new_count) / (old_total + new_total) for each finding typereroute_map — if a new reroute pattern emerges or an existing frequency changes, update itsessions_summarized and total_findingsrecent, leaving the 20 most recentIf already in compacted format and recent has <30 records, no compaction needed — use as-is.
Extract these patterns (from whichever format is present):
skip_rates or computed from raw records), treat it as low-value and raise the bar significantly before proposing that type again. Only propose it if the finding is exceptionally specific and actionable.reroute_map from aggregate or compute from raw records. If gotcha → scoped_rules gets rerouted to user_global most of the time, default to user_global for that type going forward.Store the extracted patterns as $FEEDBACK_PATTERNS for use in Step 3.
If the feedback file does not exist, proceed normally — this is the first wrapup session or feedback tracking hasn't started yet.
Verify the conversation contains substantive exchanges (at least one user message and one assistant response beyond the skill invocation itself). If the conversation history appears empty or contains only the skill invocation, state: "No conversation history available to review. Run this skill at the end of a working session, not at the start." and STOP.
Review the full conversation history for findings worth persisting or acting on. If the session was short or routine with nothing notable, state "Nothing to report from this session." and stop.
What to scan for:
Quality filters — apply strictly:
.dev/) count as existing documentation only if they are git-tracked (not gitignored). If the PRD directory is gitignored, findings documented there are transient and should still be routed to persistent project docs.For each finding, assign a type and a destination.
Finding types:
| Type | Description |
|---|---|
convention | Coding style, naming, architecture patterns |
preference | User workflow choices, stated preferences |
fact | Project-specific knowledge |
gotcha | Pitfalls or workarounds |
friction | Repeated manual steps or slowdowns |
mistake | Errors made and corrected |
skill-gap | Knowledge the assistant lacked |
automation | Repetitive patterns that could become scripts |
Destinations:
Every AI coding tool offers similar tiers of persistent documentation. This skill uses general concepts mapped to tool-specific paths:
| Destination | What belongs here | Claude Code | Codex | Gemini CLI |
|---|---|---|---|---|
| Project docs (update) | Corrections to existing team documentation | CLAUDE.md edit | AGENTS.md edit | GEMINI.md edit |
| Project docs (add) | New team knowledge: conventions, architecture, operations, gotchas | CLAUDE.md add | AGENTS.md add | GEMINI.md add |
| Scoped rules | Invariants tied to specific files; forgetting risks silent breakage | .claude/rules/<topic>.md | subdirectory AGENTS.md | subdirectory GEMINI.md |
| User global | Personal preferences that apply across ALL projects | ~/.claude/CLAUDE.md | ~/.codex/AGENTS.md | ~/.gemini/GEMINI.md |
| Personal project | Private, ephemeral, or machine-specific project context | CLAUDE.local.md | — | — |
| Personal memory | AI self-notes: non-instructional observations about user or project | auto memory | — | save_memory |
Decision tree — evaluate in order, stop at first match:
Routing guard rails:
Feedback-adjusted routing — If $FEEDBACK_PATTERNS exist from Step 1b, apply them now:
type → destination pair matches a known reroute pattern. If so, use the user's historical preferred destination instead.Self-check — After routing all findings, review once before presenting:
Routing examples:
| Finding | Correct | Why |
|---|---|---|
"Tests must run with --no-cache flag" | Project docs (add) | Operational instruction the team needs |
| "User prefers small, incremental commits" | User global | Cross-project personal preference |
| "Payment module silently swallows errors in catch blocks" | Scoped rules | File-tied gotcha; forgetting causes bugs |
"User corrected: use pnpm not npm" | Project docs (update or add) | Team should know the package manager |
"Flaky test in auth.spec.ts caused by timezone mismatch" | Personal memory | Debugging context, not an instruction |
| "Always run migrations before seeding" | Project docs (add) | Operational instruction, not a personal note |
If no findings, state: "Nothing to report from this session." and skip to the summary.
Present findings in two parts:
Part A — Detailed Analysis: For each finding, write a short paragraph explaining what happened, why it matters, and the proposed action. Number each finding.
Session Findings:
1. [Title] (
type→destination) [2-3 sentence explanation of what happened, why it matters, and what to persist or do.]2. [Title] (
type→destination) [2-3 sentence explanation...]
Part B — Recap Table: After the detailed analysis, present a summary table:
# Type Finding Destination Target 1 gotcha [Short description] Project docs (update) $PROJECT_DOCS2 convention [Short description] Scoped rules $SCOPED_RULES_DIR/naming.mdWhich items would you like to apply? Reply with the numbers (e.g., "1, 3"), "all", or "none" to skip.
STOP. Wait for the user to select items before proceeding.
For each confirmed item, apply based on its destination:
Project docs (update) items:
$PROJECT_DOCS[old] to [new] in [section]"Project docs (add) items:
$PROJECT_DOCS[content]"Scoped rules items:
$SCOPED_RULES_DIR/<topic>.md existspaths: frontmatter scoped to relevant files/directories)Scoped rules (update) items:
User global items:
$USER_GLOBAL_DOCS exists
[path] does not exist. This item requires creating it. Proceed?" Wait for confirmation before creating.$USER_GLOBAL_DOCSPersonal project items:
$PERSONAL_PROJECT_DOCS exists
[path] does not exist. This item requires creating it. Proceed?" Wait for confirmation before creating.$PERSONAL_PROJECT_DOCSPersonal memory items:
Automation items:
After applying, confirm: "Applied [N] items. [M] automation suggestions noted for future work."
After the user has made all their decisions (accept, skip, reroute, or "none"), append a feedback record to $PROJECT_ROOT/.dev/wrapup-feedback.json.
If the file doesn't exist, create it with an empty array [] first.
Feedback record schema:
{
"session": "YYYY-MM-DD",
"findings": [
{
"type": "convention",
"summary": "Short description of the finding",
"proposed_dest": "project_docs_add",
"decision": "accept",
"actual_dest": "project_docs_add"
},
{
"type": "gotcha",
"summary": "Short description of the finding",
"proposed_dest": "scoped_rules",
"decision": "reroute",
"actual_dest": "user_global"
},
{
"type": "friction",
"summary": "Short description of the finding",
"proposed_dest": "project_docs_add",
"decision": "skip",
"actual_dest": null
}
]
}
Field values:
decision: one of accept, skip, rerouteproposed_dest: the destination the skill originally proposed, using these keys: project_docs_update, project_docs_add, scoped_rules, user_global, personal_project, personal_memory, automationactual_dest: the destination the user confirmed (same keys), or null if skippedsummary: a brief description of the finding (no sensitive data, no absolute paths)Append the new record to the existing array. Do not overwrite previous records — the history is the learning signal.
If the user replied "none" (skipped all findings), still record the feedback with all findings marked as skip. This is valuable negative signal.
Report what was accomplished:
Session wrap-up complete.
- Items applied: [N] items to [list destinations touched]
- Automation ideas: [M] noted for future work (or "none")
- Files modified: [list each file that was changed, or "none"]
NEVER include in any destination file:
<API_KEY>, $ENV_VAR)npx claudepluginhub andreaserradev-gbj/dev-workflow --plugin dev-workflowAnalyzes Claude Code sessions to improve CLAUDE.md instructions and capture learnings. Quick mode suggests CLAUDE.md tweaks; deep mode reviews problems, patterns, preferences, and gaps.
Extracts reusable rules from developer corrections during a coding session and persists them to CLAUDE.md or memory for future sessions.
Reflects on the current Claude Code session to produce a structured retrospective with what went well, what didn't, and actionable takeaways.