Turn a repo-local spec, rollout doc, design note, or implementation plan into a compact /goal prompt. Use when the user wants to run Codex /goal from an existing spec-first workflow and needs the goal to preserve scope, non-goals, validations, and local constraints.
Evaluate a repository's first-rung readiness for high-quality AI code contributions and produce concrete, copy-pasteable file changes that make the repo AI-ready. Use when asked to audit AI contribution quality, diagnose why AI PRs are low quality, prepare a repo for AI-assisted engineering, or move a repo from no harness toward a basic v0.5 contribution harness.
Bootstrap a small, deterministic repo-local AI harness by adding only the docs, skills, or checks that have concrete repo-specific content. Use when a repo already has basic AI contribution readiness and the user wants continuous harness improvement without placeholder process.
Evaluate a real AI-assisted work session against the repo-local harness, classify reusable misses, and update or propose updates to docs, skills, scripts, MCP/tooling, or sensors. Use after substantial work, review feedback, failed validation, or human correction in a repo with an AI harness.
Investigate established Pulumi-vs-Terraform parity gaps in bridged providers by creating or refining bridge cross-tests, after routing has already determined that bridge parity work is the next step, or when the user explicitly asks for that help. Use when the agent already knows that Pulumi has the problem and Terraform does not, and the next step is to capture, narrow, and explain that parity gap inside pulumi-terraform-bridge without debating alternate harnesses.
Run Claude Code as a chat-only reviewer for a local diff or branch, including adversarial pressure-testing when requested. Use when the user explicitly wants a Claude second opinion without posting GitHub comments.
Work back and forth with the user to understand intent, success criteria, constraints, and open questions before or during implementation. Use explicitly when the task is fuzzy, high-context, or benefits from shared thinking rather than immediate execution.
Generate a visual local webpage that explains a GitHub PR as a decision and behavior change, not a defect-finding review. Use when the user asks to understand a PR, asks what a PR is doing, wants a walkthrough, wants a plan-review-style assessment, or wants root problem, before/after examples, tradeoffs, compatibility risks, proof gaps, and reviewer questions.