skillpacks 0.1.1 → 0.1.2

package/packs/agentic-skills-bench/codex/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/alignment-loop/claude/vertical-slice-splitter/ALIGNMENT-PAGE.md

@@ -1,6 +1,6 @@
 # Alignment Page — vertical-slice-splitter
 
-When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment/vertical-slice-splitter-{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/vertical-slice-splitter-{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-vertical-slice-splitter-research.md`; product-path mode uses `research/{slug}/_working/preliminary-vertical-slice-splitter-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-vertical-slice-splitter-research.md`; product-path mode uses `research/{slug}/_working/preliminary-vertical-slice-splitter-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/alignment-loop/claude/vertical-slice-splitter/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/alignment-loop/claude/vertical-slice-splitter/SKILL.md

@@ -2,7 +2,7 @@
 name: vertical-slice-splitter
 description: Decompose a destination doc or spec into vertical-slice issue cards with a dependency DAG
 type: planning
-version: v0.1
+version: v0.2
 argument-hint: "[path to destination doc or spec]"
 ---
 
@@ -56,7 +56,7 @@ Decompose a destination doc or spec into independently grabbable vertical-slice
 
 ## 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/vertical-slice-splitter-{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/vertical-slice-splitter-{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.
 
 ## Default Shipping Contract
 

package/packs/alignment-loop/claude/vertical-slice-splitter/archive/v0.1/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: vertical-slice-splitter
+description: Decompose a destination doc or spec into vertical-slice issue cards with a dependency DAG
+type: planning
+version: v0.1
+argument-hint: "[path to destination doc or spec]"
+---
+
+# Vertical Slice Splitter
+
+Decompose a destination doc or spec into independently grabbable vertical-slice issue cards.
+
+## Process
+
+1. **Read input document** from `$ARGUMENTS` (destination doc or spec).
+2. **Explore codebase:** file structure, layers, modules, existing test boundaries.
+3. **Identify layers** the work crosses (DB, service, API, UI, infra, etc.).
+4. **Decompose into vertical slices** — each slice crosses all relevant layers for its scope.
+5. **Reject horizontal-only slices.** Enforce tracer-bullet: slice 000 must produce something visible and testable end-to-end.
+6. **For each slice determine:**
+   - Title, description (2-5 sentences), acceptance criteria (testable)
+   - Dependencies: `blocks` and `blocked-by` (referencing other slice IDs)
+   - Label: `afk` | `human-review` | `pair`
+7. **Build DAG**, validate acyclic, identify parallel groups.
+8. **Check `issues/` directory.** If it has existing content, ask user: archive or append.
+9. **Write files:**
+   - `issues/DAG.md` — mermaid graph + summary table + parallel group annotations
+   - `issues/000-[slug].md` through `issues/NNN-[slug].md`
+
+## Issue File Format
+
+```markdown
+# [Title]
+
+**Label:** afk | human-review | pair
+**Blocks:** 001, 003
+**Blocked by:** none
+
+## Description
+[2-5 sentences]
+
+## Acceptance Criteria
+- [ ] ...
+
+## Notes
+[Optional implementation hints]
+```
+
+## Constraints
+
+- Every slice independently grabbable (one agent or session)
+- No slice larger than one focused session
+- First slice (000) is always the tracer bullet
+- DAG must be acyclic
+- `afk` slices must have unambiguous acceptance criteria (no taste judgment required)
+
+## 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/vertical-slice-splitter-{topic}.html`.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/alignment-loop/codex/vertical-slice-splitter/ALIGNMENT-PAGE.md

@@ -1,6 +1,6 @@
 # Alignment Page — vertical-slice-splitter
 
-When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment/vertical-slice-splitter-{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/vertical-slice-splitter-{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-vertical-slice-splitter-research.md`; product-path mode uses `research/{slug}/_working/preliminary-vertical-slice-splitter-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-vertical-slice-splitter-research.md`; product-path mode uses `research/{slug}/_working/preliminary-vertical-slice-splitter-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/alignment-loop/codex/vertical-slice-splitter/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/alignment-loop/codex/vertical-slice-splitter/SKILL.md

@@ -2,7 +2,7 @@
 name: vertical-slice-splitter
 description: Decompose a destination doc or spec into vertical-slice issue cards with a dependency DAG
 type: planning
-version: v0.1
+version: v0.2
 ---
 
 # Vertical Slice Splitter
@@ -52,7 +52,7 @@ Decompose a destination doc or spec into independently grabbable vertical-slice
 
 ## 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/vertical-slice-splitter-{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/vertical-slice-splitter-{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.
 
 ## Default Shipping Contract
 

package/packs/alignment-loop/codex/vertical-slice-splitter/archive/v0.1/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: vertical-slice-splitter
+description: Decompose a destination doc or spec into vertical-slice issue cards with a dependency DAG
+type: planning
+version: v0.1
+---
+
+# Vertical Slice Splitter
+
+Invoke as `$vertical-slice-splitter`.
+
+Decompose a destination doc or spec into independently grabbable vertical-slice issue cards.
+
+## Process
+
+1. Read input document from `$ARGUMENTS`.
+2. Explore codebase: file structure, layers, modules, test boundaries.
+3. Identify layers the work crosses (DB, service, API, UI, infra, etc.).
+4. Decompose into vertical slices — each crosses all relevant layers for its scope.
+5. Reject horizontal-only slices. Slice 000 must be a tracer bullet: visible and testable end-to-end.
+6. For each slice: title, description (2-5 sentences), testable acceptance criteria, dependency edges (`blocks`/`blocked-by`), label (`afk` | `human-review` | `pair`).
+7. Build DAG, validate acyclic, identify parallel groups.
+8. If `issues/` has existing content, archive it to `docs/history/archive/YYYY-MM-DD/HHMMSS/issues/`.
+9. Write `issues/DAG.md` (mermaid graph + summary table + parallel groups) and `issues/000-[slug].md` through `issues/NNN-[slug].md`.
+
+## Issue File Format
+
+```markdown
+# [Title]
+
+**Label:** afk | human-review | pair
+**Blocks:** 001, 003
+**Blocked by:** none
+
+## Description
+[2-5 sentences]
+
+## Acceptance Criteria
+- [ ] ...
+
+## Notes
+[Optional implementation hints]
+```
+
+## Constraints
+
+- Every slice independently grabbable (one agent or session)
+- No slice larger than one focused session
+- First slice (000) is always the tracer bullet
+- DAG must be acyclic
+- `afk` slices must have unambiguous acceptance criteria (no taste judgment)
+
+## 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/vertical-slice-splitter-{topic}.html`.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/alignment-page-admin/claude/upgrade-alignment-pages/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## v0.3 - 2026-06-13
+
+- Removed direct execution-loop command handoffs from non-exec routing; route through approved YAML, task, or roadmap artifacts instead.
+
+
 ## v0.2 - 2026-06-11
 
 - Update required alignment-page feature wording from separate feedback-only/final-answer YAML paths to local section feedback YAML plus unified response YAML.

package/packs/alignment-page-admin/claude/upgrade-alignment-pages/SKILL.md

@@ -2,7 +2,7 @@
 name: upgrade-alignment-pages
 description: Audit and explicitly upgrade generated alignment/*.html review pages to the current local alignment-page standard while preserving page-specific context
 type: ops
-version: v0.2
+version: v0.3
 argument-hint: "[--repo <path>] [--apply] [alignment/*.html...]"
 ---
 
@@ -33,7 +33,7 @@ Use this skill when a repository already has generated `alignment/*.html` review
    - If the user provided page paths, include only those paths after confirming they are inside the project-root `alignment/` directory.
 
 2. Load local standards:
-   - Read applicable local convention sources from `AGENTS.md`, `CLAUDE.md`, and active bundled `ALIGNMENT-PAGE.md` files found under `global/`, `packs/`, `.claude/skills/`, and `.codex/skills/`.
+   - Read applicable local convention sources from `AGENTS.md`, `CLAUDE.md`, and active bundled `ALIGNMENT-PAGE.md` files found under `base/`, `packs/`, `.claude/skills/`, and `.codex/skills/`.
    - Treat those local files as read-only standards. Do not fetch external standards.
    - Extract the current required HTML behaviors: dark-mode styling, inline approval gates, section feedback controls, local section feedback YAML, unified response YAML, copy fallback behavior, unanswered-question handling, archive-before-replace behavior, and diff/change highlighting for updates.
 
@@ -58,7 +58,7 @@ Use this skill when a repository already has generated `alignment/*.html` review
        - Acceptance criteria matching the audit findings
      - If `tasks/todo.md` already has unchecked items, append the phase at the bottom with a separator (`---`) and warn the user about pre-existing items.
      - Output the full audit report.
-     - Report: "Generated exec-loop task plan with N steps. Recommended next command: /exec"
+     - Report: "Generated exec-loop task plan with N steps. Recommended next route: approved task artifact"
      - Stop. Do not modify any HTML files.
    - If count <= 2: proceed to step 5 (inline apply).
 
@@ -86,7 +86,7 @@ Include:
 - In apply mode, archive paths and changed page paths.
 - Verification performed.
 - Next action: usually `/compile-central-alignment` after successful apply, or no mutation needed when all pages are current.
-- In batch mode: the generated `tasks/todo.md` phase with exec-loop steps and the recommended `/exec` command.
+- In batch mode: the generated `tasks/todo.md` phase with execution steps and the approved-artifact route.
 
 ## Constraints
 
@@ -102,5 +102,5 @@ Include:
 
 - **Audit mode:** no file mutations; no commit or push.
 - **Apply mode (inline, ≤2 pages):** modified generated alignment pages and archive copies are normal repo artifacts. Follow the target repository's shipping rules after verification.
-- **Apply mode (batch, >2 pages):** generates `tasks/todo.md` phase only; does not modify any HTML files. Commit the task plan, then hand off to `/exec`.
-- **Default next-step routing:** after successful inline apply, `Recommended next command: /compile-central-alignment`; after batch-mode handoff, `Recommended next command: /exec`; otherwise report the audit result and recommend no follow-up skill when no upgrades are needed.
+- **Apply mode (batch, >2 pages):** generates `tasks/todo.md` phase only; does not modify any HTML files. Commit the task plan, then stop; the approved task artifact records the next executable step.
+- **Default next-step routing:** after successful inline apply, `Recommended next command: /compile-central-alignment`; after batch-mode handoff, `Recommended next route: approved task artifact`; otherwise report the audit result and recommend no follow-up skill when no upgrades are needed.

package/packs/alignment-page-admin/claude/upgrade-alignment-pages/archive/v0.2/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: upgrade-alignment-pages
+description: Audit and explicitly upgrade generated alignment/*.html review pages to the current local alignment-page standard while preserving page-specific context
+type: ops
+version: v0.2
+argument-hint: "[--repo <path>] [--apply] [alignment/*.html...]"
+---
+
+# Upgrade Alignment Pages
+
+Invoke as `/upgrade-alignment-pages`.
+
+Use this skill when a repository already has generated `alignment/*.html` review pages and the user wants to audit or update them against the current local alignment-page convention. This skill targets generated alignment HTML artifacts only.
+
+## Inputs
+
+- Default target repository: current working directory.
+- Optional `--repo <path>` to target another repository.
+- Optional explicit page paths under the target repository's `alignment/` directory.
+- Optional `--apply`, or clear user wording such as "apply the upgrade" or "upgrade these pages", to allow page rewrites.
+
+## Mode
+
+- Default mode is audit/dry-run.
+- The skill name alone is not apply intent; do not modify files unless the visible user request explicitly asks to apply or upgrade existing pages.
+- In audit/dry-run mode, inspect pages and report drift without creating, editing, moving, or deleting any files.
+
+## Process
+
+1. Resolve scope:
+   - Locate the project-root `alignment/` directory; stop if absent.
+   - Enumerate `alignment/*.html`, excluding `alignment/index.html`.
+   - If the user provided page paths, include only those paths after confirming they are inside the project-root `alignment/` directory.
+
+2. Load local standards:
+   - Read applicable local convention sources from `AGENTS.md`, `CLAUDE.md`, and active bundled `ALIGNMENT-PAGE.md` files found under `global/`, `packs/`, `.claude/skills/`, and `.codex/skills/`.
+   - Treat those local files as read-only standards. Do not fetch external standards.
+   - Extract the current required HTML behaviors: dark-mode styling, inline approval gates, section feedback controls, local section feedback YAML, unified response YAML, copy fallback behavior, unanswered-question handling, archive-before-replace behavior, and diff/change highlighting for updates.
+
+3. Audit every selected page:
+   - Read the whole HTML file before judging it.
+   - Identify page-specific substance: title, meta/context, research findings, evidence/source matrices, assumptions, decisions, open questions, approval gates, review notes, proposed file changes, prior user feedback, and any page-specific scripts.
+   - Report missing or stale standard features per page.
+   - Classify each page as `current`, `upgrade-needed`, or `blocked-content-loss-risk`.
+
+4. Stop on content-loss risk:
+   - If a page's structure is too ambiguous to upgrade while preserving substantive content, do not rewrite it.
+   - Report exactly what content could not be mapped and what human decision is needed.
+
+4b. Batch-mode handoff (apply mode only):
+   - Count pages classified as `upgrade-needed` (excluding `blocked-content-loss-risk`).
+   - If count > 2:
+     - Generate a phase in `tasks/todo.md` titled "## Phase: Upgrade Alignment Pages" with:
+       - Execution Profile: serial
+       - A Context block listing the standards sources discovered in step 2 and the archive timestamp path (`docs/history/archive/YYYY-MM-DD/HHMMSS/`)
+       - One checklist step per upgrade-needed page: `- [ ] Upgrade alignment/<filename>.html — archive original, rewrite to current standard preserving all content, verify content preservation`
+       - A final step: `- [ ] Run /compile-central-alignment and verify all archives; commit and push`
+       - Acceptance criteria matching the audit findings
+     - If `tasks/todo.md` already has unchecked items, append the phase at the bottom with a separator (`---`) and warn the user about pre-existing items.
+     - Output the full audit report.
+     - Report: "Generated exec-loop task plan with N steps. Recommended next command: /exec"
+     - Stop. Do not modify any HTML files.
+   - If count <= 2: proceed to step 5 (inline apply).
+
+5. Apply only when explicit:
+   - Before replacing each page, archive the original to `docs/history/archive/YYYY-MM-DD/HHMMSS/alignment/<filename>.html`.
+   - Rewrite the page contextually from the original, preserving page-specific research, decisions, questions, gates, review context, and user feedback.
+   - Add or modernize missing standard elements without replacing the page with a generic template.
+   - Preserve relative links and keep the page self-contained unless the original already used explicit external resources.
+   - Highlight upgrade changes where useful with inline notes, a change summary section, or scoped diff styling.
+
+6. Verify after apply:
+   - Confirm every changed page has a matching archive copy.
+   - Re-open each changed page textually and confirm the preserved title, decisions/findings, questions, and gates still exist.
+   - Run or recommend `/compile-central-alignment` so `alignment/index.html` reflects updated page metadata.
+
+## Audit Report
+
+Include:
+
+- Target repository and mode.
+- Standards sources read.
+- Pages inspected and pages excluded.
+- Per-page status with missing standard features.
+- Content preservation risks or blockers.
+- In apply mode, archive paths and changed page paths.
+- Verification performed.
+- Next action: usually `/compile-central-alignment` after successful apply, or no mutation needed when all pages are current.
+- In batch mode: the generated `tasks/todo.md` phase with exec-loop steps and the recommended `/exec` command.
+
+## Constraints
+
+- Do not edit `CLAUDE.md`, `AGENTS.md`, any `SKILL.md`, or any bundled `ALIGNMENT-PAGE.md` file.
+- Do not modify non-alignment HTML files.
+- Do not modify `alignment/index.html`; leave index regeneration to `/compile-central-alignment`.
+- Do not rewrite pages in audit/dry-run mode.
+- Do not replace page-specific content with a generic template.
+- Stop and report when an upgrade is likely to lose research, decisions, questions, gates, or review context.
+- Do not create or modify GitHub Actions workflows.
+
+## Default Shipping Contract
+
+- **Audit mode:** no file mutations; no commit or push.
+- **Apply mode (inline, ≤2 pages):** modified generated alignment pages and archive copies are normal repo artifacts. Follow the target repository's shipping rules after verification.
+- **Apply mode (batch, >2 pages):** generates `tasks/todo.md` phase only; does not modify any HTML files. Commit the task plan, then hand off to `/exec`.
+- **Default next-step routing:** after successful inline apply, `Recommended next command: /compile-central-alignment`; after batch-mode handoff, `Recommended next command: /exec`; otherwise report the audit result and recommend no follow-up skill when no upgrades are needed.

package/packs/alignment-page-admin/codex/upgrade-alignment-pages/CHANGELOG.md

@@ -1,5 +1,10 @@
 # Changelog
 
+## v0.3 - 2026-06-13
+
+- Removed direct execution-loop command handoffs from non-exec routing; route through approved YAML, task, or roadmap artifacts instead.
+
+
 ## v0.2 - 2026-06-11
 
 - Update required alignment-page feature wording from separate feedback-only/final-answer YAML paths to local section feedback YAML plus unified response YAML.

package/packs/alignment-page-admin/codex/upgrade-alignment-pages/SKILL.md

@@ -2,7 +2,7 @@
 name: upgrade-alignment-pages
 description: Audit and explicitly upgrade generated alignment/*.html review pages to the current local alignment-page standard while preserving page-specific context
 type: ops
-version: v0.2
+version: v0.3
 argument-hint: "[--repo <path>] [--apply] [alignment/*.html...]"
 ---
 
@@ -33,7 +33,7 @@ Use this skill when a repository already has generated `alignment/*.html` review
    - If the user provided page paths, include only those paths after confirming they are inside the project-root `alignment/` directory.
 
 2. Load local standards:
-   - Read applicable local convention sources from `AGENTS.md`, `CLAUDE.md`, and active bundled `ALIGNMENT-PAGE.md` files found under `global/`, `packs/`, `.claude/skills/`, and `.codex/skills/`.
+   - Read applicable local convention sources from `AGENTS.md`, `CLAUDE.md`, and active bundled `ALIGNMENT-PAGE.md` files found under `base/`, `packs/`, `.claude/skills/`, and `.codex/skills/`.
    - Treat those local files as read-only standards. Do not fetch external standards.
    - Extract the current required HTML behaviors: dark-mode styling, inline approval gates, section feedback controls, local section feedback YAML, unified response YAML, copy fallback behavior, unanswered-question handling, archive-before-replace behavior, and diff/change highlighting for updates.
 
@@ -58,7 +58,7 @@ Use this skill when a repository already has generated `alignment/*.html` review
        - Acceptance criteria matching the audit findings
      - If `tasks/todo.md` already has unchecked items, append the phase at the bottom with a separator (`---`) and warn the user about pre-existing items.
      - Output the full audit report.
-     - Report: "Generated exec-loop task plan with N steps. Recommended next command: $exec"
+     - Report: "Generated exec-loop task plan with N steps. Recommended next route: approved task artifact"
      - Stop. Do not modify any HTML files.
    - If count <= 2: proceed to step 5 (inline apply).
 
@@ -86,7 +86,7 @@ Include:
 - In apply mode, archive paths and changed page paths.
 - Verification performed.
 - Next action: usually `$compile-central-alignment` after successful apply, or no mutation needed when all pages are current.
-- In batch mode: the generated `tasks/todo.md` phase with exec-loop steps and the recommended `$exec` command.
+- In batch mode: the generated `tasks/todo.md` phase with execution steps and the approved-artifact route.
 
 ## Constraints
 
@@ -102,5 +102,5 @@ Include:
 
 - **Audit mode:** no file mutations; no commit or push.
 - **Apply mode (inline, ≤2 pages):** modified generated alignment pages and archive copies are normal repo artifacts. Follow the target repository's shipping rules after verification.
-- **Apply mode (batch, >2 pages):** generates `tasks/todo.md` phase only; does not modify any HTML files. Commit the task plan, then hand off to `$exec`.
-- **Default next-step routing:** after successful inline apply, `Recommended next command: $compile-central-alignment`; after batch-mode handoff, `Recommended next command: $exec`; otherwise report the audit result and recommend no follow-up skill when no upgrades are needed.
+- **Apply mode (batch, >2 pages):** generates `tasks/todo.md` phase only; does not modify any HTML files. Commit the task plan, then stop; the approved task artifact records the next executable step.
+- **Default next-step routing:** after successful inline apply, `Recommended next command: $compile-central-alignment`; after batch-mode handoff, `Recommended next route: approved task artifact`; otherwise report the audit result and recommend no follow-up skill when no upgrades are needed.