菜单
Use when implementing any feature or bugfix, before writing implementation code
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation. Use when starting creative work that will produce a versioned design spec.
Use when you need to render an lmd-* skill phase or companion, or when a render call fails and you must decide whether the gateway is broken or the call was misaddressed.
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Fans out one focused subagent per independent problem domain (disjoint files, no shared state), then conflict-scans and integrates. Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies.
Executes a .lmd.md plan in this session — the main agent runs each task itself, pauses at batch checkpoints for human review, and closes at a whole-branch final gate. No companions. Use when executing an implementation plan inline with human review checkpoints.
Guides branch completion by verifying tests, detecting the workspace environment, presenting exactly 4 (or 3 for detached HEAD) integration options, then executing the choice with provenance-based worktree cleanup. Use when implementation is complete and you must decide how to integrate the work — merge, PR, keep, or discard.
| name | lmd-test-driven-development |
| description | Use when implementing any feature or bugfix, before writing implementation code |
Write the test first. Watch it fail. Write minimal code to pass. Core principle: If you didn't watch the test fail, you don't know if it tests the right thing. Violating the letter of the rules is violating the spirit of the rules.
Body renders one phase at a time — never read it from disk.
Rendering, diagnosis and fallback: see the lmd-rendering-skills skill.
Always: new features · bug fixes · refactoring · behavior changes. Exceptions (ask your human partner): throwaway prototypes · generated code · config files. Thinking "skip TDD just this once"? Stop. That's rationalization.
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
Wrote code before the test? Delete it. Start over. Delete means delete.
When adding mocks or test utilities, render the companion to avoid common pitfalls:
testing-anti-patterns — testing mock behavior instead of real behavior, test-only
methods on production classes, mocking without understanding dependencies.Production code → test exists and failed first
Otherwise → not TDD
No exceptions without your human partner's permission.