skillpacks 0.1.0

package/global/claude/autoresearch-prep/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: autoresearch-prep
+description: Scaffold a program.md for /autoresearch by auto-detecting codebase signals and interviewing for what can't be inferred
+type: planning
+version: v0.0
+invocation: chained
+argument-hint: "[output-path]"
+interview_depth: light
+---
+
+# Autoresearch Prep
+
+Scaffolds a `program.md` research program for `/autoresearch`. Auto-detects benchmark commands, test commands, sandbox boundaries, and exclude patterns from the codebase, then asks the user only what it can't infer: metric command and direction, research directions, and budget.
+
+## When to Use
+
+When the user wants to start an `/autoresearch` loop but doesn't have a `program.md` yet.
+
+## Preconditions
+
+- A git repository with code to optimize
+- The user has a measurable property in mind (benchmark, bundle size, test coverage, etc.)
+
+## Process
+
+### 0. Resolve Output Path
+
+1. If `$ARGUMENTS` is provided and non-empty, use it as the output path.
+2. Otherwise default to `./program.md`.
+3. If the file already exists, warn the user and ask whether to overwrite or pick a new path.
+
+### 1. Auto-Detect Codebase Signals
+
+Scan the repository for:
+
+**Benchmark commands:**
+- `package.json` scripts containing `bench` or `benchmark`
+- `bench/`, `benchmarks/`, or `perf/` directories
+- `Makefile` targets: `bench`, `benchmark`, `perf`
+- Language-specific: `cargo bench`, `go test -bench`, `pytest-benchmark`, `hyperfine` usage
+
+**Test commands:**
+- `package.json` `test` script
+- `Makefile` `test` target
+- Language-specific: `pytest`, `cargo test`, `go test`, `jest`, `vitest`, `mocha`
+
+**Sandbox globs** (based on what directories exist):
+- `src/**`, `lib/**`, `app/**`, `pkg/**`, `internal/**`, `crates/**`
+- Include only directories that actually exist in the repo
+
+**Exclude patterns:**
+- Test files: `**/*.test.*`, `**/*.spec.*`, `**/test/**`, `**/tests/**`, `**/__tests__/**`
+- Config: `*.config.*`, `.eslintrc*`, `tsconfig*`, `.prettierrc*`
+- Benchmark harness: `bench/**`, `benchmarks/**`, `perf/**`
+- Build output: `dist/**`, `build/**`, `target/**`, `out/**`, `.next/**`
+- Lock files: `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`, `Cargo.lock`, `go.sum`
+- VCS/tooling: `.git/**`, `node_modules/**`, `.autoresearch/**`
+
+### 2. Light Interview
+
+Present the detected signals as a summary, then ask:
+
+1. **Metric command + direction** (always required): "What shell command prints your target metric as a single number? Is higher or lower better?"
+2. **Research directions** (always required): "What optimization directions should the agent explore? List 2-5 ideas."
+3. **Budget** (offer default): "How many iterations? (default: 20)"
+
+If benchmark commands were detected, suggest them as starting points for the metric command.
+If test commands were detected, note they'll be included as the test command with `required: true`.
+
+### 3. Findings Validation
+
+Show the complete proposed `program.md` content to the user. Let them confirm or adjust any section before writing.
+
+### 4. Validate Metric Command
+
+1. Run the metric command once from the project root.
+2. Parse the last number from stdout.
+3. If the command fails or produces no parseable number, stop and ask the user to fix it.
+4. Record the parsed value as the baseline for the Context section.
+
+### 5. Write program.md
+
+Write the file in the exact format expected by `/autoresearch`:
+
+```markdown
+# Research Program
+
+## Metric
+command: <user-provided command>
+direction: <higher-is-better | lower-is-better>
+
+## Budget
+max_iterations: <user-provided or 20>
+
+## Sandbox
+files:
+  - <detected or user-adjusted globs>
+exclude:
+  - <detected or user-adjusted patterns>
+
+## Test Command
+command: <detected test command>
+required: true
+
+## Research Directions
+1. <direction one>
+2. <direction two>
+...
+
+## Context
+Baseline metric value: <measured value>
+<any additional context from interview>
+```
+
+Omit the `Test Command` section if no test command was detected or provided.
+
+### 6. Route
+
+**Recommended next command:** `/autoresearch <output-path>`
+
+## Constraints
+
+- Do not run the autoresearch loop — only scaffold `program.md`.
+- Do not modify any source files in the repository.
+- Do not create the `.autoresearch/` directory.
+- Do not create alignment pages.
+- Do not follow the shared shipping contract — this skill writes one local file, not tracked repo changes.

