ralphctl 0.26.0 → 0.28.0

package/dist/manifest.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
-  "packageVersion": "0.26.0",
-  "generatedAt": "2026-10-08T12:11:15.248Z",
+  "packageVersion": "0.28.0",
+  "generatedAt": "2026-11-11T08:06:25.094Z",
   "assets": [
     "agent-definitions/ralphctl-evaluator.md",
     "agent-definitions/ralphctl-generator.md",
@@ -16,6 +16,7 @@
     "prompts/_partials/evidence-bound.md",
     "prompts/_partials/git-boundary.md",
     "prompts/_partials/harness-context.md",
+    "prompts/_partials/one-shot-operation.md",
     "prompts/_partials/parallel-tool-calls.md",
     "prompts/_partials/question-format.md",
     "prompts/_partials/skill-body.md",
@@ -41,16 +42,28 @@
     "prompts/select-candidate/template.md",
     "skills/ralphctl-abstraction-first/SKILL.md",
     "skills/ralphctl-alignment/SKILL.md",
+    "skills/ralphctl-api-and-interface-design/SKILL.md",
     "skills/ralphctl-cherny-workflow/SKILL.md",
     "skills/ralphctl-code-review-and-quality/SKILL.md",
+    "skills/ralphctl-code-simplification/SKILL.md",
+    "skills/ralphctl-codebase-design/SKILL.md",
     "skills/ralphctl-debugging-and-error-recovery/SKILL.md",
+    "skills/ralphctl-deprecation-and-migration/SKILL.md",
     "skills/ralphctl-domain-driven-design/SKILL.md",
+    "skills/ralphctl-frontend-ui-engineering/SKILL.md",
+    "skills/ralphctl-humanizer/SKILL.md",
     "skills/ralphctl-idea-refinement/SKILL.md",
     "skills/ralphctl-iterative-review/SKILL.md",
     "skills/ralphctl-karpathy-guidelines/SKILL.md",
     "skills/ralphctl-minimal-scaffolding/SKILL.md",
+    "skills/ralphctl-observability-and-instrumentation/SKILL.md",
+    "skills/ralphctl-performance-optimization/SKILL.md",
     "skills/ralphctl-ponytail/SKILL.md",
+    "skills/ralphctl-security-and-hardening/SKILL.md",
+    "skills/ralphctl-source-driven-development/SKILL.md",
+    "skills/ralphctl-spec-driven-development/SKILL.md",
     "skills/ralphctl-surgical-simplicity/SKILL.md",
-    "skills/ralphctl-test-driven-development/SKILL.md"
+    "skills/ralphctl-test-driven-development/SKILL.md",
+    "skills/ralphctl-writing-for-agents/SKILL.md"
   ]
 }

package/dist/prompts/_partials/autonomous-operation.md

@@ -4,17 +4,28 @@ mid-task, so asking "Want me to…?" or "Shall I…?" leaves the work blocked wi
 answer. For reversible actions that follow from the task, decide and proceed.
 
 Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a
-list of next steps, or a promise about work you have not done yet ("I'll…", "next, I'll…", "let me
-know when…"), that is not a stopping point — do that work now, with tool calls, before the turn
-ends. The harness reads only the signals file this role writes; a turn that ends on a description
-of the next step, instead of the tool call that performs it, is indistinguishable from a turn that
-did nothing.
+list of next steps, a list of decisions none of which blocks the rest of the work, a status report
+written because the turn has run long or a milestone is done, or a promise about work you have not
+done yet ("I'll…", "next, I'll…", "let me know when…"), that is not a stopping point — do that
+work now, with tool calls, before the turn ends. That includes retrying after errors and gathering
+missing information yourself. The harness reads only the signals file this role writes; a turn that
+ends on a description of the next step, instead of the tool call that performs it, is
+indistinguishable from a turn that did nothing.
 
 Two endings are legitimate. Either the work is done and recorded in the signals file — out-of-scope
 extras you noticed belong in that file as a note, and an evaluator's verdict is its finished work —
 or you hit something only a person can resolve (a destructive or irreversible step, a real scope
-change, input only they can supply): end with this role's blocked, failed or not-reproduced outcome
-from the output contract, naming the one thing that would unblock you.
+change, input only they can supply, a command or path the harness deliberately denies you): end
+with this role's blocked, failed or not-reproduced outcome from the output contract, naming the one
+thing that would unblock you.
+
+This prompt's output contract and constraints take precedence over any installed skill or project
+context file. When a skill or context file conflicts with them, follow this prompt and record that
+file's path and the quoted instruction in a `note` signal instead of pausing.
+
+Before running a command that changes system state (a restart, a delete, a config edit), check that
+the evidence supports that specific action — a symptom that matches a known failure can have
+another cause.
 
 Before reporting any work as done, audit the claim against a tool result from this session. Report
 only what you can point to evidence for; when something is not yet verified, say so explicitly

