chaychun/house-rules
Six human-directed skills for design, exploration, implementation, debugging, behavioral verification, and manual testing.
Use on any bug, test failure, or unexpected behavior — including during the post-implementation feedback loop — before settling on a fix. Do NOT use for open-ended feature design (hr-design) or greenfield implementation (hr-implement).
Default for most work before code — use when the user wants something built, added, changed, refactored, integrated, improved, or figured out; when they describe a goal, feature, or problem without an exact edit target; when scope, approach, or tradeoffs are open; when they ask how to do something or what the right approach is; or at the start of non-trivial feature work. Assess depth — simple cases stay in chat or hand off to hr-implement; suggest a write-up only when it would help, always ask first. Do NOT use for precise execution (named file, exact change, "change X to Y", single obvious fix); when design is already agreed and they want code now; when already inside hr-debug, hr-implement, code review, a review subagent, or another dedicated workflow; or when the user said "just do it" / "implement the plan".
Use when visual or UX direction is genuinely uncertain — mock and compare interactive concepts in the real codebase before committing to a design. Only with user confirmation; not for routine UI tweaks or precise execution requests.
Use when design is agreed or the request is precise execution — build or change real code. Includes trivial one-shot edits with a clear target. Do NOT use for open-ended scoping (hr-design) or bugs/failures (hr-debug).
Create and run an interactive manual-testing guide for an implementation. Inspect the real code, choose proportional test depth, prepare disposable development data when needed, give the human grouped steps with exact expected results, track their feedback, and route failures with evidence. Use when a user asks how to manually test, QA, exercise, or validate an implemented change. Do not use for automated test implementation, behavioral conformance review against a specification, or realistic-data testing in beta, preview, or production environments.
Verify that implemented code matches the behavior originally planned and confirmed by the human. Use after implementation when asked to verify, audit, review, or compare code against a plan, specification, acceptance criteria, design, or prior conversation. Report correct matches, incorrect matches, planned behavior missing from code, unplanned behavior present in code, and possible gaps absent from both plan and code.