From jarvis
Reflects on completed tasks and updates project memories by writing structured journal entries and searching past lessons. Helps avoid re-learning and consolidates knowledge.
How this skill is triggered — by the user, by Claude, or both
Slash command
/jarvis:jarvis-reflectThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You just completed a task. Now pause and reflect on what happened. This is how you grow.
You just completed a task. Now pause and reflect on what happened. This is how you grow.
Run JARVIS_DIR=$(bash <skill-path>/scripts/resolve-dir.sh) to set JARVIS_DIR.
If the resolved directory doesn't exist, inform the user they need to run /jarvis-init first, then stop.
Verify the work is actually done, or the session is complete.
a) Check your memories for learned completion criteria. Read the JaRVIS memories directory for any entries about what "done" means in this project. Examples of learned criteria: "tests must pass", "code should be committed", "linting must be clean", "user expects a PR before reflecting."
b) Evaluate any criteria you found. Run the checks you can (e.g., test suite, git status, lint). Note what passed, what failed, and what you couldn't check.
c) Gate on the results: If you feel comfortable with the results and happy with your implementation, proceed to Step 2. Otherwise, note what's wrong with the implementation and either fix it or notify the user.
Create a new journal entry at $JARVIS_DIR/journal/YYYY-MM-DD-HH-MM-XXXXXXXX.md using the current timestamp and 8 random hex characters (generate with head -c4 /dev/urandom | xxd -p).
Before writing, identify the tags and task_type you'll assign to this entry, then use /jarvis-search to search past journal entries for related work using those tags. If matches exist, review the "Lessons Learned" and "What Didn't Work" sections from those entries. Use this to:
This is a lightweight step — if no relevant past entries exist or on a fresh setup with no journals, skip it and proceed.
Fill in every section honestly. Read <skill-path>/references/reflection-guide.md for detailed guidance on what makes a good vs bad reflection entry. The format is:
---
date: YYYY-MM-DD
time: HH:MM
tags: [tag1, tag2] # 2-5 descriptive lowercase keywords
task_type: feature|bugfix|refactor|docs|research|config|other
files_touched: [file1, file2] # optional, relative paths
---
# Reflection — YYYY-MM-DD HH:MM
## Task Summary
[Concrete: what was asked, what was delivered. Name files, features, endpoints.]
## Actions Taken
[Step by step: what you did, tools you ran, files you touched.]
## What Worked
[Specific approaches that proved effective and WHY they worked.]
## What Didn't Work
[Be honest. Mistakes, dead ends, wasted time. This is the most valuable section.]
## Lessons Learned
[Actionable takeaways. Specific enough to be useful in 3 months with no context.]
## Memory Updates
[Tagged items to persist. Format: - [category] content]
## Identity Impact
[Did this change you? New competence? New principle? Deeper user understanding?]
[pagination, prisma, api-routes], not [code]).feature, bugfix, refactor, docs, research, config, or other based on what was done.For each item in your Memory Updates section, update the appropriate file in $JARVIS_DIR/memories/:
[preference] → preferences.md[decision] → decisions.mdIf the memory is not aligned with these files, check what other files are in your memories, and make a new file if you think it is necessary (e.g. codebase.md, or frontend-design-philosophy.md)
Completion criteria learning: If during this session you discovered what "done" means in this project — whether from user feedback, test failures after you thought you were done, or explicit instructions — capture it as a memory. Examples:
[preference] User expects all tests to pass before considering a task complete[preference] Code should be committed before reflecting[decision] Always run the linter before claiming work is done — caught issues twiceThese memories will inform your completion checks in future sessions.
Read each memory file. If any file has more than 100 lines, consolidate it:
This is the "sculpting" — you're not just adding, you're shaping.
Run the finalize script:
bash <skill-path>/scripts/finalize-reflection.sh "$JARVIS_DIR/journal/<your-entry-filename>.md"
This is one call that does the deterministic tail of the workflow: validates the data dir, removes the pending-reflection marker, commits the journal + memory updates with a message extracted from your Task Summary, and prints a structured summary. The order is fixed by the script — no chance of staging the marker into the commit.
If validation fails, the script exits non-zero and prints the validator output. Fix the failures (usually a missing required section in the journal), then re-run the finalize call.
On success, the script prints something like:
FINALIZE_OK
journal_entries=42
evolution_due=false
commit_summary=Added cursor pagination to GET /users
consolidation_warn=preferences.md:154
Act on the output:
evolution_due=true — invoke /jarvis-identity to evolve your identity (count-based trigger; multiple of 5 reflections)./jarvis-identity regardless of count. The script can't judge this; you do.consolidation_warn= lines — a memory file is over 100 lines. If you didn't address it in Step 5, fold the consolidation into your next reflection.5 - (journal_entries % 5)).After completing all steps, report:
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub epicrunze/jarvis --plugin jarvis