theagenticguy

Use when the user asks to generate, regenerate, or refresh long-form codebase documentation, an architecture book, a module map, or a per-repo reference — especially after `codehub analyze` finishes or after a large merge. Examples: "document this repo", "regenerate the architecture docs", "write a module map for the monorepo", "produce a group-wide portfolio doc". DO NOT use if the repo is not indexed — run `codehub analyze` first and confirm `mcp__codehub__list_repos` returns the repo. DO NOT use for PR descriptions (use `codehub-pr-description`), onboarding docs (use `codehub-onboarding`), or cross-repo contract maps alone (use `codehub-contract-map`).

Use when the user asks for an ONBOARDING, getting-started, or new-engineer guide for the current repo or group. Examples: "write ONBOARDING.md", "generate an onboarding doc for new hires", "what should a new engineer read first". Produces a ranked reading order from `project_profile` + top processes + entry points + owners + centrality. DO NOT use for full architecture books (use `codehub-document`) or PR summaries (use `codehub-pr-description`).

Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: "Why is X failing?", "Where does this error come from?", "Trace this bug", "This endpoint returns 500".

Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of a codebase. Examples: "How does X work?", "What calls this function?", "Show me the auth flow", "Where does the request enter the system?".

Use when the user asks about OpenCodeHub itself — available MCP tools, resources, graph schema, or workflow reference. Examples: "What OpenCodeHub tools are available?", "How do I query the code graph?", "Show me the schema".

Use when the user is planning a rename, extraction, split, move, or restructure and wants to know the blast radius and verify the result. Examples: "What breaks if I rename this function?", "Map every caller before I extract this module.", "Did my refactor touch anything I didn't expect?". OpenCodeHub does NOT edit source — it plans and verifies; you (or your editor) apply the edits.

Use when the user asks for a deterministic code pack of a repo or group — a 9-item BOM (manifest, skeleton, file-tree, deps, ast-chunks, xrefs, optional embeddings sidecar, findings, licenses + readme) that is byte-identical given the same (commit, tokenizer, budget). Examples: "pack this repo for an LLM", "deterministic code pack", "build a reproducible context pack", "pack the platform group". DO NOT use for one-off repo packing without determinism — `pack_codebase --engine repomix` is the bandwidth-saving fallback for that case (no packHash, no 9-item BOM, no reproducibility contract).

Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: "Why is X failing?", "Where does this error come from?", "Trace this bug", "This endpoint returns 500".

Workflow for autonomous software development with the Kiro CLI (open Agent Skills standard). Classifiers route scope, complexity, directory state, and spec readiness before committing to Explore / Research / Plan / Act / Validate, then close the loop with a Compound step that persists lessons to `.erpaval/solutions/` for future sessions. Optional HMW reframing and EARS specification add structured rigor — the orchestrator agent judges when to run them. Each Act subagent edits its own Markdown task packet section-by-section per the write protocol, and the orchestrator monitors with `wc -l`. Use when the user asks to implement a feature autonomously, build with agents, use ERPAVal, plan and execute a coding task, delegate to subagents, do agent-driven development, extract lessons, recall prior lessons, or mentions autonomous coding workflow or compound engineering.

File-first orchestrator for product discovery and spec frameworks. Frames the problem with a Discovery Lead, Product Analyst, or System Architect role. Spawns parallel framework agents (Double Diamond, How Might We, Jobs to Be Done, user stories with INVEST, EARS for AI-coder specs, Gherkin), synthesizes into a PRD or discovery memo, and runs a critic pass. Absorbs prd-drafter (idea to PRD via three parallel research roles) and design-thinking (problem framing, scoped research, brainstorm). Ships per-framework references, role prompts, and templates for PRDs, HMW outputs, job stories, and EARS specs. Use when the user asks to write a PRD, draft requirements, run discovery, brainstorm a product, turn insights into HMW questions, write job stories, spec a feature in EARS for Kiro or Spec Kit, define user stories with INVEST, run a Double Diamond round, or mentions JTBD, acceptance criteria, or Kiro spec format. Do NOT use for business strategy work like Rumelt, Wardley, or PR-FAQ-as-leadership-artifact. Use pro