package/global/claude/codebase-status/CHANGELOG.md

@@ -0,0 +1,25 @@
+# Changelog
+
+## v0.5 - 2026-06-06
+
+- Updated the canonical AFPS route string to start with `customer-discovery` while preserving `research/icp.md` as the evidence artifact check.
+
+## v0.4 - 2026-06-06
+
+- Updated canonical AFPS status routing to insert `/user-flow-map` after positioning and requirements-only UI interview before layout-mode UX variations.
+
+## v0.3 - 2026-06-04
+
+- Added explicit `business-discovery` pack-install fallback wording at optional `value-prop-canvas` and `lean-canvas` recommendation sites so the routing audit can verify cross-pack guards.
+
+## v0.2 - 2026-05-29
+
+- Added canonical AFPS routing evidence requirements, last completed skill next-step contract checks, pack availability guards, and phase-aware exec/ship/brainstorm routing boundaries.
+
+## 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/global/claude/codebase-status/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: codebase-status
+description: Report what a repository is, what recent conversation history says about it, current application status, and outstanding work
+type: analysis
+version: v0.5
+argument-hint: "[optional repo path, focus, or --no-history]"
+---
+
+# Codebase Status
+
+Invoke as `/codebase-status`.
+
+Use this skill when the user asks what a repo or application is, where work was left, what is outstanding, whether it is ready/stable, or wants a detailed status report that combines codebase evidence with local Claude/Codex conversation history.
+
+This is read-only status synthesis. It does not replace `/roadmap`: `roadmap` maintains the task pipeline and priority queue; `codebase-status` explains the actual current state of the repo and relevant prior conversations.
+
+## Process
+
+1. Resolve target repo:
+   - Default to the current working directory.
+   - If the user provides a path, use that repo.
+   - Confirm it is a git worktree when possible; if not, continue with filesystem evidence and report that git evidence is unavailable.
+2. Read project orientation:
+   - `README.md`, `AGENTS.md`, `CLAUDE.md`, `.agents/project.json`, package/workspace files, app entrypoints, and high-signal docs.
+   - Identify project type, main apps/packages, runtime, tests, and likely user-facing or developer-facing purpose.
+3. Read planning and status docs when present:
+   - `tasks/roadmap.md`, `tasks/todo.md`, `tasks/manual-todo.md`, `tasks/record-todo.md`, `tasks/recurring-todo.md`, `tasks/history.md`, `tasks/lessons.md`, `tasks/phases/`, `specs/`, `spec.md`, and `research/`.
+   - Distinguish checked-off work, active work, manual blockers, advisory work, stale docs, and missing docs.
+4. Read routing evidence for product, research, or spec repos:
+   - When `research/`, `specs/`, `spec.md`, product docs, or prototype artifacts exist, read `docs/pack-workflow-matrix.md` and `docs/skill-next-step-contracts.md` if present.
+   - Identify the last completed relevant research/product skill from artifacts, task history, or conversation history. Before recommending another research/product skill, consult that skill's active `SKILL.md` `## Next Steps` contract and any `## Next Steps` section in its output artifact.
+   - Treat those route contracts as stronger evidence than a generic status impression. If docs disagree, report the contradiction and prefer the newest active skill contract or route matrix with file evidence.
+   - For pack-local recommendations, check `.agents/project.json` `enabled_packs` first. If the target skill's pack is not enabled, recommend `/pack install <pack-name>` before the skill.
+5. Inspect git evidence:
+   - `git status --short`
+   - current branch and upstream status
+   - last 20 commits
+   - unpushed commits when an upstream exists
+   - changed files in the working tree
+6. Inspect codebase health signals:
+   - Project structure and primary modules.
+   - Test/build/lint scripts from package manifests or equivalent tool files.
+   - Obvious TODO/FIXME markers, failing-test notes, disabled tests, and local quality scripts.
+   - Do not run expensive commands by default. Run cheap read-only inspections freely; ask or state assumptions before long builds, network installs, destructive commands, or mutation.
+7. Find related conversation history unless `--no-history` is passed:
+   - Read full available local prompt history, not a sample:
+     - `~/.claude/history.jsonl`
+     - `~/.codex/history.jsonl`
+     - `~/.codex/sessions/**/*.jsonl` for Codex session metadata only when needed to map session IDs to cwd.
+   - Filter to records whose project/cwd matches the target repo or whose text mentions the absolute path, repo directory name, package/app name, or repository URL.
+   - Exclude system, developer, tool output, injected skill payloads, and base instruction text from examples.
+   - Use line-by-line parsing for scale and deduplicate Codex prompt records when compact and rich histories overlap.
+   - Extract recent user goals, repeated requests, unresolved questions, blockers, and prior recommendations.
+8. Synthesize status:
+   - What this repo/app is.
+   - What has happened recently.
+   - Current implementation status by major area.
+   - Outstanding work, grouped as blocking, next execution, advisory, manual/human-only, and uncertain.
+   - Mismatches between conversation history, task docs, git history, and code reality.
+   - Confidence level for each major conclusion: high, medium, or low, with evidence.
+9. Recommend next route (check whether each skill's pack is installed; if not, recommend `/pack install <pack>` first):
+   - Use phase-aware routing before naming a command:
+     - If `tasks/todo.md` or active phase docs contain actionable implementation work, recommend `/exec`. Do not route back to research merely because advisory gaps exist.
+     - If finished work is dirty, unpushed, unvalidated, or needs packaging/review before handoff, recommend `/ship`.
+     - If user-facing product research/prototype artifacts are missing and no implementation/shipping queue is active, follow the canonical AFPS route from the routing evidence: `customer-discovery -> competitive-analysis -> journey-map -> positioning -> user-flow-map -> ui-interview --requirements-only -> ux-variations --layout-mode -> prototype -> uat --variant-evaluation -> consolidate-variations -> research-roadmap --post-prototype -> spec-interview -> research-roadmap --post-spec -> roadmap`.
+     - If `research/icp.md` and `research/competitive-analysis.md` exist but `research/journey-map.md` is missing, check `customer-lifecycle` availability. If it is not enabled, recommend `/pack install customer-lifecycle` before `/journey-map`; if enabled, recommend `/journey-map`.
+     - Treat `value-prop-canvas` and `lean-canvas` as optional risk-driven detours only. Before recommending either, check `business-discovery` availability; if it is not enabled, recommend `/pack install business-discovery` before `/value-prop-canvas` or `/lean-canvas`. Recommend `/value-prop-canvas` only for contested solution-fit evidence, and `/lean-canvas` only for material business-model risk; do not make either a default blocker before `journey-map`, `positioning`, `user-flow-map`, or layout-mode UX variations.
+     - If no research, spec, task, implementation, validation, dirty, or unpushed work remains, recommend `/brainstorm` to discover new AFPS work.
+   - `/exec` when the next task is already clear and executable. _(exec-loop pack)_
+   - `/roadmap` when specs exist but sequencing or task queue health needs updating. _(agent-work-admin pack)_
+   - `/feature-interview` when the next idea/direction is not yet represented in specs or tasks. _(product-design pack)_
+   - `/reconcile-dev-docs audit` or `/reconcile-dev-docs fix tasks` when task docs contradict git/code reality. _(docs-health pack)_
+   - `/spec-drift` when specs and code appear out of sync. _(agent-work-admin pack)_
+   - `/guide` only for human-only external blockers. _(guided-walkthrough pack)_
+   - `/brainstorm` when the repo is complete/current and the next step is discovering a new phase. _(product-design pack)_
+
+## Output
+
+Produce a structured report with:
+
+- **Overview:** repo path, project purpose, project type, primary apps/packages, branch, dirty/unpushed status.
+- **History Signal:** number of Claude/Codex prompt records scanned, number matched to this repo, date range, and 3-8 concise real examples.
+- **Recent Work:** last commits and task/history evidence.
+- **Current Status:** major areas and whether each appears complete, in progress, blocked, stale, or unknown.
+- **Outstanding Work:** prioritized list with evidence and recommended owner/skill.
+- **Risks And Drift:** contradictions, stale docs, missing tests, manual blockers, or uncertain claims.
+- **Recommended Next Step:** one concrete next work item and one command.
+
+End with exactly:
+
+```md
+**Next work:** <specific task, blocker, discovery task, or "none">
+**Recommended next command:** <one command or route>
+```
+
+## Constraints
+
+- Read-only by default. Do not modify files, create commits, run installs, or execute long test suites unless the user explicitly asks.
+- Do not include private conversation history unrelated to the target repo.
+- Quote only short prompt excerpts. Prefer paraphrase plus timestamp/source/project.
+- Do not treat `tasks/record-todo.md` or `tasks/recurring-todo.md` as execution queues unless an item has clearly become concrete work.
+- Do not put agent-executable work in `tasks/manual-todo.md` or route it to `/guide`.
+- Do not recommend `/roadmap` if the finding is only "tell me the status"; use `/roadmap` only when the task pipeline itself needs queue maintenance or roadmap extension.
+- When recommending a pack skill, first check `.agents/project.json` for `enabled_packs`. If the target skill's pack is not enabled, include `/pack install <pack-name>` as a prerequisite in the recommendation.
+- Do not create or modify GitHub Actions workflows.
+
+## 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 caller has a concrete handoff.
+- Normally read-only and should not create or modify tracked repository files.
+- If the user explicitly asks this skill to create or modify tracked files, finish by committing and pushing all intended changes to the repository primary branch (`main` when present, otherwise `master`) before stopping.
+- This contract does not override stricter safety rules about secrets, destructive history changes, release publication/tag confirmation, production deploy confirmation, paid actions, or public visibility changes.

package/global/claude/codebase-status/archive/v0.0/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: codebase-status
+description: Report what a repository is, what recent conversation history says about it, current application status, and outstanding work
+type: analysis
+version: v0.0
+argument-hint: "[optional repo path, focus, or --no-history]"
+---
+
+# Codebase Status
+
+Invoke as `/codebase-status`.
+
+Use this skill when the user asks what a repo or application is, where work was left, what is outstanding, whether it is ready/stable, or wants a detailed status report that combines codebase evidence with local Claude/Codex conversation history.
+
+This is read-only status synthesis. It does not replace `/roadmap`: `roadmap` maintains the task pipeline and priority queue; `codebase-status` explains the actual current state of the repo and relevant prior conversations.
+
+## Workflow
+
+1. Resolve target repo:
+   - Default to the current working directory.
+   - If the user provides a path, use that repo.
+   - Confirm it is a git worktree when possible; if not, continue with filesystem evidence and report that git evidence is unavailable.
+2. Read project orientation:
+   - `README.md`, `AGENTS.md`, `CLAUDE.md`, `.agents/project.json`, package/workspace files, app entrypoints, and high-signal docs.
+   - Identify project type, main apps/packages, runtime, tests, and likely user-facing or developer-facing purpose.
+3. Read planning and status docs when present:
+   - `tasks/roadmap.md`, `tasks/todo.md`, `tasks/manual-todo.md`, `tasks/record-todo.md`, `tasks/recurring-todo.md`, `tasks/history.md`, `tasks/lessons.md`, `tasks/phases/`, `specs/`, `spec.md`, and `research/`.
+   - Distinguish checked-off work, active work, manual blockers, advisory work, stale docs, and missing docs.
+4. Inspect git evidence:
+   - `git status --short`
+   - current branch and upstream status
+   - last 20 commits
+   - unpushed commits when an upstream exists
+   - changed files in the working tree
+5. Inspect codebase health signals:
+   - Project structure and primary modules.
+   - Test/build/lint scripts from package manifests or equivalent tool files.
+   - Obvious TODO/FIXME markers, failing-test notes, disabled tests, and local quality scripts.
+   - Do not run expensive commands by default. Run cheap read-only inspections freely; ask or state assumptions before long builds, network installs, destructive commands, or mutation.
+6. Find related conversation history unless `--no-history` is passed:
+   - Read full available local prompt history, not a sample:
+     - `~/.claude/history.jsonl`
+     - `~/.codex/history.jsonl`
+     - `~/.codex/sessions/**/*.jsonl` for Codex session metadata only when needed to map session IDs to cwd.
+   - Filter to records whose project/cwd matches the target repo or whose text mentions the absolute path, repo directory name, package/app name, or repository URL.
+   - Exclude system, developer, tool output, injected skill payloads, and base instruction text from examples.
+   - Use line-by-line parsing for scale and deduplicate Codex prompt records when compact and rich histories overlap.
+   - Extract recent user goals, repeated requests, unresolved questions, blockers, and prior recommendations.
+7. Synthesize status:
+   - What this repo/app is.
+   - What has happened recently.
+   - Current implementation status by major area.
+   - Outstanding work, grouped as blocking, next execution, advisory, manual/human-only, and uncertain.
+   - Mismatches between conversation history, task docs, git history, and code reality.
+   - Confidence level for each major conclusion: high, medium, or low, with evidence.
+8. Recommend next route:
+   - `/run` when the next task is already clear and executable.
+   - `/roadmap` when specs exist but sequencing or task queue health needs updating.
+   - `/feature-interview` when the next idea/direction is not yet represented in specs or tasks.
+   - `/reconcile-dev-docs audit` or `/reconcile-dev-docs fix tasks` when task docs contradict git/code reality.
+   - `/spec-drift` when specs and code appear out of sync.
+   - `/guide` only for human-only external blockers.
+   - `/brainstorm` when the repo is complete/current and the next step is discovering a new phase.
+
+## Output
+
+Produce a structured report with:
+
+- **Overview:** repo path, project purpose, project type, primary apps/packages, branch, dirty/unpushed status.
+- **History Signal:** number of Claude/Codex prompt records scanned, number matched to this repo, date range, and 3-8 concise real examples.
+- **Recent Work:** last commits and task/history evidence.
+- **Current Status:** major areas and whether each appears complete, in progress, blocked, stale, or unknown.
+- **Outstanding Work:** prioritized list with evidence and recommended owner/skill.
+- **Risks And Drift:** contradictions, stale docs, missing tests, manual blockers, or uncertain claims.
+- **Recommended Next Step:** one concrete next work item and one command.
+
+End with exactly:
+
+```md
+**Next work:** <specific task, blocker, discovery task, or "none">
+**Recommended next command:** <one command or route>
+```
+
+## Constraints
+
+- Read-only by default. Do not modify files, create commits, run installs, or execute long test suites unless the user explicitly asks.
+- Do not include private conversation history unrelated to the target repo.
+- Quote only short prompt excerpts. Prefer paraphrase plus timestamp/source/project.
+- Do not treat `tasks/record-todo.md` or `tasks/recurring-todo.md` as execution queues unless an item has clearly become concrete work.
+- Do not put agent-executable work in `tasks/manual-todo.md` or route it to `/guide`.
+- Do not recommend `/roadmap` if the finding is only "tell me the status"; use `/roadmap` only when the task pipeline itself needs queue maintenance or roadmap extension.
+- Do not create or modify GitHub Actions workflows.
+
+## 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/codebase-status-{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/codebase-status-{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.
+- This skill is normally read-only and should not create or modify tracked repository files.
+- If the user explicitly asks this skill to create or modify tracked files, finish by committing and pushing all intended changes to the repository primary branch (`main` when present, otherwise `master`) before stopping.
+- This contract does not override stricter safety rules about secrets, destructive history changes, release publication/tag confirmation, production deploy confirmation, paid actions, or public visibility changes.

package/global/claude/codebase-status/archive/v0.1/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: codebase-status
+description: Report what a repository is, what recent conversation history says about it, current application status, and outstanding work
+type: analysis
+version: v0.1
+argument-hint: "[optional repo path, focus, or --no-history]"
+---
+
+# Codebase Status
+
+Invoke as `/codebase-status`.
+
+Use this skill when the user asks what a repo or application is, where work was left, what is outstanding, whether it is ready/stable, or wants a detailed status report that combines codebase evidence with local Claude/Codex conversation history.
+
+This is read-only status synthesis. It does not replace `/roadmap`: `roadmap` maintains the task pipeline and priority queue; `codebase-status` explains the actual current state of the repo and relevant prior conversations.
+
+## Workflow
+
+1. Resolve target repo:
+   - Default to the current working directory.
+   - If the user provides a path, use that repo.
+   - Confirm it is a git worktree when possible; if not, continue with filesystem evidence and report that git evidence is unavailable.
+2. Read project orientation:
+   - `README.md`, `AGENTS.md`, `CLAUDE.md`, `.agents/project.json`, package/workspace files, app entrypoints, and high-signal docs.
+   - Identify project type, main apps/packages, runtime, tests, and likely user-facing or developer-facing purpose.
+3. Read planning and status docs when present:
+   - `tasks/roadmap.md`, `tasks/todo.md`, `tasks/manual-todo.md`, `tasks/record-todo.md`, `tasks/recurring-todo.md`, `tasks/history.md`, `tasks/lessons.md`, `tasks/phases/`, `specs/`, `spec.md`, and `research/`.
+   - Distinguish checked-off work, active work, manual blockers, advisory work, stale docs, and missing docs.
+4. Inspect git evidence:
+   - `git status --short`
+   - current branch and upstream status
+   - last 20 commits
+   - unpushed commits when an upstream exists
+   - changed files in the working tree
+5. Inspect codebase health signals:
+   - Project structure and primary modules.
+   - Test/build/lint scripts from package manifests or equivalent tool files.
+   - Obvious TODO/FIXME markers, failing-test notes, disabled tests, and local quality scripts.
+   - Do not run expensive commands by default. Run cheap read-only inspections freely; ask or state assumptions before long builds, network installs, destructive commands, or mutation.
+6. Find related conversation history unless `--no-history` is passed:
+   - Read full available local prompt history, not a sample:
+     - `~/.claude/history.jsonl`
+     - `~/.codex/history.jsonl`
+     - `~/.codex/sessions/**/*.jsonl` for Codex session metadata only when needed to map session IDs to cwd.
+   - Filter to records whose project/cwd matches the target repo or whose text mentions the absolute path, repo directory name, package/app name, or repository URL.
+   - Exclude system, developer, tool output, injected skill payloads, and base instruction text from examples.
+   - Use line-by-line parsing for scale and deduplicate Codex prompt records when compact and rich histories overlap.
+   - Extract recent user goals, repeated requests, unresolved questions, blockers, and prior recommendations.
+7. Synthesize status:
+   - What this repo/app is.
+   - What has happened recently.
+   - Current implementation status by major area.
+   - Outstanding work, grouped as blocking, next execution, advisory, manual/human-only, and uncertain.
+   - Mismatches between conversation history, task docs, git history, and code reality.
+   - Confidence level for each major conclusion: high, medium, or low, with evidence.
+8. Recommend next route (check whether each skill's pack is installed; if not, recommend `/pack install <pack>` first):
+   - `/exec` when the next task is already clear and executable. _(exec-loop pack)_
+   - `/roadmap` when specs exist but sequencing or task queue health needs updating. _(agent-work-admin pack)_
+   - `/feature-interview` when the next idea/direction is not yet represented in specs or tasks. _(product-design pack)_
+   - `/reconcile-dev-docs audit` or `/reconcile-dev-docs fix tasks` when task docs contradict git/code reality. _(docs-health pack)_
+   - `/spec-drift` when specs and code appear out of sync. _(agent-work-admin pack)_
+   - `/guide` only for human-only external blockers. _(guided-walkthrough pack)_
+   - `/brainstorm` when the repo is complete/current and the next step is discovering a new phase. _(product-design pack)_
+
+## Output
+
+Produce a structured report with:
+
+- **Overview:** repo path, project purpose, project type, primary apps/packages, branch, dirty/unpushed status.
+- **History Signal:** number of Claude/Codex prompt records scanned, number matched to this repo, date range, and 3-8 concise real examples.
+- **Recent Work:** last commits and task/history evidence.
+- **Current Status:** major areas and whether each appears complete, in progress, blocked, stale, or unknown.
+- **Outstanding Work:** prioritized list with evidence and recommended owner/skill.
+- **Risks And Drift:** contradictions, stale docs, missing tests, manual blockers, or uncertain claims.
+- **Recommended Next Step:** one concrete next work item and one command.
+
+End with exactly:
+
+```md
+**Next work:** <specific task, blocker, discovery task, or "none">
+**Recommended next command:** <one command or route>
+```
+
+## Constraints
+
+- Read-only by default. Do not modify files, create commits, run installs, or execute long test suites unless the user explicitly asks.
+- Do not include private conversation history unrelated to the target repo.
+- Quote only short prompt excerpts. Prefer paraphrase plus timestamp/source/project.
+- Do not treat `tasks/record-todo.md` or `tasks/recurring-todo.md` as execution queues unless an item has clearly become concrete work.
+- Do not put agent-executable work in `tasks/manual-todo.md` or route it to `/guide`.
+- Do not recommend `/roadmap` if the finding is only "tell me the status"; use `/roadmap` only when the task pipeline itself needs queue maintenance or roadmap extension.
+- When recommending a pack skill, first check `.agents/project.json` for `enabled_packs`. If the target skill's pack is not enabled, include `/pack install <pack-name>` as a prerequisite in the recommendation.
+- Do not create or modify GitHub Actions workflows.
+
+## 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/codebase-status-{topic}.html`.
+
+## 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.
+- This skill is normally read-only and should not create or modify tracked repository files.
+- If the user explicitly asks this skill to create or modify tracked files, finish by committing and pushing all intended changes to the repository primary branch (`main` when present, otherwise `master`) before stopping.
+- This contract does not override stricter safety rules about secrets, destructive history changes, release publication/tag confirmation, production deploy confirmation, paid actions, or public visibility changes.

package/global/claude/codebase-status/archive/v0.2/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: codebase-status
+description: Report what a repository is, what recent conversation history says about it, current application status, and outstanding work
+type: analysis
+version: v0.2
+argument-hint: "[optional repo path, focus, or --no-history]"
+---
+
+# Codebase Status
+
+Invoke as `/codebase-status`.
+
+Use this skill when the user asks what a repo or application is, where work was left, what is outstanding, whether it is ready/stable, or wants a detailed status report that combines codebase evidence with local Claude/Codex conversation history.
+
+This is read-only status synthesis. It does not replace `/roadmap`: `roadmap` maintains the task pipeline and priority queue; `codebase-status` explains the actual current state of the repo and relevant prior conversations.
+
+## Process
+
+1. Resolve target repo:
+   - Default to the current working directory.
+   - If the user provides a path, use that repo.
+   - Confirm it is a git worktree when possible; if not, continue with filesystem evidence and report that git evidence is unavailable.
+2. Read project orientation:
+   - `README.md`, `AGENTS.md`, `CLAUDE.md`, `.agents/project.json`, package/workspace files, app entrypoints, and high-signal docs.
+   - Identify project type, main apps/packages, runtime, tests, and likely user-facing or developer-facing purpose.
+3. Read planning and status docs when present:
+   - `tasks/roadmap.md`, `tasks/todo.md`, `tasks/manual-todo.md`, `tasks/record-todo.md`, `tasks/recurring-todo.md`, `tasks/history.md`, `tasks/lessons.md`, `tasks/phases/`, `specs/`, `spec.md`, and `research/`.
+   - Distinguish checked-off work, active work, manual blockers, advisory work, stale docs, and missing docs.
+4. Read routing evidence for product, research, or spec repos:
+   - When `research/`, `specs/`, `spec.md`, product docs, or prototype artifacts exist, read `docs/pack-workflow-matrix.md` and `docs/skill-next-step-contracts.md` if present.
+   - Identify the last completed relevant research/product skill from artifacts, task history, or conversation history. Before recommending another research/product skill, consult that skill's active `SKILL.md` `## Next Steps` contract and any `## Next Steps` section in its output artifact.
+   - Treat those route contracts as stronger evidence than a generic status impression. If docs disagree, report the contradiction and prefer the newest active skill contract or route matrix with file evidence.
+   - For pack-local recommendations, check `.agents/project.json` `enabled_packs` first. If the target skill's pack is not enabled, recommend `/pack install <pack-name>` before the skill.
+5. Inspect git evidence:
+   - `git status --short`
+   - current branch and upstream status
+   - last 20 commits
+   - unpushed commits when an upstream exists
+   - changed files in the working tree
+6. Inspect codebase health signals:
+   - Project structure and primary modules.
+   - Test/build/lint scripts from package manifests or equivalent tool files.
+   - Obvious TODO/FIXME markers, failing-test notes, disabled tests, and local quality scripts.
+   - Do not run expensive commands by default. Run cheap read-only inspections freely; ask or state assumptions before long builds, network installs, destructive commands, or mutation.
+7. Find related conversation history unless `--no-history` is passed:
+   - Read full available local prompt history, not a sample:
+     - `~/.claude/history.jsonl`
+     - `~/.codex/history.jsonl`
+     - `~/.codex/sessions/**/*.jsonl` for Codex session metadata only when needed to map session IDs to cwd.
+   - Filter to records whose project/cwd matches the target repo or whose text mentions the absolute path, repo directory name, package/app name, or repository URL.
+   - Exclude system, developer, tool output, injected skill payloads, and base instruction text from examples.
+   - Use line-by-line parsing for scale and deduplicate Codex prompt records when compact and rich histories overlap.
+   - Extract recent user goals, repeated requests, unresolved questions, blockers, and prior recommendations.
+8. Synthesize status:
+   - What this repo/app is.
+   - What has happened recently.
+   - Current implementation status by major area.
+   - Outstanding work, grouped as blocking, next execution, advisory, manual/human-only, and uncertain.
+   - Mismatches between conversation history, task docs, git history, and code reality.
+   - Confidence level for each major conclusion: high, medium, or low, with evidence.
+9. Recommend next route (check whether each skill's pack is installed; if not, recommend `/pack install <pack>` first):
+   - Use phase-aware routing before naming a command:
+     - If `tasks/todo.md` or active phase docs contain actionable implementation work, recommend `/exec`. Do not route back to research merely because advisory gaps exist.
+     - If finished work is dirty, unpushed, unvalidated, or needs packaging/review before handoff, recommend `/ship`.
+     - If user-facing product research/prototype artifacts are missing and no implementation/shipping queue is active, follow the canonical AFPS route from the routing evidence: `icp -> competitive-analysis -> journey-map -> positioning -> ux-variations -> ui-interview -> prototype -> uat -> consolidate-variations -> research-roadmap -> spec-interview -> roadmap`.
+     - If `research/icp.md` and `research/competitive-analysis.md` exist but `research/journey-map.md` is missing, check `customer-lifecycle` availability. If it is not enabled, recommend `/pack install customer-lifecycle` before `/journey-map`; if enabled, recommend `/journey-map`.
+     - Treat `value-prop-canvas` and `lean-canvas` as optional risk-driven detours only. Recommend `/value-prop-canvas` only for contested solution-fit evidence, and `/lean-canvas` only for material business-model risk; do not make either a default blocker before `journey-map`, `positioning`, or `ux-variations`.
+     - If no research, spec, task, implementation, validation, dirty, or unpushed work remains, recommend `/brainstorm` to discover new AFPS work.
+   - `/exec` when the next task is already clear and executable. _(exec-loop pack)_
+   - `/roadmap` when specs exist but sequencing or task queue health needs updating. _(agent-work-admin pack)_
+   - `/feature-interview` when the next idea/direction is not yet represented in specs or tasks. _(product-design pack)_
+   - `/reconcile-dev-docs audit` or `/reconcile-dev-docs fix tasks` when task docs contradict git/code reality. _(docs-health pack)_
+   - `/spec-drift` when specs and code appear out of sync. _(agent-work-admin pack)_
+   - `/guide` only for human-only external blockers. _(guided-walkthrough pack)_
+   - `/brainstorm` when the repo is complete/current and the next step is discovering a new phase. _(product-design pack)_
+
+## Output
+
+Produce a structured report with:
+
+- **Overview:** repo path, project purpose, project type, primary apps/packages, branch, dirty/unpushed status.
+- **History Signal:** number of Claude/Codex prompt records scanned, number matched to this repo, date range, and 3-8 concise real examples.
+- **Recent Work:** last commits and task/history evidence.
+- **Current Status:** major areas and whether each appears complete, in progress, blocked, stale, or unknown.
+- **Outstanding Work:** prioritized list with evidence and recommended owner/skill.
+- **Risks And Drift:** contradictions, stale docs, missing tests, manual blockers, or uncertain claims.
+- **Recommended Next Step:** one concrete next work item and one command.
+
+End with exactly:
+
+```md
+**Next work:** <specific task, blocker, discovery task, or "none">
+**Recommended next command:** <one command or route>
+```
+
+## Constraints
+
+- Read-only by default. Do not modify files, create commits, run installs, or execute long test suites unless the user explicitly asks.
+- Do not include private conversation history unrelated to the target repo.
+- Quote only short prompt excerpts. Prefer paraphrase plus timestamp/source/project.
+- Do not treat `tasks/record-todo.md` or `tasks/recurring-todo.md` as execution queues unless an item has clearly become concrete work.
+- Do not put agent-executable work in `tasks/manual-todo.md` or route it to `/guide`.
+- Do not recommend `/roadmap` if the finding is only "tell me the status"; use `/roadmap` only when the task pipeline itself needs queue maintenance or roadmap extension.
+- When recommending a pack skill, first check `.agents/project.json` for `enabled_packs`. If the target skill's pack is not enabled, include `/pack install <pack-name>` as a prerequisite in the recommendation.
+- Do not create or modify GitHub Actions workflows.
+
+## 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/codebase-status-{topic}.html`.
+
+## 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 caller has a concrete handoff.
+- Normally read-only and should not create or modify tracked repository files.
+- If the user explicitly asks this skill to create or modify tracked files, finish by committing and pushing all intended changes to the repository primary branch (`main` when present, otherwise `master`) before stopping.
+- This contract does not override stricter safety rules about secrets, destructive history changes, release publication/tag confirmation, production deploy confirmation, paid actions, or public visibility changes.