Menu
Use when a team sees repeated @codex review cycles or Codex Cloud feedback churn and needs root-cause attribution by development stage.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | pr-review-cycle-retro |
| description | Use when a team sees repeated @codex review cycles or Codex Cloud feedback churn and needs root-cause attribution by development stage. |
Explain why Codex Cloud review had to be re-run. Attribute causes to specific development stages, not just PR outcomes.
When NOT to use:
| Item | Rule |
|---|---|
| Codex cycle | Codex review comment -> code update -> new Codex review |
| Evidence | Codex comment + fix commit OR follow-up fix PR OR regression doc |
| Stage attribution | design / implementation / testing / review packaging / release |
| Mixed PR | record both frontend and backend impact |
| Noise guard | if Codex comments are generic, mark low-signal |
| Risk-layer gate | if any trigger matches, fill the addendum before @codex review |
Baseline candidate list (optional):
node scripts/ops/pr-retro.cjs \
--since YYYY-MM-DD \
--min-cycles 3 \
--limit 5 \
--out-dir docs/retrospective \
--max-prs 80
Then isolate Codex Cloud feedback per PR:
gh pr view <num> --json reviews,comments --jq '(.reviews + .comments) | map(select(.author.login == "chatgpt-codex-connector"))'
Output notes:
docs/retrospective/YYYY-MM-DD-pr-retro.json keeps summary fields for all PRs; picked contains full detail (reviews/comments/commits/files) for the selected PRs only.docs/retrospective/YYYY-MM-DD-pr-retro.csv is built from the picked list.Before requesting @codex review, check .github/PULL_REQUEST_TEMPLATE.md:
| Excuse | Reality |
|---|---|
| "Codex asked again, so it's Codex's fault" | Repeated reviews usually reflect missing context or gaps in our stages. |
| "Review cycles are enough" | Cycles show churn, not cause. Evidence is required. |
| "Titles explain the issue" | Titles are symptoms, not root causes. |
| "We fixed it later, so root cause is obvious" | Fixes show symptom; stage attribution still required. |
| "Template is optional" | Risk-layer addendum is mandatory when any trigger matches. |
Use VibeUsage to track AI coding agent token usage, inspect model and project usage, and find scoped API documentation.
Use this skill whenever the user needs backend infrastructure management — creating database tables, running SQL, managing database migration files, deploying serverless functions, managing storage buckets, deploying frontend apps, adding secrets, setting up cron jobs, checking logs, or running backend diagnostics — especially if the project uses InsForge. Trigger on any of these contexts: creating or altering database tables/schemas, fetching or applying database migrations, writing RLS policies via SQL, deploying or invoking edge functions, creating storage buckets, deploying frontends to hosting, managing secrets/env vars, setting up scheduled tasks/cron, viewing backend logs, diagnosing backend health or performance issues, or exporting/importing database backups. If the user asks for these operations generically (e.g., "create a users table", "apply a migration", "deploy my app", "set up a cron job", "check backend health") and you're unsure whether they use InsForge, consult this skill and ask. For writ
Use this skill whenever writing frontend code that talks to a backend for database queries, authentication, file uploads, AI features, real-time messaging, edge function calls, or sending custom transactional email — especially if the project uses InsForge or @insforge/sdk. Trigger on any of these contexts: querying/inserting/updating/deleting database rows from frontend code, adding login/signup/OAuth/password-reset flows, uploading or downloading files to storage, invoking serverless functions, calling AI chat completions or image generation, subscribing to real-time WebSocket channels, sending welcome/newsletter/notification emails via insforge.emails.send, or writing RLS policies. If the user asks for these features generically (e.g., "add auth to my React app", "fetch data from my database", "upload files", "send a welcome email") and you're unsure whether they use InsForge, consult this skill and ask. For backend infrastructure (creating tables via SQL, deploying functions, CLI commands), use insforge-c
Use this skill to generate well-branded interfaces and assets for VibeUsage, either for production or throwaway prototypes/mocks/etc. Contains essential design guidelines, colors, type, fonts, assets, and UI kit components for prototyping.
Use when designing or reviewing a backend MVP with tight budget, evolving schema, and reliance on third-party backends where idempotency, replay, and responsibility attribution are high-risk.
Use when managing Codex review iterations for a PR and you must enforce preflight risk-layer checks and post-merge learning capture.