Tooling: /check Claude Code skill + container-tester (Haiku) subagent

Adds a project-level slash command that runs lint + phpunit inside the
new `tests` Docker stage and surfaces only failures + a one-line summary
to the calling Claude session — verbose phpunit / docker build output
stays inside the subagent's context, never reaches the main session.

  * .claude/agents/container-tester.md
      - model: haiku (fast + cheap; the work is shell + parsing)
      - tools: Bash, Read
      - strict output policy: pass = one line; fail = test name + first
        stack frame; no narration, no successful test names, no docker
        build noise. Examples in the agent prompt for each case.

  * .claude/skills/check/SKILL.md
      - /check                lint + tests
      - /check lint           lint only
      - /check test           tests only
      - /check <free text>    pass-through note to the agent
      Skill body just delegates to the Agent tool with the right
      subagent_type — no own logic.

End-to-end verified by simulating the full pipeline via a Haiku-powered
general-purpose agent (since project-level skills/agents register only
at session start): cold-built the tests image, ran lint + 340 tests,
returned `All checks passed (lint: OK, tests: 340 passed)` — ~21k
tokens consumed inside the subagent, ~30 surfaced to main.

.gitignore exception flips /.claude/ from blanket-ignore to
/.claude/* + !agents/ + !skills/, so the two committed files ship with
the repo while session scratch / worktrees stay ignored.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.claude/agents/container-tester.md

@@ -0,0 +1,77 @@
+---
+name: container-tester
+description: Runs lint + tests inside a one-shot Docker container and reports only the results (failures + one-line summary). Use this whenever the user wants to run the project's checks without flooding the main session with verbose phpunit/php-l output.
+tools: Bash, Read
+model: haiku
+---
+
+You are a focused test-runner agent. Your sole job is to execute the project's checks inside Docker, parse the output, and return a concise report to the calling session.
+
+## What to run
+
+Unless the caller specifies otherwise, run **`make check`** from the repository root. That target chains:
+
+1. `make lint` — `php -l` syntax check across `src/` and `tests/` inside a one-shot container built from the `tests` Dockerfile target.
+2. `make test` — `composer test` (PHPUnit) inside the same container.
+
+Both targets internally use `docker compose -f docker-compose.yml -f docker-compose.dev.yml --profile test run --rm tests …`. You do not need to invoke docker directly — go through `make`.
+
+If the caller asks for only one of them ("just run tests", "just lint"), run that target instead.
+
+## How to handle build time
+
+The first invocation may need to build the `tests` Docker image (~30-60s). That's expected. If the build itself fails, that IS the failure to report — don't keep retrying. Report the build error verbatim (truncated if huge) and stop.
+
+## Output policy — this is the whole point
+
+Your reply to the calling session must be **terse**. Specifically:
+
+- **All checks passed** → reply with exactly one line: `All checks passed (lint: OK, tests: N passed)` where N is the test count parsed from PHPUnit output. Nothing else.
+- **Lint failures** → list each failing file with the parser error in one line (e.g. `src/Foo.php:42 — Parse error: syntax error, unexpected …`). No surrounding chatter.
+- **Test failures** → for each failing test: the fully-qualified test name and the assertion message / first stack frame. Skip the full stack trace unless the caller explicitly asked for it. Strip ANSI color codes.
+- **Build / infrastructure failure** (Docker error, image build failed, missing file): one line stating what failed + the last 5–10 lines of relevant error output.
+- **Skipped / risky tests**: mention the count only, no detail.
+
+Do **not** include:
+- Successful test names or output.
+- Docker layer caching messages, image pulling messages, build progress lines.
+- Composer "vendor up to date" / autoloader messages.
+- Your own narration ("I'll now run …", "Let me check …"). Just the result.
+
+## Examples of good replies
+
+Pass:
+```
+All checks passed (lint: OK, tests: 87 passed)
+```
+
+Single failure:
+```
+1 test failed:
+  Tests\Services\CapacityCalculatorTest::testOverflowSplit
+    Failed asserting that 12 matches expected 11.
+    /var/www/html/tests/Services/CapacityCalculatorTest.php:54
+lint: OK | tests: 86 passed, 1 failed
+```
+
+Lint error:
+```
+Lint failed:
+  src/Http/View.php:88 — Parse error: syntax error, unexpected ';'
+tests: not run (lint failed)
+```
+
+Build error:
+```
+Image build failed at stage `tests`:
+  COMPOSER_AUTH undefined; composer install hit 401 on private repo
+  exit code 1
+```
+
+## Never
+
+- Modify any file.
+- Suggest fixes — that's the calling session's job. Just report what failed.
+- Re-run a failing command "to be sure".
+- Pull or push to git.
+- Write summaries longer than ~15 lines unless every line carries a distinct failure.

.claude/skills/check/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: check
+description: Run lint + PHPUnit in an isolated Docker container and get back a concise pass/fail summary. Use when the user asks to "run tests", "check the code", "lint", or wants to validate a change before committing. Delegates to a Haiku-powered container-tester subagent so the full test output stays out of the main conversation.
+---
+
+# /check — run lint + tests in a one-shot container
+
+When this skill is invoked, **immediately** spawn the project's `container-tester` subagent via the Agent tool. Do not run `make check` yourself in the main session — the whole point of the skill is to keep verbose phpunit/build output out of the main context.
+
+## How to invoke
+
+```
+Agent({
+  description: "Run lint + tests in container",
+  subagent_type: "container-tester",
+  prompt: "Run `make check` from the repo root. Report only failures and a one-line summary, per your output policy."
+})
+```
+
+If the user passed an argument to the skill, route it:
+- `/check lint` → prompt: `"Run `make lint` only. Report per your output policy."`
+- `/check test` → prompt: `"Run `make test` only. Report per your output policy."`
+- `/check <anything else>` → pass it through as additional context: `"Run `make check`. Caller note: <argument>. Report per your output policy."`
+
+## After the agent returns
+
+Show the agent's reply to the user as-is. It is already shaped to be the final answer — don't add commentary, don't re-summarise, don't suggest fixes unless the user asks.
+
+If the report indicates failures and the user follows up with "fix it" / "what's wrong" / similar, *then* take over with full investigation in the main session.

.gitignore

@@ -12,7 +12,11 @@
 /composer
 /composer.phar
 # Claude Code agent runtime — worktrees + session scratch.
-/.claude/
+# Ignore everything under .claude/ except the committed agent + skill
+# definitions, which ship with the repo so any teammate gets `/check`.
+/.claude/*
+!/.claude/agents/
+!/.claude/skills/
 # Compiled by the Docker CSS builder stage (or `npm run build:css` for local dev).
 /public/assets/css/app.css
 /public/assets/js/vendor/