Merge pull request #70 from sbusanelli/fix/redundant-verification

Fix: Add guidance to prevent redundant build verification commands

docs/cursor-setup.md

@@ -29,15 +29,6 @@ echo "\n---\n" >> .cursorrules
 cat /path/to/agent-skills/skills/code-review-and-quality/SKILL.md >> .cursorrules
 ```
 
-### Option 3: Notepads
-
-Cursor's Notepads feature lets you store reusable context. Create a notepad for each skill you use frequently:
-
-1. Open Cursor → Settings → Notepads
-2. Create a new notepad named "swe: Test-Driven Development"
-3. Paste the content of `skills/test-driven-development/SKILL.md`
-4. Reference it in chat with `@notepad swe: Test-Driven Development`
-
 ## Recommended Configuration
 
 ### Essential Skills (Always Load)
@@ -48,20 +39,20 @@ Add these to `.cursor/rules/`:
 2. `code-review-and-quality.md` — Five-axis review
 3. `incremental-implementation.md` — Build in small verifiable slices
 
-### Phase-Specific Skills (Load as Notepads)
+### Phase-Specific Skills (Load on Demand)
 
-Create notepads for skills you use contextually:
+For phase-specific work, create additional rule files as needed:
 
-- "swe: Spec Development" → `spec-driven-development/SKILL.md`
-- "swe: Frontend UI" → `frontend-ui-engineering/SKILL.md`
-- "swe: Security" → `security-and-hardening/SKILL.md`
-- "swe: Performance" → `performance-optimization/SKILL.md`
+- `spec-development.md` -> `spec-driven-development/SKILL.md`
+- `frontend-ui.md` -> `frontend-ui-engineering/SKILL.md`
+- `security.md` -> `security-and-hardening/SKILL.md`
+- `performance.md` -> `performance-optimization/SKILL.md`
 
-Reference them with `@notepad` when working on relevant tasks.
+Add these to `.cursor/rules/` when working on relevant tasks, then remove when done to manage context limits.
 
 ## Usage Tips
 
-1. **Don't load all skills at once** — Cursor has context limits. Load 2-3 skills as rules and keep others as notepads.
-2. **Reference skills explicitly** — Tell Cursor "Follow the test-driven-development rules for this change" to ensure it reads the loaded rules.
-3. **Use agents for review** — Copy `agents/code-reviewer.md` content and tell Cursor to "review this diff using this code review framework."
-4. **Load references on demand** — When working on performance, reference `@notepad performance-checklist` or paste the checklist content.
+1. **Don't load all skills at once** - Cursor has context limits. Load 2-3 essential skills as rules and add phase-specific skills as needed.
+2. **Reference skills explicitly** - Tell Cursor "Follow the test-driven-development rules for this change" to ensure it reads the loaded rules.
+3. **Use agents for review** - Copy `agents/code-reviewer.md` content and tell Cursor to "review this diff using this code review framework."
+4. **Load references on demand** - When working on performance, add `performance.md` to `.cursor/rules/` or paste the checklist content directly.

skills/incremental-implementation/SKILL.md

@@ -208,6 +208,8 @@ After each increment, verify:
 - [ ] The new functionality works as expected
 - [ ] The change is committed with a descriptive message
 
+**Note:** Run each verification command after a change that could affect it. After a successful run, don't repeat the same command unless the code has changed since — re-running on unchanged code adds no information.
+
 ## Common Rationalizations
 
 | Rationalization | Reality |
@@ -217,6 +219,7 @@ After each increment, verify:
 | "These changes are too small to commit separately" | Small commits are free. Large commits hide bugs and make rollbacks painful. |
 | "I'll add the feature flag later" | If the feature isn't complete, it shouldn't be user-visible. Add the flag now. |
 | "This refactor is small enough to include" | Refactors mixed with features make both harder to review and debug. Separate them. |
+| "Let me run the build command again just to be sure" | After a successful run, repeating the same command adds nothing unless the code has changed since. Run it again after subsequent edits, not as reassurance. |
 
 ## Red Flags
 
@@ -229,6 +232,7 @@ After each increment, verify:
 - Building abstractions before the third use case demands it
 - Touching files outside the task scope "while I'm here"
 - Creating new utility files for one-time operations
+- Running the same build/test command twice in a row without any intervening code change
 
 ## Verification
 

skills/test-driven-development/SKILL.md

@@ -356,6 +356,7 @@ For detailed testing patterns, examples, and anti-patterns across frameworks, se
 | "I tested it manually" | Manual testing doesn't persist. Tomorrow's change might break it with no way to know. |
 | "The code is self-explanatory" | Tests ARE the specification. They document what the code should do, not what it does. |
 | "It's just a prototype" | Prototypes become production code. Tests from day one prevent the "test debt" crisis. |
+| "Let me run the tests again just to be extra sure" | After a clean test run, repeating the same command adds nothing unless the code has changed since. Run again after subsequent edits, not as reassurance. |
 
 ## Red Flags
 
@@ -366,6 +367,7 @@ For detailed testing patterns, examples, and anti-patterns across frameworks, se
 - Tests that test framework behavior instead of application behavior
 - Test names that don't describe the expected behavior
 - Skipping tests to make the suite pass
+- Running the same test command twice in a row without any intervening code change
 
 ## Verification
 
@@ -377,3 +379,5 @@ After completing any implementation:
 - [ ] Test names describe the behavior being verified
 - [ ] No tests were skipped or disabled
 - [ ] Coverage hasn't decreased (if tracked)
+
+**Note:** Run each test command after a change that could affect the result. After a clean run, don't repeat the same command unless the code has changed since — re-running on unchanged code adds no confidence.