skillpacks 0.1.0

package/packs/knowledge-check/claude/quiz-me/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: quiz-me
+description: Adversarial one-question-at-a-time questioning to verify deep reading comprehension of alignment pages, specs, or any document
+type: review
+version: v0.0
+argument-hint: "[file-path-or-glob]"
+---
+
+# Quiz Me
+
+Adversarial comprehension testing. Reads a document silently, then grills the user one question at a time to verify they actually read it — not skimmed it, not got the gist, actually read it. Delivers a pass/fail verdict when done.
+
+This is not teaching. This is not alignment-building. This is a test. The user claims they read something; this skill finds out if that's true.
+
+## Process
+
+### Phase 1: Silent Document Ingestion
+
+1. **Resolve input files.**
+   - If `$ARGUMENTS` contains a file path or glob, read those files.
+   - If `$ARGUMENTS` is empty, find all alignment HTML files (`docs/**/*.html`) and spec documents (`specs/**/*.md`) in the current repo. If multiple files are found, ask the user which document(s) to quiz on.
+   - Supported formats: HTML, Markdown, plain text.
+   - If no readable document is found, stop and tell the user.
+
+2. **Analyze document structure internally.**
+   - Identify major sections, key decisions, trade-offs, cross-section relationships, specific constraints/numbers/names, and non-obvious details.
+   - Build an internal question plan that covers every major section, biased toward:
+     - Cross-section relationships ("How does X in section 3 affect Y in section 7?")
+     - Implications and trade-offs ("What happens if the migration in step 2 fails?")
+     - Specific details that skimmers miss (exact constraints, numbers, edge cases)
+     - Intent questions ("Why was approach A chosen over approach B?")
+     - Synthesis questions ("Summarize the three most important trade-offs.")
+   - Do NOT surface any of this analysis to the user.
+
+3. **Open the quiz.** Tell the user which document(s) they're being quizzed on and that you'll ask one question at a time. Nothing else — no summary, no encouragement, no preview of what's coming.
+
+### Phase 2: Adversarial Questioning
+
+Ask **one question per turn**. Non-negotiable.
+
+Use `AskUserQuestion` for every question. Provide 2-3 plausible multiple-choice options plus the implicit "Other" free-text option. At least one option should be a trap — superficially plausible but wrong if the user actually read the document. Vary whether the correct answer is a named option or requires free-text via "Other".
+
+**Question types** (mix throughout, do not cluster by type):
+
+- **Relationship:** "Section X describes [thing]. How does that interact with [thing from section Y]?"
+- **Implication:** "If [condition from the doc] changes, what breaks?"
+- **Detail trap:** "What specific [constraint/number/name] does the doc specify for [thing]?"
+- **Intent:** "Why does the doc recommend [approach] instead of [alternative]?"
+- **Synthesis:** "What are the most important trade-offs the document makes?"
+
+**After each answer, evaluate strictly:**
+
+- **Correct and specific:** Acknowledge in one sentence. Move to next question.
+- **Vague or incomplete:** Push back. "That's too vague. What specifically does the doc say about [X]?" Do not accept hand-wavy answers. Re-ask or ask a targeted follow-up.
+- **Wrong:** State what's wrong. Give the user one chance to correct. If they fail again, note the gap and move on.
+- **Suspiciously perfect verbatim recall:** Ask a follow-up that requires synthesis, not recitation. If they can synthesize, accept it. If they can only parrot, mark the section as weak.
+
+Track per-section comprehension internally. Do not show the user a running score.
+
+### Phase 3: Termination
+
+Continue until one of:
+
+- The user has demonstrated understanding across **all major sections** — no section left untested.
+- The user explicitly gives up or asks to stop.
+
+Do NOT terminate early because the user got a few questions right. Cover the full document. Minimum 5 questions for short documents, more for longer ones.
+
+### Phase 4: Verdict
+
+When the quiz ends, deliver:
+
+1. **Pass or Fail.** Binary. Pass means the user demonstrated deep comprehension across all major sections. Fail means one or more sections had weak or missing comprehension.
+
+2. **Per-section summary:**
+   - Sections with strong comprehension
+   - Sections with weak or missing comprehension
+   - Specific gaps identified
+
+3. **If fail:** List which sections to re-read and why.
+
+## Constraints
+
+- **Read-only.** Do not write, create, modify, or delete any files.
+- **No commits, no pushes, no file mutations.**
+- **No external requests.** All content is local.
+- **One question per turn.** Always.
+- **Use AskUserQuestion for every question.** Do not ask questions via plain text output.
+- **Adversarial but not hostile.** Push back firmly on bad answers. Do not insult the user. Do not congratulate excessively on correct answers.
+- **No teaching.** Do not explain document content during the quiz. If the user gets something wrong, state what's wrong — do not deliver a lesson.
+- **No hints.** Do not help the user arrive at the right answer. This is a test, not a tutorial.
+
+## Differences from taste-calibration
+
+| | quiz-me | taste-calibration |
+|---|---|---|
+| Purpose | Test comprehension of existing docs | Build alignment for new work |
+| Tone | Adversarial examiner | Socratic collaborator |
+| Input | Existing document to test against | Rough idea or problem |
+| Output | Pass/fail verdict | Shared understanding summary |
+| Recommended answers | Never | Always |
+| File output | None | None |
+
+## Default Shipping Contract
+
+Read-only — do not create or modify tracked repository files. Follow the shared shipping contract convention in CLAUDE.md for next-step routing only.
+

