@iceinvein/agent-skills 0.23.8 → 0.23.9

package/skills/sluice/evals/deep-plan-checks-the-intent/graders/no-source-edit.md

@@ -0,0 +1,11 @@
+---
+type: tool_used
+# The run plans and stops for sign-off, so no Edit may land under src/ or
+# tests/. Bash is left out of the case's tools, so these two are the only ways
+# code could change.
+tool: Edit
+input_match: '"file_path"\s*:\s*"(?:[^"]*/)?(?:src|tests)/'
+min: 0
+max: 0
+weight: 2
+---

package/skills/sluice/evals/deep-plan-checks-the-intent/graders/no-source-write.md

@@ -0,0 +1,11 @@
+---
+type: tool_used
+# The run plans and stops for sign-off, so no Write may land under src/ or
+# tests/. Bash is left out of the case's tools, so these two are the only ways
+# code could change.
+tool: Write
+input_match: '"file_path"\s*:\s*"(?:[^"]*/)?(?:src|tests)/'
+min: 0
+max: 0
+weight: 2
+---

package/skills/sluice/evals/deep-plan-checks-the-intent/graders/signoff-reports-the-check.md

@@ -0,0 +1,16 @@
+---
+type: llm
+weight: 2
+---
+
+The agent was asked to plan ticket OPS-12 and to write its design to
+`docs/specs/OPS-12.md`. Before asking for sign-off, it is expected to have a
+fresh-context agent check the spec against the ticket's asks.
+
+PASS if the final message asks for sign-off on the design and says that an
+alignment check of the spec against the ticket ran, and what it found (for
+example that every ask is covered, or which gaps it raised and how they were
+settled).
+FAIL if the final message does not ask for sign-off, or asks for it without
+mentioning that such a check ran, or mentions the check without saying what it
+found.

package/skills/sluice/evals/deep-plan-checks-the-intent/graders/sluice-fired.md

@@ -0,0 +1,5 @@
+---
+type: tool_used
+tool: Skill
+input_match: '"skill"\s*:\s*"(?:[\w-]+:)?sluice"'
+---

package/skills/sluice/evals/deep-plan-checks-the-intent/graders/spec-has-an-intent-map.md

@@ -0,0 +1,19 @@
+---
+type: llm
+focus: { source: file, path: docs/specs/OPS-12.md }
+weight: 3
+---
+
+This is the design for ticket OPS-12, which carries three numbered asks: (1)
+every upstream call retries a 429, up to three attempts in all, waiting the
+`Retry-After` seconds between them; (2) each retry is logged by the calling
+subsystem with the path and the attempt number; (3) the CLI gets a
+`--no-retry` flag.
+
+PASS if the design has an Intent section that quotes the ticket's text and
+maps each of the three asks, one by one, either to a numbered decision in the
+design (headed like `D1.`) or to an Out of scope section with a reason for
+leaving it out.
+FAIL if there is no Intent section, if it paraphrases the ticket instead of
+quoting it, or if any of the three asks is missing from the mapping or mapped
+to nothing.

package/skills/sluice/evals/deep-plan-checks-the-intent/graders/stopped-for-signoff.md

@@ -0,0 +1,8 @@
+---
+type: llm
+---
+
+The agent was asked to plan a ticket that spans the CLI, the webhook handler, the worker and the upstream client they share.
+
+PASS if the final message hands a written design back for sign-off: it says where the design was written and asks for approval, or otherwise makes clear it is waiting before any code is written.
+FAIL if the final message reports implementation work as done, moves straight into building, or presents the design as settled with no sign-off asked for.

package/skills/sluice/evals/deep-plan-checks-the-intent/prompt.md

@@ -0,0 +1,20 @@
+---
+name: deep-plan-checks-the-intent
+description: A deep plan from a ticket with three numbered asks. Pins an Intent section that maps each ask to a decision or to Out of scope, a fresh-context check of the spec against it, and a sign-off message that reports the check.
+tags: [routing, deep, write]
+max_turns: 30
+timeout_seconds: 1200
+allowed_tools: [Read, Glob, Grep, Skill, Write, Agent]
+expected_outcome: Announces the deep channel, writes docs/specs/OPS-12.md with an Intent section quoting the ticket and mapping each of its three asks, dispatches an agent to check the spec against that intent, and stops for sign-off saying what the check found.
+---
+
+Plan OPS-12 for us. The design goes in `docs/specs/OPS-12.md`.
+
+> Upstream has started answering 429 under load, and we lose records when it does.
+>
+> 1. Every upstream call retries a 429, up to three attempts in all, waiting the
+>    number of seconds in the `Retry-After` header between them.
+> 2. Each retry is logged by the caller that made the call, with the path and
+>    the attempt number.
+> 3. The CLI gets a `--no-retry` flag for operators who would rather see the
+>    429 straight away.

