Research Analyst Skill

The commissioning layer that turns a decision into framed research questions, dispatches them to the right research engine, and books the returned reports as verified, decision-linked findings.

Application: Personal Assistant · Database: alh_personal · Namespace: anlst-

Purpose

The analyst runs research the way an executive briefs an analyst, not the way people query a search engine. Every mission is framed by a decision and constrained by a time horizon, a source policy, and exclusions. Without a decision-context, a mission is just a search query — create-mission warns when one is missing.

Critically, the analyst is a commissioning layer, not a research engine. It does NOT discover sources or ingest content itself — the engines do. The analyst owns what no engine does: decision framing, question setting, claim-level consensus and verification bookkeeping, and the operator’s sign-off gate. This division of labour is explicit and configured, and it is what resolves the analyst’s apparent overlap with tech-recon and deep-research: those are engines it commissions, not work it duplicates.

The script stores and queries; Claude does the sensemaking — interviewing the operator, framing questions, reading engine reports in the decision’s context, matching claims across engines, verifying, and synthesizing. Findings only reach a decision after passing through the three-question gate.

The engine contract

engines.yaml is the analyst→engine relationship, made explicit and machine-checkable. analyst.py dispatch --engine <name> validates against this file, and its output echoes the engine’s invoke/ingest instructions so the agent can commission it immediately. analyst.py list-engines serves the live contract to agents and dashboards. If a question fits an engine below, it goes there; ad-hoc is the exception, not the rule.

Engine	Kind	When to use	Where its data lives
`deep-research`	Claude skill	Default: general / market / organizational questions needing multi-source web research with adversarial verification and a cited report	Report returned by the skill run (file path / session ref)
`tech-recon`	Alhazen skill	Technology questions: compare systems, evaluate a tool, survey the state of the art, monitor a space	Deep Research app · `alh_deep_research` (trec-investigation id, cross-DB soft ref)
`scientific-literature`	Alhazen skill	Academic-literature questions: what published research says, evidence for/against a scientific claim, key papers/authors	Deep Research app · `alh_deep_research` (scilit collection/corpus id, cross-DB soft ref)
`ad-hoc`	Fallback	Small, fast lookups no engine covers (running three parallel ad-hoc threads means you wanted `deep-research`)	Findings recorded directly via `add-finding`

tech-recon and scientific-literature live in the Deep Research application against the alh_deep_research database. The analyst references their outputs by external_ref — a cross-database soft reference (e.g. a trec-investigation id) resolved against alh_deep_research, with no cross-plugin schema dependency.

Workflow

Everything between checkpoints is agent work; the operator steps in only at the ⏸ checkpoints.

Brief ⏸ — capture the operator’s messy, verbatim primer (create-mission --primer); do not ask them to structure it.
Interview ⏸ — surface unknown-unknowns like a senior analyst taking a brief; store the Q&A (add-interview).
Plan ⏸ — draft the research plan (questions, source strategy, run count) and get it approved (add-plan); separate planning from execution.
Frame decision-linked questions ⏸ — decompose the plan into discrete questions that name what the decision needs to know (add-question); the operator approves the set (update-question --status approved).
Dispatch to an engine — route each approved question to the engine that owns its shape (dispatch --engine <name> --questions ...); the run is created and the engine’s invoke/ingest contract is echoed. For load-bearing questions, dispatch the same question to more than one engine.
Engine runs and returns a report — commission the engine exactly as the dispatch output says; it does the discovery and ingestion, then hands back a report.
Ingest the report (ingest-report) — capture the report verbatim as an engine-report source, close the dispatch (run → completed), record the external_ref, and flip the run’s questions to answered.
Extract findings in decision context — read the report against the mission’s decision-context (not as a summary); record one add-finding per decision-bearing claim, with link-source evidence.
Cross-engine consensus — semantically match claims across engine reports and record each group (record-consensus); single-thread claims are flagged divergent for re-research.
Fresh-thread verification — verify claims in a session with no generation context (verify-finding); refuted claims never reach the deliverable.
Three-question gate ⏸ — before research touches a decision, the operator answers the gate (record-gate); a pass moves the mission to gated.

Data Model

Namespace anlst-, subtypes of the alh-* core types; IDs are <type>-<hash12>.

Type	Kind	Purpose
`anlst-mission`	entity	The research engagement, always framed by a decision (context, horizon, source policy, exclusions, `anlst-decision-ref` soft ref to an advisor decision)
`anlst-question`	entity	A decision-linked research question commissioned to an engine (`draft` → `approved` → `dispatched` → `answered`)
`anlst-run`	entity	One dispatch to an engine (`anlst-engine`, `anlst-external-ref`) — the analyst→engine relationship made concrete
`anlst-source` (kind `engine-report`)	entity	An engine’s report captured verbatim; other kinds are individual cited sources
`anlst-finding`	entity	One discrete claim extracted from a run (claim, confidence, consensus-count, divergent, verification-status)
`anlst-mission-question`	relation	The questions a mission frames for the engines
`anlst-run-answers`	relation	Which questions a dispatched run addresses
`anlst-run-report`	relation	Links a run to its verbatim engine-report source
`anlst-mission-run`	relation	A mission fans out into runs
`anlst-run-yielded`	relation	A run produced a finding
`anlst-finding-source`	relation	A finding is evidenced by a source

Key Commands

Command	What it does
`create-mission`	Open a decision-framed mission; store the operator primer
`list-engines`	Print the declared engine contract from `engines.yaml`
`add-question`	Frame a decision-linked research question on a mission
`dispatch`	Send approved questions to an engine; create the run and echo its invoke/ingest contract
`ingest-report`	Capture an engine report verbatim, close the dispatch, flip questions to answered
`add-finding`	Record one discrete decision-bearing claim from a run
`link-source`	Attach an evidence source to a finding
`record-consensus`	Store an agent-matched claim group (consensus-count + divergent flag)
`verify-finding`	Record fresh-thread verification (`confirmed` / `refuted` / `needs-work`)
`record-gate`	Store the three-question gate answers + pass/fail
`add-deliverable`	Attach output (brief / dashboard / infographic / interactive-page / audio-summary)
`report-mission`	Markdown mission report

The dashboard lives at /analyst.

How it fits the suite

The analyst feeds verified, gated findings into decisions managed by the advisor, career, and ops skills (via the anlst-decision-ref soft reference), and its missions are surfaced by chief-of-staff — which ones are running, which await the gate. It does the research work by commissioning engines that live in the Deep Research application: tech-recon and scientific-literature, both against alh_deep_research, plus the deep-research Claude skill. It sits alongside its Personal Assistant siblings — career, advisor, scribe, ops, chief-of-staff, and coach — sharing the alh_personal database. See the Personal Assistant application overview for the full suite.