Software Development Skills

Before starting a large-scale redesign (10+ PRs that rewrite shared files like templates, base layouts, or central views), audit ALL unmerged feature branches for commits that touch the same files. Use when: (1) the user asks for a multi-PR redesign / restructure / migration, (2) the worktree is at the top of main but other long-running branches exist with active work, (3) the redesign will replace files wholesale (template rewrites, route extractions, base.css migrations), (4) the project has a multi-branch flow (one main per client/deployment, e.g. main + starbucks-uk + feature/whitelabel-X). Symptom of having skipped this audit: hours after the redesign ships, cherry-picking the parallel branch's work into main produces a head-on conflict on the rewritten file (often progress.html / report.html / a base template), and the parallel branch's a11y / safety / hotfix commits are stranded — they must be hand-merged into the new markup rather than cleanly cherry-picked. Sister to pre-merge-client-variant-regression-audit (audits a variant branch BEING merged into main; this skill audits BEFORE main diverges from a variant). Different from parallel-pr-scope-overlap-tiebreaker-delta-check (which is about two PRs targeting the same scope simultaneously — this is about a redesign on main vs WIP on an unrelated long-running branch).

Run an overnight autonomous B-vs-C parallel insight-discovery workflow that surfaces ah-ha findings from data for a client. Use when: (1) a client wants interesting or surprising insights (not just monitoring or action items); (2) you want to hedge LLM creativity against deterministic rigor by running two tracks in parallel and consolidating; (3) the work fits an 8-hour autonomous window with review-panel gates; (4) the underlying data supports both exploratory querying and mechanical candidate scans. Specializes overnight-review-client-delivery for INSIGHT DISCOVERY rather than deliverable polishing — the two are sister skills with different problem shapes. ALWAYS use this skill when the user asks for "ah-ha insights", "surprise patterns", "funnel leaks", "hidden findings", "overnight analysis to surface X", or wants a dual-approach (creative + mechanical) for client-facing insight work — even if they don't explicitly name the pattern. NOT for: synchronous analysis (use exploratory- data-analysis), single-track LLM exploration (use deep-research), or work that needs user input mid-stream.

Run an overnight autonomous workflow that takes a cluster of related GitHub issues (typically a P1 review-panel finding set) and ships them to merged PRs by morning. Use when: (1) the user wants 6-15 related issues closed in one autonomous run, (2) the issues split naturally into two PRs (e.g., hardening + features, or refactor + new-functionality), (3) the user is going to sleep and won't be available to merge PR1 between phases, (4) each issue has clear acceptance criteria so each task can be implemented + tested + reviewed independently. Specializes superpowers:subagent-driven- development for the "issues -> stacked PRs by morning" problem shape: stacks PR2 on PR1's branch (so PR2 doesn't wait for human PR1-merge mid- night), audits tracker IDs against main before claiming (concurrent sessions steal ids), runs final code-review subagent before proposing merge, and surfaces important findings as PR comments before squashing (so review trail survives). Sister plugin to overnight-review-client- delivery (deliverable polishing) and overnight-insight-discovery (ah-ha pattern surfacing) — different problem shape, same overnight- autonomous philosophy + multi-agent review-panel discipline. ALWAYS use this skill when the user says "implement these issues overnight", "ship N–M autonomously", "wake up to merged PRs", "two-PR overnight plan", or wants a stacked-PR autonomous run from an issue cluster. NOT for: synchronous single-PR work (use plain subagent-driven- development), polishing an existing deliverable (use overnight-review- client-delivery), or generating insights from data (use overnight- insight-discovery).

Run an overnight autonomous work session that produces a client delivery package the next morning, with a multi-agent review panel built in to catch factual errors before they reach the client. Use when: (1) you have client deliverables that need polishing/regenerating before a morning hand-off, (2) you want a thorough quality gate without blocking on synchronous review, (3) the work scope is bounded enough to fit in 1-3 hours of agent time, (4) you want to maximise agent throughput by running content work and review agents in parallel. Implements the Phase A (content work in foreground) / Phase B (8-agent review panel in parallel background) / Phase C (morning synthesis + user hand-off) structure validated on the a causal-impact project, including the locked-file escape hatch discipline for surgical P0 fixes, the "regenerate don't banner" rule for stale content refreshes, and parallel-agent branch hygiene to avoid silent commit drops. NOT for: synchronous code review (use ce:review or claude-code-guide instead), single-task overnight automation (use scheduled-tasks or cron), or work that requires user input mid-stream.

Overnight specialization of code-reviewer-subagent-no-bash-blocked-on-pr-diff (the general tool-gap mechanism). In an UNATTENDED overnight review panel, a reviewer that couldn't see the code reads as a CLEAN one — so a real bug ships by morning. The usual cause: code-review subagents (feature-dev:code-reviewer, voltagent-, Explore) are frequently provisioned WITHOUT a Bash tool, so when prompted to "review PR N, fetch the diff with gh pr diff" they return a BLOCKED report (no review performed), or silently review the current checkout (often main, which predates the PR). Use when: (1) an overnight review panel (e.g. overnight-multi-issue-implementation Phase C, or any agent-review-panel run) dispatches reviewers against GitHub PRs or branches not checked out in the working tree; (2) a reviewer returns "I have no shell/gh/git tool" or "the PR sources are not in the working tree"; (3) one reviewer in a parallel panel comes back BLOCKED while siblings succeeded. Fix: pre-generate per-base diffs to files, materialize PR branches as worktrees, hand each reviewer explicit paths, and in the morning synthesis treat BLOCKED as not-clean (re-dispatch before counting the vote). Sibling to voltagent-reviewer-no-write-tool (Write gap → inline output) and stacked-pr-review-per-base-diff-and-attach.

Fire-ASAP orchestrator pattern for multi-track autonomous workflows dispatched via scheduled triggers (RemoteTrigger / CronCreate) rather than in-session agents. Use when: (1) a multi-track overnight workflow's orchestrator trigger has a fixed t+Nh timer that wastes wallclock when tracks finish early, (2) an overnight run should run consolidation/merge AS SOON AS all parallel tracks report complete, not on a clock, (3) the parent orchestrator session is too context-heavy to stay alive 12-20h and needs a scheduled successor to pick up track outputs, (4) you're choosing between "fire all tracks + one fixed-timer consolidator" vs "fire tracks + self-rescheduling polling consolidator". The polling pattern replaces a fixed wait with a cheap re-schedule loop that exits to consolidation at the first poll where all tracks report phase: complete. Distinct from successor-handoff (in-session parent polling a subagent) — this is for scheduled-trigger orchestrators that need to survive session ends.

Calibrate review intensity per-PR when orchestrating a long chain (10+ PRs) of independent tasks overnight from a single implementation plan. Use when: (1) running superpowers:subagent-driven-development against a plan that produces many independent PRs (not stacked PRs from an issue cluster — for that shape use overnight-multi-issue-implementation), (2) user has authorized auto-merge on green review, (3) the user is asleep / unavailable to merge between tasks, (4) the chain spans multiple risk tiers (some PRs rewrite views/handlers, others restyle CSS only). The skill prescribes three review tiers — full two-stage / combined single-agent / bash-only verification — and a decision rubric for picking the right tier per PR to maximize overnight throughput WITHOUT silently approving real bugs. Sister to subagent-driven-development (specializes its review step for throughput-tuned chains) and overnight-multi-issue-implementation (different problem shape — issues vs. plan tasks; stacked vs. independent). Symptom of having ignored this: orchestrator dispatches 14 × 2 = 28 review subagents in one session when 14 × 1 + 5 × 0 would have caught the same bugs in half the wall time.