package/packs/knowledge-check/codex/quiz-me/CHANGELOG.md

@@ -0,0 +1,5 @@
+# Changelog
+
+## v0.0 - 2026-06-02
+
+- Added the initial Codex mirror of `quiz-me` with read-only quiz behavior and Codex-compatible user-question handling.

package/packs/knowledge-check/codex/quiz-me/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: quiz-me
+description: Adversarial one-question-at-a-time questioning to verify deep reading comprehension of alignment pages, specs, or any document
+type: review
+version: v0.0
+argument-hint: "[file-path-or-glob]"
+---
+
+# Quiz Me
+
+Invoke as `$quiz-me`.
+
+Adversarial comprehension testing. Reads a document silently, then grills the user one question at a time to verify they actually read it -- not skimmed it, not got the gist, actually read it. Delivers a pass/fail verdict when done.
+
+This is not teaching. This is not alignment-building. This is a test. The user claims they read something; this skill finds out if that's true.
+
+## Process
+
+### Phase 1: Silent Document Ingestion
+
+1. **Resolve input files.**
+   - If `$ARGUMENTS` contains a file path or glob, read those files.
+   - If `$ARGUMENTS` is empty, find all alignment HTML files (`docs/**/*.html`) and spec documents (`specs/**/*.md`) in the current repo. If multiple files are found, ask the user which document(s) to quiz on.
+   - Supported formats: HTML, Markdown, plain text.
+   - If no readable document is found, stop and tell the user.
+
+2. **Analyze document structure internally.**
+   - Identify major sections, key decisions, trade-offs, cross-section relationships, specific constraints/numbers/names, and non-obvious details.
+   - Build an internal question plan that covers every major section, biased toward:
+     - Cross-section relationships ("How does X in section 3 affect Y in section 7?")
+     - Implications and trade-offs ("What happens if the migration in step 2 fails?")
+     - Specific details that skimmers miss (exact constraints, numbers, edge cases)
+     - Intent questions ("Why was approach A chosen over approach B?")
+     - Synthesis questions ("Summarize the three most important trade-offs.")
+   - Do NOT surface any of this analysis to the user.
+
+3. **Open the quiz.** Tell the user which document(s) they're being quizzed on and that you'll ask one question at a time. Nothing else -- no summary, no encouragement, no preview of what's coming.
+
+### Phase 2: Adversarial Questioning
+
+Ask **one question per turn**. Non-negotiable.
+
+Use Codex's available user-input mechanism for every question. When a structured user-input tool is available, present 2-3 plausible multiple-choice options and leave room for the user's free-form "Other" answer. When no structured user-input tool is available, ask exactly one concise question in the conversation, include 2-3 labeled options, explicitly allow a free-form answer, and wait for the user's reply. At least one option should be a trap -- superficially plausible but wrong if the user actually read the document. Vary whether the correct answer is a named option or requires free text.
+
+**Question types** (mix throughout, do not cluster by type):
+
+- **Relationship:** "Section X describes [thing]. How does that interact with [thing from section Y]?"
+- **Implication:** "If [condition from the doc] changes, what breaks?"
+- **Detail trap:** "What specific [constraint/number/name] does the doc specify for [thing]?"
+- **Intent:** "Why does the doc recommend [approach] instead of [alternative]?"
+- **Synthesis:** "What are the most important trade-offs the document makes?"
+
+**After each answer, evaluate strictly:**
+
+- **Correct and specific:** Acknowledge in one sentence. Move to next question.
+- **Vague or incomplete:** Push back. "That's too vague. What specifically does the doc say about [X]?" Do not accept hand-wavy answers. Re-ask or ask a targeted follow-up.
+- **Wrong:** State what's wrong. Give the user one chance to correct. If they fail again, note the gap and move on.
+- **Suspiciously perfect verbatim recall:** Ask a follow-up that requires synthesis, not recitation. If they can synthesize, accept it. If they can only parrot, mark the section as weak.
+
+Track per-section comprehension internally. Do not show the user a running score.
+
+### Phase 3: Termination
+
+Continue until one of:
+
+- The user has demonstrated understanding across **all major sections** -- no section left untested.
+- The user explicitly gives up or asks to stop.
+
+Do NOT terminate early because the user got a few questions right. Cover the full document. Minimum 5 questions for short documents, more for longer ones.
+
+### Phase 4: Verdict
+
+When the quiz ends, deliver:
+
+1. **Pass or Fail.** Binary. Pass means the user demonstrated deep comprehension across all major sections. Fail means one or more sections had weak or missing comprehension.
+
+2. **Per-section summary:**
+   - Sections with strong comprehension
+   - Sections with weak or missing comprehension
+   - Specific gaps identified
+
+3. **If fail:** List which sections to re-read and why.
+
+## Constraints
+
+- **Read-only.** Do not write, create, modify, or delete any files.
+- **No commits, no pushes, no file mutations.**
+- **No external requests.** All content is local.
+- **One question per turn.** Always.
+- **Use Codex-compatible user-input handling for every question.** Do not batch questions, and do not ask multiple independent questions in one response.
+- **Adversarial but not hostile.** Push back firmly on bad answers. Do not insult the user. Do not congratulate excessively on correct answers.
+- **No teaching.** Do not explain document content during the quiz. If the user gets something wrong, state what's wrong -- do not deliver a lesson.
+- **No hints.** Do not help the user arrive at the right answer. This is a test, not a tutorial.
+
+## Differences from taste-calibration
+
+| | quiz-me | taste-calibration |
+|---|---|---|
+| Purpose | Test comprehension of existing docs | Build alignment for new work |
+| Tone | Adversarial examiner | Socratic collaborator |
+| Input | Existing document to test against | Rough idea or problem |
+| Output | Pass/fail verdict | Shared understanding summary |
+| Recommended answers | Never | Always |
+| File output | None | None |
+
+## Default Shipping Contract
+
+Read-only — do not create or modify tracked repository files. Follow the shared shipping contract convention in CLAUDE.md for next-step routing only.
+