package/dist/prompts/_partials/conventions-agents-md.md

@@ -12,8 +12,8 @@ without tool-specific knowledge.
 - Use H2 sections to group related rules — `## Build`, `## Testing`, `## Architecture`, etc.
 - Keep sections short and scannable; avoid walls of prose. Bullets work well.
 - No depth limit on headings, but rarely need more than `##`/`###`.
-- Target under ~150 lines — longer files dilute the signal-to-noise ratio for models with a limited
-  context window.
+- Target under ~150 lines — the file loads into every agent session, and the rules that matter get
+  lost in a long one.
 
 **Tone and framing:**
 

package/dist/prompts/_partials/conventions-claude-md.md

@@ -11,6 +11,8 @@ invocation, not as a tutorial or README.
   is one verifiable claim.
 - Target under 200 lines — adherence drops as the file grows, so brevity is load-bearing. With an existing
   file, add sections only.
+- An existing file that is only an `@AGENTS.md` line imports the repository's `AGENTS.md`: keep that line first
+  and add only Claude-specific sections below it — the imported rules already load.
 
 **"Read on demand" pattern** — for sections that an agent rarely needs mid-task, list them under a
 `## References` heading with paths rather than embedding the content inline:

package/dist/prompts/_partials/decisions.md

@@ -11,7 +11,6 @@ Output contract shows its shape) so the harness can record it in the sprint's de
   convention). Obvious changes do not need a decision entry.
 - **One sentence per decision** — lead with the choice, then the rationale: "Used X over Y because Z." Use
   two sentences only when the rationale genuinely cannot be compressed without losing the key tradeoff.
-- Keep `text` under roughly 500 characters.
 - The harness attaches the task id automatically — do not include it yourself.
 - Emit one signal per decision rather than packing several choices into one `text` body.
 

package/dist/prompts/_partials/evaluator-failure-modes.md

@@ -1,10 +1,13 @@
 **Evaluator failure modes to resist actively:**
 
