analysis-auto

/analysis-auto — Guided Autopilot (driver)

Drives the analysis pipeline so you don't type a /command at every step. It orchestrates the existing skills (it does not reimplement them) and stops only at genuine decisions. Autonomy is scoped to this run — the individual skills stay explicit/interactive everywhere else. See ADR-0005.

When to Use

• You have (or are about to frame) a hypothesis and want Claude to carry it through to results with minimal manual dispatch, pausing for your judgment where it matters.

When NOT to Use

• You want to run a single step (use that step's /command directly).
• Unattended / headless batch execution — this is not that. It is interactive; it stops at the gates below and waits for you.

Gate policy

The whole point is reduce friction, keep judgment. The driver enforces:

Step	KEEP — pause for the user	AUTO — proceed without asking
framing	present the Data Map + candidate directions and settle the direction with the user (Direction Dialogue)	agentic exploration of .insight/; Framing Brief construction once the direction is agreed
design ① hypothesis	confirm the hypothesis statement + background	drafting them from the Framing Brief
design ② methodology	confirm the method + metrics + explanatory roles (treatment/confounder/…) + intent	auto-drafting these fields from the Framing Brief
design ③ data-extraction	confirm the data-acquisition plan — the actual query text (methodology.steps) for SQL sources, or file + columns + filter for CSV/others, plus expected grain & rough row scale	auto-drafting the query / column selection from the catalog schema
design ④ charts	confirm the planned chart[] specs (intent / type / x / y)	auto-drafting chart specs from the direction
review (optional)	the verdict (revision_requested vs approve)	running the critique itself
premortem	result is HARD_BLOCK/HIGH → stop, surface the risk	running premortem; LOW/MEDIUM
notebook	non-allowlisted package / external comms beyond the declared source / other side-effects	generate + run when premortem cleared AND it's declared-source read + allowlisted + local compute
journal	—	auto-record the notebook verdict (observe/evidence/question)
reflection	the conclusion (conclude/refine/branch) + terminal transition	presenting the evidence summary
report (optional)	generating the distributable report — offer /analysis-report after a terminal conclusion; the user hand-edits it, so confirm before writing	—
catalog-register	registering a data source (external-data side-effect); unregistered source → stop	—

The four design ①–④ beats are ordered confirmation gates run before design_io create (and therefore before premortem): each is presented as its own AskUserQuestion so the user can adjust it, rather than collapsing the whole design into a single "looks good?". Beat ③ (data-extraction) is where the actual data pull — the SQL query or the CSV file+columns+filter — gets a seat, so premortem then estimates cost against the confirmed query.

If in doubt whether something is a genuine decision, stop and ask — bias toward the KEEP column.

Workflow

Step 1: Locate the current position

• design_io get --id {id} (if an id was given) or design_io list to see existing designs. Decide the entry point:
  • no hypothesis yet → start at framing/design;
  • design exists in in_review/analyzing → continue from review/premortem/notebook;
  • design has journal/results → continue from reflection.
• Tell the user the plan ("これから design→premortem→notebook→journal→reflection を自動で進める。 仮説確定・コスト判定・結論では止まる").

Step 2: Drive each step (delegate to the skill, apply the gate policy)

For each step, follow that skill's SKILL.md (do not duplicate its logic here) and apply the gate policy above:

1. framing (if no hypothesis yet): run /analysis-framing in full — explore .insight/, present the Data Map, and hold the Direction Dialogue with the user (candidate directions, gaps, missing data). Do not silently auto-pick the direction — this is where a beginner's intent gets elicited. Settle the direction with the user, then produce the Framing Brief.

2. design: run /analysis-design, auto-drafting fields from the agreed Framing Brief. Then walk the four ordered confirmation beats — one AskUserQuestion each — before design_io create, letting the user adjust at every beat. Do not collapse them into a single "looks good?"; don't silently commit auto-picked methodology / roles / query.

   1. hypothesis — present the drafted hypothesis_statement + hypothesis_background; confirm.
   2. methodology — present methodology (method + code patterns), metrics, and especially the explanatory variables' causal roles (treatment / confounder / covariate / …) + analysis_intent; confirm. These shape the analysis and are genuine choices.
   3. data-extraction — present the actual data-acquisition plan: for a SQL source, the query text drafted into methodology.steps (see /analysis-design Step 2.6); for a CSV/other source, the file
      • the columns/filter that will be read — plus the expected grain and a rough row-count. Confirm the pull before it is committed to the design, so premortem (item 4) estimates cost against the confirmed query. A source with no SQL still gets this beat as a data-acquisition plan.
   4. charts — present the planned chart[] specs (intent / type / x / y); confirm.

   After all four beats are confirmed, design_io create the design.

3. review (optional): if the user wants a review pass, run /analysis-review; pause on the verdict.

4. premortem: always run /premortem before touching data. If HARD_BLOCK/HIGH, stop and surface the risk (unregistered source → offer /catalog-register; cost/allowlist/location → let the user decide). If LOW/MEDIUM, continue.

5. notebook: run /analysis-notebook. Auto-run only when premortem cleared and the analysis is confined to the declared source(s) + allowlisted packages (.insight/rules/package_allowlist.yaml) + local computation. If the methodology needs a non-allowlisted package, network egress beyond the declared source, or another side-effect, stop and get the user's go-ahead first.

6. journal: the notebook step already records observe/evidence/question — no pause.

7. reflection: run /analysis-reflection; pause at the conclusion (conclude/refine/branch) and the terminal transition.

8. report (optional): once a terminal conclusion exists, offer /analysis-report to build the distributable APA report — a KEEP gate (the user hand-edits it, so confirm before writing). This is where the run ends.

Step 3: Summarize

Report what ran automatically, where it paused and why, and the final state (status, journal, lineage).

Delegated skills

/analysis-framing, /analysis-design, /analysis-review, /premortem, /analysis-notebook, /analysis-journal, /analysis-reflection, /catalog-register — each remains explicit-invocable on its own; /analysis-auto only sequences them and enforces the gate policy.

Chaining

From	To	When
/analysis-auto	→ /analysis-design	Autopilot needs a hypothesis first
/analysis-auto	→ /analysis-reflection	Autopilot reaches results; conclusion is the user's call
/analysis-auto	→ /analysis-report	After a terminal conclusion, offer the distributable report (KEEP gate)

Language Rules

• Follow project CLAUDE.md language settings. Default to Japanese if no setting.
• Code, IDs, tool names, and YAML fields always stay in English.