seed-gates

name	seed-gates
description	Scan a repo's package.json scripts, CI workflows, and equivalent manifests, then SUGGEST a committed .claude/tale-mode.json gate list for tale-mode's Stop-hook loop — suggestions only; this skill never writes the config unasked, never trusts it, and never arms anything. Invoke ONLY when the user explicitly asks to seed, suggest, or set up tale-mode gates for a repo.

Seed the committed gates (suggest-only)

Help the user pick the gates for a committed .claude/tale-mode.json — the config tale-mode's Stop hook enforces during a kickoff phase (once the user trusts its content-hash; see the trust skill). Your output is a suggestion the user reviews — never silently write the config, and never touch the trust store.

1. Inventory candidates mechanically — don't guess from memory

Read the repo's own definition of "green":

• every package.json → the scripts block (root first; workspaces if a monorepo)
• CI workflows → .github/workflows/*.yml (or the host's equivalent) — the commands CI actually runs are the strongest signal of what "passing" means here
• other manifests as present: Makefile, pyproject.toml/tox.ini, Cargo.toml, go.mod (→ go test ./...), a repo-local tests/ runner script

2. Filter hard — a gate runs at EVERY turn-end during a phase

Keep only commands that are hermetic and terminating:

• ✅ local + deterministic: typecheck (tsc --noEmit), lint, format-check, unit tests, a build that's reasonably fast, a repo-local test script
• ❌ anything that doesn't terminate: dev, start, serve, --watch
• ❌ anything non-hermetic: network calls, fresh dependency installs, deploy/publish/release, E2E needing a live server or credentials, destructive/generative steps (db migrations, codegen that rewrites files — a gate must be read-only/idempotent, it runs repeatedly)
• ❌ anything slow enough to hurt: the default per-gate timeout is 120s (TALE_CHECK_TIMEOUT); a 10-minute suite belongs in CI, not a turn-end gate
• Each gate runs as ONE shell script — a multi-line JSON string is allowed (it executes as a single script, not split per line), but prefer one command per gate for readable failure output.

3. Verify each candidate by RUNNING it, then present

Run every surviving candidate once from the repo root and record its exit code. A suggested gate that can't run (missing dep, wrong path) — or that always fails — is worse than none: it would trap the loop, and the user would "fix" it by weakening the config. Drop or flag anything that isn't green on the current tree, and say why.

Then present:

1. the suggested .claude/tale-mode.json as a fenced snippet, e.g.

   { "gates": ["npm run -s typecheck", "npm test --silent"] }
   

   (gates is the only key the hook reads — don't add decorative fields)
2. one line per gate: where it came from (package.json scripts.typecheck, ci.yml:24) and its verified exit code
3. what you deliberately left out and why (the ❌ list above — name the rejects, don't hide them)

4. Hand off — the user decides

Only write the file if the user says so (writing it is safe in itself — it's inert until trusted — but it's their repo and their review). Then point them at the two user-only follow-ups you must NOT do yourself: committing the config, and trusting its content-hash (the trust skill has the exact commands). Remind them a later edit to the config changes its hash and needs a re-trust.