Run any Skill in Manus with one click

analysis-state-management

Stars2

Forks0

UpdatedJuly 8, 2026 at 02:30

Use whenever an analysis plan, phase state, decision log, artifact registry, run record, or subagent handoff needs to be created, updated, resumed, or compacted. Replaces the old habit of growing and rereading one root analysis-plan.md with a small docs/analysis/ YAML index and task-specific records. Use at phase boundaries, before/after compaction, when recording approved deviations, when registering outputs, and when briefing fresh subagents from durable state.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

lancegui

lancegui/causal-powers

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Data ScientistsComputer and Mathematical Occupations·SOC 15-2051

SKILL.md

readonly

More from this repository

same repository

data-contracts

lancegui/causal-powers

Use when computing, transforming, cleaning, joining, merging, aggregating, reshaping, or modeling ANY result from data — before you trust a number, a table, a model metric, or a chart. Establishes data contracts and invariants up front, validates assumptions before building on them, asserts join cardinality before every merge, and freezes validated results as regression baselines. Use this whenever you load a dataset, write a transform or cleaning step, do a join or group-by, fit a model, or are about to report a figure — even if the user only says "analyze this", "what's the trend", "clean this up", "merge these two files", or "build this metric" without ever mentioning tests or validation — in R, Julia, Python, or Stata. NOT the owner of the cleaning PHASE: building a dataset end-to-end is data-preparation, which calls this skill per step.

2026-07-092

descriptive-evidence

lancegui/causal-powers

Use when the deliverable is a DESCRIPTION of what's in the data rather than an effect, a counterfactual, or a prediction — stylized facts, trends ("what's the trend in X", "how has Y changed over time", "plot the growth"), summary-statistics/Table-1 tables, distributions, descriptive maps/choropleths ("map where X is concentrated"), and the motivating-facts section of an empirical paper. The descriptive layer BENEATH the modeling fork: often the whole deliverable; otherwise the stylized fact motivates the causal/structural/predictive question. Use in R, Julia, or Python whenever someone says "what's the trend", "show me the growth", "summary stats", "Table 1", "describe this data", "stylized facts", "what does the distribution look like", or "give me some motivating facts" — even for a quick plot or map, because a mis-deflated, mis-weighted, composition-driven, or count-not-rate "fact" looks exactly as clean as a real one. Co-fires with question-framing.

2026-07-092

predictive-modeling

lancegui/causal-powers

Use whenever the GOAL is a prediction that drives an action — predict, score, rank, flag, classify, forecast, or detect anomalies on units ("which pharmacy is likely diverting opioids", "which claim to audit", "who's likely to churn", "rank by risk"). Route by GOAL, not algorithm: a prediction deliverable is this skill even when a random forest does the work; a causal effect stays in causal-identification even when ML does the heavy lifting (double/debiased ML, causal forests, ML propensity scores). Covers clean-label, proxy/weak-label, unsupervised/anomaly (no label), and ranking/triage regimes in R, Julia, or Python. A high validation score is not a working model until leakage is ruled out and the split mirrors deployment. NOT for one-off data-QA outlier checks while cleaning a dataset — that's data-contracts; uplift/CATE-for-targeting runs BOTH this skill's evaluation gates and causal-identification's design.

2026-07-092

question-framing

lancegui/causal-powers

Use BEFORE starting any data analysis, metric, model, causal study, or any deliverable built FROM data — "what's the trend", "is X driving Y", "how many users", "did the policy work", "build me a dashboard metric", "plot/map/visualize this", "make a figure/chart/map/dashboard/table of …", "build an interactive map of these facilities", or a dataset handed over to "look into". Fires for figures, maps, charts, dashboards, and summary tables built from a dataset, not only metrics — the from-data anchor separates it from generic app/UI building. For general/exploratory work it is the everyday analysis-state skill: data sources, approach, and deliverable fixed in docs/analysis/ before execution. Use even when the request feels clear — vague definitions ("active users", "the effect of X") and unspecified joins are the root cause of artifacts that answer the wrong question precisely or silently mis-join. Not for polishing prose or UI work with no dataset behind it.

