From ade0455c69f530affde852e70fa5dab5375380f2 Mon Sep 17 00:00:00 2001 From: Yogesh Rao Date: Fri, 15 May 2026 12:14:01 +0530 Subject: [PATCH] feat: improve tdd skill score from 83% to 93% MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hey @ericjohnolson 👋 I ran your skills through `tessl skill review` at work and found some targeted improvements for `tdd`. Here's the full before/after: | Skill | Before | After | Change | |-------|--------|-------|--------| | **tdd** | **83%** | **93%** | **+10%** | | adr | 95% | — | — | | research | 93% | — | — | | harness | 93% | — | — | | implement | 93% | — | — | | plan-tasks | 92% | — | — | | reflect | 83% | — | — | I picked `tdd` because it had the most improvement headroom alongside `reflect`, and TDD is core to your RPI methodology — the `implement` skill's three-agent orchestration relies on the same Core Rules and red-green discipline defined here.
Changes made **Description improvements (biggest impact):** - Rewrote from jargon-heavy label ("L3/L4 altitude testing") to a concrete description listing specific actions: guides writing one test at a time, ZOMBIES test discovery, boundary-level and integration testing, structured session log tracking - Added explicit "Use when..." clause with natural trigger terms users would actually say ("writing unit tests", "doing TDD", "start with tests") - Added "Do NOT use for..." negative trigger pointing to `implement` for automated plan execution - Wrapped description in quoted string (standard frontmatter format) **Trigger improvements:** - Added three natural-language trigger phrases: "unit tests for this module", "start with tests", "TDD this feature" **Content improvements:** - Removed introductory philosophy paragraph ("TDD is a design technique...") — Claude already understands TDD motivation, and the behavioral constraints are already encoded in the Core Rules section - Added plain-language parenthetical for L3/L4 jargon in the boundary testing reference link ("boundary and integration-level testing (L3/L4 altitude)")
I also stress-tested your `tdd` skill against a ZOMBIES-driven circular buffer implementation and it correctly guided the full zero-one-many-boundary progression without skipping a step. Kudos for that. Honest disclosure — I work at @tesslio where we build tooling around skills like these. Not a pitch — just saw room for improvement and wanted to contribute. Want to self-improve your skills? Just point your agent (Claude Code, Codex, etc.) at [this Tessl guide](https://docs.tessl.io/evaluate/optimize-a-skill-using-best-practices) and ask it to optimize your skill. Ping me — [@yogesh-tessl](https://github.com/yogesh-tessl) — if you hit any snags. Thanks in advance 🙏 --- plugins/praxis/skills/tdd/SKILL.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/plugins/praxis/skills/tdd/SKILL.md b/plugins/praxis/skills/tdd/SKILL.md index 81b2769..fa2d574 100644 --- a/plugins/praxis/skills/tdd/SKILL.md +++ b/plugins/praxis/skills/tdd/SKILL.md @@ -1,12 +1,15 @@ --- name: tdd -description: Boundary-focused TDD workflow enforcing L3/L4 altitude testing, property-based tests, and red-green-refactor phase separation. Use when starting a new module or feature with test-first discipline. +description: "Interactive test-driven development workflow that guides writing one test at a time through red-green-refactor cycles with ZOMBIES test discovery, enforces boundary-level and integration testing with property-based tests, and tracks session progress in a structured log. Use when starting a new module or feature with test-first discipline, writing unit tests, doing TDD, or when the user says 'write tests first', 'start with tests', or 'red green refactor'. Do NOT use for automated multi-phase plan execution (use implement instead)." triggers: - "TDD workflow" - "test driven development" - "red green refactor" - "write tests first" - "test-first implementation" + - "unit tests for this module" + - "start with tests" + - "TDD this feature" allowed-tools: Read Glob Write Bash --- @@ -14,8 +17,6 @@ allowed-tools: Read Glob Write Bash > **For automated multi-phase execution** of a pre-planned feature, use `/implement` instead. This skill is for interactive, human-in-the-loop TDD on individual modules where you want to stay in the RED → GREEN → REFACTOR loop yourself. Implement's `agent-test` and `agent-impl` agents follow the same RED → GREEN discipline and Core Rules defined here. -TDD is a design technique that uses tests as a tool. Design emerges from usage, not speculation. Short feedback loops let you course-correct immediately. The resulting architecture is testable by design, not retrofitted. We are not trying to rush towards a feature completion, it's important that the code is correct and well-designed, it's crucial to be thorough and only add what tests demand. - When starting, announce: "Using TDD skill in mode: [auto|human]" MODE (user specifies, default: auto) @@ -39,7 +40,7 @@ MODE (user specifies, default: auto) ## Boundary Testing (Layered Architectures) -For layered architectures, see [boundary-testing.md](references/boundary-testing.md) for L3/L4 altitude testing, property-based tests with fast-check, behavioral assertions, HTTP contract tests, and architecture-specific anti-patterns. +For layered architectures, see [boundary-testing.md](references/boundary-testing.md) for boundary and integration-level testing (L3/L4 altitude), property-based tests with fast-check, behavioral assertions, HTTP contract tests, and architecture-specific anti-patterns. ## Session Log