菜单
Coding conventions for analysis work — marimo vs plain scripts, uv for execution, scratchpad patterns, notebook structure, input/formula/source organization. Use when writing notebooks or analysis scripts.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when the user wants a collaborative review of a PR — their own read reconciled against existing bot/reviewer comments, with high-confidence fixes applied and judgment calls surfaced — typically via /co-review or asking for a "co-review". Flags — --local reviews the uncommitted working tree (no PR); --remote skips local reviewer agents; --post reviews someone else's PR and posts vetted findings to GitHub instead of editing files; --non-interactive runs unattended with no prompts and bounded reviewer waits.
Write a multi-step implementation plan as markdown files under dev_docs/tasks/<name>_plan/ instead of printing it inline, then refine the plan through clarifying questions. Use when the user runs /plan-with-docs, asks to "plan X to files", or has just approved a plan in plan mode and wants it persisted. Default for any plan that is more than ~3 tasks or spans multiple PRs.
Use when a user notices incidental work during development (stale config, tech debt, dead code, test gaps) they want to defer without losing context, says "task"/"todo"/"follow-up"/"we should come back to this", or runs /add-task, /do-tasks, /list-tasks, or /promote-tasks.
Use when a task estimates larger than size 5, when /promote-tasks flags "scope exceeds size 5 — split into sub-tasks", or when the user says a task/card/ticket is "too big", "won't fit in one PR", or asks to "split", "slice", "break down", or "chunk up" existing work.
Take ONE identified task through its full per-task delivery lifecycle — claim, implement via a routed coder worker, verify, open a PR, run non-interactive co-review, iterate on the findings, and hand off at needs_review (never completed — completion stays merge-verified via /sweep-for-complete). Handler-dispatched (repo-pr / linear / gh-issue / jira) like the other task skills, and the per-task unit the /auto-pilot orchestrator calls. Use when the user wants one specific task driven all the way to a reviewed, hand-off-ready PR (e.g. /deliver-task <slug>), not a batch.
Unattended autonomous mode — "pick up this Project and grind on it overnight." Runs a task graph (a Linear project or a plan-with-docs directory) task-by-task in an isolated worktree, taking each through /deliver-task (claim → implement → PR → co-review → hand-off) with durable, crash-resumable state and no human in the loop. Use when the user wants a body of work advanced autonomously and unattended. NOTE - v1 is under construction; this entry establishes the skill home and the run-state reference. Launch, run, and resume are implemented.
| name | analysis-conventions |
| description | Coding conventions for analysis work — marimo vs plain scripts, uv for execution, scratchpad patterns, notebook structure, input/formula/source organization. Use when writing notebooks or analysis scripts. |
| user-invocable | false |
Note: Project-level preferences (CLAUDE.md, AGENTS.md) override these.
.py script: deterministic pipeline steps, one-shot computations, CI/automation contexts where a notebook adds unnecessary complexity. Always use plain scripts for pipeline model steps (see analysis-pipeline skill).When in doubt, start with a plain script. Refactor to marimo if the user wants interactivity.
uvx marimo edit <path> — interactive editinguvx marimo export html <path> -o output.html — executes cells and renders output (use for generating reports as side effects)uvx marimo export md <path> — exports source code as markdown (does NOT execute cells)Use uv run for executing plain scripts. Use uvx for running CLI tools (like marimo). Do not use bare python — uv handles dependency resolution and virtual environments.
When testing setup calls or ephemerally computing numbers during a conversation, MUST write a temp/_.py file and re-use it. Don't inline multi-line Python in bash commands that need to be re-approved each time.
Once the numbers are incorporated into a notebook or model, delete the scratchpad — its purpose is to make a single approval all that's required, keep intermediate work visible, not to be a permanent artifact. If there's no model to fold it into, the scratchpad is the artifact and should be kept. The agent should clean up temp/ files before ending the conversation unless they are the final output.
MUST NOT embed raw calculated numbers in markdown without a visible formula or a reference to the model that produced them.
(370/1000) x 92 x 24 = 817)