一键导入
project
Project-level planner — breaks large work into epics and tasks, creates GitHub issues with milestones, sequences execution order.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Project-level planner — breaks large work into epics and tasks, creates GitHub issues with milestones, sequences execution order.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
Primary review entrypoint for plans, diffs, commits, subagent results, and pre-submit checks. Selects quick, standard, or deep mode by scale and risk.
Planner-led repo improvement loops with subagents, review gates, Mermaid DAGs, and workflow-aware commits. Use for improve, refactor, audit, or continue-loop requests.
Triage and apply code review feedback with technical verification. Use when a human, reviewer subagent, CI, or adversarial reviewer returns findings or requested changes.
Heavy review mode normally invoked by request-code-review for risky checkpoints, pre-submit stacks, OpenSpec/cflx acceptance, security-sensitive work, or explicit deep review, audit, or red-team requests.
Post-implementation cleanup for recent changes using parallel reuse, quality, and efficiency reviewers. Use after building a feature or fix, before commit, PR, or submit.
End-of-workflow learning loop for skill-guided work. Use at session/checkpoint closeout to classify GitHub/CodeRabbit/human/CI findings, log missed-review patterns, and propose skill improvements only when evidence justifies them.
基于 SOC 职业分类
| name | project |
| description | Project-level planner — breaks large work into epics and tasks, creates GitHub issues with milestones, sequences execution order. |
| user-invocable | true |
| argument-hint | <project description> |
| model | opus |
You are planning a multi-epic project. Break large work into executable chunks with GitHub issue tracking.
omega_query() to recall past decisions and patterns for this codebaseAsk the user clarifying questions about:
Use the AskUserQuestion tool for structured questions.
Break the project into:
For each task:
Before creating issues, dispatch the project-reviewer agent:
After user approval, create the tracking infrastructure:
gh api /repos/{owner}/{repo}/milestones -f title="Epic: <name>" -f description="<epic description>"
Note: {owner}/{repo} are placeholders — substitute with actual values or use $(gh repo view --json owner,name -q '"\(.owner.login)/\(.name)"'). Capture the milestone number from the response for use in issue creation. You can also use the milestone title directly with --milestone "Epic: <name>" in gh issue create.
gh issue create \
--title "<task title>" \
--body "$(cat <<'EOF'
## Description
<task description>
## Acceptance Criteria
- [ ] <criterion 1>
- [ ] <criterion 2>
## Dependencies
Blocked by: #<issue-number> (if any)
## Approach
<estimated approach, files to touch>
## Complexity
<S|M|L|XL>
EOF
)" \
--milestone "<milestone-number>" \
--label "epic:<name>" \
--label "size:<S|M|L|XL>" \
--label "status:planned"
After all issues are created, add dependency references:
#issue-number cross-referencesblocked-by:<issue> labels where applicabledocs/plans/YYYY-MM-DD-<project-name>.mdomega_store(plan_summary, "decision") with key architectural decisionsPresent to the user:
/next-level:execute <epic-name>