skillpacks 0.1.1 → 0.1.2

package/packs/agentic-skills-bench/claude/benchmark-agent-review/archive/v0.1/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: benchmark-agent-review
+description: Review persisted benchmark run outputs with one or more agent graders and report subjective ergonomic quality separately from deterministic benchmark scores
+type: analysis
+version: v0.1
+argument-hint: "<skill name or run path> [--reviewers codex,claude] [--runs N]"
+---
+
+# Benchmark Agent Review
+
+Invoke as `/benchmark-agent-review <skill-or-run-path>`.
+
+Use this skill after `/benchmark-test-skill <skill>` when the deterministic benchmark passed but the user wants agent judgment on whether the generated artifacts are actually excellent, ergonomic, and useful for the next caller.
+
+Act as a follow-up review workflow. It does not replace hard benchmark assertions, deterministic output-quality rubrics, or verify/bench commands.
+
+The primary object of review is the generated skill output, not the benchmark harness. Treat hard assertions and deterministic output-quality scores as context and triage signals only. Lead with whether each retained output is excellent, good, usable, weak, or failing under the agent-review rubric; discuss deterministic rubric tightening only after output-quality findings, and only when it would help future triage surface the same output-quality issue.
+
+## Input
+
+- Required: a benchmark target skill name such as `run`, or a raw run directory such as `tests/benchmarks/runs/run-codex-47e0dd54/`.
+- Optional: `--reviewers codex,claude` to request named reviewer families when both outputs are available.
+- Optional: `--runs N` to request multiple independent review passes. Default to 3 when practical; use 1 when only one reviewer pass is available in the active environment.
+
+## Process
+
+1. Resolve benchmark evidence:
+   - If the input is a run directory, inspect that directory.
+   - If the input is a skill name, find the newest matching directories under `tests/benchmarks/runs/<skill>-*/`.
+   - Prefer the latest Claude and Codex run directories when both exist.
+   - Read `report.md`, `report.json`, each `run-*.json`, and any persisted generated artifact content visible in stdout/stderr or file snapshots.
+   - If generated artifact content is not fully available, state that limitation and grade only the retained evidence.
+
+2. Extract outputs under review:
+   - Identify the artifact path the benchmark expected, such as `run-plan.md` or `benchmark/test-*.md`.
+   - Extract the generated artifact text when available.
+   - Preserve runner identity, run index, hard assertions, deterministic quality score, and infrastructure-blocked status.
+   - Exclude infrastructure-blocked runs from subjective scoring.
+
+3. Build the review packet:
+   - Include the original benchmark prompt.
+   - Include the benchmark fixture facts.
+   - Include the output artifact text or retained summary.
+   - Include hard assertions and deterministic quality scores for context.
+   - Include the target skill contract only when needed to judge ergonomics.
+
+4. Grade each evaluated output with this rubric:
+   - **Task selection clarity**: the selected work is unambiguous and traceable to fixture evidence.
+   - **Implementation specificity**: the output gives a next caller concrete enough steps to act without redoing basic discovery.
+   - **Validation strength**: proposed checks prove behavior or artifact quality, not just file existence or generic completion.
+   - **Scope control**: the output respects the fixture and user constraints without becoming timid or incomplete.
+   - **Next-route ergonomics**: the next command is correct for the runner mode and explains what it will do.
+   - **No invented facts**: the output avoids unsupported services, files, metrics, commands, deploys, or repository claims.
+   - **Residual-risk awareness**: the output names meaningful uncertainty, missing evidence, or follow-up risk when relevant.
+
+5. Score:
+   - Use a 0-100 integer score per reviewed output.
+   - Treat 90-100 as excellent, 80-89 as good, 70-79 as usable but meaningfully incomplete, 60-69 as weak, and below 60 as failing human review.
+   - When multiple review passes are available, report median score, score range, and common findings.
+   - Do not blend subjective scores into hard assertion pass rate or deterministic quality score.
+
+6. Optional multi-reviewer handling:
+   - Use subagents only when the active Claude tool instructions permit them and the user explicitly requested multiple agent review passes.
+   - Assign each reviewer one independent grading pass over the same review packet.
+   - Do not let reviewers edit repository files.
+   - Synthesize reviewer findings into a normalized score table.
+
+7. Write the report:
+   - Create `benchmark/review-<SKILL>-<YYYY-MM-DD>.md` when the input resolves to a skill.
+   - Create `benchmark/review-<RUN-DIR-NAME>-<YYYY-MM-DD>.md` when the input is one run directory.
+   - If the review is exploratory and the user asks for chat-only output, do not write a file.
+
+8. Build the remediation handoff:
+   - Convert every material weakness into a remediation target instead of stopping at broad advice.
+   - Classify each target as target-skill contract, benchmark rubric, retained-evidence gap, harness/setup issue, or one-off run behavior.
+   - Name the exact owner file, skill contract, benchmark setup, or report artifact when known; when the exact file is not proven, name the narrowest known owner surface and state the lookup needed to confirm it.
+   - Propose the exact contract, rubric, fixture, or evidence-capture behavior to add or tighten; avoid vague changes such as "update the skill" without naming the behavior that changes.
+   - Include the validation command or contract-lint assertion that would prove the issue is fixed; a focused fixture rerun is acceptable only when it names the expected assertion or artifact-quality behavior.
+   - When retained artifact text contains placeholder risk, monitoring, validation, or known-unknown sections such as `Not captured`, `Not specified`, `TBD`, `None`, or `N/A`, the remediation must identify the owner target that should reject or repair that placeholder and the validation check that would fail before the fix.
+   - Choose one definitive next route from the highest-impact verified remediation; do not leave the next caller to choose among generic options.
+
+## Output
+
+Report:
+
+- Source benchmark report paths.
+- Reviewed run directories and run indexes.
+- Hard assertion pass rate and deterministic output-quality score from the benchmark report.
+- Output-quality verdict against the agent-review rubric, explicitly focused on the generated skill artifacts rather than the benchmark's ease or strictness.
+- Agent-review score table with reviewer, runner, run index, score, and grade band.
+- Median subjective score and score range when multiple scores exist.
+- Common strengths.
+- Common weaknesses.
+- Remediation table with finding, classification, owner target, proposed change, validation check, and route.
+- Remediation rows must be implementation-ready: each material finding needs a concrete owner target, a proposed behavior change, and a validation check or command. Broad rows like "tighten the rubric" or "update the skill" are incomplete unless they also name the owning file/surface, exact behavior, and proof.
+- Optional deterministic-rubric notes only when the retained output-quality findings show the deterministic rubric failed to surface a meaningful issue or produced misleading context.
+- **Next work:** the one definitive remediation selected from the remediation table, or no follow-up when all evaluated outputs are excellent and no meaningful issue remains.
+- **Recommended next command:** one command derived from that remediation, usually `/targeted-skill-builder <skill> <specific output-quality gap>`, `/targeted-skill-builder <benchmark setup or reviewed skill> <specific rubric gap>`, `/session-triage <skill> benchmark review`, or `/ship` only when no remediation is needed.
+
+## Alignment Page
+
+When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment/benchmark-agent-review-{topic}.html`.
+
+## Constraints
+
+- Do not re-run `/benchmark-test-skill` unless the requested benchmark artifacts are missing or stale and the user explicitly asks for a fresh benchmark.
+- Do not present subjective agent-review scores as statistically definitive.
+- Do not merge subjective scores into deterministic output-quality scores.
+- Do not frame benchmark pass/fail laxness as the primary problem when the task is to judge skill output quality. If the benchmark intentionally passes weak-but-compliant outputs, grade the output quality directly and use deterministic-rubric notes only as supporting context.
+- Do not grade infrastructure-blocked runs as skill outputs.
+- Do not fabricate missing artifact content. State when only stdout summaries, assertions, or quality results are available.
+- Do not collapse multiple material weaknesses into a vague handoff such as "tighten the rubric"; the remediation table must preserve the responsible target, exact behavior change, and validation check for each issue.
+- Do not create or modify GitHub Actions workflows.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/agentic-skills-bench/claude/benchmark-test-skill/ALIGNMENT-PAGE.md

@@ -1,6 +1,6 @@
 # Alignment Page — benchmark-test-skill
 
-When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment/benchmark-test-skill-{topic}.html`. Use a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.
+Alignment pages are optional for this operational skill. By default, report the outcome inline and write only the skill's normal durable artifacts (`tasks/*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Build `alignment/benchmark-test-skill-{topic}.html` only when the user explicitly requests an alignment page or when the agent explicitly identifies a concrete clarification/review need that cannot be resolved cleanly in conversation or the normal artifacts. When an alignment page is created, use the full contract below and a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.
 
 **Visual rendering tier.** Each alignment page declares a rendering tier:
 - `document` (default) — text, tables, approval gates. No charts or interactive elements.
