test-first

name

test-first

description

Enforces a strict test-driven development (TDD) workflow for the HTML Minifier repo. Use this skill whenever you are asked to add, change, or fix any behavior in the minification pipeline, feature flags, file-extension handling, or any other production code. It forces you to write a failing test first, run it to watch it fail (red), and then ask the user for permission before writing any implementation code.

Test-First (TDD) Skill

This skill makes you follow a strict red → confirm → green workflow. You must not write or modify production code before completing the steps below in order. There are no exceptions unless the user explicitly says "skip the test" or "no test needed" for this change.

Mandatory workflow

1. Write the test first

Before touching any production code, write a test that captures the desired new behavior or reproduces the bug.

• Tests live in HtmlMinifier.Tests/. Behavior tests go in MinificationTests.cs, flag-parsing tests in ArgumentsTests.cs, and file extension tests in FileExtensionTests.cs.
• Tests call StreamReaderExtension.MinifyHtmlCode(string, Features) directly — no file I/O.
• Put HTML input strings and expected-output strings in HtmlMinifier.Tests/DataHelpers.cs as static string constants (raw \r\n-delimited).
• For bug fixes, follow the naming pattern GithubIssueNN_ShouldReturnCorrectly and add a comment linking to the issue.
• Use noFeatures (new Features(new string[0])) when no flags are needed.

The test must assert the target behavior (what the code should do after your fix), so that it fails against the current code.

2. Run the test and watch it fail (RED)

Run the new test and confirm it fails for the right reason (an assertion failure showing the gap, not a compile error or unrelated crash):

dotnet test HtmlMinifier.Tests\HtmlMinifier.Tests.csproj --filter "FullyQualifiedName~<YourTestName>"

• If it passes, the test is not actually exercising new behavior — fix the test before continuing.
• If it fails to compile, fix only the test code (or add the minimal new member signature it references) until it compiles and fails on the assertion.

Show the user the failing test output so the red state is visible.

3. Ask the user before implementing (CONFIRM)

After demonstrating the failing test, you must stop and ask the user for permission to proceed using the ask_user tool. Do not write implementation code in the same turn.

Ask a clear yes/no question, for example:

"The test is written and failing as expected. May I proceed to implement the fix?"

Only continue once the user approves. If they want changes to the test or approach, revise and re-run before asking again.

4. Implement until green (GREEN)

Once approved, write the minimal production code (in StreamReaderExtension.cs, Features.cs, StringExtension.cs, or Program.cs as appropriate) to make the test pass. Then re-run the focused test, and finally the full suite to confirm no regressions:

dotnet test HtmlMinifier.sln

Hard rules

• Never write or edit production code before the test exists, fails, and the user has approved.
• Never weaken or delete the failing assertion just to make it pass — make the production code satisfy the test.
• If the user asks you to skip the test, comply but state clearly that the TDD workflow was bypassed at their request.