Pane

Executes an approved plan with one primary implementation stream by default, using bounded parallel sidecars only when the write scopes are truly disjoint. Supports default Claude execution or an explicit Codex executor option. Automatically reviews the result for completeness and intent fidelity. Use after a plan is approved.

Selectively stages and commits only the changes related to the current session, skipping unrelated modifications.

Executes an approved plan directly in Codex with one primary implementation stream by default, bounded sidecars only when write scopes are truly disjoint, and mandatory review gates for completeness and intent fidelity. Use after a plan is approved.

Review completed code changes against a plan, run quality checks, and call out gaps, regressions, or missing integrations. Use when implementation work needs a plan-based review.

Carry out a structured implementation plan carefully and systematically, following existing repo patterns, preserving intent, and running quality checks as work progresses. Use when a plan already exists and the goal is execution.

Review an implementation plan for repo accuracy, fact purity, intent fidelity, reconciliation quality, and completeness. Use when a plan needs a correctness and completeness pass.

Creates a reconciled implementation plan by combining a structured plan draft with a normalized intent brief and a PRP-style research dossier, then auto-reviews the final plan. Use when planning a new feature or significant change in Codex.

Quick gut-check before implementing when the user directly asks you to do something. Investigates, proposes a lightweight plan, and implements only after approval. Use this instead of `plan` when the change is straightforward.

Selectively stages and commits only the changes related to the current session, skipping unrelated modifications.

Creates a reconciled implementation plan by combining a structured plan draft with a normalized intent brief and a PRP-style research dossier, then auto-reviews the final plan. Use when planning a new feature or significant change.

Have an interactive discussion about a topic, approach, or feature. Researches the codebase as needed, talks through options, and updates ./tmp/context.md with decisions. Use when you want to think through an approach before planning.

Commits changes grouped by done-plans, rebases main, builds API and webapp, then creates or updates a PR. Replaces the commit command. Use when you're ready to open or update a pull request.

Performs a comprehensive PR code review. Reads the linked GitHub issue for context, runs quality checks, and reviews code for bugs, architecture, conventions, and frontend best practices. Posts structured findings as a PR review.

Quick gut-check before implementing when the user directly asks you to do something (e.g. "add X", "fix Y", "change Z"). Investigates, proposes a lightweight plan, and implements after approval. Use this instead of /create-plan when the user wants something done, not a formal plan.

Explore the notetake codebase to locate files, trace behavior, and document existing patterns with precise file references. Use when the task is understanding what exists, not proposing changes.

Have an implementation-focused discussion about a feature, bug, or approach without making code changes. Use when the goal is to think through options before planning or coding.

Investigate a bug or broken behavior through hypothesis-driven root cause analysis and report what is wrong without jumping straight to a fix. Use when something is failing or behaving unexpectedly.

Prepare a branch for review by committing scoped changes, rebasing on main, running builds, and creating or updating a pull request. Use when the user wants the branch ready for PR review.

Perform technical web research using authoritative sources, synthesize the results, and save a cited research note in the repo. Use when external documentation or up-to-date behavior matters.

Research a technical topic using a mix of web sources and local codebase context, then produce actionable guidance with citations. Use when the user wants a thorough research-oriented answer.

After shipping a non-trivial fix, find related GitHub issues across the ecosystem, draft helpful human-sounding comments linking the fix and root cause, and optionally file upstream issues. Drafts must pass as human writing or the user's GitHub reputation suffers. Works on the current session's fix or retroactively on past commits/PRs. Always asks for approval before posting anything public.

Investigates bugs through hypothesis-driven root cause analysis. Automatically invoked when the user reports a bug, error, broken behavior, or something not working as expected. Use when something is broken, failing, or behaving unexpectedly.

Conducts extensive web research on technical topics with validated references and citations. Use when you need external documentation, library comparisons, or best practices research.