Question about best practices

[Anima-t3d]

I've been experimenting with TDD guard for a nextjs monorepo. When creating UIs the TDD hook is triggered excessively, seemingly making progress slow and potentially polluting the context window. It really makes sense for the API and pure logic parts of the code. I know there is a TDD on/off function, but what is the recommended approach for this scenario? Is there a way to configure when to enforce tdd guard and when not in terms of path/filetype?

[nizos]

Hi @Anima-t3d,

Thanks for sharing your experience!

I also feel that a one-size-fits-all approach to TDD validation is not ideal.

I can think of two improvements we can make in this regard:

• file type/path filtering through configuration
• custom validation instructions

We currently skip validation for certain file types but this list is hard coded. We could instead let the users configure it as they see fit.

As for the validation strictness and verbosity, we could add support for defining custom validation instructions. For example, TDD Guard will automatically look for a special markdown file in the project root and simply append its contents to the prompt that is sent to the validation model.

Regarding the performance, we are currently looking into how to improve the validation time without negatively impacting the validation quality.

What are your thoughts on those suggestions? Will they provide you with the flexibility you need? Let me know if there is anything else that we should take into consideration. :)

[YenK260]

Hi @nizos and @Anima-t3d,

I'm encountering the exact same issue with UI component development. Just spent time building a simple form
component with 6 fields and 2 buttons, and the strict one-field-at-a-time enforcement made what should be a
2-minute task take 10-15 minutes.

Each cycle required: edit → blocked by hook → run test → see next failure → implement one element → repeat.

For now, I'm using tdd-guard off for initial UI structure, then tdd-guard on for business logic. But this feels
like working around the tool rather than with it.

That said, I really appreciate this tool and the disciplined TDD workflow it enforces! It's great to see how
well-maintained and thoughtfully developed TDD Guard is. The strict enforcement has definitely improved my
testing habits for business logic and API development.

Looking forward to the upcoming improvements you mentioned. These would make TDD Guard even more valuable for full-stack development.

Thanks for building and maintaining this excellent tool!

[nizos]

Thank you @YenK260 for the kind words and for taking the time to provide such thoughtful feedback! I really appreciate it.

[nizos]

I've just released v0.9.0 which adds support for configurable ignore patterns. You can define custom file patterns to control exactly which files TDD Guard should not validate.

Update to the latest version:

npm update -g tdd-guard

Configure the ignore patterns in .claude/tdd-guard/data/config.json:

  {
    "guardEnabled": true,
    "ignorePatterns": [
      "*.md",
      "*.css",
      "*.json",
      "*.yml",
      "**/*.generated.ts",
      "**/public/**",
      "*.config.*",
      "**/components/**/*.tsx",
      "**/*.stories.tsx"
    ]
  }

I've also added a full guide for configuring ignore patterns here: ignore-patterns.md

This should give you more control over which files TDD Guard should validate modifications for. Let me know if this works or there are any improvements that should be made.

Regarding custom validation instructions, I will look into possibly during the weekend. :)

[nizos]

Hi @Anima-t3d,

I have now released version 0.10.0 of TDD-Guard which includes the ability to customize TDD instructions. Happy to take feedback on how you experience the new flexibility and validation rules. You can find more details here: #44 (reply in thread) :)