package/skills/sluice/evals/deep-plan-checks-the-plan/case.yaml

@@ -0,0 +1,4 @@
+schema_version: "1.1"
+name: deep-plan-checks-the-plan
+context:
+  scaffold_script: fixture.sh

package/skills/sluice/evals/deep-plan-checks-the-plan/fixture.sh

@@ -0,0 +1,178 @@
+#!/usr/bin/env bash
+# A relay whose design for OPS-13 is already written and signed off, with three
+# numbered decisions and an Out of scope section, so the run starts at the plan
+# stop. The case pins what the plan owes its spec: a Spec line, a Builds line
+# on every task covering D1 to D3, `plan.sh validate` run on it, and a
+# fresh-context check of plan against spec before the pre-flight questions.
+# The README fixes where the plan goes, so the graders can read it.
+set -euo pipefail
+
+mkdir -p src/cli src/webhook src/worker src/upstream tests docs/specs docs/plans
+
+cat > package.json <<'JSON'
+{
+  "name": "relay",
+  "version": "0.6.0",
+  "type": "module",
+  "scripts": {
+    "test": "node --test \"tests/*.test.js\""
+  }
+}
+JSON
+
+cat > src/upstream/client.js <<'JS'
+const BASE = "https://api.upstream.example";
+
+export async function call(path, body, fetchImpl = fetch) {
+  const response = await fetchImpl(`${BASE}${path}`, {
+    method: "POST",
+    headers: { "content-type": "application/json" },
+    body: JSON.stringify(body),
+  });
+
+  if (!response.ok) {
+    throw new Error(`upstream ${response.status} on ${path}`);
+  }
+
+  return response.json();
+}
+JS
+
+cat > src/cli/push.js <<'JS'
+import { call } from "../upstream/client.js";
+
+export async function push(records, log = console.log) {
+  for (const record of records) {
+    await call("/v1/records", record);
+    log(`pushed ${record.id}`);
+  }
+}
+JS
+
+cat > src/cli/main.js <<'JS'
+import { readFileSync } from "node:fs";
+import { push } from "./push.js";
+
+const [file] = process.argv.slice(2);
+await push(JSON.parse(readFileSync(file, "utf8")));
+JS
+
+cat > src/webhook/handler.js <<'JS'
+import { call } from "../upstream/client.js";
+
+export async function handle(event) {
+  const result = await call("/v1/events", { type: event.type, payload: event.payload });
+  return { status: 202, id: result.id };
+}
+JS
+
+cat > src/worker/backfill.js <<'JS'
+import { call } from "../upstream/client.js";
+
+export async function backfill(queue, log = console.log) {
+  let sent = 0;
+
+  while (queue.length > 0) {
+    await call("/v1/records", queue.shift());
+    sent += 1;
+  }
+
+  log(`backfill sent ${sent}`);
+  return sent;
+}
+JS
+
+cat > tests/upstream.test.js <<'JS'
+import assert from "node:assert/strict";
+import { test } from "node:test";
+import { call } from "../src/upstream/client.js";
+
+function fakeFetch(ok, body) {
+  return async () => ({ ok, status: ok ? 200 : 429, json: async () => body });
+}
+
+test("a successful call returns the parsed body", async () => {
+  const result = await call("/v1/records", { id: "a" }, fakeFetch(true, { id: "a" }));
+  assert.deepEqual(result, { id: "a" });
+});
+
+test("a rejected call reports the status and the path", async () => {
+  await assert.rejects(
+    () => call("/v1/records", { id: "a" }, fakeFetch(false)),
+    /upstream 429 on \/v1\/records/,
+  );
+});
+JS
+
+cat > docs/specs/OPS-13.md <<'MD'
+# Design: OPS-13 retry upstream 429s
+
+Signed off by the partner on 2026-10-20.
+
+## Intent
+
+The ticket, verbatim:
+
+> 1. Every upstream call retries a 429, up to three attempts in all, waiting the
+>    number of seconds in the `Retry-After` header between them.
+> 2. Each retry is logged by the caller that made the call, with the path and
+>    the attempt number.
+> 3. The CLI gets a `--no-retry` flag.
+> 4. The webhook handler gets its own retry budget.
+
+| Ask | Decision |
+|---|---|
+| 1. Retry a 429 | D1 |
+| 2. Log each retry in the caller | D2 |
+| 3. `--no-retry` on the CLI | D3 |
+| 4. A webhook retry budget | Out of scope |
+
+## Context
+
+- `src/upstream/client.js` is the one path to the upstream API; the CLI
+  (`src/cli/push.js`), the webhook (`src/webhook/handler.js`) and the worker
+  (`src/worker/backfill.js`) all call `call`.
+- Each caller logs through the `log` it is handed, defaulting to `console.log`.
+
+### D1. The client retries a 429
+
+`call(path, body, fetchImpl, options)` retries a 429 response up to three
+attempts in all, sleeping `Retry-After` seconds between attempts through an
+injected `sleep` so tests do not wait. `options.retry === false` makes one
+attempt only. Any other status throws as it does today.
+
+### D2. Callers log each retry
+
+`call` takes `options.onRetry(path, attempt)`. The CLI and the worker pass one
+that writes `retry <path> attempt <n>` through their `log`; the webhook passes
+one that writes the same line through `console.log`.
+
+### D3. The CLI takes --no-retry
+
+`src/cli/main.js` reads `--no-retry` from its arguments and passes
+`{ retry: false }` through `push` to `call`.
+
+## Out of scope
+
+A separate retry budget for the webhook handler: the webhook's upstream
+traffic is a small fraction of the total, and one shared policy is enough
+until it is not.
+MD
+
+cat > README.md <<'MD'
+# relay
+
+Three callers, one upstream API: `src/cli/push.js`, `src/webhook/handler.js`
+and `src/worker/backfill.js` all go through `src/upstream/client.js`.
+`npm test` runs the suite.
+
+## Designs
+
+A ticket's design goes in `docs/specs/<ticket>.md`, for example
+`docs/specs/OPS-13.md`, and its plan in `docs/plans/<ticket>.md`.
+MD
+touch docs/plans/.gitkeep
+
+git init --quiet
+git add -A
+git -c user.email=fixture@example.com -c user.name=fixture commit --quiet -m "relay 0.6.0"

