/press

When to invoke: Harden the test surface after /cook — map changed behavior to tests, find weak assertions and missing boundaries, and add focused hardening tests. Use when the user wants the tests strengthened before review or shipping — phrases like “press the changes”, “harden this”, “check coverage”, “strengthen the tests”, “are the tests good enough”, “press before /age”, “/press”. Use even when the user wants to “tighten things up” before review. Do NOT use to add broad new behavior — only corrective fixes that hardening tests force.

Press may add or strengthen tests and make tiny corrective fixes only when a test exposes a clear defect in the cooked scope.

–hard propagation

/press --hard (propagated from /cook --hard) is pass-through only. Press runs no gate. Hand --hard forward to /age at the handoff so it eventually reaches /cure, which is the only pipeline skill that fires the metacognitive vibecheck. See skills/hard-cheese/SKILL.md.

Baseline-aware gates

When the cooked diff’s handoff slug carries a recorded baseline: block, press re-runs the project’s gates but does not re-flag or re-halt on failures identical to that baseline (same test, same signature) — only new or changed failures affect readiness. See ../cook/references/quality-gates.md for the classification and policy.

Flow

Read — load the spec or acceptance criteria and the cooked diff. If .cheese/glossary/<slug>.md exists, read it for naming consistency when hardening tests.
Map — for each changed behaviour, find the test(s) that cover it through semantic caller search.
Gap analysis — identify weak assertions, missing boundaries, and uncovered integration seams. See references/gap-analysis.md for what counts as a gap and the priority order.
Add focused tests — observe red first when behaviour changes. Apply precise stale-safe edits.
Corrective fixes — only for defects the hardening tests expose. No new behaviour.
Run checks — narrowest useful tests, then relevant wider gates already in the project. When the handoff carries a baseline: block, classify gate failures against it per ../cook/references/quality-gates.md: identical failures do not affect readiness; only new or changed failures do.
Report — write .cheese/press/<slug>.md (slug carried from /cook, or derived from branch/task) and print the path. Mark readiness: ready for /age, follow-up recommended, or blocked.
Hand off — in manual mode, prompt the next step via the shared handoff gate (see ## Handoff below); in --auto mode, chain forward per ## Auto mode.

Preferred tools and fallbacks

Call source-code search, read, and edit backends directly according to code-intelligence-routing.md. For coverage and test discovery, use semantic caller search plus tilth_deps when available.

Portability reference: ../cheese/references/harness-portability.md. It covers helper resolution, sub-agent dispatch, GitHub operations, and handoff transitions; prefer the bundled or repo-local helper first, and treat ${CLAUDE_SKILL_DIR} as optional host-provided fallback. The handoff blocks below are the portable contract; slash commands are host renderings, not the control model.

Beyond source-code routing there are press-specific tools:

Need	Prefer	Fallback
Diff review	`delta`	plain `git diff`
Affected execution flows + risk scoring	semantic caller/dependency tracing and `tilth_deps`	manual flow tracing from changed files; note the precision loss

If optional tools are missing, press a narrower surface and state the residual risk.

Output

House style and citation form: ../cheese/references/formatting.md. This section owns the press-report shape.

Write to .cheese/press/<slug>.md with a minimum handoff slug at the top so /cook’s fan pathway and /cheese --continue can chain without re-parsing the report. The full report shape:

status: ok | halt: <one-line reason>
next: press | age | done
artifact: <path-if-any>
baseline: none | <recorded baseline block copied from the cook handoff — see ../cook/references/quality-gates.md>
<one-line orientation: what press did — e.g., "added 4 boundary tests; no defects exposed">

# Press Report — <slug>

## Orientation
<one or two factual sentences about what press did this pass — the hardening added, the gaps closed, the readiness verdict. `/cheese --continue` surfaces the slug's orientation line to the user as "where you are", so press's orientation must describe press's own work, not duplicate cook's orientation.>

## Checks run
- <command>: <pass|fail|skipped with reason>

## Findings
| Severity | Category | Evidence | Recommendation |
| --- | --- | --- | --- |

## Coverage
- Spec coverage:
- Boundary coverage:
- Assertion strength:

## Readiness
<ready for /age | follow-up recommended | blocked>

## Next step
<ready for /age>:           /age <slug>           — review the cooked + pressed diff
<follow-up recommended>:    /age <slug>           — review-safe; documented follow-ups addressed after review
<blocked>:                  resolve blocking issues before proceeding

status: ok maps to readiness ready for /age or follow-up recommended; status: halt: <reason> maps to blocked. next: names the next runnable phase: age when review-safe, press when blocking issues must be resolved and the hardening phase rerun. Use next: done only for true terminal completion, not for a blocked-but-resumable halt. /ultracook still stops automatically on any status: halt; next: is the resume hint for /cheese --continue.

When baseline: is present, press honors it: identical recorded failures never move readiness off ready for /age; only new or changed failures do, per ../cook/references/quality-gates.md.

Then print:

Press report: .cheese/press/<slug>.md
Next step:    /age <slug>                          (when ready for /age or follow-up recommended)
              blocked — resolve before continuing  (when blocked)

Handoff

Pipeline: culture → mold → cook → [press] → age → cure → plate

After the press report is on disk, ask via the shared handoff gate in ../cheese/references/handoff-gate.md, following its Standard forward-step menu. Lead each option with the verb (what the user wants to do next); the skill command (with any in-scope --hard propagation) is the backing detail. Default options:

Review the diff (recommended when readiness is ready for /age or follow-up recommended) — /age <slug>. For follow-up recommended, documented follow-ups can be addressed after review.
Plate it — /age <slug> --auto --open-pr: run age → cure, then /plate resolves topology and publishes.
Checkpoint & stop — /wheypoint: write a resumable handoff and pause.
Stop — dispatch none; defer review (use this if you want to harden manually before /age, even though the contract is review-safe).

Pre-select Review the diff when ready. If blocked, do not pre-select Plate it. Run a non-stop selection immediately.

Auto mode

When invoked with --auto (propagated from /cook --auto):

Skip the handoff gate entirely.
If readiness is ready for /age or follow-up recommended, invoke /age <slug> --auto directly (forward --open-pr when it is in scope).
If readiness is blocked, stop the auto chain and surface the press report to the user. Blocked criteria: defined once in references/gap-analysis.md.

Within cook’s own fan pathway

When /cook’s fan pathway (its retired-/ultracook mechanics, now self-hosted — see skills/cook/SKILL.md ## Fan pathway) spawns press as a fresh-context sub-agent, it owns the chain itself. When the spawn prompt explicitly says “for THIS PHASE ONLY” and “do not chain forward to the next phase,” honour the override: write .cheese/press/<slug>.md (with the handoff slug at the top) and stop. Do not invoke /age <slug> --auto from inside the sub-agent regardless of readiness. The orchestrator reads the handoff slug and either chains to age (when status: ok and next: age) or halts (when status: halt, regardless of next:). next: remains the resume hint for /cheese --continue.

Rules

Do not weaken assertions.
Do not broaden implementation beyond the cooked contract.
Every changed behaviour in the cooked diff leaves press with an executable hardening test that would fail if the change regressed. If press cannot produce a stable hardening test for a changed behaviour (flaky seam, missing infrastructure, design decision required), readiness is blocked — never ready for /age or follow-up recommended.
Cap iteration at three attempts per gap. Count test-edit + run cycles. On the third failed cycle on the same gap, mark readiness blocked with reason spinning: <gap-description> and surface the report. Do not loop indefinitely.
Surface medium and high findings explicitly; summarize low findings.
If the cooked diff or spec rests on a false premise (the contract is wrong, or the test surface is solving the wrong problem), stop and surface the premise before adding tests; do not harden the wrong angle.
Apply the shared voice kernel (lives at ../age/references/voice.md): lead the press report with the readiness verdict, flag residual risk as certain | speculating | don't know, agree when coverage is already sufficient without manufacturing tests.

Gap analysis

What counts as a gap

Gap type	Symptom	Example
Spec uncovered	A spec bullet has no executable test	“Returns 401 on missing token” with no test for that path
Weak assertion	Test passes for the wrong reason	`expect(result).toBeTruthy()` instead of `expect(result).toEqual(expected)`
Missing boundary	Edge case not exercised	empty input, null, max-length, off-by-one, concurrent access
Integration seam	Cooked code crosses a boundary that is mocked or untested	filesystem write, subprocess, network call, time-dependent logic
Error path	Happy path tested, failure path not	What happens when the dependency throws?

Mapping changed behaviour to tests

For each function or module touched by the cooked diff:

Find existing tests through semantic caller search, following the shared routing contract. With tilth:
```
tilth_search(queries: [{query: "<changed-symbol>", kind: "callers"}], scope: "**/*.test.*")
```
Read the test bodies to verify they actually exercise the new behaviour, not just the symbol’s existence.
List any spec bullet without a corresponding test.

Priority order

Hard floor — every changed behaviour gets a hardening test. Before working through the priority list, lock each behaviour in the cooked diff with an executable test that would fail on regression. Even a 3-line off-by-one fix gets a test_off_by_one_at_boundary. If press cannot produce a stable hardening test for a changed behaviour, readiness is blocked.

Then address remaining gaps in this order — stop when the time-budget runs out:

Spec compliance: every promised behaviour has executable coverage.
Assertion strength: tests fail for wrong values, wrong errors, or wrong state.
Boundary behaviour: empty, missing, malformed, minimal, maximum.
Integration seams: filesystem, subprocess, network, time, dependency failure when in scope.
Happy path regression: the primary user path still passes.

Mapping to readiness:

blocked — false premise on the cooked contract, hard floor unmet (a changed behaviour has no stable hardening test press can write), an unfixable level-1/2 gap inside cooked scope, or spinning wheels (three attempts at one gap without green).
follow-up recommended — hard floor met. Only level-4/5 gaps remain, plus out-of-scope findings and untouched-code coverage. Cooked contract is review-safe; follow-ups are documented for post-review attention.
ready for /age — hard floor met. Levels 1-3 closed on cooked scope.

Spinning-wheels cap: count test-edit + run cycles per gap. On the third failed attempt without green, mark readiness blocked with reason spinning: <gap-description> and stop.

When to fix vs follow-up

Situation	Action
Hardening test exposes a bug in cooked code	Fix it now (corrective fix only — no new behaviour).
Hardening test exposes a bug outside cooked scope	Document it in the press report; do not fix.
Coverage gap is in code that cook did not touch	Document it in the press report; do not add tests.

Hard rule — never weaken assertions

If a hardening test reveals that an existing test passes for the wrong reason, strengthen the existing test. Do not delete it, do not loosen its assertion, do not skip it. If you must skip it temporarily, the press report says exactly which test and why, and recommends a follow-up issue.