
Observe Before Editing
- 463 installs
- 3.9k repo stars
- Updated January 26, 2026
- parcadei/continuous-claude-v3
observe-before-editing is an agent debugging skill that requires confirming actual system outputs before editing code for developers who need evidence-based bug fixes instead of assumptions.
About
observe-before-editing is a non-user-invocable skill from parcadei/continuous-claude-v3 that enforces an evidence-first debugging pattern: check directories with `ls`, verify expected files under `.claude/cache/`, tail logs for errors, and rerun failing commands manually before touching source code. The core principle is that outputs do not lie while code assumptions often do. It explicitly warns against editing based on what should happen, assuming hooks did not run without checking artifacts, and confusing global versus project paths. Developers reach for observe-before-editing when agents jump to code changes without confirming what the system actually produced.
- observe-before-editing
Observe Before Editing by the numbers
- 463 all-time installs (skills.sh)
- +3 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #915 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/parcadei/continuous-claude-v3 --skill observe-before-editingAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 463 |
|---|---|
| repo stars | ★ 3.9k |
| Last updated | January 26, 2026 |
| Repository | parcadei/continuous-claude-v3 ↗ |
How do you debug before changing code?
Use observe-before-editing for development tasks
Who is it for?
Developers debugging Claude hook pipelines, cache directories, or failing CLI commands who want agents to verify outputs first.
Skip if: Greenfield feature work where no failing output exists and the task is pure implementation without a bug to reproduce.
When should I use this skill?
An agent is about to edit code to fix a bug, hook failure, or missing artifact without first checking logs, cache files, or command output.
What you get
Verified filesystem artifacts, log excerpts, reproduced command errors, and evidence-backed edit decisions.
- Reproduced error output
- Verified artifact inventory
Files
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
1. Check if expected directories exist: ls -la .claude/cache/ 2. Check if expected files were created: ls -la .claude/cache/learnings/ 3. Check logs for errors: tail .claude/cache/*.log 4. Run the failing command manually to see actual error 5. 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
Related skills
FAQ
What should agents check before editing code?
observe-before-editing requires agents to list expected directories like `.claude/cache/`, verify created files, tail log files for errors, and rerun failing commands manually before making any source code changes.
Why use observe-before-editing over immediate fixes?
observe-before-editing prevents wasted edits by confirming actual system outputs first, because logs and filesystem artifacts reveal real failures while code assumptions about hook behavior often mislead agents.