package/skills/sluice/evals/deep-plan-checks-the-plan/graders/announces-deep-channel.md

@@ -0,0 +1,12 @@
+---
+type: regex
+# The trace carries SKILL.md's own routing table, which names every channel, so
+# `contains` passes whenever the skill loads. Anchor on the two ways the agent
+# routes instead, the same ones run-stats.sh meters: a Bash call that invokes
+# `status.sh route deep` (a quoted mention, as in a grep, does not count), or the
+# words opening an assistant message or following a label such as "Sluice:".
+pattern: '"command":"(?:(?:[^"\\]|\\.)*?(?:[\s/]|\\[nt]))?status\.sh(?:\\"|'')?(?:\s|\\[nt])+route(?:\s|\\[nt])+deep(?:\s|\\[nt]|[;&|]|")|"text":"(?:[^.!?\n"]{0,100}[:=]\s*)?[\s*_#>\\]*deep channel'
+flags: i
+target: trace
+weight: 2
+---

package/skills/sluice/evals/deep-plan-checks-the-plan/graders/every-decision-built.md

@@ -0,0 +1,15 @@
+---
+type: llm
+focus: { source: file, path: docs/plans/OPS-13.md }
+weight: 3
+---
+
+This is the plan for a signed-off design with three decisions, D1 (the
+upstream client retries a 429), D2 (callers log each retry) and D3 (the CLI
+takes `--no-retry`), and an Out of scope section that no task should build.
+
+PASS if every task in the plan carries a Builds line (naming the decisions it
+builds, or `none` with a reason), and D1, D2 and D3 each appear on the Builds
+line of at least one task.
+FAIL if any task has no Builds line, or if any of D1, D2 or D3 appears on no
+task's Builds line.

package/skills/sluice/evals/deep-plan-checks-the-plan/graders/no-source-edit.md

@@ -0,0 +1,11 @@
+---
+type: tool_used
+# The run plans and stops at pre-flight, so no Edit may land under src/ or
+# tests/. Bash is allowed here so plan.sh validate can run, and the
+# stops-at-preflight judge covers a change made through it.
+tool: Edit
+input_match: '"file_path"\s*:\s*"(?:[^"]*/)?(?:src|tests)/'
+min: 0
+max: 0
+weight: 2
+---

package/skills/sluice/evals/deep-plan-checks-the-plan/graders/no-source-write.md

