maxwellsdm1867

Scaffold a NEW Wheeler service adapter that integrates an external tool into Wheeler end to end. Reach for this whenever the user wants to "create a wheeler service", "add a new tool adapter", "scaffold an integration", "wrap a service for wheeler", "onboard <some CLI/API/agent> into the graph", "ingest a new tool's output", or otherwise connect an external research tool (a search API, a generator, an analyzer, an agent card) to Wheeler so its results land in the knowledge graph with provenance, even if they do not say the word "adapter". Given the tool (interview the scientist, or read its `--help` / agent card), it produces four pieces: (a) the declarative registry contract the router reads (`.wheeler/services.yaml` or the bundled default), (b) a marshal-out ingest module wired to the shared `_marshal.py` helpers with BOTH provenance sides (`Execution -[USED]-> inputs`, produced nodes `-[WAS_GENERATED_BY]-> Execution`), (c) the marshal-in act `/wh:<provider>-<tool>` that reads graph context, passes `--used`

Render a self-contained, scientist-friendly HTML research brief (a "game plan" decision aid) for a Wheeler investigation plan or execution. It leads with the question and sub-questions, then figure mockups (wireframe or synthetic-data PNG) showing what will be plotted and how competing hypotheses would differ, then the execution steps, a pipeline flow chart, and data sources; at execute time it pairs each mockup with the real result figure and tucks data tables into dropdowns. ALWAYS reach for this skill, and do not hand-write the HTML yourself, whenever the user wants to SEE, VISUALIZE, or SHARE a Wheeler plan or its results as a page: triggers include "visualize the plan", "show/make the brief", "research brief", "render the execution dashboard", "game plan view", "show mockups vs results", "what will the figure look like", "draw the figure under each hypothesis", "re-render that plan/brief", or any request to view a specific plan (for example a PL-xxxx id) or its figures as an HTML page. Even a short reque

Wrap up and package an Asta research-challenge run (or any autonomous research run) for submission — built around NOT hallucinating the write-up. Its core is (1) grounding every feedback/submission claim against the REAL conversation context — via a context-inheriting fork that sees what actually happened, not just the files or a from-memory summary — and (2) capturing the full session trace (trace.tar.gz) so every claim is verifiable against the raw source. Use this whenever the user is finishing a challenge and says things like "wrap up the challenge", "prepare/package the submission", "write the skills feedback", "ground the feedback", "make sure the feedback is true", "cite where that happened", "generate the trace", "set up the submission", or "we just finished a job, package it". It also verifies deliverables, sets up a clean env, scaffolds the submission form fields + RESEARCH_CHALLENGE.md, and optionally publishes to GitHub + Pages so the HTML renders. Reach for it even if the user names only one piec

Scaffold a NEW research repository for an Asta research project — the front bookend to `asta-challenge-wrapup`. Use this whenever the user wants to start a research project and says things like "set up a research repo", "start a new research project", "scaffold a research repository", "create a research project", "make me a Quarto research repo", "init the research environment", or "new Asta challenge repo". It creates (or clones) a git repo, drops in a Quarto scaffold so reports render with citations, sets up a sane .gitignore and a clean Python env, adds a data/ folder with a data dictionary, and — only if asked — the optional GitHub Pages workflow and devcontainer. Defaults to PRIVATE (research/blind-challenge data shouldn't be public up front). Reach for it even if the user only names one piece (e.g. "just add the Quarto scaffold").