3.1 KiB
name, description, allowed-tools
| name | description | allowed-tools |
|---|---|---|
| detector-cross-task-reference | Self-check whether your holistic rubric (or `instruction.md`) references another task — a separate task with its own prompt, workspace, and rubric that this task's grader will never see. The common slip: calibrating a new task against one you wrote earlier ("the failure-mode silhouette is similar to narrowed-too-early", "unlike the webhook-threat task"), which leaves a dangling pointer the grader can't resolve and couples two tasks that must stand alone. Each task has to be fully independent. Reads the holistic rubric file that `bash scripts/guidance-target.sh <slug>` resolves + instruction.md. | Bash, Read, Write |
Cross-task-reference detector
This skill checks whether your task stands on its own — whether your
holistic rubric (or instruction.md) explains this task's expected
behavior by pointing at a different task.
The grader evaluates your task in isolation. It sees only this task's
instruction.md, its workspace, and your holistic rubric (the file
bash scripts/guidance-target.sh <slug> resolves) — never any
other task. So a sentence like "the failure-mode silhouette is similar to
narrowed-too-early" or "unlike the webhook-threat task" is a dead end: the
grader can't look up what that other task was, and any calibration that hangs off
the comparison is lost. It also couples two tasks that are supposed to be
independent — if the other task is later changed or dropped, your rubric's
meaning silently shifts.
What is not a problem: citing your own source repo (grep "def as_json" app/models/), comparing the product to real companies ("similar to Earnin /
DailyPay"), or naming general concepts, patterns, and libraries. The defect is
specifically a pointer to another task in the set.
Read these before deciding:
.claude/skills/_detector-worker-shell.md— where to write the report and how to handle re-runs..claude/skills/detector-cross-task-reference/core.md— what counts as a cross-task reference vs. what doesn't, the 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
clean— your rubric and prompt stand on their own. No references to other tasks. Good. Move on.partial-reference— a borderline or low-severity reference (a generic "like other tasks" aside, or a token that might be a sibling-task name). Read the grounding; inline whatever the reference was gesturing at so nothing depends on another task.clear-reference— you reference a specific other task (a named sibling, a "similar to / unlike X" comparison, or borrowed calibration). Delete the cross-task comparison and state the point directly in terms of this task's own prompt and workspace. Keep any concrete in-this-task guidance (e.g. the exact grep or file to check) — it's only the pointer to the other task that has to go. Re-run after.not-applicable— there's no holistic rubric (or prompt) to assess yet. Draft it first.