메뉴
Close delivery by capturing outcomes, learning, technical debt, follow-up work, reusable decisions, and measurable process improvements in canonical project knowledge.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use first to route end-to-end, ambiguous, multi-phase, review, release, incident, or decommission work through the minimum sufficient project-delivery lifecycle when depth, state, or authority is unclear.
Coordinate delivery across authorized trackers, documents, meetings, calendars, messages, and operational systems while preserving canonical sources, exact targets, write authority, traceability, and read-after-write evidence.
Update canonical project knowledge for users, developers, operators, reviewers, releases, and future agents. Use for docs-only work or whenever a change affects behavior, interfaces, configuration, architecture, operations, migration, status, or release communication.
Prepare, validate, and—when explicitly authorized—execute integration, CI/CD, versioning, deployment, rollback, monitoring, post-release verification, and hotfix/change-management work.
Assess and improve security, privacy, risk, reliability, observability, supportability, and operational readiness across requirements, design, implementation, review, or release.
Select, execute, and report risk-based validation for a change or release candidate. Use for unit, integration, end-to-end, contract, regression, invariant, static, performance, security, CI-parity, and failure-triage evidence.
| name | retrospective-improvement |
| description | Close delivery by capturing outcomes, learning, technical debt, follow-up work, reusable decisions, and measurable process improvements in canonical project knowledge. |
| license | MIT |
Read ../.shared/operating-model.md; use the retrospective template in ../.shared/artifact-templates.md.
Use after a meaningful release/initiative, incident/hotfix, failed/cancelled effort, recurring delivery friction, or when maintaining the backlog/knowledge base. For a direct retrospective request whose meaningful outcome evidence is not yet available, act only as the intake and evidence owner: record the outcome as unknown, link the evidence gap, and stop before producing findings or lessons. Small changes need only notable learning or follow-ups; do not manufacture ceremony.
Inspect project brief/success measures, requirements/design/plan/RAID/status history, commits/PRs/CI/test/review/release evidence, production metrics/incidents/support feedback when authorized, decisions/assumptions, and existing debt/backlog/knowledge locations.
unassigned, target/revisit trigger, dependencies, and acceptance/evidence. Do not use vague TODOs.Outcome assessment, learning summary, root causes, debt/follow-up ledger, process experiments with measures, RAID closure, and canonical artifacts updated. Route follow-up work through delivery-orchestrator as new scoped delivery items.
Claims link to delivery/production evidence; an evidence-incomplete direct request ends with a cited outcome gap and no fabricated findings; open debt has actionable metadata; durable decisions/knowledge live canonically; temporary rollout/migration work is closed or owned; no redundant retrospective file was created when an existing system suffices.