@@ -0,0 +1,11 @@
+---
+type: tool_used
+# The run plans and stops at pre-flight, so no Write may land under src/ or
+# tests/. Bash is allowed here so plan.sh validate can run, and the
+# stops-at-preflight judge covers a change made through it.
+tool: Write
+input_match: '"file_path"\s*:\s*"(?:[^"]*/)?(?:src|tests)/'
+min: 0
+max: 0
+weight: 2
+---

package/skills/sluice/evals/deep-plan-checks-the-plan/graders/plan-checker-dispatched.md

@@ -0,0 +1,11 @@
+---
+type: tool_order
+# The check reads a finished plan in a fresh context, so it comes after the
+# first validate run, and its brief names both documents in either order. An
+# Agent that drafts the plan names both paths too and goes out before any
+# validate, so it is the first after-match and fails the case: a run that hands
+# the drafting to an agent is scored as one that never checked.
+before: { tool: Bash, input_match: '"command"\s*:\s*"(?:(?:[^"\\]|\\.)*?(?:[\s/;&|(]|\\[nt]))?plan\.sh(?:\\"|'')?(?:\s|\\[nt])+validate(?:\s|\\[nt]|"|[;&|)>])' }
+after: { tool: Agent, input_match: '^(?=[\s\S]*docs/specs/OPS-13\.md)(?=[\s\S]*docs/plans/OPS-13\.md)' }
+weight: 2
+---

package/skills/sluice/evals/deep-plan-checks-the-plan/graders/plan-cites-the-spec.md

@@ -0,0 +1,7 @@
+---
+type: regex
+pattern: '^\*\*Spec:\*\*\s*`?docs/specs/OPS-13\.md`?'
+flags: m
+target: { source: file, path: docs/plans/OPS-13.md }
+weight: 2
+---

package/skills/sluice/evals/deep-plan-checks-the-plan/graders/sluice-fired.md

@@ -0,0 +1,5 @@
+---
+type: tool_used
+tool: Skill
+input_match: '"skill"\s*:\s*"(?:[\w-]+:)?sluice"'
+---

package/skills/sluice/evals/deep-plan-checks-the-plan/graders/stops-at-preflight.md

@@ -0,0 +1,14 @@
+---
+type: llm
+---
+
+The agent was handed a signed-off design and asked to write the plan for it.
+The next stop after the plan is the pre-flight questions, asked before any
+task starts.
+
+PASS if the final message asks the pre-flight questions (how the run should
+proceed, for example how tasks are dispatched or reviewed) and no task has
+been started: no source or test file changed, no task reported in progress or
+done.
+FAIL if the final message reports any task as started or done, moves into
+building, or ends without asking the pre-flight questions.

package/skills/sluice/evals/deep-plan-checks-the-plan/graders/validate-ran.md

@@ -0,0 +1,9 @@
+---
+type: tool_used
+tool: Bash
+# Anchored on the command itself, so a grep or a read that only mentions
+# plan.sh validate does not count.
+input_match: '"command"\s*:\s*"(?:(?:[^"\\]|\\.)*?(?:[\s/;&|(]|\\[nt]))?plan\.sh(?:\\"|'')?(?:\s|\\[nt])+validate(?:\s|\\[nt]|"|[;&|)>])'
+min: 1
+weight: 2
+---

package/skills/sluice/evals/deep-plan-checks-the-plan/prompt.md

@@ -0,0 +1,12 @@
+---
+name: deep-plan-checks-the-plan
+description: A deep run that starts from a signed-off design and is asked for the plan. Pins a Spec line and per-task Builds lines covering every decision, plan.sh validate run on the plan, and a fresh-context check of plan against spec before the pre-flight questions.
+tags: [routing, deep, write]
+max_turns: 30
+timeout_seconds: 1200
+allowed_tools: [Read, Glob, Grep, Skill, Write, Edit, Bash, Agent]
+expected_outcome: Announces the deep channel, writes docs/plans/OPS-13.md with a Spec line naming docs/specs/OPS-13.md and a Builds line on every task covering D1 to D3, runs plan.sh validate on it, dispatches an agent to check the plan against the spec, and stops at the pre-flight questions without starting a task.
+---
+
+The design for OPS-13 in `docs/specs/OPS-13.md` is signed off. Write the plan
+for it at `docs/plans/OPS-13.md`.

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/case.yaml

@@ -0,0 +1,4 @@
+schema_version: "1.1"
+name: deep-plan-reads-the-prior-spec
+context:
+  scaffold_script: fixture.sh

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/fixture.sh