@@ -57,7 +57,9 @@ The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected
 
 **Report-only research gates.** For report-only or pre-approval research skills, the first `review` alignment page must explicitly contain proposed research scope, source plan, assumptions/confidence, recommended output path, proposed file changes, and approval gates before synthesized research begins and before any working packet, canonical research, spec, or task file is created or updated.
 
-**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, and research-scope approval gates. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-benchmark-test-skill-research.md`; product-path mode uses `research/{slug}/_working/preliminary-benchmark-test-skill-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the full preliminary packet, evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, research-scope approval gates, and a `Stage 2 Preview / Expected Review Format` section that shows the future Stage 2 review shape before research starts. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-benchmark-test-skill-research.md`; product-path mode uses `research/{slug}/_working/preliminary-benchmark-test-skill-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the complete working-packet substance as structured HTML review UI: purpose-built sections, tables, matrices, gates, cards, and tier-appropriate charts or diagrams that preserve every packet section, finding, caveat, and decision detail without summary loss. Raw Markdown packet text may appear only as a supplemental source view after the rendered review UI; do not make a `Full Preliminary Packet` or `Full Working Packet` raw Markdown dump, giant `<pre><code>` block, link-only view, or source-only view the primary review surface. Include the evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+
+**Stage 2 review-page template.** Stage 1 scope-review pages must include a `Stage 2 Preview / Expected Review Format` section that previews the exact section sequence, table shapes, evidence treatment, visual density, and approval gates the user will see after research; make it specific enough for the user to flag preferred content formats, grouping, labels, visuals, and evidence density before the agent does heavy research. After scope approval and research, the Stage 2 review page must include these sections as structured HTML, not as raw Markdown dumps: `Research Scope Approved` status block with approved scope, source plan, output paths, and unresolved caveats; `Executive Findings` or a skill-specific top-findings section with confidence labels; `Evidence Matrix` mapping claim, evidence/source/path, inference, confidence, assumptions, and decision impact; `Working Packet Review` with the complete working-packet substance rendered as purpose-built HTML sections, lists, tables, matrices, cards, and tier-appropriate charts or diagrams; `Alternatives / Rejected or Lower-Confidence Findings`; `Source Coverage & Gaps`; `Assumptions / Confidence Register`; `Proposed Canonical Artifacts & File Changes`; a required `User Format Preferences` gate asking whether the layout, tables, grouping, visuals, labels, and evidence density match expectations; and a required `Final Artifact Approval` gate for Stage 3 readiness. Raw Markdown packet text, search logs, or source notes may appear only as supplemental source views after the rendered review UI and never replace the Stage 2 review sections.
 
 **Required inline questions.** In `review` pages, each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: "Other / None of the above" backed by a multi-line text box for free-form input, and "Need clarification" backed by an optional notes box where the user can explain what is unclear. When any radio option other than "Other" or "Need clarification" is selected, show an optional "Additional notes" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom "Decisions & Clarifications" section. Confirmed pages must not keep these as required input controls; render the answered decisions as read-only records.
 

