菜单
Use when operating existing `pipelines_v2` workflows in this repo. Covers planning, running, local run tracking, inspecting runs, resuming failed runs, rerunning a step, rerunning from a step, and regenerating local reports from existing artifacts.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when planning, running, or reviewing activation patching or interchange experiments for causal claims in mechanistic interpretability. Especially useful for choosing patch sites, designing paired examples, adding same-label controls, distinguishing read layers from write layers, and avoiding overclaiming from weak or lossy interventions.
Use when a benchmark already has a validated latent label spec and the next job is to plan or review the actual mechanistic analysis program. Covers feature hypotheses, readout and localization strategy, probe choice, control design, evidence ladder, and first experiments.
Use when converting a benchmark's native labels into a benchmark-specific latent label spec for mechanistic interpretability. Covers prompt-side vs response-side separation, label-type classification, direct vs derived targets, derivability checks, confounds, ontology freeze, and gap-list handoff.
Use when deciding whether a benchmark is worth deeper benchmark-first mechanistic interpretability work. Covers public availability, runnable access, label richness, product relevance, likely mechanistic question richness, scale, and obvious confounds before investing in latent-label work.
Constructs linear and nonlinear probes for LLM interpretability in Python. Covers extracting hidden states from transformer models, training probing classifiers/regressors on activations, PCA visualization of representations, SAE feature analysis, logit lens, and causal interventions. Use when the user wants to probe, analyze, or interpret LLM internal representations, build probing classifiers, extract hidden states, or study what information is encoded in model activations.
Use when designing or editing `pipelines_v2` workflow files in this repo. Covers workflow file structure, runner specs, dataset patterns, row alignment, section metadata, report inputs, and the decision boundary between first-class specs and workspace-local transforms.
| name | pipelines-v2-run-ops |
| description | Use when operating existing `pipelines_v2` workflows in this repo. Covers planning, running, local run tracking, inspecting runs, resuming failed runs, rerunning a step, rerunning from a step, and regenerating local reports from existing artifacts. |
Use this skill when the workflow file already exists and the task is to operate it rather than redesign it.
For workflow authoring or structural changes, use constructing-workflows.
workflows/<name>/workflow.py,
workflows/<name>/specs/workflow.py, or
workspaces/<workspace>/[<thread>/]phase_XX/specs/workflow.py.uv run python -m pipelines_v2.cli workflow plan --file path/to/workflow.py
uv run python -m pipelines_v2.cli workflow runs --file path/to/workflow.py
Run:
uv run python -m pipelines_v2.cli workflow run --file path/to/workflow.py
Inspect one run:
uv run python -m pipelines_v2.cli workflow show --run-id wr_...
Resume the latest failed run:
uv run python -m pipelines_v2.cli workflow resume --file path/to/workflow.py --latest-failed
Rerun one step only:
uv run python -m pipelines_v2.cli workflow rerun-step --file path/to/workflow.py --run-id wr_... --step report
Rerun from one step through downstream dependents:
uv run python -m pipelines_v2.cli workflow rerun-from-step --file path/to/workflow.py --run-id wr_... --step capture_prompt_eos_router
resume
rerun-step
rerun-from-step
Use resume for interrupted or failed work. Use rerun-* for intentional branching.
The CLI mirrors workflow state into:
~/.xenon/pipelines_v2/catalogOverride if needed with:
--local-catalog-root /path/to/catalog
If an external catalog is also configured, the CLI still writes the local registry. Use the local registry first for operator UX.
For local report steps:
report.json, summary.json, and report.md are published under the report output dirOperationArtifact inputs are copied into:
report_<id>/results/{step_name}_results.jsonIf you only need a fresh report from existing artifacts, use:
rerun-step --step reportDo not rebuild the whole workflow for that.
runtime_app_id is persisted per step when the runner reports oneworkflow show --run-id ... to inspect which remote app ran which stepenable_prefix_caching=FalseWhen behavior-validating smoke tests are the goal:
CREATE TABLE IF NOT EXISTS is enoughWhen a run fails:
resumererun-steprerun-from-stepDo not manually reconstruct prior artifacts unless the CLI surface is genuinely missing a needed operation.