2026-07-092

analysis-checkpoints

lancegui/causal-powers

Use throughout the EXECUTION of any analysis — while running, debugging, modeling, or cleaning data — to decide which decisions you may make on your own and which you must STOP and bring to the user first. Forces a human-in-the-loop checkpoint before any consequential analytical choice — changing the research design, estimand, or identification strategy; deviating from the framed question or pre-analysis plan; dropping/filtering/winsorizing data or changing the sample; choosing between materially different specifications; redefining a metric; or changing any number the user has already seen. Use this whenever you catch yourself about to "just fix it", "upgrade the design", "drop the outliers", or otherwise decide something on the user's behalf — especially mid-debugging, where design changes get smuggled in as bug fixes.

2026-07-082

causal-identification

lancegui/causal-powers

Use whenever an analysis makes or implies a CAUSAL claim — "the effect of", "X caused Y", "the policy raised", "the treatment increased", "because we did X, Y changed" — or whenever you're running difference-in-differences, event studies, instrumental variables, regression discontinuity, matching, synthetic control, or panel fixed-effects models. Forces the identification strategy and its assumptions to be stated and tested BEFORE estimating, and treats the design-specific robustness suite (parallel trends, first-stage strength, manipulation tests, balance, placebo, sensitivity) as mandatory, not optional. Use in R, Julia, or Python even when the user just says "regress Y on X", "did it work", or "estimate the impact" — a regression coefficient is not a causal effect until the design earns it.

2026-07-082

name

analysis-state-management

description

Analysis State Management

Principle

A long analysis should resume from durable state, not from a bloated chat or a single growing markdown file. The default memory surface is a small YAML index that points to the few records needed for the current task.

Core rule: read docs/analysis/index.yaml first, then only the records it names. Do not read a whole analysis-plan.md by default.

Folder Layout

Use this layout unless the repo already has an equivalent convention:

docs/analysis/
  index.yaml
  current.yaml
  decisions.yaml
  artifact_registry.yaml
  phases/
  evidence/
  runs/
  handoffs/
  scratch/

YAML is the agent-facing memory because it is compact, diffable, and easy to address by field. Markdown is still allowed for human narrative and detailed evidence, but it should be referenced from YAML rather than read by default. JSON is acceptable for generated records; YAML is preferred for hand-edited plans. Do not put full logs, full diffs, or long prose in YAML.

Required Records

index.yaml is the only default read:

updated: 2026-07-08
active_phase: phase-1b
current: current.yaml
decisions: decisions.yaml
artifact_registry: artifact_registry.yaml
read_for_current_task:
  - phases/2026-07-08_phase-1b.yaml
  - evidence/label-rule-choice.yaml
latest_handoffs:
  fixer: handoffs/fixer_phase-1b_2026-07-08.yaml
  oracle: handoffs/oracle_phase-1b_2026-07-08.yaml
do_not_read_by_default:
  - scratch/
  - old phase markdown
  - archived logs

current.yaml names the live state:

updated: 2026-07-08
goal: apply chosen label rule to production pipeline
phase: phase-1b
status: in_progress
next_action: run production pipeline after label assertions pass
blockers: []

decisions.yaml is a compact ledger:

decisions:
  - id: label-rule-choice
    date: 2026-07-08
    decision: use mme_q, WINDOWN_Q=2, SCALE_FRAC=0.20
    basis:
      - evidence/phase-1a-sensitivity.yaml
    supersedes: []

artifact_registry.yaml maps truth to files:

artifacts:
  production_score:
    path: Detection/results/score_2007_2010.parquet
    produced_by: Detection/scripts/18d_deploy_production_score.R
    last_verified: 2026-07-08
    checks:
      - runs/2026-07-08_smoke.yaml

Phase records carry the plan. Each non-trivial phase should cover two horizons: what this session will do, and where the work sits in the full lifecycle.