package/packs/agentic-skills-bench/claude/benchmark-test-skill/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## v0.2 - 2026-06-12
+
+- Made alignment pages optional by default: report inline and write the skill's normal durable artifacts unless the user requests an alignment page or the agent identifies a concrete clarification/review need.
+
 ## v0.0
 
 - Archived previous skill contract.

package/packs/agentic-skills-bench/claude/benchmark-test-skill/SKILL.md

@@ -2,7 +2,7 @@
 name: benchmark-test-skill
 description: Run verify and benchmark tests for one agentic-skills skill, producing pass-rate, latency, cost, and consistency metrics
 type: execution
-version: v0.1
+version: v0.2
 argument-hint: "<skill name>"
 ---
 
@@ -116,7 +116,7 @@ The Markdown report and the final assistant response must both include a literal
 
 ## Alignment Page
 
-When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment/benchmark-test-skill-{topic}.html`.
+By default, this skill reports results inline and writes only its normal durable artifacts (for example `tasks/*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Do not build an alignment page automatically. Create `alignment/benchmark-test-skill-{topic}.html` only when the user explicitly requests an alignment page or when you explicitly identify a concrete clarification/review need that cannot be handled cleanly inline; when you create one, follow `ALIGNMENT-PAGE.md` in this skill's directory.
 
 ## Constraints
 

package/packs/agentic-skills-bench/claude/benchmark-test-skill/archive/v0.1/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: benchmark-test-skill
+description: Run verify and benchmark tests for one agentic-skills skill, producing pass-rate, latency, cost, and consistency metrics
+type: execution
+version: v0.1
+argument-hint: "<skill name>"
+---
+
+# Benchmark Test Skill
+
+Invoke as `/benchmark-test-skill <skill>`.
+
+Use this skill when the user wants to benchmark-test a skill defined in this repository. The trailing argument is the skill under test, not a mode for that skill. For example, `/benchmark-test-skill design-system` tests the `design-system` skill with the harness; it does not run `design-system` against the current app or website.
+
+Run the agentic-skills test harness verification gate followed by the benchmark extension for a single skill. By default, benchmark both Claude and Codex runners and report them separately.
+
+Produce deterministic benchmark evidence only. It should hand off to `/benchmark-agent-review <skill>` as a separate step when the user needs subjective ergonomic judgment or remediation planning for the generated skill outputs.
+
+## Input
+
+- Required: one skill name, such as `design-system`.
+- If no skill name is provided, ask the user which skill to benchmark-test.
+- When invoked as `/benchmark-test-skill <skill>`, resolve `benchmark-test-skill` as the active command first, including this project-local pack path, before treating the trailing argument as the skill under test.
+- Do not reinterpret the trailing argument as the active workflow unless the benchmark-test-skill command cannot be found after checking project-local packs.
+
+## Execution
+
+Run commands from `/Users/georgele/projects/tools/agentic-skills/tests`.
+
+### Step 0 - Command Resolution Guard
+
+Confirm the active workflow is this `packs/agentic-skills-bench` skill. The requested target skill is data for the benchmark harness, not a command to execute directly.
+
+- For command-like invocations, preserve the leading command and route by the pack command first.
+- If a target such as `design-system`, `run`, or `ship` is provided, never run that skill directly as the benchmark action.
+- If command resolution is ambiguous, stop and report the ambiguity instead of running the target skill.
+
+### Step 1 - Eligibility Preflight
+
+Before running verify, check whether the requested skill is a repository skill known to the benchmark harness:
+
+```bash
+pnpm bench --list-skills
+```
+
+- If `<SKILL>` is not listed, stop immediately and report `unknown skill: <SKILL>`.
+- List the known repository skills from the command output.
+- Do not run `pnpm verify` or `pnpm bench` for unknown skills.
+- Read and report the listed coverage status for `<SKILL>`: `custom`, `generic`, or `blocked`.
+- Skills with custom layer4 setups use skill-specific fixtures and hard assertions. Some setups also include deterministic output-quality rubrics.
+- Skills without custom layer4 setups use the harness generic smoke benchmark. Treat that as invocation/compliance evidence, not deep domain-quality evidence.
+- If the row is `blocked`, stop before verify and bench. Report the blocked reason and next command from the list output.
+- If the row is `generic`, continue only as generic smoke evidence and route missing custom coverage to `/targeted-skill-builder <SKILL> benchmark coverage`.
+
+### Step 2 - Verify
+
+```bash
+pnpm verify --skill <SKILL>
+```
+
+- Expect layer1 to pass and layer2 to pass when target-specific tests exist.
+- Treat layer1 as the static harness-contract gate, including basic benchmark setup alignment checks such as expected next-route handoffs, runner command conventions, output file expectations, and quality-rubric facts against the current skill contract.
+- If layer1 fails because a benchmark setup is misaligned with the skill contract, classify it as a harness/benchmark coverage defect and route to `/targeted-skill-builder <SKILL> benchmark failure`; do not spend agent budget on `pnpm bench`.
+- If layer2 reports no tests matched `<SKILL>`, treat that layer as skipped and continue to the benchmark step. Record the skip clearly because generic benchmark coverage is weaker than target-specific layer2 verification.
+- Record pass/fail and wall time per layer.
+- If verify fails, stop and report the failure. Do not run the benchmark step.
+
+### Step 3 - Bench
+
+Run only if verify passes:
+
+```bash
+pnpm bench --skill <SKILL> --agent both --runs 3 --chunk-size 3 --pause 0
+```
+
+- Use 3 iterations by default.
+- Use `--agent both` by default. Only use `--agent claude` or `--agent codex` when the user explicitly asks to isolate one runner.
+- The expected budget is about $1 per run for the current design-system variant; report actual cost from the benchmark output when available.
+- The bench system persists raw data to `tests/benchmarks/runs/<skill>-<agent>-<sessionId>/` and generates `report.json`.
+- Treat rate limits, quota exhaustion, and similar runner-capacity errors as infrastructure-blocked runs, not skill failures. Report them separately from evaluated pass rate.
+- If recent same-skill benchmark reports or triage reports show repeated same-family benchmark false negatives, do not recommend another blind rerun as the next step. Report the recurrence and route to `/targeted-skill-builder <SKILL> benchmark repeated false-negative generalization` so the harness/setup gets a family-level semantic evaluator, fixture set, or infrastructure classifier instead of another one-off tolerance patch.
+
+### Step 4 - Report
+
+Write results to `benchmark/test-<SKILL>-<YYYY-MM-DD>.md` at the repository root. Use the current date.
+
+Populate the report from `report.json` and verify the output includes:
+
+- verify table with layer status and wall time
+- agent name, evaluated pass rate, blocked-run count, and Wilson 95% confidence interval
+- failed assertions, if any
+- output-quality score summary when the setup defines a quality evaluator, including threshold failures, critical failures, and lowest-scoring criteria when present
+- infrastructure-blocked runs, if any
+- latency p50, p95, and p99
+- cost per run and total cost
+- mean pairwise similarity and outlier count
+- raw session path
+- recommended next route, using a literal label such as `Recommended next command:` or `Recommended next skill:`
+
+After writing the report, verify the file exists and contains the benchmark target, agent rows, pass-rate or blocked-run data, latency, cost, and raw session path. If any required report field is missing, treat the workflow as incomplete and fix the report before marking the benchmark done.
+
+## Output
+
+Print a concise benchmark summary:
+
+- verify pass/fail
+- hard assertion pass rate
+- output-quality score when present, labeled as an additional rubric score rather than a statistical confidence measure
+- infrastructure-blocked count, if any
+- p50 latency
+- total cost
+- report path
+- next review handoff when subjective output-quality judgment or remediation planning is still needed
+
+The Markdown report and the final assistant response must both include a literal next-route label accepted by the harness, such as `Recommended next skill: /benchmark-agent-review <skill>` or `Recommended next command: /ship`.
+
+## Alignment Page
+
+When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment/benchmark-test-skill-{topic}.html`.
+
+## Constraints
+
+- Do not audit or benchmark the app, website, docs, or product surface unless the user explicitly asks for a separate website/product benchmark workflow.
+- Do not run `pnpm bench` when `pnpm verify` fails.
+- Do not fabricate benchmark metrics. Use the command output and `report.json`.
+- Do not present quality score as a replacement for hard assertion pass rate, or present a small benchmark run as statistically definitive.
+- Do not omit the final next-step route. Completion output must include either `Recommended next skill: <command>` or the two-line pair `**Next work:** <specific task or "none">` and `**Recommended next command:** <one command or route>`.
+- Do not create or modify GitHub Actions workflows.
+
+## Next-Step Routing
+
+If the skill is unknown to the repository, recommend checking the skill name or creating the skill first with `/create-agentic-skill`.
+
+If the skill has blocked benchmark coverage, recommend the row's `next_command`.
+
+If the skill only has generic smoke benchmark coverage or otherwise lacks custom domain-quality assertions, recommend `/targeted-skill-builder <skill> benchmark coverage`.
+
+If the skill fails verification, hard benchmark assertions, or configured quality thresholds, recommend `/session-triage <skill> benchmark failure`.
+
+If benchmark runs are blocked only by rate limits or quota exhaustion, recommend re-running `/benchmark-test-skill <skill>` after the reset instead of treating the skill as failed.
+
+If the failure pattern has already been triaged as a repeated same-family benchmark false negative, recommend `/targeted-skill-builder <skill> benchmark repeated false-negative generalization` instead of another `/benchmark-test-skill <skill>` rerun.
+
+If evaluated benchmark runs completed and subjective output-quality review or remediation planning has not yet been performed, recommend `/benchmark-agent-review <skill>` as the next separate step.
+
+If the skill passes, the report is written, and no subjective review is needed or the separate `/benchmark-agent-review <skill>` step has already been completed, recommend `/ship`.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/agentic-skills-bench/codex/benchmark-agent-review/ALIGNMENT-PAGE.md

@@ -1,6 +1,6 @@
 # Alignment Page — benchmark-agent-review
 
-When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment/benchmark-agent-review-{topic}.html`. Use a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.
+Alignment pages are optional for this operational skill. By default, report the outcome inline and write only the skill's normal durable artifacts (`tasks/*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Build `alignment/benchmark-agent-review-{topic}.html` only when the user explicitly requests an alignment page or when the agent explicitly identifies a concrete clarification/review need that cannot be resolved cleanly in conversation or the normal artifacts. When an alignment page is created, use the full contract below and a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.
 
 **Visual rendering tier.** Each alignment page declares a rendering tier:
 - `document` (default) — text, tables, approval gates. No charts or interactive elements.
@@ -57,7 +57,9 @@ The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected
 
 **Report-only research gates.** For report-only or pre-approval research skills, the first `review` alignment page must explicitly contain proposed research scope, source plan, assumptions/confidence, recommended output path, proposed file changes, and approval gates before synthesized research begins and before any working packet, canonical research, spec, or task file is created or updated.
 
-**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, and research-scope approval gates. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-benchmark-agent-review-research.md`; product-path mode uses `research/{slug}/_working/preliminary-benchmark-agent-review-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the full preliminary packet, evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, research-scope approval gates, and a `Stage 2 Preview / Expected Review Format` section that shows the future Stage 2 review shape before research starts. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-benchmark-agent-review-research.md`; product-path mode uses `research/{slug}/_working/preliminary-benchmark-agent-review-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the complete working-packet substance as structured HTML review UI: purpose-built sections, tables, matrices, gates, cards, and tier-appropriate charts or diagrams that preserve every packet section, finding, caveat, and decision detail without summary loss. Raw Markdown packet text may appear only as a supplemental source view after the rendered review UI; do not make a `Full Preliminary Packet` or `Full Working Packet` raw Markdown dump, giant `<pre><code>` block, link-only view, or source-only view the primary review surface. Include the evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+
+**Stage 2 review-page template.** Stage 1 scope-review pages must include a `Stage 2 Preview / Expected Review Format` section that previews the exact section sequence, table shapes, evidence treatment, visual density, and approval gates the user will see after research; make it specific enough for the user to flag preferred content formats, grouping, labels, visuals, and evidence density before the agent does heavy research. After scope approval and research, the Stage 2 review page must include these sections as structured HTML, not as raw Markdown dumps: `Research Scope Approved` status block with approved scope, source plan, output paths, and unresolved caveats; `Executive Findings` or a skill-specific top-findings section with confidence labels; `Evidence Matrix` mapping claim, evidence/source/path, inference, confidence, assumptions, and decision impact; `Working Packet Review` with the complete working-packet substance rendered as purpose-built HTML sections, lists, tables, matrices, cards, and tier-appropriate charts or diagrams; `Alternatives / Rejected or Lower-Confidence Findings`; `Source Coverage & Gaps`; `Assumptions / Confidence Register`; `Proposed Canonical Artifacts & File Changes`; a required `User Format Preferences` gate asking whether the layout, tables, grouping, visuals, labels, and evidence density match expectations; and a required `Final Artifact Approval` gate for Stage 3 readiness. Raw Markdown packet text, search logs, or source notes may appear only as supplemental source views after the rendered review UI and never replace the Stage 2 review sections.
 
 **Glossary Additions gate.** When this research introduces domain-specific terms, acronyms, or concept definitions that a reader outside the project would not know, include a `## Glossary Additions` section in the alignment page. Render a table of proposed terms with columns: Term, Definition, Source (`benchmark-agent-review`), Category (business/tooling/workflow/technical/domain), and per-term Approve/Edit/Reject/Flag radio controls. Only user-approved terms are appended to the target glossary (`research/glossary.md` or `research/{slug}/glossary.md` for scoped paths) during the confirmed-page write step. When the skill operates in a product-path scope, ask whether each term belongs in the parent or scoped glossary; default to the scoped glossary.
 

package/packs/agentic-skills-bench/codex/benchmark-agent-review/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## v0.2 - 2026-06-12
+
+- Made alignment pages optional by default: report inline and write the skill's normal durable artifacts unless the user requests an alignment page or the agent identifies a concrete clarification/review need.
+
 ## v0.0
 
 - Archived previous skill contract.

package/packs/agentic-skills-bench/codex/benchmark-agent-review/SKILL.md

@@ -2,7 +2,7 @@
 name: benchmark-agent-review
 description: Review persisted benchmark run outputs with one or more agent graders and report subjective ergonomic quality separately from deterministic benchmark scores
 type: analysis
-version: v0.1
+version: v0.2
 argument-hint: "<skill name or run path> [--reviewers codex,claude] [--runs N]"
 ---
 
@@ -99,7 +99,7 @@ Report:
 
 ## Alignment Page
 
-When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment/benchmark-agent-review-{topic}.html`.
+By default, this skill reports results inline and writes only its normal durable artifacts (for example `tasks/*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Do not build an alignment page automatically. Create `alignment/benchmark-agent-review-{topic}.html` only when the user explicitly requests an alignment page or when you explicitly identify a concrete clarification/review need that cannot be handled cleanly inline; when you create one, follow `ALIGNMENT-PAGE.md` in this skill's directory.
 
 ## Constraints
 

package/packs/agentic-skills-bench/codex/benchmark-agent-review/archive/v0.1/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: benchmark-agent-review
+description: Review persisted benchmark run outputs with one or more agent graders and report subjective ergonomic quality separately from deterministic benchmark scores
+type: analysis
+version: v0.1
+argument-hint: "<skill name or run path> [--reviewers codex,claude] [--runs N]"
+---
+
+# Benchmark Agent Review
+
+Invoke as `$benchmark-agent-review <skill-or-run-path>`.
+
+Use this skill after `$benchmark-test-skill <skill>` when the deterministic benchmark passed but the user wants agent judgment on whether the generated artifacts are actually excellent, ergonomic, and useful for the next caller.
+
+Act as a follow-up review workflow. It does not replace hard benchmark assertions, deterministic output-quality rubrics, or verify/bench commands.
+
+The primary object of review is the generated skill output, not the benchmark harness. Treat hard assertions and deterministic output-quality scores as context and triage signals only. Lead with whether each retained output is excellent, good, usable, weak, or failing under the agent-review rubric; discuss deterministic rubric tightening only after output-quality findings, and only when it would help future triage surface the same output-quality issue.
+
+## Input
+
+- Required: a benchmark target skill name such as `run`, or a raw run directory such as `tests/benchmarks/runs/run-codex-47e0dd54/`.
+- Optional: `--reviewers codex,claude` to request named reviewer families when both outputs are available.
+- Optional: `--runs N` to request multiple independent review passes. Default to 3 when practical; use 1 when only one reviewer pass is available in the active environment.
+
+## Process
+
+1. Resolve benchmark evidence:
+   - If the input is a run directory, inspect that directory.
+   - If the input is a skill name, find the newest matching directories under `tests/benchmarks/runs/<skill>-*/`.
+   - Prefer the latest Claude and Codex run directories when both exist.
+   - Read `report.md`, `report.json`, each `run-*.json`, and any persisted generated artifact content visible in stdout/stderr or file snapshots.
+   - If generated artifact content is not fully available, state that limitation and grade only the retained evidence.
+
+2. Extract outputs under review:
+   - Identify the artifact path the benchmark expected, such as `run-plan.md` or `benchmark/test-*.md`.
+   - Extract the generated artifact text when available.
+   - Preserve runner identity, run index, hard assertions, deterministic quality score, and infrastructure-blocked status.
+   - Exclude infrastructure-blocked runs from subjective scoring.
+
+3. Build the review packet:
+   - Include the original benchmark prompt.
+   - Include the benchmark fixture facts.
+   - Include the output artifact text or retained summary.
+   - Include hard assertions and deterministic quality scores for context.
+   - Include the target skill contract only when needed to judge ergonomics.
+
+4. Grade each evaluated output with this rubric:
+   - **Task selection clarity**: the selected work is unambiguous and traceable to fixture evidence.
+   - **Implementation specificity**: the output gives a next caller concrete enough steps to act without redoing basic discovery.
+   - **Validation strength**: proposed checks prove behavior or artifact quality, not just file existence or generic completion.
+   - **Scope control**: the output respects the fixture and user constraints without becoming timid or incomplete.
+   - **Next-route ergonomics**: the next command is correct for the runner mode and explains what it will do.
+   - **No invented facts**: the output avoids unsupported services, files, metrics, commands, deploys, or repository claims.
+   - **Residual-risk awareness**: the output names meaningful uncertainty, missing evidence, or follow-up risk when relevant.
+
+5. Score:
+   - Use a 0-100 integer score per reviewed output.
+   - Treat 90-100 as excellent, 80-89 as good, 70-79 as usable but meaningfully incomplete, 60-69 as weak, and below 60 as failing human review.
+   - When multiple review passes are available, report median score, score range, and common findings.
+   - Do not blend subjective scores into hard assertion pass rate or deterministic quality score.
+
+6. Optional multi-reviewer handling:
+   - Use subagents only when the active Codex tool instructions permit them and the user explicitly requested multiple agent review passes.
+   - Assign each reviewer one independent grading pass over the same review packet.
+   - Do not let reviewers edit repository files.
+   - Synthesize reviewer findings into a normalized score table.
+
+7. Write the report:
+   - Create `benchmark/review-<SKILL>-<YYYY-MM-DD>.md` when the input resolves to a skill.
+   - Create `benchmark/review-<RUN-DIR-NAME>-<YYYY-MM-DD>.md` when the input is one run directory.
+   - If the review is exploratory and the user asks for chat-only output, do not write a file.
+
+8. Build the remediation handoff:
+   - Convert every material weakness into a remediation target instead of stopping at broad advice.
+   - Classify each target as target-skill contract, benchmark rubric, retained-evidence gap, harness/setup issue, or one-off run behavior.
+   - Name the exact owner file, skill contract, benchmark setup, or report artifact when known; when the exact file is not proven, name the narrowest known owner surface and state the lookup needed to confirm it.
+   - Propose the exact contract, rubric, fixture, or evidence-capture behavior to add or tighten; avoid vague changes such as "update the skill" without naming the behavior that changes.
+   - Include the validation command or contract-lint assertion that would prove the issue is fixed; a focused fixture rerun is acceptable only when it names the expected assertion or artifact-quality behavior.
+   - When retained artifact text contains placeholder risk, monitoring, validation, or known-unknown sections such as `Not captured`, `Not specified`, `TBD`, `None`, or `N/A`, the remediation must identify the owner target that should reject or repair that placeholder and the validation check that would fail before the fix.
+   - Choose one definitive next route from the highest-impact verified remediation; do not leave the next caller to choose among generic options.
+
+## Output
+
+Report:
+
+- Source benchmark report paths.
+- Reviewed run directories and run indexes.
+- Hard assertion pass rate and deterministic output-quality score from the benchmark report.
+- Output-quality verdict against the agent-review rubric, explicitly focused on the generated skill artifacts rather than the benchmark's ease or strictness.
+- Agent-review score table with reviewer, runner, run index, score, and grade band.
+- Median subjective score and score range when multiple scores exist.
+- Common strengths.
+- Common weaknesses.
+- Remediation table with finding, classification, owner target, proposed change, validation check, and route.
+- Remediation rows must be implementation-ready: each material finding needs a concrete owner target, a proposed behavior change, and a validation check or command. Broad rows like "tighten the rubric" or "update the skill" are incomplete unless they also name the owning file/surface, exact behavior, and proof.
+- Optional deterministic-rubric notes only when the retained output-quality findings show the deterministic rubric failed to surface a meaningful issue or produced misleading context.
+- **Next work:** the one definitive remediation selected from the remediation table, or no follow-up when all evaluated outputs are excellent and no meaningful issue remains.
+- **Recommended next command:** one command derived from that remediation, usually `$targeted-skill-builder <skill> <specific output-quality gap>`, `$targeted-skill-builder <benchmark setup or reviewed skill> <specific rubric gap>`, `$session-triage <skill> benchmark review`, or `$ship` only when no remediation is needed.
+
+## Alignment Page
+
+When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment/benchmark-agent-review-{topic}.html`.
+
+## Constraints
+
+- Do not re-run `$benchmark-test-skill` unless the requested benchmark artifacts are missing or stale and the user explicitly asks for a fresh benchmark.
+- Do not present subjective agent-review scores as statistically definitive.
+- Do not merge subjective scores into deterministic output-quality scores.
+- Do not frame benchmark pass/fail laxness as the primary problem when the task is to judge skill output quality. If the benchmark intentionally passes weak-but-compliant outputs, grade the output quality directly and use deterministic-rubric notes only as supporting context.
+- Do not grade infrastructure-blocked runs as skill outputs.
+- Do not fabricate missing artifact content. State when only stdout summaries, assertions, or quality results are available.
+- Do not collapse multiple material weaknesses into a vague handoff such as "tighten the rubric"; the remediation table must preserve the responsible target, exact behavior change, and validation check for each issue.
+- Do not create or modify GitHub Actions workflows.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/agentic-skills-bench/codex/benchmark-test-skill/ALIGNMENT-PAGE.md

