bamr87

Deep-analyze a GitHub issue into a client-engagement estimate — classify scope, refine the plan (approach/deliverables/acceptance), and record an agent-refined estimate in _data/engagements.yml. Use when asked to "estimate", "quote", "scope", or "price" an issue or a repo's backlog, or to review/refine a draft the estimator produced.

Read the Monitor board health data, explain why each repo needs attention, and propose the next concrete action per repo. Use to turn monitoring signals into action, or as the input step of the self-evolution loop.

Read the committed Actions analytics (_data/actions_usage.yml), explain the worst workflows (cost, effectiveness, waste), and drive the next action — dispatch the actions-review issue-filer or fix a workflow directly. Use when asked "where are Actions minutes going" or after the daily actions-usage refresh.

Run the dash drift gate and explain every failure in plain language with the exact fix. Use when CI drift-check fails or before opening a PR.

Run a focused improvement pass on a single project (code quality, docs, tests, error handling) using the matching .github/agents persona. Use when a repo needs maintenance attention or as the action step of the evolution loop.

Scaffold a new project and register it in the dash. Use when starting a new repo/app that should appear in the portfolio.

Adopt (or remove) a project directory that exists on disk under projects/ but is in neither .gitmodules nor the registry. Use when the drift gate flags a stray/unregistered project dir.

Regenerate the dash's monitoring data and the profile README project list from the registry. Use after editing _data/projects.yml or when the portfolio/README looks stale.

Run, drive, and orchestrate the bamr87 dash — the hub for ~40 submodule projects. Use to get the orchestration map, see project health/status, generate a per-project "work order" before dispatching Claude Code into a submodule, or serve/screenshot the Jekyll dash site. Triggers: "run the dash", "start the dash", "dash status", "what should I work on", "orchestrate the submodules", "serve the dash site", "screenshot the dash".

Audit the submodule fleet against the tiered standardization baseline and explain each required gap with the concrete fix. Use to see "which repos are off-standard" or before a fan-out.

Bring one existing submodule up to its standardization tier baseline — add the missing README/LICENSE/.editorconfig/CI/agent-context and open a PR in the submodule's own repo. Use to fix a repo flagged by standardize-audit.

Pull each project's current README summary and status from GitHub into the registry descriptions. Use periodically (or in the evolution loop) to keep the dash's descriptions accurate as projects progress.

Reconcile _data/projects.yml (the project registry) with .gitmodules and GitHub repo metadata. Use when a submodule or repo was added/removed/renamed, or the registry looks out of date.