package/packs/knowledge-check/codex/quiz-me/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Quiz Me"
+  short_description: "Adversarial comprehension quiz for local docs"
+  default_prompt: "Use $quiz-me to test whether I deeply understood a local document."
+
+policy:
+  allow_implicit_invocation: true

package/packs/monorepo/PACK.md

@@ -0,0 +1,95 @@
+# Monorepo Pack
+
+Project-local workflows for pnpm workspace monorepos that need package-aware planning, execution, guardrails, and shipping.
+
+Install this pack when a project uses `pnpm-workspace.yaml` and may use Turborepo via `turbo.json`, especially when roadmap phases need to split serial cross-cutting work from package-scoped parallel lanes. V1 focuses on pnpm workspaces plus Turborepo because those files provide stable detection, package graph, and build/test/lint orchestration signals.
+
+Default flow:
+
+```text
+mono-detect -> mono-exec -> mono-guard -> mono-ship
+```
+
+Install in a project with:
+
+```bash
+scripts/pack.sh install monorepo
+```
+
+Then refresh local skill links if needed:
+
+```bash
+scripts/pack.sh refresh
+```
+
+## Skills
+
+- `mono-detect`: detects pnpm workspace structure, optional Turborepo overlay, package metadata, internal dependency graph, and writes `.agents/monorepo.json`.
+- `mono-exec`: augments the standard `/exec` or `$exec` lifecycle with monorepo detection, lane-spec generation, pre-flight guard checks, cross-cutting serial work, package-scoped worktree dispatch on separate GitHub branches, and consolidation/PR review when a phase is explicitly eligible.
+- `mono-guard`: validates lane-spec artifacts before dispatch and verifies actual changed files stay inside declared lane ownership and branch/PR review requirements after integration.
+- `mono-ship`: augments the standard `/ship` or `$ship` lifecycle with package-scoped validation and transitive-dependent validation before delegating to normal shipping.
+- `mono-plan`: safe lane decomposition planning across monorepo packages.
+- `affected`: identifies packages and tests affected by changes in the monorepo.
+- `scaffold`: generates a new package or app in the monorepo following established project conventions.
+
+## Augmentation Injection Pattern
+
+This pack does not duplicate the global execution and shipping skills. It injects monorepo-aware pre/post steps around the existing contracts:
+
+- Pre-execution: run `mono-detect`, read the phase execution profile, generate lane specs when appropriate, and run `mono-guard` pre-flight.
+- Execution: keep root-only and cross-cutting steps serial in the main agent; dispatch only approved package-scoped lanes with disjoint `owns` paths and separate non-primary GitHub branches.
+- Post-integration: run consolidation/PR review, then `mono-guard` against the actual diff before package-scoped shipping.
+- Pre-ship: use `.agents/monorepo.json` and lane specs to run package and transitive-dependent validation before delegating to `/ship` or `$ship`.
+
+This differs from `*-kanban` packs, which intentionally provide workflow variants. The monorepo pack is an overlay that makes the normal skill pipeline workspace-aware while preserving the global skill contracts as the source of truth.
+
+## Package-Scope Tags
+
+Specs and roadmap phases may declare package scope with YAML frontmatter:
+
+```yaml
+---
+packages: [api, web]
+scope: cross-cutting
+---
+```
+
+Valid `scope` values:
+
+- `cross-cutting`: shared packages, multiple package boundaries, root coordination, or lockfile-affecting work; always serial.
+- `package-scoped`: work contained to declared package paths; eligible for parallel lanes only after guard validation and user approval.
+- `root-only`: root config, scripts, docs, or repository-level policy; always serial.
+
+When `scope` is omitted, agents infer `package-scoped` for one declared package and `cross-cutting` for multiple declared packages.
+
+## Turborepo Awareness
+
+When `turbo.json` exists, monorepo pack skills defer build, test, and lint commands to `turbo run` so Turborepo can apply cache-aware, dependency-aware ordering. Without Turborepo, the pack falls back to `pnpm --filter` and the dependency graph in `.agents/monorepo.json`.
+
+## V1 Scope
+
+V1 includes:
+
+- pnpm workspace detection from `pnpm-workspace.yaml`.
+- Turborepo detection from `turbo.json`.
+- `.agents/monorepo.json` as the package graph artifact.
+- `.agents/lane-specs.json` plus `tasks/lane-specs.md` as the lane dispatch artifact.
+- Guardrails for disjoint lane ownership, lockfile/root-config protection, dependency ordering, branch/PR isolation, and post-integration boundary checks.
+- Stop-all-lanes failure semantics that preserve failed worktree state for inspection.
+
+V1 does not include:
+
+- npm, Yarn, Lerna, or Nx support.
+- Multi-repository to monorepo migration.
+- Per-package task files.
+- GitHub Actions or CI integration.
+
+## Monorepo Skills
+
+`/mono-plan` is the planning authority for safe lane decomposition across monorepo packages. `mono-exec` consumes those execution-profile concepts and materializes lane specs for a project-local run.
+
+`/mono-guard` provides contracts and scripts for validating `.agents/lane-specs.json`, `.agents/monorepo.json`, and the integrated diff.
+
+`/affected` identifies packages and tests affected by changes. `/scaffold` generates new packages following project conventions.
+
+**Primary role:** Both - Claude-orchestration for lane review and approval; Codex-execution for detection scripts, artifacts, validation, and shipping.