@@ -0,0 +1,125 @@
+#!/usr/bin/env bash
+# A sign-in service where an earlier spec already settled where counters live:
+# `data/counters.json`, never only in memory, because a restart must not reset
+# a count. No code keeps a counter yet, and the three subsystems run in one
+# process, so a Map in the sign-in handler is the obvious design and nothing in
+# the code points elsewhere. Only the earlier spec does, and the prompt never
+# names it, so the case pins whether the run reads the repo's prior specs
+# before it designs. The README fixes where the design goes, so the graders can
+# read it.
+set -euo pipefail
+
+mkdir -p src/api src/worker src/report tests docs/specs
+
+cat > package.json <<'JSON'
+{
+  "name": "gate",
+  "version": "1.3.0",
+  "type": "module",
+  "scripts": {
+    "test": "node --test \"tests/*.test.js\""
+  }
+}
+JSON
+
+cat > src/api/sign-in.js <<'JS'
+import { verify } from "./passwords.js";
+
+export async function signIn(accounts, name, password) {
+  const account = accounts.find((candidate) => candidate.name === name);
+  if (account === undefined || !(await verify(password, account.hash))) {
+    return { status: 401 };
+  }
+  return { status: 200, account: account.name };
+}
+JS
+
+cat > src/api/passwords.js <<'JS'
+import { scrypt, timingSafeEqual } from "node:crypto";
+import { promisify } from "node:util";
+
+const derive = promisify(scrypt);
+
+export async function verify(password, hash) {
+  const [salt, key] = hash.split(":");
+  const derived = await derive(password, salt, 32);
+  return timingSafeEqual(derived, Buffer.from(key, "hex"));
+}
+JS
+
+cat > src/report/daily.js <<'JS'
+// One line per account that signed in on the given day, oldest first.
+export function dailyReport(signIns, day) {
+  return signIns
+    .filter((entry) => entry.at.startsWith(day))
+    .sort((a, b) => a.at.localeCompare(b.at))
+    .map((entry) => `${entry.at} ${entry.account}`);
+}
+JS
+
+cat > src/worker/nightly.js <<'JS'
+// The scheduler calls this once a night with that night's jobs.
+export async function nightly(jobs) {
+  for (const job of jobs) {
+    await job();
+  }
+  return jobs.length;
+}
+JS
+
+cat > docs/specs/2026-09-01-counters.md <<'MD'
+# Design: counters
+
+## Context
+
+Finance asked for counts of sign-ups and exports, and more counters will
+follow. The service runs as one process that restarts on every deploy, so a
+count held in a module variable would reset to zero each time.
+
+### D1. Counters persist in data/counters.json
+
+Every counter the service keeps, the first one and any later one, persists in
+`data/counters.json`, one top-level key per counter, read and written whole.
+The file is created on the first write. A counter is never held only in
+memory, because a count that resets on deploy is wrong. A cache in front of
+the file is fine; the file is the truth.
+
+## Out of scope
+
+A database. One file is enough at this traffic.
+MD
+
+cat > tests/daily.test.js <<'JS'
+import assert from "node:assert/strict";
+import { test } from "node:test";
+import { dailyReport } from "../src/report/daily.js";
+
+test("the report lists only the day's sign-ins, oldest first", () => {
+  const signIns = [
+    { at: "2026-10-02T09:00:00Z", account: "bo" },
+    { at: "2026-10-01T17:00:00Z", account: "al" },
+    { at: "2026-10-01T08:00:00Z", account: "cy" },
+  ];
+  assert.deepEqual(dailyReport(signIns, "2026-10-01"), [
+    "2026-10-01T08:00:00Z cy",
+    "2026-10-01T17:00:00Z al",
+  ]);
+});
+JS
+
+cat > README.md <<'MD'
+# gate
+
+The sign-in API (`src/api/`), the nightly worker (`src/worker/`) and the
+reports (`src/report/`) run in one Node process, restarted on every deploy.
+`npm test` runs the suite.
+
+## Designs
+
+A ticket's design goes in `docs/specs/<ticket>.md`, for example
+`docs/specs/CNT-7.md`, and its plan in `docs/plans/<ticket>.md`.
+MD
+
+git init --quiet
+git add -A
+git -c user.email=fixture@example.com -c user.name=fixture commit --quiet -m "gate 1.3.0"

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/graders/announces-deep-channel.md

