rlm-tdd
RLM TDD Discipline
Overview
Test-Driven Development is mandatory for all RLM implementation work. This skill ensures test-first discipline is followed rigorously.
Core Principle: If you didn't watch the test fail, you don't know if it tests the right thing.
The Iron Law for RLM:
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Trigger examples
Implement Phase 3 for run '2026-02-24-add-oauth'Add a failing regression test first, then fix the bugI already wrote the code; now add tests(should trigger TDD reset guidance)Follow RED-GREEN-REFACTOR for this change
More from try-works/rlm-workflow-acp
rlm-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-debugging
Use when RLM requirement involves debugging a bug, test failure, or unexpected behavior. Insert Phase 1.5 between Phase 1 and Phase 2 to perform systematic root cause analysis before attempting any fixes. Trigger phrases: "debug", "investigate", "failing tests", "crash", "root cause".
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