Exclude test files from a skill's sources

[viclafouch]

A test-only change reopens the skill review, because sources cannot exclude test files.

Example

src/price.ts
src/price.test.ts
skills/helpers-core/SKILL.md   sources: [src/*.ts]

1. Record the review of helpers-core.
2. Add a test case to src/price.test.ts, and commit.
3. Run intent maintainer review --base HEAD~1.

Skill: "skills/helpers-core/SKILL.md"
  Changed: "src/price.test.ts"

src/*.ts also matches price.test.ts, so a test change needs a skill review.

What does not work

• review.ignore: [src/**/*.test.ts] skips unmapped files only.
• :(exclude)src/*.test.ts in sources is rejected.

Today we list each code file in sources by hand.

Proposal

A maintainer who uses Intent adds a ! entry to sources, and Intent leaves out the files it matches:

sources:
  - src/*.ts
  - '!src/**/*.test.ts'

Change	Result
src/price.ts	The review of helpers-core reopens.
src/price.test.ts	No skill review.
New file src/slug.ts	Covered, with no edit to sources.

Would you accept this? If yes, we open the PR.

@tanstack/intent 0.5.4

[LadyBluenotes]

Thanks for the write-up.

Before I weigh in, I want to understand the pain you're dealing with a bit more. Is the cost mainly the review step itself on test-only PRs, or that maintainer check goes red in CI until someone records it? And roughly how often do test-only changes land for you?

I ask because I've been treating tests as part of a skill's evidence. A new test case can mean someone found an edge case the code has to handle, and that's the kind of thing a skill may need to mention. So I'm hesitant to make test changes invisible to review, but I'd like to know what you're running into.

One thing worth checking on the proposal: with ! alone, src/price.test.ts would stop reopening helpers-core but then show up as an unmapped change, so you'd also need it in review.ignore. Is that the setup the kind of setup you were thinking of?

For now, intent maintainer review --unchanged "<reason>" records every pending item in one step when a test change doesn't affect the guidance. Curious whether that's workable or still maybe too much friction

[viclafouch]

Thanks a lot for the thoughtful answer!

To your questions:

• The pain we expected was maintainer check going red in CI on a pull request that only touches tests.
• It has not happened yet: in our repo, 0 of the 16 pull requests that touched src/ were test-only.

The closest real case: we moved our hook tests from jsdom to Chromium, and rewrote 7 test files with no change to the hooks. As its own pull request, that would reopen hooks-core with nothing to update, and --unchanged "test runner migration" handles it in one step.

Your point on tests as evidence makes sense to us. So no need for an exclusion on our side. Closing this one, thanks again!