Stats
Actions
Tags
From operation-logger
Creates and maintains a persistent operation-log.md file that records every step, decision, error, and file change during complex tasks — your long-term memory on disk. Use this skill whenever the task involves: multi-file refactoring, codebase migration (JS to TS, Express to Fastify, etc.), building new features spanning multiple modules, complex debugging sessions, security audits, performance optimization, infrastructure setup, or any work touching 3+ files. Also use when the user says things like 'track what we do', 'record each step', 'don't forget', 'step by step', 'keep track', 'log the process', or expresses concern about forgetting earlier work. Essential for tasks requiring more than 5 tool calls where context loss would be costly. When in doubt, use it — an unused log costs nothing, a missing one during a 50-step task costs everything.
How this skill is triggered — by the user, by Claude, or both
Slash command
/operation-logger:operation-loggerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Persistent step-by-step operation recording for long conversations and complex tasks.
Persistent step-by-step operation recording for long conversations and complex tasks.
Context windows are limited. In long conversations, earlier operations get compressed or dropped entirely. This creates a dangerous pattern: Claude forgets what it already tried, repeats failed approaches, loses track of modified files, and makes decisions that contradict earlier ones.
This skill solves that by treating the filesystem as persistent memory. Every meaningful operation gets recorded in operation-log.md — a single, chronological document that serves as the complete history of what happened, why, and what the outcome was.
Think of it this way:
The log isn't just a record — it's a tool. Re-reading it before decisions keeps the full picture in your attention window, even after context compression has stripped away the details.
Before anything else, check if operation-log.md already exists in the project directory:
This is how cross-session continuity works. The log file IS the memory.
Create operation-log.md at the start of any task that will involve 3+ tool calls. Don't wait — if in doubt, create it. A log you didn't need costs nothing; a log you needed but didn't create costs everything.
Specific triggers:
Always create operation-log.md in the project root directory (the current working directory). Never create it in the skill's installation folder.
Version control note: The operation-log.md is a working file, not source code. Consider adding it to .gitignore if you don't want it tracked. Some teams prefer to keep it for audit trails — use your judgment.
If the user says "don't log this", "skip the log", or otherwise indicates they don't want logging for a task, respect that and skip log creation. The skill is a tool, not a mandate.
The log has three sections that work together:
A live-updated summary that answers: "What's the current state?" This gets updated every 5 operations or whenever something significant changes. It should be short — 5-10 lines max — so re-reading it is fast.
Each session (conversation) gets its own header with a timestamp. Within a session, operations are logged chronologically.
Each operation entry follows this format:
#### [OP-NNN] Operation Type | Brief Description
- **Time**: HH:MM (optional — include when available)
- **Action**: What was done (1-2 sentences)
- **Result**: What happened (success/failure/partial, key output)
- **Files**: Files created, modified, or read (if any)
- **Context**: Why this was done / what it connects to (if not obvious)
Keep entries concise but complete. The goal is that someone reading only the log can understand the full history of the task. Don't write paragraphs — write clear, scannable bullet points.
Categorize each operation to make the log scannable:
| Type | Use When |
|---|---|
SEARCH | Searching for files, code patterns, or information |
READ | Reading/examining files or documentation |
EDIT | Modifying existing files |
CREATE | Creating new files |
DELETE | Removing files or code |
TEST | Running tests or verification |
BUILD | Building, compiling, or bundling |
COMMAND | Running shell commands |
DECISION | Making a design or implementation choice |
ERROR | Encountering and diagnosing errors |
FIX | Resolving an error or bug |
RESEARCH | Web searches, API exploration, doc reading |
PLAN | Planning next steps or revising approach |
REVIEW | Reviewing code or outputs |
After completing any tool call that changes state or produces important information, append a log entry. "Meaningful" means:
You do NOT need to log:
After every 5th operation entry (OP-005, OP-010, OP-015...), update the Running Summary at the top. The summary should reflect:
Before making any significant decision (choosing an approach, starting a new phase, handling an error), re-read the Running Summary. This takes seconds but prevents contradictions with earlier work.
When an error occurs, log:
This prevents the deadly pattern of retrying the same failed approach after context compression drops the memory of the failure.
When making a choice between alternatives, log it as a DECISION entry with the rationale. Future-you (or the user reviewing the log) needs to know not just what was chosen but why.
#### [OP-012] DECISION | Use REST API instead of GraphQL
- **Action**: Chose REST over GraphQL for the data layer
- **Result**: Decision made
- **Context**: GraphQL would require additional dependencies (apollo-server),
and the data model is simple enough that REST endpoints are clearer.
The user mentioned wanting to keep dependencies minimal.
When resuming from an existing log:
## Session: [DATE] (Resumed)Use templates/operation-log.md as the starting template. Copy it to the project root and fill in the task description.
The log should be detailed enough to reconstruct context, but not so verbose that re-reading it is slow. A good operation entry is 3-5 lines. If you need more detail, that detail probably belongs in a separate findings file.
If you do 3 quick file reads in a row to understand a module, you can batch them into one entry:
#### [OP-007] READ | Examined auth module structure
- **Action**: Read auth/login.ts, auth/middleware.ts, auth/types.ts
- **Result**: Auth uses JWT with refresh tokens, middleware checks on every route
- **Files**: auth/login.ts, auth/middleware.ts, auth/types.ts (read)
- **Context**: Understanding auth before modifying the session handling
The log isn't just for Claude's memory — it's also useful for the user. They can review operation-log.md at any time to see exactly what was done, in what order, and why. Write entries as if another developer will read them.
If you're also using task_plan.md (from planning-with-files) or todo tasks, the operation log complements them. The plan says what to do, the log says what was done. Reference plan phases in your log entries when relevant.
Stop logging when:
Before stopping, add a final summary entry:
#### [OP-NNN] REVIEW | Task Complete
- **Action**: Final review of all work performed
- **Result**: [Summary of what was accomplished]
- **Files**: [All files created/modified during the session]
- **Context**: Task completed successfully / with notes: [any caveats]
This skill works alongside other skills, not instead of them:
| Skill | Role | How They Connect |
|---|---|---|
| planning-with-files | Plans what to do | Operation log records what was actually done |
| systematic-debugging | Guides debug approach | Operation log records each debug step and finding |
| test-driven-development | Guides test workflow | Operation log records test results and iterations |
| brainstorming | Explores ideas | Operation log records which ideas were explored/chosen |
| Don't | Do Instead |
|---|---|
| Skip logging "just this once" | Log it — the one you skip is the one you'll need |
| Write multi-paragraph entries | Keep entries to 3-5 concise lines |
| Log only successes | Errors and failures are the most valuable log entries |
| Forget to update the summary | Every 5 ops, refresh the running summary |
| Create the log mid-task | Create it at the start, before the first operation |
| Put external/untrusted content in the log | Summarize external content; put raw data in separate files |
| Stop logging when things get complex | That's exactly when logging matters most |
npx claudepluginhub 1nv1s1b1e/operation-logger-skill --plugin operation-loggerLogs accomplishments from Claude Code sessions to dated markdown files at session end, context checkpoints, self-improve triggers, or user request.
Writes and maintains implementation diaries for non-trivial tasks like features, bug fixes, refactors; captures changes, why, successes, failures with errors/commands, learnings, tricky parts, review notes in dated Markdown files.
Generates and saves Markdown session logs capturing objectives, file changes, referenced materials, technical notes, future plans, open items, and metrics to resume project work across conversations.