菜单
Use at the start of any planning request to classify the work and size it — what kind of request this is, its complexity and risk, the right mode, and therefore how much planning it needs. Reads .aspis/config/modes.yaml so effort matches the work.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Keep commits atomic — split a mixed change set into scoped, reviewable commits.
The one-time procedure to take an exported project to live — understand it, confirm the name/goal/stack with the user, run the deterministic `aspis bootstrap`, enrich the judgment files (AGENTS.md, ARCHITECTURE, context), verify, and let the package self-clean. Followed by the bootstrap agent.
Keep per-subsystem architectural intent current through the planning loop — read before designing, record an impact report on change, confirm with the user, apply a dated update, and verify the build against approved intent.
Audit a plan's task dependency graph for structural integrity — circular dependencies, missing prerequisites, orphan tasks, and dependency classification (hard/soft/warning). Produces a pass/warn/fail audit report per dependency so planners catch graph errors before build starts.
Every editing agent should start on a clean working tree so parallel work never collides.
Verify hooks ran, no secrets, protected paths untouched, and commit message valid before committing. Owned by the reviewer.
| name | planning-intake |
| description | Use at the start of any planning request to classify the work and size it — what kind of request this is, its complexity and risk, the right mode, and therefore how much planning it needs. Reads .aspis/config/modes.yaml so effort matches the work. |
Decide how to plan before planning. The intake decision sets the depth of every downstream step, so a one-line fix doesn't get an epic's ceremony and a risky feature doesn't get under-planned.
First, on every planning request, before gathering deep context or writing anything.
/plan --mode vibe, "build this MVP-style") → the active feature's mode →
the project default (.aspis/config/project.yaml) → modes.yaml's default.
You may infer a mode from the request's risk and scope and confirm it with the
user, rather than always asking. Read the chosen mode's knobs from
.aspis/config/modes.yaml — do not invent them.spec, architecture,
task_size, plan_review, build_review, test_depth, docs, promotable.
These decide which artifacts P2–P5 produce and how deep each goes (e.g.
architecture: skip drops P3; plan_review: skip drops P5). task_size is the
base granularity; shade it by the builder's model — a weaker/cheaper model
earns finer task packets (smaller, more checked), a stronger one can take coarser
ones. When it matters, read the builder's model from .aspis/config/agent-models.yaml
(model routing is the system-lead's domain — planning only reads it, never changes it).The track (set by size and complexity) chooses the path; the mode only tunes how much rigor that path gets. So a genuinely small change in production mode still takes the small-task path — production raises the bar on that path (require a test, require the review) but never forces a full spec + architecture onto a one-file edit. Let real simplicity collapse phases even under production; let real risk resist vibe. Mode sets the maximum ceremony, not a minimum.
modes.yaml.