Workflow for autonomous software development with Claude Code. Classifiers route scope, complexity, directory state, and spec readiness before committing to Explore / Research / Plan / Act / Validate, then close the loop with a Compound step that persists lessons to `.erpaval/solutions/` for future sessions. Optional HMW reframing and EARS specification add structured rigor — Claude judges when to run them. Each Act subagent edits its own Markdown task packet section-by-section per the write protocol, and the orchestrator monitors with `wc -l`. Use when the user asks to implement a feature autonomously, build with agents, use ERPAVal, plan and execute a coding task, delegate to subagents, do agent-driven development, extract lessons, recall prior lessons, or mentions autonomous coding workflow or compound engineering.

File-first orchestrator for product discovery and spec frameworks. Frames the problem with a Discovery Lead / Product Analyst / System Architect role, spawns parallel framework agents (Double Diamond, How Might We, Jobs to Be Done, user stories + INVEST, EARS for AI-coder specs, Gherkin), synthesizes into a PRD or discovery memo, runs a critic pass. Absorbs prd-drafter (idea to PRD via 3 parallel research roles) and design-thinking (pain-point excavation, landscape research, brainstorm). Ships per-framework references, role prompts, templates for PRDs, HMW outputs, job stories, EARS specs. Use when the user asks to write a PRD, draft requirements, run discovery, brainstorm a product, turn insights into HMW questions, write job stories, spec a feature in EARS for Kiro or Spec Kit, define user stories with INVEST, run a Double Diamond round, or mentions JTBD, acceptance criteria, Kiro spec format. Do NOT use for business strategy (Rumelt, Wardley, PR-FAQ as leadership artifact) — use product-strategy.

Shared canonical references for product-design frameworks — Pyramid Principle, Working Backwards, Double Diamond, research design, methodology selection. Consumed by `product-discovery`, `product-strategy`, `working-backwards`, and `customer-research` via `${ERPAVAL_HOME}/skills/product-design-shared/references/`. Do NOT invoke this skill directly — it has no orchestrator and no assets. Load the upstream skill that owns your task (`product-discovery` for PRD / HMW / EARS, `product-strategy` for Rumelt / Wardley / Minto, etc.) and let it pull from this pool as needed.

Shared canonical references for product-design frameworks — Pyramid Principle, Working Backwards, Double Diamond, research design, methodology selection. Consumed by `product-discovery`, `product-strategy`, `working-backwards`, and `customer-research` via `${CLAUDE_PLUGIN_ROOT}/skills/product-design-shared/references/`. Do NOT invoke this skill directly — it has no orchestrator and no templates. Load the upstream skill that owns your task (`product-discovery` for PRD / HMW / EARS, `product-strategy` for Rumelt / Wardley / Minto, etc.) and let it pull from this pool as needed.

Customer research and problem framing using the research-design discipline: hypothesis, null hypothesis, MECE questions, methods, findings. Produces Pyramid-base-shaped output ready for downstream composition into PR/FAQs, long-form narratives, or PRDs. Use when the user asks to design user research, run customer interviews, synthesize research findings, frame a problem statement, build a customer journey map, plan a VoC study, or mentions pain-point analysis, research plan, hypothesis testing, customer insights, jobs-to-be-done, or voice of customer.

Working Backwards 5-stage customer-first product discovery. Orchestrates Listen, Define, Invent, Refine, Test & Iterate to produce a 5CQ, PR/FAQ, or Dear Customer Letter. Use when the user asks to work backwards, write a PR/FAQ, draft 5 customer questions, do customer-first product definition, or mentions Working Backwards, press release FAQ, 5CQ, MLP, or customer obsession. Do NOT use for strategy kernel, Rumelt diagnosis, or Wardley mapping — use product-strategy. Do NOT use for PRD drafting or HMW/EARS specs — use product-discovery.

Query the user's own Claude Code transcript history with SQL, semantic search, and LLM-driven analytics. Use this skill whenever the user asks about their past Claude sessions, their coding history with Claude, what they worked on last week/month/quarter, how much they spent on Opus or Sonnet, which sessions succeeded or failed, their autonomy patterns, the themes across their work, recurring topics, todos they never closed, or any analytical question about their own ~/.claude/ transcripts. Also triggers for "my claude history", "my claude sessions", "my transcripts", "analyze my sessions", "what did I do in claude", "search my conversations", "my opus cost", "my claude spend", "autonomy tier", "work categories", "group my sessions", "cluster my work", "find sessions about X", "sessions where I disagreed with myself", or any phrasing that implies analyzing the user's own Claude Code corpus.

