pardes

Write or rewrite concise reviewer-first pull request titles and descriptions for Pardes manager publication. Use approved intent, owner reports, conditional verifier reports, and narrow factual details without filler.

Use when a completed or active Codex coding session should be evaluated as a workflow run, especially to identify where orchestration skills, sub-agent delegation, worktree routing, verification handoffs, PR monitoring, or compaction recovery worked well or caused friction.

Use when a user installs the Codex workstreams plugin, asks to set it up, or sees permission prompts for workstream checkpoints, reports, or temporary pull-request body files.

Use when a coding objective spans multiple workflow phases or pull requests and needs a persistent manager to coordinate investigation, architecture, planning, implementation, verification, PR creation, review feedback, and merge gates across a long-running session.

Use when an approved PR-sized coding goal needs execution through an owner worker and optional supporting workers in manually managed Git worktrees.

Use when a coding task is not understood well enough to choose an implementation direction, including broad feature requests, unfamiliar code paths, bugs with multiple plausible causes, and work that benefits from parallel read-only exploration before architecture or planning.

Use when a verified owner-worker branch is ready to publish, or when an open pull request needs blocking lifecycle management through CI failures, review feedback, conflicts, and merge.

Use when implementation is complete or a PR branch changed after feedback and needs repo-native quality gates, diff review, and a clear readiness decision before publication or another review cycle.

Use when opening or rewriting a pull request and the reviewer needs a concise, truthful explanation of why the change exists, how it works, which decisions matter, and where to look carefully.

Get oriented in the pardes marketplace and tune the user's Claude Code setup. Explains what each plugin does and how they compose, then runs an advisory config doctor that reports recommended settings and applies them only on explicit confirmation. Use when a user is new to the marketplace, asks what these plugins do or how to get set up, or wants their config checked.

Run as the autonomous shift leader of a multi-PR / multi-agent effort — maximize progress, reach the away user only via AskUserQuestion, gate phases on PR merges (never merge yourself), and dispatch file-disjoint parallel worktree agents at high velocity. Use whenever you orchestrate sub-agents or workflows across multiple PRs.

Reusable orchestration shell helpers for keeping a checkout fresh — freshen to a clean baseline, prune merged branches, and reap stale worktrees. Use when advancing local main after a merge or cleaning up after a parallel-worktree wave.

Plan a large multi-chunk PR through a user interview, then ship it by dispatching focused Opus sub-agents one chunk at a time. Use when the work is too big for a single agent context but is sequenceable into discrete commits.

Write a clear, useful PR description — a tight Why / How / Decisions / Callouts structure that tells a reviewer what changed and why, with no filler. Use whenever you open or rewrite a pull request.