package/packs/monorepo/claude/affected/CHANGELOG.md

@@ -0,0 +1,9 @@
+# Changelog
+
+## v0.0
+
+- Archived previous skill contract.
+
+## v0.1 - 2026-05-25
+
+- Added research-quality alignment requirements covering claim/evidence/inference separation, no-context-loss HTML translation, evidence matrices, confidence/assumption registers, source coverage, and research completeness gates.

package/packs/monorepo/claude/affected/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: affected
+description: Analyze which monorepo packages and apps are affected by current changes
+type: analysis
+version: v0.1
+argument-hint: "[optional: specific commit range or branch to analyze]"
+---
+
+# Affected
+
+Determine which packages and apps in the monorepo are affected by current changes. Useful before committing, testing, or deploying to know the blast radius.
+
+## Process
+
+1. **Determine the change set:**
+   - If `$ARGUMENTS` specifies a commit range or branch, use `git diff` for that range.
+   - Otherwise, use `git diff HEAD` (staged + unstaged changes).
+   - If no changes exist, check for unpushed commits with `git log @{u}..HEAD`.
+
+2. **Read the monorepo structure:**
+   - Check for `turbo.json`, `pnpm-workspace.yaml`, `lerna.json`, or `package.json` workspaces to understand the package graph.
+   - List all packages/apps and their locations.
+
+3. **Map changes to packages:**
+   - For each changed file, determine which package it belongs to.
+   - List directly changed packages.
+
+4. **Compute transitive dependents:**
+   - Read `package.json` of each directly changed package to find its `name`.
+   - Search other packages' `package.json` files for dependencies on the changed packages.
+   - Build the full dependency chain (direct → transitive).
+
+5. **Check for cross-cutting changes:**
+   - Root config changes (`tsconfig.json`, `turbo.json`, `.env*`, `tailwind.config.*`) affect all packages.
+   - Shared package changes (e.g., `packages/ui`, `packages/config`) cascade to consumers.
+
+6. **Identify what to test:**
+   - If Turborepo: suggest `turbo run test --filter=...[HEAD~1]` or equivalent.
+   - Otherwise: list the test commands for each affected package.
+
+## Output
+
+### Directly Changed
+- `packages/foo` — 3 files changed (briefly what)
+- `apps/bar` — 1 file changed (briefly what)
+
+### Transitively Affected
+- `apps/web` — depends on `packages/foo`
+- `apps/admin` — depends on `packages/foo` via `packages/shared`
+
+### Cross-Cutting
+- `tsconfig.base.json` changed — affects all TypeScript packages
+
+### Recommended Test Commands
+```bash
+# commands to test affected packages
+```
+
+## Constraints
+- Do not run tests — only analyze and recommend.
+- If the monorepo tool is Turborepo, prefer Turbo-native filtering where possible.
+- Keep the output concise — list packages, not individual files (unless scoped to a single package).
+
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/monorepo/claude/affected/archive/v0.0/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: affected
+description: Analyze which monorepo packages and apps are affected by current changes
+type: analysis
+version: v0.0
+argument-hint: "[optional: specific commit range or branch to analyze]"
+---
+
+# Affected
+
+Determine which packages and apps in the monorepo are affected by current changes. Useful before committing, testing, or deploying to know the blast radius.
+
+## Process
+
+1. **Determine the change set:**
+   - If `$ARGUMENTS` specifies a commit range or branch, use `git diff` for that range.
+   - Otherwise, use `git diff HEAD` (staged + unstaged changes).
+   - If no changes exist, check for unpushed commits with `git log @{u}..HEAD`.
+
+2. **Read the monorepo structure:**
+   - Check for `turbo.json`, `pnpm-workspace.yaml`, `lerna.json`, or `package.json` workspaces to understand the package graph.
+   - List all packages/apps and their locations.
+
+3. **Map changes to packages:**
+   - For each changed file, determine which package it belongs to.
+   - List directly changed packages.
+
+4. **Compute transitive dependents:**
+   - Read `package.json` of each directly changed package to find its `name`.
+   - Search other packages' `package.json` files for dependencies on the changed packages.
+   - Build the full dependency chain (direct → transitive).
+
+5. **Check for cross-cutting changes:**
+   - Root config changes (`tsconfig.json`, `turbo.json`, `.env*`, `tailwind.config.*`) affect all packages.
+   - Shared package changes (e.g., `packages/ui`, `packages/config`) cascade to consumers.
+
+6. **Identify what to test:**
+   - If Turborepo: suggest `turbo run test --filter=...[HEAD~1]` or equivalent.
+   - Otherwise: list the test commands for each affected package.
+
+## Output Format
+
+### Directly Changed
+- `packages/foo` — 3 files changed (briefly what)
+- `apps/bar` — 1 file changed (briefly what)
+
+### Transitively Affected
+- `apps/web` — depends on `packages/foo`
+- `apps/admin` — depends on `packages/foo` via `packages/shared`
+
+### Cross-Cutting
+- `tsconfig.base.json` changed — affects all TypeScript packages
+
+### Recommended Test Commands
+```bash
+# commands to test affected packages
+```
+
+## Constraints
+- Do not run tests — only analyze and recommend.
+- If the monorepo tool is Turborepo, prefer Turbo-native filtering where possible.
+- Keep the output concise — list packages, not individual files (unless scoped to a single package).
+
+
+## Alignment Page
+
+When this skill produces durable deliverables (research, specs, plans, reports, prototypes, or any document output), build a full-depth HTML alignment page at `alignment/affected-{topic}.html`. Use a normalized topic slug derived from the app, feature, research subject, report subject, or output filename.
+
+**Full content requirement.** The alignment page must contain the complete content of every proposed markdown deliverable -- every section, every finding, every detail, every list item. It is a thorough interactive review document, not a summary. Render the full deliverable content in clean, readable HTML with appropriate hierarchy, styling, and navigation. If the skill writes multiple scoped deliverables in one run, build one alignment page that contains all deliverables with anchor-linked navigation. Durable tracker artifacts, such as `research/assumption-tracker.md`, remain canonical markdown outputs but must also be fully rendered into the alignment page before approval.
+
+**Dark-mode styling.** Use a dark color scheme by default. Base CSS variables: `--bg: #0d1117; --surface: #161b22; --border: #30363d; --text: #c9d1d9; --text-muted: #8b949e; --accent: #58a6ff; --green: #3fb950; --red: #f85149; --orange: #d29922; --purple: #bc8cff;`. Apply `background: var(--bg); color: var(--text);` on body. Use `--surface` for cards, nav, and table headers. Use `--border` for all borders. Use `--purple` for question blocks and gate headings. Use `--accent` for links and section headings. Keep headings `color: #fff` or `var(--accent)` for hierarchy. Question block backgrounds should use `#1c2333`.
+
+**Alignment gates.** Treat gates as explicit review sections inside the HTML page. A gate blocks finalization until its required inline questions are answered and compiled into YAML. Include every gate that applies to the skill output, and include these gate types whenever relevant: evidence coverage, assumptions/confidence, scope/non-goals, candidate/verdict decisions, artifact destination, proposed file changes, coverage checkpoint, and post-approval route.
+
+**Report-only research gates.** For report-only or pre-approval research skills, the alignment page must explicitly contain evidence coverage, assumptions/confidence, recommended path, proposed file changes, and approval gates before any canonical research, spec, or task file is created or updated.
+
+
+**Required inline questions.** 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.
+
+**Gate YAML contract.** At the bottom of the page, include a "Compile Answers" button that aggregates answers from all inline gate questions throughout the page, including free-text notes. The button remains disabled until every required question has a selection, shows a count of remaining unanswered questions, and scrolls to the first unanswered question if clicked early. When every question is answered, generate a structured YAML block with one item per gate answer using this stable shape: `section`, `gate_type`, `status` (`answered`, `other`, or `needs-clarification`), `answer`, optional `notes`, and optional `target_artifact` or `target_path` when the gate controls file output. After successful compilation, automatically attempt to copy the YAML to the clipboard with the Clipboard API, display copy status, and display the YAML in a read-only textarea with an explicit "Copy YAML" button. The copy button must retry clipboard copy when supported and fall back to selecting the textarea contents when clipboard access is unavailable or blocked.
+
+**Pre-approval stop.** Before user approval, the next action is review of the HTML alignment page, not downstream routing. Ask the user to review the page and provide the compiled YAML answers. Do not include `Recommended next skill`, `Recommended next command`, or downstream routing language until after compiled YAML has been provided and the approved artifacts have been written or updated.
+
+**Diff highlighting on updates.** When the agent updates an existing alignment page after receiving compiled answers, highlight what changed since the previous version. The agent chooses inline annotation or side-by-side layout per situation.
+
+**Archiving.** Before replacing an existing alignment page, archive it to `docs/history/archive/YYYY-MM-DD/HHMMSS/alignment/affected-{topic}.html`.
+
+**Browser open.** Attempt to open the resulting HTML page in the browser and report whether the open succeeded or was blocked. A blocked browser-open attempt does not make the skill fail when the files were written correctly.
+
+## Default Shipping Contract
+
+- **Default next-step routing:** when reporting completion, 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>` so the next operator has a concrete handoff.
+- If this skill creates or modifies tracked repository files, finish by committing and pushing all intended changes to the repository primary branch (`main` when present, otherwise `master`) before stopping, even if the user did not explicitly ask for commit/push.
+- Do not leave tracked changes or unpushed commits behind. If unrelated tracked work is already present, either include it in sensible commits too or stop and explain the blocker.
+- This contract does not override stricter safety rules about secrets, destructive history changes, release publication/tag confirmation, or production deploy confirmation.

package/packs/monorepo/claude/mono-detect/CHANGELOG.md

@@ -0,0 +1,9 @@
+# Changelog
+
+## v0.0
+
+- Archived previous skill contract.
+
+## v0.1 - 2026-05-25
+
+- Added research-quality alignment requirements covering claim/evidence/inference separation, no-context-loss HTML translation, evidence matrices, confidence/assumption registers, source coverage, and research completeness gates.

package/packs/monorepo/claude/mono-detect/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: mono-detect
+description: Detect pnpm workspace structure, optional Turborepo overlay, package metadata, and internal dependency graph for monorepo-aware skills
+type: analysis
+version: v0.1
+argument-hint: "[optional: repository root]"
+invocation: sub-skill
+parent: mono-plan
+---
+
+# Mono Detect
+
+Use this skill to detect a pnpm workspace monorepo and generate the `.agents/monorepo.json` artifact consumed by the monorepo pack.
+
+`mono-detect` is the foundation skill for `mono-exec`, `mono-ship`, and `mono-guard`. Those skills use its output to inject monorepo-aware pre/post steps into the standard `/exec` and `/ship` contracts without duplicating the global workflow.
+
+## Augmentation Injection Pattern
+
+`mono-detect` is the pack's detection foundation for the augmentation injection pattern. It does not replace `/exec`, `/ship`, or global monorepo planning skills; it supplies `.agents/monorepo.json` so `mono-exec`, `mono-ship`, and `mono-guard` can inject monorepo-aware pre-flight and post-integration checks around those existing workflows.
+
+## Process
+
+1. Resolve the target repository root.
+   - Use `$ARGUMENTS` as the root when provided.
+   - Otherwise use the current working directory.
+2. Locate the pack script relative to this skill: `../../scripts/mono-detect.sh` from the monorepo pack root.
+3. Check whether `.agents/monorepo.json` is fresh:
+   - Run `packs/monorepo/scripts/mono-detect.sh <root> --check-stale`.
+   - If it prints `fresh: .agents/monorepo.json`, keep the existing artifact.
+   - If the file is missing, stale, or the check does not report fresh, run `packs/monorepo/scripts/mono-detect.sh <root>` to regenerate it.
+4. If detection fails because `pnpm-workspace.yaml` is missing:
+   - Report that the project is not a detected pnpm monorepo.
+   - Suggest `/mono-migrate` as a future V2 migration route when the user wants to convert a single-app project.
+   - Do not create `.agents/monorepo.json` by hand.
+5. Read `.agents/monorepo.json` and summarize:
+   - Workspace manager.
+   - Build orchestrator (`turborepo` when `turbo.json` is present, otherwise none).
+   - Package count and package paths.
+   - Internal dependency graph edges.
+   - Turborepo pipeline names.
+6. Report staleness behavior:
+   - Mention that the artifact is regenerated when `pnpm-workspace.yaml`, `turbo.json`, or workspace `package.json` files are newer than `.agents/monorepo.json`.
+7. Route the next step:
+   - If detection passed and the user is preparing execution, recommend `/mono-exec`.
+   - If detection passed and the user is checking lane safety, recommend `/mono-guard`.
+   - If detection failed because this is not a pnpm monorepo, recommend `/mono-migrate` as the V2 advisory route.
+
+## Output
+
+- **Detection:** detected, fresh, regenerated, or not detected.
+- **Workspace:** manager, build orchestrator, root path.
+- **Packages:** count plus package name/path list.
+- **Dependency graph:** internal dependency edges; say `none` when no internal edges exist.
+- **Turbo pipelines:** pipeline names when present; say `none` when Turborepo is absent.
+- **Artifact:** `.agents/monorepo.json` path and whether it was reused or regenerated.
+- **Next work:** concrete follow-up.
+- **Recommended next command:** one command.
+
+## Constraints
+
+- Do not edit task files.
+- Do not run package manager install/add commands.
+- Do not infer non-pnpm workspace managers in V1.
+- Do not modify `.agents/monorepo.json` manually; use `mono-detect.sh`.
+- Treat `mono-detect` as an augmentation foundation for `mono-exec`, `mono-ship`, and `mono-guard`, not as a replacement for `/exec`, `/ship`, or global monorepo planning skills.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.