Use when the user asks for a deterministic code pack of a repo or group — a 9-item BOM (manifest, skeleton, file-tree, deps, ast-chunks, xrefs, optional embeddings sidecar, findings, licenses + readme) that is byte-identical given the same (commit, tokenizer, budget). Examples: "pack this repo for an LLM", "deterministic code pack", "build a reproducible context pack", "pack the platform group". DO NOT use for one-off repo packing without determinism — `pack_codebase --engine repomix` is the bandwidth-saving fallback for that case (no packHash, no 9-item BOM, no reproducibility contract).

Use when the user asks for a cross-repo contract map, an API-consumer matrix, or a service-interaction diagram across a repo group. Examples: "map the HTTP contracts between services", "which services call the billing API", "show the contract matrix for the platform group". GROUP MODE ONLY — requires a named group. DO NOT use on a single repo (use `codehub-document` with `reference/public-api.md`). DO NOT use if `mcp__codehub__group_list` does not include the group.

Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: "Why is X failing?", "Where does this error come from?", "Trace this bug", "This endpoint returns 500".

Use when the user asks to generate, regenerate, or refresh long-form codebase documentation, an architecture book, a module map, or a per-repo reference — especially after `codehub analyze` finishes or after a large merge. Examples: "document this repo", "regenerate the architecture docs", "write a module map for the monorepo", "produce a group-wide portfolio doc". DO NOT use if the repo is not indexed — run `codehub analyze` first and confirm `mcp__codehub__list_repos` returns the repo. DO NOT use for PR descriptions (use `codehub-pr-description`), onboarding docs (use `codehub-onboarding`), or cross-repo contract maps alone (use `codehub-contract-map`).

Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of a codebase. Examples: "How does X work?", "What calls this function?", "Show me the auth flow", "Where does the request enter the system?".

Use when the user asks about OpenCodeHub itself — available MCP tools, resources, graph schema, or workflow reference. Examples: "What OpenCodeHub tools are available?", "How do I query the code graph?", "Show me the schema".

Use when the user wants to know what will break if they change something, or needs safety analysis before editing or merging code. Examples: "Is it safe to change X?", "What depends on this?", "What will break?", "Blast radius for this change".

Big-Sleep variant analysis. Given a recently-fixed bug shape (the lines added/removed in a patch), find more code in the repository that has the same shape and is likely to carry the same defect. Reports variants linked to their seed. Deny-by-default: only the allowed_tools below are permitted.

Review a code diff or corpus for security vulnerabilities grounded in the supplied threat model. Reads code semantically, forms hypotheses, verifies them, and emits scored findings as a single JSON code block. Deny-by-default: only the allowed_tools below are permitted.

Given an architecture description or diagram, produce a STRIDE threat model plus attack trees as YAML. Use when the user asks to threat model a system.

Triage a candidate finding by deciding whether the vulnerable code is reachable from an untrusted entry point, producing the reachability axis (0-1) that feeds asec-confidence. Use when the user asks to triage a finding or assess exploitability.

Review a git diff for vulnerabilities by running Semgrep and CodeQL, then emit structured findings. Use when the user asks for a security review of a diff/PR.

Given an architecture description, diagram, or repo, produce a Phase-Zero STRIDE threat model plus attack trees as YAML conforming to asec-threat-model schema. Use when the user asks to bootstrap or create a threat model for a system.

Critique an existing threat model for completeness and rigor — missing STRIDE categories, unjustified skips, weak mitigations, ungrounded likelihood/impact. Use when the user asks to review, critique, or red-team a threat-model.yaml.

Compare two threat-model.yaml revisions and report what changed — added or

Bootstrap the full codeprobe developer experience for a repository, producing `.codeprobe.toml`, `lefthook.yml`, CI workflows, `.claude/plugins/codeprobe/`, GitNexus graph, and a merged `CLAUDE.md` section. Use when the user asks to 'bootstrap a project', 'set up codeprobe', or 'install the codeprobe plugin'. DO NOT use when the repository is already bootstrapped and the drift check passes — use the individual stage commands (`codeprobe init`, `codeprobe ci-init`) for targeted regeneration instead. DO NOT use for interpretation of existing scan results — use codeprobe-interpret.