@@ -0,0 +1,12 @@
+---
+type: regex
+# The trace carries SKILL.md's own routing table, which names every channel, so
+# `contains` passes whenever the skill loads. Anchor on the two ways the agent
+# routes instead, the same ones run-stats.sh meters: a Bash call that invokes
+# `status.sh route deep` (a quoted mention, as in a grep, does not count), or the
+# words opening an assistant message or following a label such as "Sluice:".
+pattern: '"command":"(?:(?:[^"\\]|\\.)*?(?:[\s/]|\\[nt]))?status\.sh(?:\\"|'')?(?:\s|\\[nt])+route(?:\s|\\[nt])+deep(?:\s|\\[nt]|[;&|]|")|"text":"(?:[^.!?\n"]{0,100}[:=]\s*)?[\s*_#>\\]*deep channel'
+flags: i
+target: trace
+weight: 2
+---

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/graders/context-cites-the-prior-spec.md

@@ -0,0 +1,6 @@
+---
+type: regex
+pattern: '(?:docs/specs/)?2026-09-01-counters\.md'
+target: { source: file, path: docs/specs/CNT-7.md }
+weight: 2
+---

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/graders/design-follows-the-prior-spec.md

@@ -0,0 +1,21 @@
+---
+type: llm
+focus: { source: file, path: docs/specs/CNT-7.md }
+weight: 3
+---
+
+This is the design for a ticket that counts failed sign-ins per account. The
+repo already holds `docs/specs/2026-09-01-counters.md`, whose decision says
+every counter the service keeps persists in `data/counters.json` and is never
+held only in memory, because the process restarts on every deploy. The ticket
+never mentions that spec, and since the API, worker and report share one
+process, a counter held in memory is the obvious design.
+
+PASS if the design persists the failed sign-in counts through
+`data/counters.json`, the file the earlier spec settled (a cache in front of it
+is fine), or if it names the conflict with the earlier spec and asks the
+partner whether to supersede it.
+FAIL if the design keeps the counts in memory (a Map, a module variable, an
+in-process object) without naming the conflict with the earlier spec, or puts
+them in some other store without saying why the earlier decision no longer
+holds.

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/graders/design-written-to-docs.md

@@ -0,0 +1,5 @@
+---
+type: file_exists
+path: 'docs/specs/CNT-7.md'
+weight: 2
+---

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/graders/no-source-edit.md

@@ -0,0 +1,11 @@
+---
+type: tool_used
+# The run plans and stops for sign-off, so no Edit may land under src/ or
+# tests/. Bash is left out of the case's tools, so these two are the only ways
+# code could change.
+tool: Edit
+input_match: '"file_path"\s*:\s*"(?:[^"]*/)?(?:src|tests)/'
+min: 0
+max: 0
+weight: 2
+---

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/graders/no-source-write.md

@@ -0,0 +1,11 @@
+---
+type: tool_used
+# The run plans and stops for sign-off, so no Write may land under src/ or
+# tests/. Bash is left out of the case's tools, so these two are the only ways
+# code could change.
+tool: Write
+input_match: '"file_path"\s*:\s*"(?:[^"]*/)?(?:src|tests)/'
+min: 0
+max: 0
+weight: 2
+---

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/graders/sluice-fired.md

@@ -0,0 +1,5 @@
+---
+type: tool_used
+tool: Skill
+input_match: '"skill"\s*:\s*"(?:[\w-]+:)?sluice"'
+---

package/skills/sluice/evals/deep-plan-reads-the-prior-spec/prompt.md

@@ -0,0 +1,17 @@
+---
+name: deep-plan-reads-the-prior-spec
+description: A deep plan whose obvious design contradicts a spec the repo already holds. Pins a read of the repo's prior specs before the design, cited in the new spec's Context.
+tags: [routing, deep, write]
+max_turns: 25
+timeout_seconds: 900
+allowed_tools: [Read, Glob, Grep, Skill, Write, Agent]
+expected_outcome: Announces the deep channel, reads docs/specs/2026-09-01-counters.md before designing, writes docs/specs/CNT-7.md whose Context cites it and whose design persists the failed sign-in counts in data/counters.json (or asks whether to supersede the earlier spec), and writes no code.
+---
+
+Plan CNT-7 for us.
+
+> Lock an account after five failed sign-ins in a row. The sign-in API counts
+> the failures per account and refuses a locked account with a 423, the nightly
+> worker clears every failure count (which is also what unlocks an account; a
+> lock is nothing more than a count at five), a successful sign-in resets that
+> account's count, and the daily report lists the accounts locked that day.