skillpacks 0.1.0

package/packs/monorepo/claude/mono-detect/archive/v0.0/SKILL.md

@@ -0,0 +1,95 @@
+---
+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.0
+argument-hint: "[optional: repository root]"
+---
+
+# 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-run`, `mono-ship`, and `mono-guard`. Those skills use its output to inject monorepo-aware pre/post steps into the standard `/run` 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 `/run`, `/ship`, or global monorepo planning skills; it supplies `.agents/monorepo.json` so `mono-run`, `mono-ship`, and `mono-guard` can inject monorepo-aware pre-flight and post-integration checks around those existing workflows.
+
+## Workflow
+
+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-run`.
+   - 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 Format
+
+- **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-run`, `mono-ship`, and `mono-guard`, not as a replacement for `/run`, `/ship`, or global monorepo planning skills.
+
+## 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/mono-detect-{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/mono-detect-{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 the two-line pair `**Next work:** <specific task, blocker, or follow-up>` 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-exec/CHANGELOG.md

@@ -0,0 +1,9 @@
+# Changelog
+
+## v0.1 - 2026-05-26
+
+- Renamed the execution wrapper command from `mono-run` to `mono-exec` to follow the exec command surface.
+
+## v0.0
+
+- Initial skill contract.

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

@@ -0,0 +1,115 @@
+---
+name: mono-exec
+description: Augment the standard exec lifecycle with monorepo detection, lane-spec generation, guard validation, and package-scoped dispatch
+type: execution
+version: v0.1
+argument-hint: "[--phase] [--pipeline]"
+invocation: orchestrator
+---
+
+# Mono Exec
+
+Use this skill to execute planned work in a pnpm workspace monorepo with package-aware guardrails. `mono-exec` does not replace `/exec`; it injects monorepo-aware pre/post steps around the standard `/exec` contract.
+
+## Augmentation Injection Pattern
+
+`mono-exec` adds these stages around normal exec execution:
+
+1. **Pre-execution:** run `mono-detect`, generate lane specs when the phase is eligible for parallel monorepo dispatch, run `mono-guard` pre-flight, and present lane specs for plan-mode approval.
+2. **Dispatch:** run cross-cutting steps serially first in the main agent, then dispatch package-scoped worktree waves on separate GitHub branches only after lane specs are approved and guard validation passes.
+3. **Post-dispatch:** perform consolidation/PR review, run `mono-guard --post-integration`, update lane-spec lifecycle, then continue to `mono-ship` when shipping is requested.
+
+The global `/exec` skill remains the source of truth for task selection, task docs, validation, history updates, commit/push, deploy handling, and next-step routing.
+
+## Flags
+
+- Default: execute the next incomplete step.
+- `--phase`: execute all steps in the current phase, using cross-cutting serial work first and package-scoped waves where eligible.
+- `--pipeline`: execute the monorepo run flow and continue into `mono-ship` after successful post-integration guard validation.
+
+## Process
+
+1. Run `mono-detect`.
+   - If the project is not a detected pnpm workspace monorepo, delegate directly to `/exec`.
+   - If `turbo.json` is present, record that build/test/lint should defer to `turbo run`.
+   - If Turborepo is absent, record that build/test/lint should fall back to `pnpm --filter`.
+2. Read the current phase execution profile from `tasks/todo.md` and, when needed for phase context, `tasks/roadmap.md`.
+3. Decide execution mode:
+   - If the phase mode is `serial`, delegate directly to `/exec`.
+   - If the phase mode is not monorepo-parallel eligible, delegate directly to `/exec`.
+   - If the phase mode is `agent-team` or explicitly package-scoped parallel work, continue with lane-spec generation.
+4. Generate `.agents/lane-specs.json`.
+   - Include `phase`, `source_roadmap_hash`, `lifecycle`, `cross_cutting_steps`, and `lanes`.
+   - Each lane must include `id`, `step`, `packages`, `owns`, `must_not_edit`, `depends_on`, `mode`, and `branch`.
+   - Put root-only, shared-package, lockfile, and root-config work into `cross_cutting_steps` with serial mode.
+   - Put package-contained work into lanes with package-owned `owns` paths.
+   - Ensure every package lane's `must_not_edit` includes lockfiles, root config files, and other lanes' package paths.
+   - Ensure every package lane's `branch` is a deterministic non-primary GitHub branch such as `agent-team/phase-N-<lane-id>`.
+5. Generate `tasks/lane-specs.md` as the committed human-readable mirror of `.agents/lane-specs.json`.
+6. Run `mono-guard` pre-flight.
+   - Use `packs/monorepo/scripts/lane-spec-validate.sh` through `mono-guard`.
+   - Stop on `FAIL`.
+   - Present `WARN` findings for review before dispatch.
+7. Enter plan mode with lane specs for approval before launching package-scoped lanes.
+8. Dispatch work:
+   - Execute cross-cutting steps serially in the main agent first.
+   - Create worktree-isolated package lanes on their declared GitHub branches for parallel work after cross-cutting work is integrated.
+   - Give every lane its `branch`, `owns`, `must_not_edit`, `depends_on`, package scope, validation commands, and deliverable.
+   - Require every lane to commit to its branch, push it, open or update a draft PR, and return branch name, commit SHA, validation evidence, PR URL, and changed paths.
+   - Do not dispatch a lane until its `depends_on` steps are satisfied.
+   - If the repo has no GitHub remote, branch push is unavailable, or PR creation/review cannot happen, stop before dispatch.
+9. Apply stop-all-lanes failure semantics:
+   - If any lane fails, halt remaining lanes.
+   - Preserve worktree state for inspection.
+   - Update `.agents/lane-specs.json` lifecycle to `failed`.
+   - Update `tasks/lane-specs.md` with the failed lane and reason.
+   - Report the blocker and stop before shipping.
+10. After all lanes complete:
+   - Run the consolidation/PR review step: inspect every lane PR, validate changed paths against `owns` and `must_not_edit`, classify findings as blocker or advisory, and approve only safe lanes.
+   - Stop before integration if any lane has blocker findings, missing PR evidence, or changed files outside its boundary.
+   - Integrate approved lane work in dependency order from the reviewed remote branches.
+   - Run `mono-guard --post-integration`.
+   - If post-integration guard fails, stop and report boundary violations.
+   - If it passes, set lane-spec lifecycle to `integrated` and update `tasks/lane-specs.md`.
+11. If `--pipeline` was used, continue to `mono-ship`; otherwise report next work and recommended command.
+
+## Validation Command Preference
+
+- With `turbo.json`: prefer `turbo run <task> --filter=<package>` for build, test, lint, and package validation.
+- Without `turbo.json`: prefer `pnpm --filter <package> run <task>`.
+- Use `.agents/monorepo.json.dependency_graph` to order package work when Turborepo is absent.
+
+## Output
+
+- **Detection:** monorepo detected or delegated to `/exec`.
+- **Execution mode:** serial delegation, guarded package lanes, or pipeline.
+- **Lane specs:** `.agents/lane-specs.json` and `tasks/lane-specs.md` status.
+- **Guard result:** pre-flight and post-integration verdicts.
+- **Dispatch result:** cross-cutting steps, package lanes, branch/commit/PR evidence, failures, and preserved worktrees when applicable.
+- **Consolidation/PR review:** reviewed PRs, blocker/advisory findings, approved branches, and integration order.
+- **Lifecycle:** draft, approved, dispatched, integrated, or failed.
+- **Next work:** concrete follow-up.
+- **Recommended next command:** one command.
+
+## Constraints
+
+- Do not run package manager install/add commands in package lanes.
+- Do not modify lockfiles from parallel lanes.
+- Do not dispatch package lanes unless `mono-guard` pre-flight passes and lane specs are approved.
+- Do not dispatch package lanes unless every write lane has a non-primary GitHub branch and PR review can be performed.
+- Do not continue after a lane failure; preserve worktree state and mark lifecycle `failed`.
+- Do not bypass standard `/exec` task selection, validation, history, commit/push, deploy, or next-step routing responsibilities.
+- Do not use GitHub Actions.
+
+## Next-Step Routing
+
+- Non-monorepo or serial phase: `/exec`.
+- Pre-flight guard failure: `/mono-guard` after fixing or regenerating lane specs.
+- Successful guarded run without pipeline: `/mono-ship`.
+- Failed lane dispatch: inspect preserved worktree state, then rerun `/mono-exec` after the blocker is fixed.
+- Completed pipeline: follow the next command reported by `mono-ship`.
+
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/monorepo/claude/mono-exec/archive/v0.0/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: mono-run
+description: Augment the standard run lifecycle with monorepo detection, lane-spec generation, guard validation, and package-scoped dispatch
+type: execution
+version: v0.0
+argument-hint: "[--phase] [--pipeline]"
+---
+
+# Mono Run
+
+Use this skill to run planned work in a pnpm workspace monorepo with package-aware guardrails. `mono-run` does not replace `/run`; it injects monorepo-aware pre/post steps around the standard `/run` contract.
+
+## Augmentation Injection Pattern
+
+`mono-run` adds these stages around normal run execution:
+
+1. **Pre-execution:** run `mono-detect`, generate lane specs when the phase is eligible for parallel monorepo dispatch, run `mono-guard` pre-flight, and present lane specs for plan-mode approval.
+2. **Dispatch:** run cross-cutting steps serially first in the main agent, then dispatch package-scoped worktree waves on separate GitHub branches only after lane specs are approved and guard validation passes.
+3. **Post-dispatch:** perform consolidation/PR review, run `mono-guard --post-integration`, update lane-spec lifecycle, then continue to `mono-ship` when shipping is requested.
+
+The global `/run` skill remains the source of truth for task selection, task docs, validation, history updates, commit/push, deploy handling, and next-step routing.
+
+## Flags
+
+- Default: execute the next incomplete step.
+- `--phase`: execute all steps in the current phase, using cross-cutting serial work first and package-scoped waves where eligible.
+- `--pipeline`: execute the monorepo run flow and continue into `mono-ship` after successful post-integration guard validation.
+
+## Workflow
+
+1. Run `mono-detect`.
+   - If the project is not a detected pnpm workspace monorepo, delegate directly to `/run`.
+   - If `turbo.json` is present, record that build/test/lint should defer to `turbo run`.
+   - If Turborepo is absent, record that build/test/lint should fall back to `pnpm --filter`.
+2. Read the current phase execution profile from `tasks/todo.md` and, when needed for phase context, `tasks/roadmap.md`.
+3. Decide execution mode:
+   - If the phase mode is `serial`, delegate directly to `/run`.
+   - If the phase mode is not monorepo-parallel eligible, delegate directly to `/run`.
+   - If the phase mode is `agent-team` or explicitly package-scoped parallel work, continue with lane-spec generation.
+4. Generate `.agents/lane-specs.json`.
+   - Include `phase`, `source_roadmap_hash`, `lifecycle`, `cross_cutting_steps`, and `lanes`.
+   - Each lane must include `id`, `step`, `packages`, `owns`, `must_not_edit`, `depends_on`, `mode`, and `branch`.
+   - Put root-only, shared-package, lockfile, and root-config work into `cross_cutting_steps` with serial mode.
+   - Put package-contained work into lanes with package-owned `owns` paths.
+   - Ensure every package lane's `must_not_edit` includes lockfiles, root config files, and other lanes' package paths.
+   - Ensure every package lane's `branch` is a deterministic non-primary GitHub branch such as `agent-team/phase-N-<lane-id>`.
+5. Generate `tasks/lane-specs.md` as the committed human-readable mirror of `.agents/lane-specs.json`.
+6. Run `mono-guard` pre-flight.
+   - Use `packs/monorepo/scripts/lane-spec-validate.sh` through `mono-guard`.
+   - Stop on `FAIL`.
+   - Present `WARN` findings for review before dispatch.
+7. Enter plan mode with lane specs for approval before launching package-scoped lanes.
+8. Dispatch work:
+   - Execute cross-cutting steps serially in the main agent first.
+   - Create worktree-isolated package lanes on their declared GitHub branches for parallel work after cross-cutting work is integrated.
+   - Give every lane its `branch`, `owns`, `must_not_edit`, `depends_on`, package scope, validation commands, and deliverable.
+   - Require every lane to commit to its branch, push it, open or update a draft PR, and return branch name, commit SHA, validation evidence, PR URL, and changed paths.
+   - Do not dispatch a lane until its `depends_on` steps are satisfied.
+   - If the repo has no GitHub remote, branch push is unavailable, or PR creation/review cannot happen, stop before dispatch.
+9. Apply stop-all-lanes failure semantics:
+   - If any lane fails, halt remaining lanes.
+   - Preserve worktree state for inspection.
+   - Update `.agents/lane-specs.json` lifecycle to `failed`.
+   - Update `tasks/lane-specs.md` with the failed lane and reason.
+   - Report the blocker and stop before shipping.
+10. After all lanes complete:
+   - Run the consolidation/PR review step: inspect every lane PR, validate changed paths against `owns` and `must_not_edit`, classify findings as blocker or advisory, and approve only safe lanes.
+   - Stop before integration if any lane has blocker findings, missing PR evidence, or changed files outside its boundary.
+   - Integrate approved lane work in dependency order from the reviewed remote branches.
+   - Run `mono-guard --post-integration`.
+   - If post-integration guard fails, stop and report boundary violations.
+   - If it passes, set lane-spec lifecycle to `integrated` and update `tasks/lane-specs.md`.
+11. If `--pipeline` was used, continue to `mono-ship`; otherwise report next work and recommended command.
+
+## Validation Command Preference
+
+- With `turbo.json`: prefer `turbo run <task> --filter=<package>` for build, test, lint, and package validation.
+- Without `turbo.json`: prefer `pnpm --filter <package> run <task>`.
+- Use `.agents/monorepo.json.dependency_graph` to order package work when Turborepo is absent.
+
+## Output Format
+
+- **Detection:** monorepo detected or delegated to `/run`.
+- **Execution mode:** serial delegation, guarded package lanes, or pipeline.
+- **Lane specs:** `.agents/lane-specs.json` and `tasks/lane-specs.md` status.
+- **Guard result:** pre-flight and post-integration verdicts.
+- **Dispatch result:** cross-cutting steps, package lanes, branch/commit/PR evidence, failures, and preserved worktrees when applicable.
+- **Consolidation/PR review:** reviewed PRs, blocker/advisory findings, approved branches, and integration order.
+- **Lifecycle:** draft, approved, dispatched, integrated, or failed.
+- **Next work:** concrete follow-up.
+- **Recommended next command:** one command.
+
+## Constraints
+
+- Do not run package manager install/add commands in package lanes.
+- Do not modify lockfiles from parallel lanes.
+- Do not dispatch package lanes unless `mono-guard` pre-flight passes and lane specs are approved.
+- Do not dispatch package lanes unless every write lane has a non-primary GitHub branch and PR review can be performed.
+- Do not continue after a lane failure; preserve worktree state and mark lifecycle `failed`.
+- Do not bypass standard `/run` task selection, validation, history, commit/push, deploy, or next-step routing responsibilities.
+- Do not use GitHub Actions.
+
+## Next-Step Routing
+
+- Non-monorepo or serial phase: `/run`.
+- Pre-flight guard failure: `/mono-guard` after fixing or regenerating lane specs.
+- Successful guarded run without pipeline: `/mono-ship`.
+- Failed lane dispatch: inspect preserved worktree state, then rerun `/mono-run` after the blocker is fixed.
+- Completed pipeline: follow the next command reported by `mono-ship`.
+
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/monorepo/claude/mono-guard/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-guard/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: mono-guard
+description: Validate monorepo lane specs before dispatch and verify integrated changes stay inside declared lane boundaries
+type: analysis
+version: v0.1
+argument-hint: "[--post-integration] [optional: lane-specs.json]"
+---
+
+# Mono Guard
+
+Use this skill to validate monorepo pack lane artifacts before parallel dispatch and to audit integrated lane changes after dispatch.
+
+This pack-local `mono-guard` consumes `.agents/lane-specs.json` and `.agents/monorepo.json`. It preserves behavioral compatibility with the global `/mono-guard` contract while using the monorepo pack's JSON artifacts and scripts as the project-local enforcement surface.
+
+## Augmentation Injection Pattern
+
+`mono-guard` is the pack's safety gate for the augmentation injection pattern. `mono-exec` injects it before package-scoped dispatch, and `mono-ship` relies on its post-integration boundary checks before delegating to `/ship`. The skill augments existing run/ship workflows with monorepo lane enforcement rather than replacing their task selection, validation, history, commit, push, or deploy responsibilities.
+
+## Modes
+
+- **Pre-flight (default):** Validate `.agents/lane-specs.json` before `mono-exec` dispatches package-scoped lanes.
+- **Post-integration (`--post-integration`):** Verify actual changed files from the integrated diff stay inside declared lane ownership and do not include unsafe shared files.
+
+## Inputs
+
+- `.agents/lane-specs.json`: generated lane plan with lifecycle, cross-cutting steps, lanes, `owns`, `must_not_edit`, `depends_on`, mode, and branch.
+- `.agents/monorepo.json`: workspace detection output from `mono-detect`, including packages and internal dependency graph.
+- `packs/monorepo/scripts/lane-spec-validate.sh`: schema and boundary validator for lane specs.
+
+If `.agents/monorepo.json` is missing or stale, run `mono-detect` first. If `.agents/lane-specs.json` is missing, stop and recommend generating lane specs through `mono-exec`.
+
+## Pre-Flight Workflow
+
+1. Resolve the lane-spec file:
+   - Use the path in `$ARGUMENTS` when provided.
+   - Otherwise use `.agents/lane-specs.json`.
+2. Run `packs/monorepo/scripts/lane-spec-validate.sh <lane-specs.json>`.
+   - This verifies required fields, lifecycle state, disjoint `owns`, required root `must_not_edit` entries, valid `depends_on` references, unique non-primary branches, and duplicate step protection.
+   - On failure, report `FAIL` and do not dispatch.
+3. Read `.agents/monorepo.json`.
+   - If missing, run or recommend `mono-detect`.
+   - Use its `packages` and `dependency_graph` to evaluate package-aware safety.
+4. Verify every lane's `owns` paths map to declared workspace package paths or clearly root-only serial work.
+5. Verify every lane's `must_not_edit` includes lockfiles and shared root config files:
+   - `pnpm-lock.yaml`
+   - `package.json`
+   - `pnpm-workspace.yaml`
+   - `turbo.json`
+6. Verify dependency ordering:
+   - If package X depends on package Y and both packages are owned by different lanes, the lane for X must depend on the lane for Y directly or transitively.
+   - Use `.agents/monorepo.json.dependency_graph` for dependency edges.
+7. Verify lane dependency graph validity:
+   - All `depends_on` references resolve to known cross-cutting step IDs or lane step IDs.
+   - No lane dependency cycle exists.
+8. Verify branch isolation:
+   - Every write lane has a unique non-primary GitHub branch.
+   - No lane branch is `main` or `master`.
+   - If PR review is required by the execution profile but branch/PR evidence is missing after dispatch, report `FAIL`.
+9. Scan lane descriptions, scopes, and modes when present for install/add intent.
+   - Fail non-serial package lanes that instruct `pnpm install`, `pnpm add`, `npm install`, `yarn add`, or equivalent lockfile-modifying commands.
+   - Warn on natural-language dependency changes such as "add dependency" or "install package".
+
+## Post-Integration Workflow
+
+1. Read `.agents/lane-specs.json` and `.agents/monorepo.json`.
+2. Inspect the integrated diff with `git diff --name-only` unless the user supplied a different reviewed diff range.
+3. For each changed file:
+   - Flag any lockfile modification from a parallel lane as `FAIL`.
+   - Flag root config changes as `WARN` unless they are declared in a serial cross-cutting step.
+   - Verify the path is inside at least one declared lane `owns` path or an allowed serial cross-cutting/root scope.
+   - Flag files outside declared ownership as boundary violations.
+4. Verify consolidation/PR review evidence when lane specs record branch-backed dispatch:
+   - Every integrated lane must have branch, commit SHA, and PR URL evidence recorded in `tasks/lane-specs.md` or the dispatch report.
+   - Missing PR review evidence is `FAIL` because package lanes must not bypass consolidation review.
+5. Report violations without reverting, fixing, or editing task files.
+
+## Output
+
+```markdown
+### Mono Guard Report
+
+**Mode:** pre-flight | post-integration
+**Lane spec:** .agents/lane-specs.json
+**Monorepo artifact:** .agents/monorepo.json
+**Verdict:** PASS | WARN | FAIL
+
+#### Results
+
+| Check | Verdict | Details |
+|---|---|---|
+| Lane-spec schema | PASS | lane-spec-validate.sh passed |
+| Owns disjointness | PASS | all lane owns paths are disjoint |
+| Shared file exclusions | PASS | lockfile and root config paths are in must_not_edit |
+| Branch isolation | PASS | each write lane has a unique non-primary GitHub branch |
+| Dependency ordering | PASS | package dependency lanes are ordered |
+| Integrated diff boundaries | WARN | one root config changed in serial integration |
+
+#### Failures
+
+- List blocking issues with lane IDs, step IDs, paths, and specific fixes.
+
+#### Warnings
+
+- List advisory issues with recommended follow-up.
+```
+
+## Verdicts
+
+- **PASS:** Safe to dispatch or ship.
+- **WARN:** Advisory issues found; review before proceeding.
+- **FAIL:** Dispatch or shipping is blocked until the lane specs or integrated changes are corrected.
+
+## Constraints
+
+- Do not edit task files.
+- Do not run package manager install/add commands.
+- Do not modify `.agents/lane-specs.json` or `.agents/monorepo.json` except by invoking the designated generation/detection skills when appropriate.
+- Do not revert or repair post-integration changes; report violations only.
+- Keep behavior compatible with the global `/mono-guard` safety contract.
+
+## Next-Step Routing
+
+- **PASS pre-flight:** `/mono-exec` to dispatch the validated lanes.
+- **WARN pre-flight:** Review warnings, then `/mono-exec` if accepted.
+- **FAIL pre-flight:** Fix or regenerate `.agents/lane-specs.json`, then rerun `/mono-guard`.
+- **PASS post-integration:** `/mono-ship` for package-scoped validation and shipping.
+- **WARN/FAIL post-integration:** Resolve boundary issues, then rerun `/mono-guard --post-integration`.
+
+## Default Shipping Contract
+
+Follow the shared shipping contract convention in CLAUDE.md.

