Convert nextflow lint to a Stop hook (supersedes #5)

[edmundmiller]

Supersedes #5 (closed). Adds a nextflow lint integration as an if-scoped, async PostToolUse hook, addressing @pditommaso's review on #5.

Design

• if-scoped PostToolUse (hooks/scripts/nextflow-lint.sh): fires only on .nf/.config edits. The if patterns (Edit(*.nf), Write(*.nf), MultiEdit(*.nf) and the *.config variants) use gitignore semantics, so a bare *.nf matches at any depth (root and nested). One handler per tool×extension since if takes a single pattern.
• async (asyncRewake): the lint runs in the background — never blocks the edit. On a lint failure it exits 2 and the output is surfaced to Claude as a system reminder to fix, rather than a blocking nag.
• No state machinery: this replaces the earlier Stop-hook + record-edit companion + per-session state file. The script just extracts the edited file path and lints that one file.
• Guards: command -v jq, command -v nextflow — skips silently if either is missing (fixes the original macOS-no-jq exit-127 spam).

Addressing the review

@pditommaso's point	Resolution
🔴 Missing jq guard	command -v jq || exit 0
🔴 N× synchronous JVM stalls per turn	async — lint runs off the critical path, never blocks
🔴 Blocking exit 2 interrupts the agent	asyncRewake → non-blocking system reminder
🟡 PostToolUse → Stop hook	We went further: if-scoped async PostToolUse, no Stop hook or state file

Tradeoff worth a look, @pditommaso

This lints per edit rather than once per turn, so it can still run on a half-finished file mid-composition. Because it's async + non-blocking (a soft system reminder, not exit-2 blocking), a stray intermediate-state reminder is cheap and ignorable — but if you'd prefer strict once-per-turn-on-final-state semantics, that requires the Stop-hook approach (which can't use if). Happy to switch.

jq note

I checked whether the edited path is exposed as an env var so we could drop the jq dependency — it isn't (only on stdin JSON, not interpolatable into command/args). So robust per-file targeting needs jq. The jq-free alternative is to lint the whole project dir each edit, but that's slower and re-surfaces unrelated pre-existing issues. Kept jq (guarded).

Verified locally

• clean file → exit 0; bad file → exit 2 + stderr; nonexistent path → exit 0; empty path → exit 0; no nextflow → silent; no jq → silent (no spam)
• shellcheck v0.10.0 clean; claude plugin validate accepts the asyncRewake + if config

Test plan

• Edit an invalid .nf in Claude Code; confirm the edit isn't blocked and a lint system-reminder arrives shortly after
• Edit a clean .nf; nothing reported
• Edit a nested file (workflows/main.nf); confirm the if glob matches
• macOS without jq: silent

https://claude.ai/code/session_01BDX5Wh7CXx1hXbfJCyBmMN

[bentsherman]

This seems more reasonable since it waits for the agent to finish editing. It also seems better than encoding it in the skill and hoping the agent remembers to do it

I wonder if it would be feasible to just run the LSP in the background and have the agent check the LSP diagnostics after every turn. That would eliminate the JVM overhead and you wouldn't need to record the edits because the LSP does that for you

[bentsherman]

Related: nextflow-io/language-server#146

We can minimize the JVM overhead in any case by providing a native build

[edmundmiller]

This seems more reasonable since it waits for the agent to finish editing. It also seems better than encoding it in the skill and hoping the agent remembers to do it

I wonder if it would be feasible to just run the LSP in the background and have the agent check the LSP diagnostics after every turn. That would eliminate the JVM overhead and you wouldn't need to record the edits because the LSP does that for you

https://code.claude.com/docs/en/plugins-reference#lsp-servers

😆

[bentsherman]

Closing in favor of LSP integration (#12 -> #11)