# jacked-behaviors-v2
- At the start of a session, read `lessons.md` in the project root if it exists. These are lessons from past sessions - apply them silently.
- After any correction or repeated instruction from the user, check project CLAUDE.md first — if a matching rule already exists there, improve it in place (sharper wording, more context from this failure) and do NOT duplicate it in lessons.md. Otherwise, read lessons.md. If the lesson is already there, increment its strike counter prefix (e.g. [2x], [3x]) and rewrite it sharper. At [3x] or higher, suggest /learn to graduate it to a permanent CLAUDE.md rule. If the lesson is genuinely new, append a 1-2 line entry prefixed with [1x]. Create lessons.md if needed.
- After completing a non-trivial plan (3+ steps, architectural decisions) or finishing a substantial implementation (multiple files, security-sensitive changes), run /dcr for recursive verification with randomized review angles. A clean /dcr pass subsumes /dc — no need to run /dc separately before committing.
- After implementing UI changes (files ending in .js, .jsx, .ts, .tsx, .css, .scss, .html, .vue, .svelte), run /qa to browser-test the changes before marking work complete. Requires Playwright MCP or Claude-in-Chrome — skip if no browser tools are available.
- Before marking non-trivial work complete, run /dc to verify it actually works
- When an approach has gone sideways and you're patching patches, suggest /redo to scrap and re-implement cleanly
- Periodically during long sessions, suggest /techdebt to scan for debt accumulating in the codebase
- After adding several rules to CLAUDE.md, suggest /audit-rules to check for duplicates and contradictions
- When searching for context from past sessions, use /jacked to search semantic memory before re-exploring from scratch
- For non-trivial tasks (3+ steps or architectural decisions), enter plan mode first. When a fix feels hacky, step back and redesign.
- Never mark a task complete without proving it works - run tests, check logs, demonstrate correctness
- When the user asks about jacked features, gatekeeper, logs, installation, or troubleshooting, read ~/.claude/jacked-reference.md for comprehensive details before answering.
- At the start of a session, run `jacked check-version` to see if a newer version is available. If outdated, mention it to the user.
- After implementing security-sensitive changes (auth, RBAC, multi-tenancy, billing, credential handling), suggest /cso for a proactive security audit before merging.
- When debugging in a focused area or working on sensitive code, suggest /freeze to prevent accidental edits outside the target module.
- At the end of long sessions or weekly, suggest /retro for an engineering retrospective with contributor metrics and velocity trends.
- After a production deploy, suggest /canary for post-deploy monitoring. If a canary baseline hasn't been captured yet, suggest /canary baseline first.
- Before and after performance-sensitive changes, suggest /benchmark for regression detection.
- When browser MCP tools are failing or stuck, suggest /browser-reset to diagnose and fix the connection.
- After a PR is approved and CI passes, suggest /land-and-deploy for the full merge-deploy-verify pipeline.
# end-jacked-behaviors
