Menu
Use when about to edit code to fix a bug or change behavior -- check actual system outputs before making changes
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when reviewing a spec or task graph for completeness before implementation
Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, logging in, or automating browser actions
Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, logging in, or automating browser actions
Use when decomposing a spec, design, or feature description into a task dependency graph with self-evaluating acceptance criteria
Use when doing creative product, feature, component, functionality, or behavior design work
Use when infrastructure or features are built but before declaring done -- verifies work is wired into the system and actively used
| name | observe-before-editing |
| description | Use when about to edit code to fix a bug or change behavior -- check actual system outputs before making changes |
Outputs don't lie. Code might. Check outputs first.
Core principle: Never edit code based on what you think should happen. Verify what actually happened.
NO CODE EDITS WITHOUT OBSERVING ACTUAL SYSTEM STATE FIRST
Check if expected outputs exist
ls -la path/to/expected/output/
Check logs for actual errors
# Read recent logs, test output, build output
Run the failing command manually to see the real error
Mark your confidence level:
| Marker | Meaning | Action |
|---|---|---|
| VERIFIED | Read the file, traced the code | Safe to assert |
| INFERRED | Based on grep/search pattern | Must verify before claiming |
| UNCERTAIN | Haven't checked | Must investigate |
Only then edit code
| Trap | Reality |
|---|---|
| "Hook didn't run" | Check output files — it probably did |
| "Function is broken" | Did you run it? What was the actual error? |
| "File doesn't exist" | Searched wrong directory or wrong name |
| "Feature is missing" | Grep returned nothing ≠ doesn't exist (try alternate names) |
| "Test should have caught this" | Run the test. Read the output. |
When reviewing or auditing code:
Pass 1 — Hypotheses:
"I think X might be missing" (INFERRED)
Pass 2 — Verification:
Read the actual file
→ Found X at line 42
→ "X exists at file.go:42" (VERIFIED)
If you catch yourself doing any of these: STOP. Observe first.
| Excuse | Reality |
|---|---|
| "I know what the error is" | You're guessing. Check. |
| "Obviously this is the problem" | Obvious ≠ verified. Run it. |
| "I'll check after I fix it" | Fix might mask the real issue. Observe first. |
| "Grep returned nothing" | Try alternate names, check different paths |
| "The code clearly shows..." | Code shows intent. Output shows reality. |