When should I apply Observe Before Editing?

Apply it whenever you’re about to edit code to fix a bug. First verify the system’s real outputs in the cache and logs, then reproduce the failure before making changes.

What should I check first if something seems off?

Check the cache directories (.claude/cache and .claude/cache/learnings), then tail the logs to identify errors, and finally reproduce the failure manually.

How do I handle global vs project paths?

Always check both .claude/ and ~/.claude/ paths to distinguish where outputs and hooks actually ran, preventing misdiagnosis due to path scope.

observe-before-editing

Scanned

npx machina-cli add skill parcadei/Continuous-Claude-v3/observe-before-editing --openclaw

Files (1)

SKILL.md

1.0 KB

Observe Before Editing

Before editing code to fix a bug, confirm what the system actually produced.

Pattern

Outputs don't lie. Code might. Check outputs first.

DO

Check if expected directories exist: ls -la .claude/cache/
Check if expected files were created: ls -la .claude/cache/learnings/
Check logs for errors: tail .claude/cache/*.log
Run the failing command manually to see actual error
Only then edit code

DON'T

Assume "hook didn't run" without checking outputs
Edit code based on what you think should happen
Confuse global vs project paths (check both: .claude/ and ~/.claude/)

Source Sessions

a541f08a: Token limit error was invisible until manual run revealed it
6a9f2d7a: Looked in wrong cache path (~/.claude/ vs .claude/), assumed hook failure
a8bd5cea: Confirmed hook worked by finding output files in project cache
1c21e6c8: Verified Artifact Index indexing by checking DB file exists

Source

git clone https://github.com/parcadei/Continuous-Claude-v3/blob/main/.claude/skills/observe-before-editing/SKILL.mdView on GitHub

Overview

Observe Before Editing teaches you to confirm what the system actually produced before making code changes. By inspecting cache directories, logs, and reproducing the error, you avoid editing based on assumptions.

How This Skill Works

The skill guides you to validate runtime artifacts in .claude/cache, verify expected files in .claude/cache/learnings, tail logs, and reproduce the failing command. Only after confirming the real output should you edit the code, reducing guesswork and errors.

When to Use It

After a bug report or failure where the UI output seems inconsistent with the code behavior.
When you suspect a hook didn’t run and you need evidence from cache or logs.
When debugging requires distinguishing between project (.claude) and global (~/.claude) paths.
When a token limit or similar error isn’t obvious until a manual run reveals it.
Before editing to fix a bug, reproduce the exact failure by running the failing command manually.

Quick Start

Step 1: Check caches with ls -la .claude/cache/ and ls -la .claude/cache/learnings/
Step 2: Inspect logs via tail .claude/cache/*.log
Step 3: Run the failing command manually, then proceed to edit only if outputs match expectations

Best Practices

Check if the expected directories exist: ls -la .claude/cache/
Check if expected files were created: ls -la .claude/cache/learnings/
Check logs for errors: tail .claude/cache/*.log
Run the failing command manually to observe the actual error
Only edit code after confirming outputs align with expectations and verify path scope (project vs global)

Example Use Cases

Token limit error was invisible until a manual run revealed it (a541f08a).
Looked in the wrong cache path ( ~/.claude/ vs .claude/ ), assumed hook failure (6a9f2d7a).
Hook worked as evidenced by output files found in the project cache (a8bd5cea).
Artifact Index indexing confirmed by the presence of the DB file (1c21e6c8).
A developer reproduced a mismatch by running the command and validating actual outputs before editing.

Frequently Asked Questions

Add this skill to your agents