القائمة
Run a retrospective analysis on completed work to identify process improvement opportunities. Use when the user wants to review a completed batch or item run, or invoke on-demand with a PR number, branch, or date as scope hint.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Compatibility/advanced alias: resolve a native GitHub epic into a bounded workflow execution scope, with optional delegated review and merge gates. For the recommended starting point, use /run-work <epic-target> instead. Use /run-epic when you need direct control over delegation flags (--delegate-review, --may-merge, --max-risk). For explicit item lists, use /run-items.
Bounded multi-item execute command: advance two or more explicit workflow items through Protocol 90 explicit_list mode. For a single item use $run-item; for an epic use $run-epic; for a read-only portfolio scan use $run-work.
Read-only portfolio scan. No-target scan proposes batches with no dispatch. Two or more targets redirect to $run-items. Single targets redirect to $run-item or $run-epic. No mutation in any mode.
Batch-orchestrate the repository's staged AI development workflow. Use when the user wants Codex to discover what can advance or start across multiple items, propose the largest safe batch by priority and parallelization feasibility, and supervise approved item work until it reaches a real terminal condition.
Primary bounded command: advance exactly one non-epic workflow item. Use when the user asks for /run-item or wants to resume a specific development, branch, PR, or issue with the shared bounded prelude before Protocol 91. /run-item-work is a deprecated alias with identical behavior.
Advance a single workflow item until it reaches a real terminal condition. Use when the user wants Codex to resume or advance one specific development, branch, or PR without scanning the whole portfolio.
| name | workflow-retrospective |
| description | Run a retrospective analysis on completed work to identify process improvement opportunities. Use when the user wants to review a completed batch or item run, or invoke on-demand with a PR number, branch, or date as scope hint. |
Recommended model tier: balanced
Meta-Retrospective: If the user invokes this skill with a meta scope (e.g., "run meta-retro", "periodic verification", or similar phrasing indicating trend analysis of prior improvements), follow docs/workflow/development-workflow/protocols/06b-meta-retrospective-protocol.md instead of the regular retrospective flow below. The meta-retrospective includes a platform evaluation step (Step 2b) that reads docs/workflow/retro-metrics-platforms.md and reports the running exclusive-block rate for each review platform against the graduation criteria. When fewer than 30 compare-mode runs are logged, Step 2b explicitly states data is insufficient for a graduation decision.
AGENTS.md for repository-wide rules.docs/workflow/development-workflow/protocols/06-retrospective-protocol.md.gh. When conversation context is available, also analyze manual interventions, human corrections, and agent deviations from the current session.reviewer_loop_history.v1 from the latest script-owned reviewer-loop
summary comment first and calculate max(entries.length - 1, 0) when
history_status is available; otherwise record unavailable (<reason>)
before falling back to legacy timestamp heuristics. Record unavailable for
any field that cannot be reliably determined.fix/[slug] branch, open a PR to develop, and proceed through normal review/CI gates — do not push directly to shared branches. "Add to backlog": create GitHub issue directly via gh issue create. "Skip": move on.docs/workflow/retro-metrics.md as a new table row.