verify-before-done

Imported from GuntherW/scala-cheatsheet (.opencode/skills/verify-before-done/SKILL.md). Install upstream with npx skills add GuntherW/scala-cheatsheet --skill verify-before-done. Copyright stays with the author.

You have just modified Scala source in this repository. Before telling the user the task is done, verify: compiles cleanly → formatted → linted → tests green, in that order, stopping at the first failure to fix it.

Use sbt --client for all checks (faster, connects to running sbt server). Use plain sbt run (never sbt --client run) only to start a long-running app.

Workflow

1. Format

   sbt --client scalafmtAll

   Run first so formatting diffs don't obscure real changes later.

2. Lint

   sbt --client scalafixAll

   Fix reported violations — don't suppress/@SuppressWarnings unless the user explicitly approves.

3. Compile + test — scope to what changed

   Prefer the narrowest scope that still gives confidence:

   # One touched module
   sbt --client "project core" test
   
   # One touched test class
   sbt --client "project core" "testOnly de.codecentric.wittig.scala.futur.TestFuture"
   
   # One touched test method
   sbt --client "project munit" "testOnly de.wittig.CheckTest -- --test=addition*"

   If changes span multiple modules, or you're unsure what else is affected, run the full suite: sbt --client test.

4. On failure

   • Read the actual assertion/compiler error before changing anything.
   • Use -oF for full stack traces on a flaky/unclear failure.
   • Fix the root cause. Re-run the failing test, then the broader scope from step 3.
   • Never mark a task complete with known-red, skipped, or .ignore/@Ignored tests — unless explicitly asked.

5. Scala CLI files (under cli/) — not part of the sbt build, verify separately:

   scala-cli test <file>.scala

6. Code review — once compile/format/lint/test are green, invoke the scala-reviewer subagent (via the task tool) on every .scala file you created or modified in this session. Pass it the list of changed files.

   • Apply findings you agree with, then re-run the affected steps above (format/lint/compile/test) if you changed code.
   • If you disagree with a finding, say so explicitly to the user with your reasoning — don't silently drop it.
   • Skip only for pure comment/doc/formatting-only edits with no logic change.

When to skip steps

• Docs/comment-only changes: formatting/linting still apply, tests can be skipped.
• build.sbt / project/Dependencies.scala changes: run import-build first, then full sbt --client test.
• User explicitly says not to run tests yet: respect it, but flag before ending the session that verification is outstanding.

Reporting back

State plainly which steps passed and which module/test scope was actually exercised (e.g. "ran project core tests only — other modules untouched"). State whether scala-reviewer was invoked and summarize its findings (or note why it was skipped). Don't claim "all tests are green" if only a subset ran.