package/packs/monorepo/claude/mono-guard/archive/v0.0/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: mono-guard
+description: Validate monorepo lane specs before dispatch and verify integrated changes stay inside declared lane boundaries
+type: analysis
+version: v0.0
+argument-hint: "[--post-integration] [optional: lane-specs.json]"
+---
+
+# Mono Guard
+
+Use this skill to validate monorepo pack lane artifacts before parallel dispatch and to audit integrated lane changes after dispatch.
+
+This pack-local `mono-guard` consumes `.agents/lane-specs.json` and `.agents/monorepo.json`. It preserves behavioral compatibility with the global `/mono-guard` contract while using the monorepo pack's JSON artifacts and scripts as the project-local enforcement surface.
+
+## Augmentation Injection Pattern
+
+`mono-guard` is the pack's safety gate for the augmentation injection pattern. `mono-run` injects it before package-scoped dispatch, and `mono-ship` relies on its post-integration boundary checks before delegating to `/ship`. The skill augments existing run/ship workflows with monorepo lane enforcement rather than replacing their task selection, validation, history, commit, push, or deploy responsibilities.
+
+## Modes
+
+- **Pre-flight (default):** Validate `.agents/lane-specs.json` before `mono-run` dispatches package-scoped lanes.
+- **Post-integration (`--post-integration`):** Verify actual changed files from the integrated diff stay inside declared lane ownership and do not include unsafe shared files.
+
+## Inputs
+
+- `.agents/lane-specs.json`: generated lane plan with lifecycle, cross-cutting steps, lanes, `owns`, `must_not_edit`, `depends_on`, mode, and branch.
+- `.agents/monorepo.json`: workspace detection output from `mono-detect`, including packages and internal dependency graph.
+- `packs/monorepo/scripts/lane-spec-validate.sh`: schema and boundary validator for lane specs.
+
+If `.agents/monorepo.json` is missing or stale, run `mono-detect` first. If `.agents/lane-specs.json` is missing, stop and recommend generating lane specs through `mono-run`.
+
+## Pre-Flight Workflow
+
+1. Resolve the lane-spec file:
+   - Use the path in `$ARGUMENTS` when provided.
+   - Otherwise use `.agents/lane-specs.json`.
+2. Run `packs/monorepo/scripts/lane-spec-validate.sh <lane-specs.json>`.
+   - This verifies required fields, lifecycle state, disjoint `owns`, required root `must_not_edit` entries, valid `depends_on` references, unique non-primary branches, and duplicate step protection.
+   - On failure, report `FAIL` and do not dispatch.
+3. Read `.agents/monorepo.json`.
+   - If missing, run or recommend `mono-detect`.
+   - Use its `packages` and `dependency_graph` to evaluate package-aware safety.
+4. Verify every lane's `owns` paths map to declared workspace package paths or clearly root-only serial work.
+5. Verify every lane's `must_not_edit` includes lockfiles and shared root config files:
+   - `pnpm-lock.yaml`
+   - `package.json`
+   - `pnpm-workspace.yaml`
+   - `turbo.json`
+6. Verify dependency ordering:
+   - If package X depends on package Y and both packages are owned by different lanes, the lane for X must depend on the lane for Y directly or transitively.
+   - Use `.agents/monorepo.json.dependency_graph` for dependency edges.
+7. Verify lane dependency graph validity:
+   - All `depends_on` references resolve to known cross-cutting step IDs or lane step IDs.
+   - No lane dependency cycle exists.
+8. Verify branch isolation:
+   - Every write lane has a unique non-primary GitHub branch.
+   - No lane branch is `main` or `master`.
+   - If PR review is required by the execution profile but branch/PR evidence is missing after dispatch, report `FAIL`.
+9. Scan lane descriptions, scopes, and modes when present for install/add intent.
+   - Fail non-serial package lanes that instruct `pnpm install`, `pnpm add`, `npm install`, `yarn add`, or equivalent lockfile-modifying commands.
+   - Warn on natural-language dependency changes such as "add dependency" or "install package".
+
+## Post-Integration Workflow
+
+1. Read `.agents/lane-specs.json` and `.agents/monorepo.json`.
+2. Inspect the integrated diff with `git diff --name-only` unless the user supplied a different reviewed diff range.
+3. For each changed file:
+   - Flag any lockfile modification from a parallel lane as `FAIL`.
+   - Flag root config changes as `WARN` unless they are declared in a serial cross-cutting step.
+   - Verify the path is inside at least one declared lane `owns` path or an allowed serial cross-cutting/root scope.
+   - Flag files outside declared ownership as boundary violations.
+4. Verify consolidation/PR review evidence when lane specs record branch-backed dispatch:
+   - Every integrated lane must have branch, commit SHA, and PR URL evidence recorded in `tasks/lane-specs.md` or the dispatch report.
+   - Missing PR review evidence is `FAIL` because package lanes must not bypass consolidation review.
+5. Report violations without reverting, fixing, or editing task files.
+
+## Output Format
+
+```markdown
+### Mono Guard Report
+
+**Mode:** pre-flight | post-integration
+**Lane spec:** .agents/lane-specs.json
+**Monorepo artifact:** .agents/monorepo.json
+**Verdict:** PASS | WARN | FAIL
+
+#### Results
+
+| Check | Verdict | Details |
+|---|---|---|
+| Lane-spec schema | PASS | lane-spec-validate.sh passed |
+| Owns disjointness | PASS | all lane owns paths are disjoint |
+| Shared file exclusions | PASS | lockfile and root config paths are in must_not_edit |
+| Branch isolation | PASS | each write lane has a unique non-primary GitHub branch |
+| Dependency ordering | PASS | package dependency lanes are ordered |
+| Integrated diff boundaries | WARN | one root config changed in serial integration |
+
+#### Failures
+
+- List blocking issues with lane IDs, step IDs, paths, and specific fixes.
+
+#### Warnings
+
+- List advisory issues with recommended follow-up.
+```
+
+## Verdicts
+
+- **PASS:** Safe to dispatch or ship.
+- **WARN:** Advisory issues found; review before proceeding.
+- **FAIL:** Dispatch or shipping is blocked until the lane specs or integrated changes are corrected.
+
+## Constraints
+
+- Do not edit task files.
+- Do not run package manager install/add commands.
+- Do not modify `.agents/lane-specs.json` or `.agents/monorepo.json` except by invoking the designated generation/detection skills when appropriate.
+- Do not revert or repair post-integration changes; report violations only.
+- Keep behavior compatible with the global `/mono-guard` safety contract.
+
+## Next-Step Routing
+
+- **PASS pre-flight:** `/mono-run` to dispatch the validated lanes.
+- **WARN pre-flight:** Review warnings, then `/mono-run` if accepted.
+- **FAIL pre-flight:** Fix or regenerate `.agents/lane-specs.json`, then rerun `/mono-guard`.
+- **PASS post-integration:** `/mono-ship` for package-scoped validation and shipping.
+- **WARN/FAIL post-integration:** Resolve boundary issues, then rerun `/mono-guard --post-integration`.
+
+## 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/mono-guard-{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/mono-guard-{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 the two-line pair `**Next work:** <specific task, blocker, or follow-up>` 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.