rlm-debugging
RLM Systematic Debugging (Phase 1.5)
Overview
When a requirement involves fixing a bug or investigating unexpected behavior, ad-hoc fixes waste time and create new bugs. Systematic debugging finds the root cause before any fix is attempted.
Core Principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
The Iron Law for RLM Debugging:
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
Trigger examples
Tests are failing after the last change; debug itFix crash on empty inputInvestigate why the API returns wrong dataDo a root cause analysis before making changes
More from try-works/rlm-workflow-acp
rlm-tdd
Use when implementing any code in RLM Phase 3. Enforces strict RED-GREEN-REFACTOR discipline with The Iron Law - no production code without a failing test first. Trigger phrases: "implement this", "add feature", "fix bug", "write a failing test", "TDD".
3rlm-subagent
Master skill for parallel subagent-driven execution with automatic fallback to single-agent sequential mode. Use when implementing plans with multiple independent sub-phases (SP1, SP2...) to dispatch parallel subagents, or when requiring code review between implementation and testing. Trigger phrases: "parallelize", "dispatch subagent", "split into sub-phases", "code review subagent", "parallel testing".
3rlm-workflow-acp
Orchestrate the RLM repo workflow end to end with strict sequential phase gates, locked artifacts, traceability, TODO discipline, and optional ACP delegation to Kimi via `acpx`. Use for requests like "Implement requirement <run-id>", "Run RLM Phase <N>", "resume requirement", "lock Phase <N>", or "verify locks".
3rlm-worktree
Use when starting any RLM requirement to set up an isolated git worktree. Required before Phase 1. Create an isolated workspace, verify the worktree directory is safe to use, run project setup, confirm a clean test baseline, and prevent direct main/master branch work.
3