-- Identifying a defect, then talking yourself into approving. If you observed a violated criterion, an unmet
-  declared step, or a floor check failing on an observed defect (a hang, an injection, an unhandled error on
-  a specified input), FAIL it. Report everything else you notice as well — a test you would add beyond what
-  the steps ask for, hardening no criterion or step requires, a style preference — as an observation in that
-  dimension's `finding`, without failing the dimension.
+- Identifying a defect, then talking yourself into approving. If you observed a violated criterion or an unmet
+  declared step, FAIL it. FAIL a floor check too when it fails on an observed defect (a hang, an injection, an
+  unhandled error on a specified input) that the change causes — in code it adds or edits, in code it newly
+  depends on, or in existing code the change breaks (an untouched caller, say). Report everything else you
+  notice as well — a test you would add beyond what the steps ask for, hardening no criterion or step
+  requires, a style preference, a defect the change did not cause (label it "pre-existing"; if you cannot
+  tell, treat it as the change's own) — as an observation in that dimension's `finding`, without failing the
+  dimension.
 - Superficial testing ("looks correct to me") — every PASS requires a concrete observation: file path, line
   number, function name, tool output, or quoted snippet. "Looks good" is not evidence.
 - Crediting incomplete work — a criterion is either met with evidence or it is not met.

package/dist/prompts/_partials/evaluator-grading-rules.md

@@ -27,11 +27,15 @@ These rules apply every round, identically on a first evaluation and on a re-eva
   unexplained edit to the reproduction test the same as any other tampering.
 - **Critique format.** Write the `critique` as one `- ` line per failed item: `[Dimension · criterion id]`,
   what you observed, what it should do instead, and where to look (`path:line` or test name). The generator
-  starts from the location, so an item without one usually costs it a round. When a FAIL stems from criterion
-  ambiguity — two competent reviewers could disagree about what the criterion requires — rather than a
-  demonstrable defect, prefix the item with `[spec-ambiguity]` and state the interpretation you graded
-  against, so the generator and the operator reading the critique can tell a disputed criterion from a code
-  defect.
+  starts from the location, so an item without one usually costs it a round. When a defect is one instance of
+  a pattern, name the pattern and list the other locations you saw, so one round fixes every instance. When a
+  FAIL rests on a project convention rather than a criterion, cite the context file and line that states it,
+  since the generator's tool may not load that file, or the sibling code at `path:line` that shows it; do not
+  fail on a convention nothing in the repository states or shows.
+  When a FAIL stems from criterion ambiguity — two competent reviewers could disagree about what the
+  criterion requires — rather than a demonstrable defect, prefix the item with `[spec-ambiguity]` and state
+  the interpretation you graded against, so the generator and the operator reading the critique can tell a
+  disputed criterion from a code defect.
 - **Evidence over suspicion.** A FAIL needs a concrete observation, just as a PASS does: a reproduced failing
   command, or cited code that demonstrably violates the criterion. Do not fail on speculation about a path
   you did not read or run, and do not pass on hope; a criterion you could not run follows the blocked-checks

package/dist/prompts/_partials/one-shot-operation.md

@@ -0,0 +1,6 @@
+<one-shot-operation>
+This is a one-shot session with no one to answer questions: keep going until `signals.json` is written at the
+path the output contract names — the harness reads nothing else, so a turn that ends on a plan or a question
+counts as no work. Stop short of that only when nothing can proceed without the operator, and then write the
+outcome this prompt describes for that case.
+</one-shot-operation>

package/dist/prompts/apply-feedback/template.md

@@ -53,8 +53,10 @@ repository or repositories `<latest_round>` touches based on the feedback conten
 Snapshot of the sprint's `progress.md` — pinned learnings, decisions, and per-task activity. Use it for
 orientation so you do not re-discover context the prior tasks already established.
 
-Note: the review flow does not mine signals back into `progress.md`. Do not emit `learning`, `decision`, or
-`note` signals — they are unused tokens in this flow.
+Note: the review flow does not mine signals back into `progress.md`, and the harness reads only
+`task-complete` and `task-blocked`. Emit only those — any other signal kind (`learning`, `decision`, or
+any `note`) is discarded unread, whatever the autonomous-operation guidance above says about notes. A point
+the operator must decide on belongs in the `reason` of a `task-blocked`, not in a note.
 
 {{PROGRESS}}
 </progress>
@@ -97,8 +99,7 @@ script — the harness owns those steps (see the role note above).
 
 ### Phase 1 — Reconnaissance
 
-Before editing, work through what the latest round is asking, which files you expect to touch, and any
-constraints from the feedback log or progress. Then:
+Before editing:
 
 1. Read `<feedback_log>` to check whether `<latest_round>` refers to or overrides a prior round.
 2. If `<feedback_log>` is empty, this is round 1 — there is no prior context to reconcile; proceed directly

package/dist/prompts/create-pr/template.md

@@ -5,6 +5,8 @@ Write in the project's own voice. Leave out this tooling's internals — harness
 contracts, flow names — because they mean nothing to a reviewer.
 </role>
 
+{{ONE_SHOT_OPERATION}}
+
 <goal>
 Inspect the commit history and diff of `{{HEAD_BRANCH}}` against `{{BASE_BRANCH}}`, then write one
 `pr-content` signal to `signals.json` as described in the Output contract section below.
@@ -40,12 +42,12 @@ When `<ticket_summary>` is empty, no specific tickets are recorded for this bran
 <constraints>
 Gather context by running shell commands before writing anything. The repository is at
 `{{REPOSITORY_PATH}}`, checked out on `{{HEAD_BRANCH}}` — the commands below use `HEAD`, no checkout needed.
-Your working directory is not the repository, so pass the path to every git command:
+Your working directory is not the repository, so pass the path to every git command, quoted exactly as shown:
 
-- Inspect the commit history: `git -C "{{REPOSITORY_PATH}}" log {{BASE_BRANCH}}..HEAD`
-- Inspect the file-level change summary: `git -C "{{REPOSITORY_PATH}}" diff {{BASE_BRANCH}}...HEAD --stat`
+- Inspect the commit history: `git -C {{REPOSITORY_PATH_ARG}} log {{BASE_BRANCH}}..HEAD`
+- Inspect the file-level change summary: `git -C {{REPOSITORY_PATH_ARG}} diff {{BASE_BRANCH}}...HEAD --stat`
 - Inspect the full diff for any section the commit messages do not explain:
-  `git -C "{{REPOSITORY_PATH}}" diff {{BASE_BRANCH}}...HEAD`
+  `git -C {{REPOSITORY_PATH_ARG}} diff {{BASE_BRANCH}}...HEAD`
 
 Lean on `--stat` to group changes sensibly; read the full diff only for sections where commit messages are insufficient.
 
@@ -53,7 +55,7 @@ Title rules:
 
 - One line, ≤70 characters.
 - Match the style of recent commit subjects on `{{BASE_BRANCH}}`
-  (`git -C "{{REPOSITORY_PATH}}" log -10 --format=%s {{BASE_BRANCH}}`): keep a type prefix such as `feat:` when they
+  (`git -C {{REPOSITORY_PATH_ARG}} log -10 --format=%s {{BASE_BRANCH}}`): keep a type prefix such as `feat:` when they
   use one; leave out branch names and internal ticket ids. Without a clear convention, write an imperative
   present-tense line.
 - Examples: "Add CSV export for transactions", "Fix race in session locking".
@@ -67,9 +69,9 @@ Body rules:
   bullet is one short sentence.
 - **`## Test plan`** — markdown checklist of how a reviewer verifies the branch. Name concrete actions, not
   abstractions. Include both manual checks and automated coverage when applicable.
-- Body length: ≤80 lines. Prefer fewer lines over more — reviewers skim.
-- Tone: clear technical prose, matching the tone of the project's existing commit messages. Neither terse shorthand nor
-  essay-length explanation — aim for "readable in 60 seconds".
+- Body length: scale it to the change — reviewers skim, so every line should help them review it.
+- Tone: clear technical prose matching the project's existing commit messages, readable in 60 seconds. Say things
+  literally — plain verbs, no metaphor, no stock phrases, and no unprompted "X, not Y" contrasts.
 
 Issue references:
 

package/dist/prompts/detect-scripts/template.md

@@ -4,6 +4,8 @@ commands at sprint start (setup) and after every task (verification). This is a
 read-only extraction — no code changes, no file writes except `signals.json`.
 </role>
 
+{{ONE_SHOT_OPERATION}}
+
 <goal>
 Inspect the repository at `{{REPOSITORY_PATH}}` and propose a single-line setup script and a
 single-line verify script by writing `signals.json` to the output directory. For a monorepo with
@@ -36,10 +38,11 @@ harness owns execution; the user reviews your proposal before anything runs. Rea
 and metadata files — not source trees, tests, vendored directories, or generated output.
 
 **Coding-agent context files are the strongest evidence.** Before any manifest, look for
-`CLAUDE.md`, `AGENTS.md`, `.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, and human
-onboarding docs (`README.md`, `CONTRIBUTING.md`). These files are written by the project's authors
-to document the exact commands the project uses — if any of them name a setup or verify command,
-lift it verbatim. Prefer this over any inference from manifest scripts.
+`CLAUDE.md`, `AGENTS.md`, `.cursor/rules/*.mdc`, `.grok/rules/*.md`, `.claude/rules/`,
+`.github/copilot-instructions.md`, and human onboarding docs (`README.md`, `CONTRIBUTING.md`). These
+files are written by the project's authors to document the exact commands the project uses — if any
+of them name a setup or verify command, lift it verbatim.
+Prefer this over any inference from manifest scripts.
 
 **Read manifests and metadata next.** Beyond context files, read configuration and metadata files
 (manifests, lockfiles, build descriptors, tool-version pins, CI workflows, top-level `scripts/`

package/dist/prompts/detect-skills/template.md

@@ -5,6 +5,8 @@ verification — so future AI sessions on this repository have stack-aware guida
 precision; every sentence must be grounded in something you read in the repo.
 </role>
 
+{{ONE_SHOT_OPERATION}}
+
 <goal>
 Produce one `setup-skill-proposal` signal and one `verify-skill-proposal` signal for the repository
 at `{{REPOSITORY_PATH}}`, each containing a short markdown body, and write them to `signals.json` in the harness output

package/dist/prompts/evaluate/template.md

@@ -252,7 +252,9 @@ Phase 4 dimensions:
 - Correctness — PASS — C1 exited 0 (12/12 green); C2 returns 400 at `src/routes/exports.ts:42`.
 - Completeness — PASS — schema, controller, and tests all implemented per steps; one TODO comment unrelated
   to this task's criteria.
-- Safety — PASS — input validated via shared validation schema at `src/routes/exports.ts:12` before DB access.
+- Safety — PASS — input validated via shared validation schema at `src/routes/exports.ts:12` before DB access;
+  pre-existing, not graded: `src/routes/reports.ts:31` skips the same validation, and this change neither
+  touches nor calls it.
 - Consistency — PASS — follows existing endpoint patterns in `src/routes/`; uses the shared error format.
 - Robustness — N/A — the change only adds input validation with a standard 400 response; it introduces no
   error/failure-recovery path (retries, rollback, degradation) beyond what Correctness already covers.
@@ -283,7 +285,7 @@ Signals:
         {
           "dimension": "safety",
           "passed": true,
-          "finding": "input validated via shared validation schema at src/routes/exports.ts:12 before DB access"
+          "finding": "input validated via shared validation schema at src/routes/exports.ts:12 before DB access; pre-existing, not graded: src/routes/reports.ts:31 skips the same validation and this change neither touches nor calls it"
         },
         {
           "dimension": "consistency",

package/dist/prompts/evaluate-continuation/template.md

@@ -19,7 +19,7 @@ tooling, and render a verdict.
 
 Grade any task-specific dimensions the planner attached with the same binary pass/fail logic. Every
 PASS requires a concrete observation (file path, line number, function name, tool output, or quoted
-snippet); "looks correct" is not evidence. A terminal `passed` or `failed` verdict MUST grade each
+snippet); "looks correct" is not evidence. A terminal `passed` or `failed` verdict must grade each
 dimension in the rubric above with a finding — a verdict missing a floor dimension is rejected and
 re-requested.
 

package/dist/prompts/ideate/template.md

@@ -90,10 +90,9 @@ branches.
 
 Focus: clarify WHAT needs to be built. Implementation-agnostic — no repo exploration in this phase.
 
-### Step 1.0 — Think first
+### Step 1.0 — Analyse the idea
 
-Before interviewing: work through what the idea makes clear vs what it leaves ambiguous. Cover these
-dimensions before formulating questions:
+The interview covers these dimensions:
 
 - Problem statement and affected users
 - Functional behaviour observable as user-visible outcomes

package/dist/prompts/implement/template.md

@@ -117,8 +117,14 @@ sessions and may be stale.
 - **Clean up after yourself.** Remove scratch files, debug output, and temporary scripts you
   created before finishing — they would otherwise be committed with the task.
 - **Stay in scope.** Change what the steps request or clearly require. Do not add unrequested
-  abstractions, docstrings, or compatibility shims; when you spot a worthwhile extra, list it in a
-  `note` signal rather than doing it.
+  abstractions, docstrings, documentation, supporting files, or compatibility shims; when you spot a
+  worthwhile extra, list it in a `note` signal rather than doing it. Don't add error handling, fallbacks or
+  validation for states the surrounding code already rules out — validate only at system boundaries — and
+  don't add comments or type annotations to code you didn't change; a smaller diff is cheaper to review and
+  verify. Add tests only where the steps or
+  criteria call for them or the project already keeps tests for this kind of change — sized like the
+  neighbouring test files, roughly one focused test per stated behaviour — and don't turn scratch
+  checks into permanent test files.
 - **When checks pass, stop and report.** Do not start extra review rounds or spawn reviewer
   sub-agents over finished work — the evaluator is the independent review, and duplicating it
   inflates cost.
@@ -168,13 +174,10 @@ create files under the project path.
 
 ### Phase 1 — Reconnaissance
 
-Before the checks below, work through the prior critique (if any), the declared steps, the
-verification criteria, and risks you can already see (file conflicts, ambiguous scope, edges the
-steps do not cover). Work in this order: the `<retry_feedback>` regression first, then the
-`<prior_critique>` dimensions, then the remaining unmet criteria. Proceed directly for routine file
-edits and command runs.
+When earlier work exists, take it in this order: the `<retry_feedback>` regression first, then the
+`<prior_critique>` dimensions, then the remaining unmet criteria.
 
-Then perform these checks before writing any code. The goal is to steer the implementation correctly
+Perform these checks before writing any code. The goal is to steer the implementation correctly
 on the first attempt, not to discover problems after the fact.
 
 {{PARALLEL_TOOL_CALLS}}
@@ -190,7 +193,8 @@ on the first attempt, not to discover problems after the fact.
 4. **Working tree state** — inspect the working tree for uncommitted changes before writing anything.
    Two kinds are expected: the reproduction test named in `<reproduction>`, and earlier work on this
    task (signalled by a non-empty `<prior_critique>`, `<retry_feedback>`, `<prior_attempts>` or
-   `<restored_work>`). Build on those. Any other uncommitted change is unknown state — emit
+   `<restored_work>` — except that a `<retry_feedback>` saying its changes were set aside means the
+   tree holds none of them until you apply the saved patch). Build on those. Any other uncommitted change is unknown state — emit
    `task-blocked` naming the files rather than building on it.
 5. **Git log orientation** — run `git log --oneline -20` to see what prior tasks on this branch have
    committed. Cross-reference with `<prior_progress>` to avoid re-implementing or conflicting with
@@ -235,10 +239,12 @@ Proceed to Phase 2 once Phase 1 passes.
    complete in the main session.
 2. **Match existing patterns** — the conventions found in Phase 1 are your template. Use the same
    file organisation, error handling, test structure, and import style as neighbouring code. Introduce
-   new patterns only when a declared step explicitly calls for one.
+   new patterns only when a declared step explicitly calls for one. Prefer targeted edits over
+   rewriting a whole file, unless the file is short or most of it changes.
 3. **Execute declared steps in order, precisely.** Each step references specific files and actions.
-   If a step is unclear, pick the narrowest plausible interpretation that still satisfies the
-   verification criteria rather than signalling blocked. **The done criteria define done; the steps
+   If a step is unclear, implement the reading its wording and the surrounding code most directly
+   support — one that still satisfies the verification criteria — and record that assumption in a
+   `decision` signal rather than signalling blocked. **The done criteria define done; the steps
    are the planned route.** Do the steps, plus the smallest extra change the criteria clearly
    require — the planner may have scoped the steps narrowly on purpose. If meeting the criteria needs
    a materially different change (a new module, API or behaviour the steps don't mention), emit
@@ -282,8 +288,9 @@ In order:
    one sentence in `task-verified` so the evaluator does not treat the absence as an oversight.
 
    If the product cannot start for an environment reason: when only the project's declared
-   dependencies are missing, install them with its own tooling and lockfile first; otherwise record
-   in `task-verified` which exercise you could not run and why, and continue. Emit `task-blocked`
+   dependencies are missing, install them with its own tooling and lockfile first (not via sudo or
+   the system package manager, unless a declared step calls for it); otherwise record in
+   `task-verified` which exercise you could not run and why, and continue. Emit `task-blocked`
    only when no criterion command could run either. A deliberate skip (no run-path declared) does
    not warrant `task-blocked`.
 

package/dist/prompts/plan/template.md

@@ -312,8 +312,7 @@ Read the repositories mounted under `<repositories>` to:
 5. Extract verification commands (build, test, lint, typecheck), how to run the test runner
    against one file, name, or tag, and which subset CI gates on when CI filters (e.g. a tag or grep).
 
-Remember: you are in the per-sprint plan unit root, not inside any repository. Use the
-repository paths from `<repositories>` as the roots for all file reads and searches.
+Use the repository paths from `<repositories>` as the roots for all file reads and searches.
 
 ### Step 2 — Map tickets to tasks
 
@@ -377,8 +376,8 @@ dependency exists:
 - ... (check type, command)
 ```
 
-The approval question goes last, as a structured multiple-choice question — do not ask in prose ("does
-this look right?"). Prose answers are ambiguous and the harness cannot act on them.
+The approval question goes last, as a structured multiple-choice question (or the numbered-list fallback
+in `<approval-gate>`) — not an open prose question like "does this look right?", whose answer is ambiguous.
 
 - **Question:** "Does this task breakdown look correct?"
 - **Options:**

package/dist/prompts/readiness/template.md

@@ -5,6 +5,8 @@ review. Write nothing except `signals.json`; run only read-only inspection comma
 install, or otherwise mutating commands. The harness owns execution.
 </role>
 
+{{ONE_SHOT_OPERATION}}
+
 <goal>
 Inspect the repository at `{{REPOSITORY_PATH}}` and emit an `agents-md-proposal` signal whose `content`
 field is the project context file body the harness will write for the `{{CURRENT_TOOL}}` provider. Emit
@@ -40,6 +42,7 @@ bottom of this prompt.
 <target_file_conventions>
 {{TARGET_FILE_CONVENTIONS}}
 </target_file_conventions>
+<target_cli_loads>{{TARGET_CLI_LOADS}}</target_cli_loads>
 </inputs>
 
 <constraints>
@@ -47,10 +50,12 @@ bottom of this prompt.
 **Read-only scope.** Read configuration and metadata files only — `package.json`, `pyproject.toml`,
 `Cargo.toml`, `go.mod`, `Makefile`, `mise.toml`, `.tool-versions`, `.github/workflows/*.yml`, `README.md`,
 top-level `scripts/` entries, `flake.nix`. Also read other tools' context files and onboarding docs when
-present — `AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`, `.cursor/rules/`, `CONTRIBUTING.md` —
-and do not restate or contradict them; when they disagree with a manifest, mention it in a `note`. Do not
-read source trees, test directories, vendored or generated directories. Do not write any file other than
-`signals.json` in `<outputDir>`.
+present — `AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`, `.cursor/rules/`, `.grok/rules/`,
+`.claude/rules/`, `CONTRIBUTING.md`. `<target_cli_loads>` names the ones the `{{CURRENT_TOOL}}` CLI loads by
+itself: do not restate or contradict those; from a context file it does not load, carry over the rules that
+still apply, since its sessions never see that file. When they disagree with a manifest, mention it in a
+`note`. Do not read source trees, test directories, vendored or generated directories. Do not write any file
+other than `signals.json` in `<outputDir>`.
 
 **Evidence requirement.** For each tech-stack claim in the context file body, quote the file that
 establishes it (e.g. `"build": "tsup src/index.ts"` from `package.json` → `## Build & Run` bullet).

package/dist/prompts/refine/template.md

@@ -57,10 +57,7 @@ If the `<context>` block above is empty or absent, no upstream issue body was av
 
 ### Step 1 — Analyse the ticket
 
-Before producing any output, work through what is clear, what is ambiguous, and what edge cases the
-ticket omits.
-
-Then identify, in order:
+Before asking anything, identify, in order:
 
 1. What is already clear and doesn't need clarification.
 2. What is ambiguous, missing, or underspecified.
@@ -244,8 +241,8 @@ Field names differ by kind — match the `signals.json` shape below exactly:
 - `note` (OPTIONAL) — narrative annotation in its `text` field; use sparingly for facts worth surfacing to the operator.
 - `learning` (OPTIONAL) — a non-obvious finding about the ticket, in its `text` field, worth recording in the sprint
   log.
-- `decision` (OPTIONAL) — a scope or design decision made during the interview, in its `text` field (keep it
-  concise — roughly 500 characters).
+- `decision` (OPTIONAL) — a scope or design decision made during the interview, in its `text` field (one or two
+  sentences).
 
 **Failure mode.** If, after the interview, the ticket cannot be refined as stated — due to
 contradictory requirements or information you cannot extract from the user — emit the `refined-ticket`

package/dist/prompts/reproduce/template.md

@@ -103,6 +103,13 @@ Choose the smallest test that demonstrates the defect exactly as reported — no
 narrower one. Add it to an existing relevant test file when one fits naturally; otherwise create a new
 test file following the project's own conventions.
 
+Assert the behaviour the report or done criteria state — the expected value, exception, or output — not
+only that the result differs from today's wrong value: a test that only rejects the current output also
+accepts a wrong fix. Do not assert what the report does not require (formatting or ordering it never
+mentions, a particular helper or call sequence) — that rejects a correct fix written another way. If the
+defect is a hang, bound it with a timeout inside the test so it fails instead of hanging — a run the
+harness has to kill (timeout or runaway output) is not accepted as a reproduction.
+
 ### Phase 3 — Run it and capture the failure
 
 Run the new test in isolation using the project's own test runner. Confirm it fails, and confirm the

package/dist/skills/ralphctl-api-and-interface-design/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: ralphctl-api-and-interface-design
+description: Interface-design discipline for any surface one piece of code exposes to another — network endpoints, library exports, module boundaries, CLI flags and exit codes, file and message formats. Contract first, one consistent error model, validation at the trust boundary, additive change over breaking change, and every observable behaviour treated as a commitment (Hyrum's law). Use when designing a new interface, changing an existing one, or planning work that crosses a module or service boundary.
+license: MIT
+---
+
+# API and Interface Design
+
+> Adapted from [addyosmani/agent-skills — "API and Interface Design"](https://github.com/addyosmani/agent-skills)
+> (MIT). Adapted for ralphctl's harness contract.
+
+Good interfaces make the right use easy and the wrong use hard. This applies to every surface where one
+piece of code talks to another: a network API, a library's exports, a module boundary inside one
+repository, a CLI's flags and exit codes, a file or message format. The guidance is language-neutral —
+express it in the project's own idiom and with its own typing or schema mechanism.
+
+## When this applies
+
+- **Plan** — when a ticket adds or changes an interface, make the contract its own task or the first step
+  of one, and put its shape in the verification criteria: inputs, outputs, error cases, and what existing
+  consumers must keep seeing. Name who consumes the interface today.
+- **Execute** — define the contract before the body, and check every change to an existing interface
+  against its current consumers before making it. When reviewing, a breaking change the task did not ask
+  for is a finding even when the new code is correct.
+
+## Every observable behaviour is a commitment
+
+Hyrum's law: with enough consumers, everything observable gets depended on — field order, error message
+text, default values, timing, undocumented quirks. So:
+
+- Expose deliberately. Anything a caller can observe is something you may have to keep.
+- Keep implementation details out of the interface — storage ids, internal layout, stack traces in errors.
+- Tests are necessary but not sufficient: a "safe" change still breaks a consumer that relies on behaviour
+  no test pins. Search for real consumers before changing what they can see.
+
+## Core principles
+
+### Contract first
+
+Write the interface — names, input and output shapes, error cases, invariants — before the
+implementation. The contract is the spec; the body follows it. Separate what a caller provides from what
+the system returns: generated fields (ids, timestamps) appear only in the output shape.
+
+### One error model, everywhere
+
+Pick one way to report failure and use it on every operation: the same envelope or error type, a stable
+machine-readable code, a human-readable message, optional detail. Map failure classes consistently —
+invalid input, not authenticated, not permitted, not found, conflict, internal. When some operations
+throw, others return an empty value, and others return an error object, the caller cannot predict
+behaviour. Internal failures never expose internals.
+
+### Validate at the boundary, trust inside
+
+Validate where untrusted data enters: request handlers, argument parsing, config and environment loading,
+responses from third-party services, files the code did not write. After validation, internal code
+trusts the types and does not re-validate. Third-party responses are untrusted — check shape and content
+before using them in logic, rendering, or decisions. For the full trust-boundary treatment, see
+ralphctl-security-and-hardening when installed.
+
+### Prefer addition over modification
+
+- Add optional fields, new operations, and new variants a consumer can ignore.
+- Do not change a field's type, remove or rename a field, or narrow what was previously accepted.
+- When a breaking change is unavoidable, treat it as a migration (ralphctl-deprecation-and-migration when
+  installed), not an in-place edit.
+- Extend one live version rather than forking a second one consumers must choose between.
+
+### Predictable names and shapes
+
+Follow the conventions the project already uses for this kind of surface, identically across every
+operation: casing, resource naming, boolean prefixes, time and id formats. Model variants as an explicit
+tagged union or discriminated record rather than a bag of optional fields. Where the language allows,
+give each kind of id its own type so one cannot be passed for another. List operations paginate (a limit
+plus a stable order or cursor) from the start; partial updates change only the fields provided.
+
+### Retry safety
+
+A state-changing operation either honours an idempotency key or is documented as unsafe to retry. When
+it honours one:
+
+- Derive the key from the intent (client-supplied, or an immutable id of the thing being done), never per
+  attempt — a fresh random value or a timestamp makes every retry a new effect.
+- Claim the key atomically — a uniqueness constraint or a single compare-and-set. A check followed by an
+  act is a race.
+- Reject the same key arriving with a different payload instead of replaying the first response.
+- Decide on purpose what an in-flight duplicate gets: rejected, a bounded wait, or a pending status.
+- A timeout is a third outcome — unknown. Record the intent before the side effect so it can be resolved.
+- Keep keys longer than the longest path that can re-deliver the same request.
+
+## Common rationalisations
+
+| Rationalisation                            | Reality                                                                                   |
+| ------------------------------------------ | ----------------------------------------------------------------------------------------- |
+| "Nobody uses that undocumented behaviour"  | If it is observable, someone depends on it. Treat it as a commitment.                     |
+| "We'll pin the contract down later"        | The contract is the documentation. Define it first; the implementation follows it.        |
+| "Internal interfaces don't need contracts" | Internal consumers are still consumers. Contracts are what let them change independently. |
+| "We don't need pagination yet"             | Adding it once a list has grown is a breaking change.                                     |
+| "Accepting the idempotency key is enough"  | Accepting it tells clients retries are safe; storing it against the result makes it so.   |
+
+## Red flags
+
+- An operation that returns different shapes depending on conditions.
+- Inconsistent error formats across one interface.
+- Validation scattered through internal code instead of at the boundary.
+- A field changed, renamed, or removed in place.
+- A list operation without pagination.
+- Third-party responses used without validation.
+- A lookup-then-insert idempotency check, or a key regenerated on every attempt.
+
+## Self-check
+
+- [ ] Every operation has explicit input and output shapes and named error cases.
+- [ ] One error model across the whole interface.
+- [ ] Validation happens at the boundary only.
+- [ ] Changes to an existing interface are additive, or handled as a migration.
+- [ ] Naming matches the conventions the project already uses.
+- [ ] The retry behaviour of every state-changing operation is a deliberate choice.