Agentic-Research-Control-Panel

Use when the user invokes /research-auto or asks to run an autonomous research campaign over one Direction toward a measurable gate.

The Step-3 direction-formation on-ramp. Use when the user has only a vague or partial research idea and cannot yet state a clear Direction, or types /research-brainstorm, or asks to brainstorm / shape / explore a research direction before committing. Captures cheap pre-package, pre-SSOT ideas onto the dashboard brainstorm lane, automatically generates an English brainstorm HTML detail page for each idea, and converts one or more ideas into a single Direction proposal submitted through Triage. The agent only PROPOSES the Direction — the PM ratifies. Project-agnostic. Requires a committed Project node (run /research-onboard or /research-scope first).

Set up, repair, or validate the global research_html/ HTML dashboard scaffold for any research project. Use this skill whenever the user types /research-dashboard, asks to create or initialize a research dashboard, repair a broken research_html/ scaffold, install the four lane pages (brainstorm / in-progress / success / fail) before creating research packages, bring a project under the binding HTML rules R1-R18 and Trustworthy Research rules T1-T24, or set up the global research-system protocol for autonomous research agents. Project-agnostic: works in any repository the user opens. The dashboard chrome is overview-only — claims, evidence, and stage transitions live on package pages, not on the dashboard.

Use when bridging a raw or existing workspace into the Scope SSOT with /research-onboard: detect/scaffold or analyze the workspace, write prior knowledge, draft a Project objective, and create a PM-ratifiable Project Scope proposal. Always show the proposed Scope clearly to the PM with the next ratification step. The skill only proposes through Triage; it never commits the SSOT or creates packages.

Use when the user invokes /research-op or needs guarded changes to an existing research package or Scope SSOT: row/card/section edits, inventory field updates, checks/lints, artifact event fanout, registry additions, scope transitions, or natural-language status fixes.

Use when defining or revising Project, Direction, or Task Scope intent, or when execution discovers a needed scope change. The agent only proposes through Triage and must show every proposed Scope clearly to the PM with the next ratification step; accepted Scope writes route through research-op's scope-transition op. Never invokes git.

Use when the user invokes /research-package or asks to create, initialize, draft, scaffold, or materially restructure a research package under research_html/packages, including materializing accepted Scope SSOT Directions, adding dashboard package entries, or large structural results.html edits.

Use when the user types /research-run or asks to run, continue, monitor, verify, or complete an existing scoped research package. Operates only after Project/Direction/Task scope and package materialization exist; missing setup is handed off to research-onboard, research-brainstorm, research-scope, or research-package. Objective: complete the package by advancing its next executable experiment through readiness, implementation/review if needed, launch/monitoring, artifact propagation, result verification, and terminal success/fail/archive routing. Every package mutation routes through research-op; long runs use research-exp-live when applicable. Never invokes git.

Create, maintain, and validate the per-package `analysis.html` page (Rules + Insight). Use this skill whenever the user types /research-analysis, asks to initialize / scaffold / lint an analysis page, asks to add a distilled rule or a deep-analysis insight to a package, asks to summarize an insight into a rule, or asks to embed a visualization (bar chart, heatmap, threshold chart, admission matrix) into an insight sub-block. Project-agnostic. Hard requirement: the dashboard at <cwd>/research_html/ must already exist (run /research-dashboard first) and the target package must already exist (run /research-package first). Analysis is the single home for the lessons distilled from a package's results — Rules are generalized constraints future packages must obey; Insights are the mechanism-level diagnostics that justify those rules. Both blocks are manual-only and never auto-populated from results, tracker, or inventory.

Use when launching, monitoring, resuming, or stopping long-running research experiment commands that should be tracked through structured runtime artifacts, adaptive live checks, startup health gates, or global live.html.

Use when registering the user's predefined compute servers (local workstation, HPC/Slurm clusters, cloud VMs) into the typed resource registry, probing GPU availability, choosing where to run an experiment, or releasing a finished allocation. Triggers: /research-resource, 'register a server', 'where should this run', 'allocate GPUs', 'free the allocation'.