菜单
Specification-driven feature planning with OpenSpec. Use when starting a non-trivial feature, designing a system change, or when "what to build" isn't settled yet. Triggers on phrases like "plan this", "let's spec this out", "before we build", or when the scope is unclear.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Multi-axis code review across correctness, readability, architecture, security, and performance, applying irega project patterns. Use when reviewing code before merge, evaluating agent-generated output, or doing a quality pass on any code change. Use when user says "code review", "review this", "review my changes", or invokes /irega-code-review.
Security-focused review from an OWASP/threat-modeling angle, covering input validation, auth, data protection, infrastructure, and third-party integrations. Works on any artifact (file, component, PR diff, or described architecture), not just open PRs. Use when user asks for a security review, security audit, or wants to check vulnerabilities. Invoke with /security-audit.
Evaluates technical design decisions and engineering judgment from a Staff Engineer perspective. Use to rubber-duck your own code or architecture, validate technical decisions before committing, or review architectural proposals and design docs. Use when user mentions "staff review", "design review", "architecture review", "technical decisions", or invokes /staff-review.
irega's coding philosophy, conventions, and preferred approaches. Always active — apply these rules for any commit, code, or PR in this session.
Generate PR description from template and git changes. Use when creating a PR and want to auto-generate description based on .github template, commits, and diffs. Extracts Jira tickets from commit messages.
Compact the current conversation into a handoff document for another agent to pick up.
| name | planning |
| description | Specification-driven feature planning with OpenSpec. Use when starting a non-trivial feature, designing a system change, or when "what to build" isn't settled yet. Triggers on phrases like "plan this", "let's spec this out", "before we build", or when the scope is unclear. |
Thin orchestration layer over OpenSpec that ties proposal, design, implementation, and review into a single workflow using the existing engineering skills.
Skip planning for small, well-defined tasks — jump straight to /tdd.
/opsx:propose <feature description>
OpenSpec creates a changes/ folder with proposal.md, specs/, design.md, and tasks.md.
Review and edit design.md before moving on. This is the cheapest point to change direction.
Run /staff-review on design.md to catch architectural issues before any code is written.
Fix design.md based on feedback, then confirm with the user.
Work through tasks.md using /tdd — one task at a time, vertically. Each task becomes a tracer bullet.
/opsx:apply # OpenSpec generates task checklist in context
When all tasks in tasks.md are checked off:
/irega-code-review on the full diff/security-audit if the change touches auth, data handling, or external APIsAddress all Critical/Important findings before proceeding.
/pr-description # generates PR from template + git changes
/opsx:archive # moves change to history
| Command | Phase | Purpose |
|---|---|---|
/opsx:propose <idea> | Plan | Create change proposal |
/opsx:apply | Implement | Generate task checklist from spec |
/opsx:verify | Review | Check implementation against spec |
/opsx:archive | Close | Move completed change to history |
OpenSpec must be installed globally once per machine (handled by install.sh):
npm install -g @fission-ai/openspec@latest
Initialize OpenSpec in each project where you want planning:
cd your-project
openspec init
openspec config profile # select workflow profile