| name | prime |
| description | Orient a fresh session against the tickets in this worktree before any plan is written: read them, ground them in the pinned AdCP version, and measure what BDD coverage actually exists. Use at the start of every session in a ticket worktree, including after compaction.
|
Prime
Produces a falsifiable orientation for the tickets in this worktree, then
stops. No plan, no code — the point is to know what is true before proposing
anything.
This skill does not restate the rules
CLAUDE.md and tests/CLAUDE.md are already loaded in every session. They own
the architecture patterns, the test-integrity policy, the DRY invariant and the
spec-grounding gate. Do not summarise them here or in your output.
A second copy of a rule drifts from the first, and drifted guidance in this repo
has repeatedly sent people at the wrong thing: a stale comment blaming
"generic-step shadowing" pointed at a bug fixed weeks earlier and cost about a
week; a ledger mis-cited its own graduation three separate times; a memory note
asserting a macOS/Linux duplication skew caused a legitimate ratchet improvement
to be reverted three times before anyone measured it.
So: rules live in CLAUDE.md. This skill produces only what is
ticket-specific and dynamic — things that change per ticket and can be
checked.
Steps
1. Read the tickets
cat TICKETS
gh issue view <n> --repo prebid/salesagent --comments
Read the comments, not just the body. In this repo the sharpest constraint is
often in a comment — and several issues carry a Measured on: <branch> @ <sha>
header. If it does, grep that tree, not yours. Four issues were once
declared false-premise because someone grepped only the checked-out branch; the
symbols were real, on the branch the author measured. Before writing "X does not
exist", run git log --all -S"X" --oneline.
2. Ground against the pinned AdCP version
Resolve the pin, do not assume it:
grep -n 'adcp==' pyproject.toml
grep -n 'targets AdCP spec' docs/adcp-spec-version.md
Then read the spec at that version — the worktree at ~/projects/adcp is
usually checked out somewhere else, so always go through git show:
cd ~/projects/adcp && git show v<PIN>:dist/schemas/<PIN>/<area>/<file>.json
cd ~/projects/adcp && git show v<PIN>:dist/docs/<PIN>/building/implementation/<tool>.mdx
For protocol behaviour, record the exact sentence that mandates it and
whether a conformance storyboard grades it — check
dist/compliance/<PIN>/ and say "ungraded" if nothing does. The installed SDK
is a cross-check, never the authority.
3. Measure the BDD coverage that exists
This is the part nothing else tells you. For the ticket's use case:
ls tests/bdd/features/BR-UC-*<area>*.feature
grep -c '^ Scenario' tests/bdd/features/BR-UC-<n>-*.feature
grep -n '@T-UC-<n>' tests/bdd/features/BR-UC-<n>-*.feature | head -20
grep -n 'T-UC-<n>' tests/bdd/conftest.py | head
grep -c '^tests/bdd/' tests/bdd/e2e_rest_known_failures.txt
Report numbers: how many scenarios, how many currently xfailed and why, how
many sit in the e2e_rest ledger. "N scenarios, M xfailed, 2 ledgered" is
checkable; "there is good coverage" is not.
If the ticket implies graduating an xfail, read
.claude/rules/workflows/xpass-graduation.md now, in full, before planning.
4. Note who will grade the work
Name them and point at their definitions — do not summarise their practices,
for the drift reason above:
ls .claude/agents/ 2>/dev/null
The code-review skill fans out reviewers covering DRY, testing, layering,
consistency, AdCP grounding, ratcheting allowlists and BDD grounding. Read the
relevant one's definition before writing code it will judge.
5. Note the tools that are not obvious
.agent-index/ — generated .pyi stubs. Read these before scanning the
tree; a full-tree grep for a symbol they already index is wasted work.ast-grep for structural queries; plain grep for text.saci test {unit,integration,bdd} <path|-k> runs slices on the CI box.
saci run is the full gate. saci run silently attaches to an in-flight
run for the same worktree — if you have just committed, check the box
actually has your change before trusting a green result.make quality is the local gate. It rewrites .duplication-baseline when
duplication genuinely drops; that is the ratchet working, not drift.
6. Write the orientation down
Into the ticket's bead if one exists, else .claude/research/<ticket>.md:
- the spec citation and whether it is graded
- the coverage numbers from step 3
- which files the change will touch
- the Core Invariant — one sentence naming what must stay true
- open questions that would change the approach
Then stop and report. Do not plan or implement until the orientation is
agreed.
Anti-patterns
- Restating
CLAUDE.md instead of measuring this ticket
- Asserting a symbol is absent from one branch's
src/
- Reporting prose where a count would be checkable
- Planning inside this skill — orientation first, agreement, then a plan