Generate `.codeprobe.toml` and recommend scanner/tool configuration for a repository based on detected languages, frameworks, and IaC types. Use when the user says 'configure codeprobe', 'what scanners should I use', or 'initialize codeprobe'. DO NOT use when `.codeprobe.toml` already exists and the user has not asked to regenerate or reconfigure it — edit the existing file directly. DO NOT use for running scans — use codeprobe-probe or the `/probe` command.

Generate a comprehensive, cross-linked codebase documentation directory at `.codeprobe/docs/` (33 markdown files across 8 subdirectories, with Mermaid diagrams and source-level citations). Use when the user asks to 'document this codebase', 'generate docs', or 'create documentation'. DO NOT use for single-section updates — pass `--section <name>` or edit the target file directly. DO NOT use if `.codeprobe/heuristic_summary.json` is absent — run `uv run codeprobe index .` first to produce the required artifacts.

Interpret `.codeprobe/scan.sarif` and produce a layered human-readable findings report (Layer 1 dashboard, Layer 2 source explanations, Layer 3 execution flow risk, Layer 4 remediation previews). Use when the user asks to 'interpret scan', 'explain findings', or 'what did the scan find'. DO NOT use when `.codeprobe/scan.sarif` is absent — run codeprobe-probe or `uv run codeprobe scan .` first. DO NOT use for running the scan itself — this skill only reads existing artifacts.

Run `uv run codeprobe scan .` to produce `.codeprobe/scan.sarif` and then hand off to codeprobe-interpret for a layered findings report. Use when the user says 'probe', 'scan and explain', or 'check my code'. DO NOT use for interpretation-only requests when a SARIF file already exists — use codeprobe-interpret directly. DO NOT use if `.codeprobe.toml` is absent and the user has declined bootstrap — run codeprobe-configure or codeprobe-bootstrap first.

Explain the codeprobe trust model and verdict engine (signals, tier escalation, blast-radius thresholds, temporal risk) that produces a `VerdictResponse` with one of {auto_merge, single_review, dual_review, expert_review, block}. Use when the user asks about 'trust model', 'change verdict', or 'when to block a PR'. DO NOT use to compute a verdict for a specific PR — run `uv run codeprobe verdict` (or the CI workflow generated by `codeprobe ci-init`) instead. DO NOT use for general scan interpretation — use codeprobe-interpret.

Builds disposable localhost workbenches — Flask + raw sqlite3 + htmx + Server-Sent Events apps — that give an agentic coding/eval/PR/data session a live UI with no build step, npm install, or deploy. The signature move is a two-way human↔agent loop over one SQLite file: the human acts in the browser (htmx POST → SQLite → fragment + SSE invalidation), the agent acts from the terminal (httpx → SQLite → SSE), both seeing the same state update live with no reload. Ships recipes for eval viewers, PR review rooms, document review / redline surfaces, trace replays, refactor cockpits, and more. Use when the user wants a quick local UI for a coding/eval/PR/data task, OR mentions localhost workbench, eval viewer, PR review room, review/redline a document, select text and leave comments, htmx+SSE app, live invalidation, two-way agent loop, or "build me a little UI for this." Do NOT use for production apps or React/Vue/Svelte SPAs (use frontend-design), or static one-shot data pages / HTML reports (use generative-ui).

Score a single skill against the gardener rubric. Reads the skill's SKILL.md, references/, and templates/, then writes a 7-dimension scorecard with per-criterion rationales and a recommended-actions list. Isolated counterpart to /gardener: same rubric, one item at a time. Use when the user asks to audit a skill, score a skill, check if a skill is healthy, or wants to re-score after making changes.

Monthly catalog hygiene audit for Claude Code plugin marketplaces. Inventories every skill and agent, scores each against a 7-dimension rubric via parallel Opus Agents, detects description collisions via Bedrock Cohere v4 embeddings with pairwise cosine, and writes a delta report vs. the prior audit. Proposes resolutions; does not auto-apply. Use when the user asks to audit the catalog, run the gardener, find skill collisions, check plugin hygiene, generate a monthly audit report, or mentions catalog drift.

Propose description rewrites to resolve skill collisions. Given a collision pair from a gardener audit, reads both skills' descriptions, generates before/after rewrites with negative discriminators, and writes a proposal Markdown the user applies manually. Uses current Claude prompting discipline: positive imperatives, motivation clauses, scope explicit. Use when the user asks to fix a collision, rewrite a description, disambiguate two skills, or mentions resolving a gardener-flagged pair.