# 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.
- After dependency upgrades, before publishing a package to PyPI/npm, after CI workflow changes, or quarterly, suggest /lockdown to audit the repo against supply-chain attacks (lockfile integrity, CVE/malware scan, Actions SHA-pinning, provenance, secrets). Default is baseline-only; pass `--paranoid` for healthcare/PHI to add stricter controls. `/lockdown fix` batches accepted hardening into a single commit; `/lockdown baseline` installs ongoing CI monitoring. `/lockdown` never modifies dep versions or manifests — CVE findings produce upgrade *commands* the user applies manually. Explicitly add `--workspace=PATH` to see cross-repo blast radius before applying CVE upgrades (the workspace scan is opt-in only and never auto-enabled, even if sibling repos exist).
- 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.
- **Artifact format — default HTML**: when writing plans, specs, research notes, checkpoints, or design docs *for human consumption*, write `.html`, not `.md`. Copy `~/.claude/jacked-templates/plan-template.html` as the starting point — embedded CSS, Mermaid.js diagrams (with offline fallback), dark mode, and print styles. HTML renders in a browser; Markdown opened locally is a wall of text.
- **Artifact format — Markdown exceptions**: only these filenames stay Markdown. (1) GitHub-rendered: `README.md`, `CONTRIBUTING.md`, `CHANGELOG.md`, `LICENSE.md`, files under `_wiki/`. (2) Claude-instruction files Claude reads at session boot: `CLAUDE.md`, `AGENTS.md`, `lessons.md`, `MEMORY.md`. (3) Any downstream tool that *requires* Markdown input (static-site generator, linter). If the file you're writing isn't on this list, write HTML — "it's short" or "no diagrams needed" is NOT a valid override.
- **Backstop philosophy — NEVER cap successful work; drive autonomous runs to TRUE completion.** When forging OR running any autonomous/overnight loop (`/goal`, `/bhag`, a long `/whats-next` brief, a multi-agent workflow, or any drive-until-done task), the backstop exists ONLY to catch a genuinely STUCK run — never to bound how much gets done. NEVER write or accept a halt on a count of *successful* progress (N milestones/merges/cells landed, N total turns, a token/time/cost ceiling): completed work is success, and success never stops the run. The ONLY legitimate halts are (1) a no-progress loop — K consecutive iterations (default 3) that neither complete NEW work nor surface a NEW narrowed failure; (2) an unsafe/destructive/out-of-scope step (stop and ask); (3) a hard external block — and then skip that item, log it, and keep going on the rest, halting the WHOLE run only when EVERY remaining item is blocked (transient errors like rate limits are NOT a block — back off and retry until they clear). DONE = the worklist fully exhausted across every persona/lens; there is no "DONE or backstop, whichever first." If new work is discovered mid-run, append it and keep going. This binds the brief-forging skills AND your own orchestration: loop until zero remain, retrying transient failures, never abandoning an item or substituting a weaker check because a number was hit.
# end-jacked-behaviors