id: phase-1-data-prep
updated: 2026-07-08
status: planned
owner: causal-powers:data-preparation
session_plan:
  goal: build validated cleaned panel
  scope:
    - inventory sources
    - assert join cardinality
    - write cleaned output
  out_of_scope:
    - estimating treatment effects
  acceptance_checks:
    - row/key deltas logged after each join
    - totals reconciled to source
  delegated_agents:
    preflight:
      - git-specialist
      - cleanliness-specialist
    execution:
      - fixer
    verification:
      - oracle
  budget:
    context_pressure_red_at: "50%"
    fresh_subagent_each_phase: true
lifecycle:
  previous_phase: phase-0-framing
  next_phase: phase-2-primary-spec
  dependencies:
    - decisions.yaml#source-selection
  verification_gate: oracle verifies data contracts before estimation
  state_updates:
    - current.yaml
    - artifact_registry.yaml
    - runs/
checklist:
  - item: source inventory with provenance
    status: pending
  - item: each join cardinality declared and asserted
    status: pending
outputs: []
next_action: inventory source files

How To Update State

Update the smallest record that changed:

phase status or next step -> current.yaml and the active phase YAML;
consequential decision or approved deviation -> decisions.yaml;
new or changed output -> artifact_registry.yaml;
command/result reproducibility -> runs/*.yaml;
subagent continuation -> handoffs/*.yaml;
routing changes -> index.yaml.

Each record should carry updated or date, a short summary, paths, and the minimum evidence needed to find the truth. Do not paste full logs, full diffs, or full data samples into YAML. Store large detail in files and reference paths.

Draft, Review, Approve

For non-trivial work, create or update draft planning YAML before execution:

Write the active phase session_plan and lifecycle fields.
Keep current.yaml pointed at the next planning/action step.
Route the YAML plan plus the user-facing contract to oracle when plan review is needed.
After user approval, execution agents work inside the approved scope and update runs, artifacts, decisions, and handoffs as they complete.

The draft YAML is allowed to exist before implementation approval because it is planning state, not implementation. Keep it compact and reviewable.

Migrating Old Plans

If a root analysis-plan.md or old monolithic plan exists, convert it by extraction, not transcription:

Read only enough of the old plan to recover current goal, active phase, next action, decisions, artifacts, and blockers.
Create docs/analysis/index.yaml, current.yaml, decisions.yaml, and artifact_registry.yaml.
Create one active phase YAML with session_plan and lifecycle fields.
Add only task-relevant old notes to read_for_current_task.
Put the old markdown path under do_not_read_by_default or archive/scratch.

Do not preserve every paragraph. The migration succeeds when a fresh agent can resume from index.yaml plus the named records without reading the old plan.

Handoffs

A subagent handoff should be compact:

date: 2026-07-08
agent: fixer
phase: phase-1b
status: complete
files_touched:
  - Detection/scripts/02_build_panel.R
commands_run:
  - Rscript Detection/scripts/00_smoke_verify_pipeline.R
large_outputs:
  - logs/phase-1b-smoke.log
next_prompt: >
  Fresh fixer should continue from current.yaml and verify the production run.
budget_status:
  context_pressure: red
  continue_same_thread: false

If context pressure is above 50 percent, handoff and stop. Do not continue the same subagent into a new phase.

Oracle Isolation

Oracle may read index.yaml for navigation and the verification packet for paths, commands, claims, and expected invariants. Oracle must verify claims from source files, outputs, and commands, not from fixer/explorer prose.

Resume Rule

On resume or after compaction:

Read docs/analysis/index.yaml.
Read only current.yaml and the records named in read_for_current_task.
Continue from current.next_action.
If state is missing or stale, repair the state before doing more analysis.

Red Flags

A root analysis-plan.md is growing and being reread in full.
Phase history is mixed with current next steps.
Decisions are buried in narrative instead of a compact ledger.
Artifacts exist but no record says which script produced or verified them.
A fresh subagent needs chat history to continue.

Bottom Line

Good state  -> docs/analysis/index.yaml routes to tiny YAML records
Bad state   -> one long markdown plan every agent rereads from the top