---
name: detector-offline-verifiability
description: |
  Self-check whether your task makes sense in the no-network sandbox it runs
  in. The test agent's environment is initialized up front — repo checked
  out, packages installed — and then runs with no outbound network access, so
  a good task is offline-completable and offline-verifiable: a competent SWE
  could do the work AND trust their verification of it entirely from within
  the repo. Flags tasks whose success criteria live materially outside the
  sandbox — "speed up our CI/CD pipeline" (verifying needs the live
  pipeline), "redeploy to prod" (prod doesn't exist in the sandbox),
  "migrate from Zendesk to Intercom" (neither service is reachable, so
  mocks are guesses that likely won't survive real integration), "check the
  dashboard," published-package behavior. External services as scenario
  dressing are fine; protocol-slice integrations against a faithful local
  fake are fine. Explicitly advisory: every finding is something to
  consider, never a failure, and it blocks nothing. Reads instruction.md +
  the resolved holistic rubric (+ the workspace for local fakes); runs
  before or after reference runs exist.
allowed-tools: Bash, Read, Write
---

# Offline-verifiability detector

This skill checks one of your tasks for **offline-verifiability** — whether
the ask still makes sense inside the sandbox the test agent actually gets.
That sandbox is initialized before the task starts (repo checked out,
dependencies installed) and then has **no outbound network access**. So the
question is: could a competent SWE complete AND verify your task entirely
from within the initialized repo — and would their "it works" actually be
trustworthy?

The failure shape to catch: tasks whose *success criteria* live outside the
sandbox. "Speed up our CI/CD pipeline" — the pipeline the work would be
verified against isn't there. "Redeploy to prod" — there is no prod. "Migrate
from Zendesk to Intercom" — the agent can't interact with either service, so
it can only mock both ends, and mocks written without ever touching the real
services almost certainly won't work at integration time. When a task has
this shape, the grade measures how convincingly the agent pantomimes the
work, not whether the work is right — and an agent that honestly says "I
can't verify this from here" can end up scoring worse than one that
confidently fakes it.

What *doesn't* trip this check: external services as scenario dressing (a
prompt set at a company that uses Stripe is realism, as long as the graded
work and its verification are local), and integrations scoped to a documented
protocol slice with a faithful local fake — ideally wired through the fake
providers your repo already ships (see `/brainstorm-product-arcs` for the
"simulate the protocol, not the product" filter this mirrors).

**This check is advisory.** Where the line falls is a judgment call — a task
can even be deliberately built around recognizing the sandbox's limits, with
a holistic rubric that credits saying so. The report exists so you can *consider*
where your success criteria live: each finding quotes the passage, says what a
human SWE would need the network or a live system for, and offers a rescoping
option, so the decision stays yours. Nothing here blocks your submission.

Read these before deciding:

1. `.claude/skills/_detector-worker-shell.md` — where to write the report and how to handle re-runs.
2. `.claude/skills/detector-offline-verifiability/core.md` — the controlling test (offline-completable + offline-verifiable), the external-dependency shapes, the mock-fidelity boundary, what is NOT a finding, verdict enums, and the body schema.

Compose the report per the schema in `core.md` and write it per `_detector-worker-shell.md`.

## Acting on the verdict

- **`offline-verifiable`** — the work and its verification both live inside
  the workspace; any external names are scenario context or faithfully
  faked. Good. Move on.
- **`partial`** — the core of your task is offline-completable, but some
  success criteria lean outside: a "works in prod"-shaped expectation, a
  local proxy (config parses, unit tests pass) standing in for an external
  outcome (the pipeline gets faster), or a mock whose fidelity is carrying a
  lot of the grade. Read each finding and decide: tighten the prompt so it
  asks for the local slice, point the criterion at your repo's fake provider,
  or keep the framing deliberately and make sure your holistic rubric grades
  only what the sandbox can check (crediting honest disclosure of the rest).
- **`not-offline-verifiable`** — the system your task operates on (pipeline,
  prod, third-party service) isn't in the sandbox and can't be faithfully
  faked, so neither doing the work well nor verifying it can happen there.
  Consider the rescoping option in each finding: extract the protocol slice
  and build an adversarial local mock for it, reframe the ask as an
  assessment or plan graded on repo evidence, or pick a different behavior to
  test. If you believe the task works as-is, that's your call — but make sure
  the holistic rubric never asks the grader (or the agent) for a verification
  the sandbox cannot perform.
- **`not-applicable`** — there's no prompt to assess yet. Draft it first.