@@ -1,6 +1,6 @@
 # Alignment Page — benchmark-test-skill
 
-When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment/benchmark-test-skill-{topic}.html`. Use a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.
+Alignment pages are optional for this operational skill. By default, report the outcome inline and write only the skill's normal durable artifacts (`tasks/*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Build `alignment/benchmark-test-skill-{topic}.html` only when the user explicitly requests an alignment page or when the agent explicitly identifies a concrete clarification/review need that cannot be resolved cleanly in conversation or the normal artifacts. When an alignment page is created, use the full contract below and a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.
 
 **Visual rendering tier.** Each alignment page declares a rendering tier:
 - `document` (default) — text, tables, approval gates. No charts or interactive elements.
@@ -57,7 +57,9 @@ The tier is set per skill via `visual_tier` in SKILL.md frontmatter (or detected
 
 **Report-only research gates.** For report-only or pre-approval research skills, the first `review` alignment page must explicitly contain proposed research scope, source plan, assumptions/confidence, recommended output path, proposed file changes, and approval gates before synthesized research begins and before any working packet, canonical research, spec, or task file is created or updated.
 
-**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, and research-scope approval gates. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-benchmark-test-skill-research.md`; product-path mode uses `research/{slug}/_working/preliminary-benchmark-test-skill-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the full preliminary packet, evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+**Staged research workflow.** Heavy report-first research uses a scope-first three-stage approval workflow. Stage 1 is minimal scope discovery only: inspect enough repository, user, and source context to propose research scope, source plan, assumptions, output paths, and approval questions. Build the `review` alignment page before synthesized research. The page must render the proposed scope, available source categories, known context, assumptions/confidence, proposed working-packet and canonical output paths, research-scope approval gates, and a `Stage 2 Preview / Expected Review Format` section that shows the future Stage 2 review shape before research starts. Stop for final compiled response YAML approval of the research scope. Do not synthesize findings, rank candidates, recommend a path, or create working packets, canonical research, spec, or task files in Stage 1. Stage 2 starts only after final compiled response YAML approves the research scope with no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Perform the synthesized research, run required source/code checks, and write only a non-canonical working packet. Flat mode uses `research/_working/preliminary-benchmark-test-skill-research.md`; product-path mode uses `research/{slug}/_working/preliminary-benchmark-test-skill-research.md`. Existing raw evidence or search-log outputs may remain as supporting evidence when the skill contract already requires them, but synthesized deliverables stay in the working packet. Update the same `review` alignment page so it renders the complete working-packet substance as structured HTML review UI: purpose-built sections, tables, matrices, gates, cards, and tier-appropriate charts or diagrams that preserve every packet section, finding, caveat, and decision detail without summary loss. Raw Markdown packet text may appear only as a supplemental source view after the rendered review UI; do not make a `Full Preliminary Packet` or `Full Working Packet` raw Markdown dump, giant `<pre><code>` block, link-only view, or source-only view the primary review surface. Include the evidence matrix, assumptions/confidence register, source coverage gaps, proposed canonical file changes, and artifact approval gates. Partial compiled responses revise the working packet and review page, then remain in Stage 2. Stage 3 consumes final compiled response YAML for artifact approval only when it has `approval_status: ready-for-agent-review` and no unresolved `needs-clarification`, unresolved `down` feedback, or other unresolved negative feedback. Apply approved edits first, archive the working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/<original-working-path>`, remove the active working packet, write the approved canonical artifacts to the unchanged output paths, and convert the page to `confirmed` with the approval record preserved.
+
+**Stage 2 review-page template.** Stage 1 scope-review pages must include a `Stage 2 Preview / Expected Review Format` section that previews the exact section sequence, table shapes, evidence treatment, visual density, and approval gates the user will see after research; make it specific enough for the user to flag preferred content formats, grouping, labels, visuals, and evidence density before the agent does heavy research. After scope approval and research, the Stage 2 review page must include these sections as structured HTML, not as raw Markdown dumps: `Research Scope Approved` status block with approved scope, source plan, output paths, and unresolved caveats; `Executive Findings` or a skill-specific top-findings section with confidence labels; `Evidence Matrix` mapping claim, evidence/source/path, inference, confidence, assumptions, and decision impact; `Working Packet Review` with the complete working-packet substance rendered as purpose-built HTML sections, lists, tables, matrices, cards, and tier-appropriate charts or diagrams; `Alternatives / Rejected or Lower-Confidence Findings`; `Source Coverage & Gaps`; `Assumptions / Confidence Register`; `Proposed Canonical Artifacts & File Changes`; a required `User Format Preferences` gate asking whether the layout, tables, grouping, visuals, labels, and evidence density match expectations; and a required `Final Artifact Approval` gate for Stage 3 readiness. Raw Markdown packet text, search logs, or source notes may appear only as supplemental source views after the rendered review UI and never replace the Stage 2 review sections.
 
 **Required inline questions.** In `review` pages, each gate must contain at least one required inline question placed directly under the content it governs, inside a visually distinct question block. Each question must use radio-button inputs and include two standing options after the skill-generated choices: "Other / None of the above" backed by a multi-line text box for free-form input, and "Need clarification" backed by an optional notes box where the user can explain what is unclear. When any radio option other than "Other" or "Need clarification" is selected, show an optional "Additional notes" text box beneath it so the user can qualify their choice. Generate questions based on what genuinely needs user input -- do not add filler questions. Do not create a separate bottom "Decisions & Clarifications" section. Confirmed pages must not keep these as required input controls; render the answered decisions as read-only records.
 

package/packs/agentic-skills-bench/codex/benchmark-test-skill/CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## v0.2 - 2026-06-12
+
+- Made alignment pages optional by default: report inline and write the skill's normal durable artifacts unless the user requests an alignment page or the agent identifies a concrete clarification/review need.
+
 ## v0.0
 
 - Archived previous skill contract.

package/packs/agentic-skills-bench/codex/benchmark-test-skill/SKILL.md

@@ -2,7 +2,7 @@
 name: benchmark-test-skill
 description: Run verify and benchmark tests for one agentic-skills skill, producing pass-rate, latency, cost, and consistency metrics
 type: execution
-version: v0.1
+version: v0.2
 argument-hint: "<skill name>"
 ---
 
@@ -116,7 +116,7 @@ The Markdown report and the final assistant response must both include a literal
 
 ## Alignment Page
 
-When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page following `ALIGNMENT-PAGE.md` in this skill's directory. Output: `alignment/benchmark-test-skill-{topic}.html`.
+By default, this skill reports results inline and writes only its normal durable artifacts (for example `tasks/*.md`, reports, queues, benchmark notes, status docs, or other skill-specific files). Do not build an alignment page automatically. Create `alignment/benchmark-test-skill-{topic}.html` only when the user explicitly requests an alignment page or when you explicitly identify a concrete clarification/review need that cannot be handled cleanly inline; when you create one, follow `ALIGNMENT-PAGE.md` in this skill's directory.
 
 ## Constraints