waypoint-codex 1.1.1 → 1.1.3

package/dist/src/core.js

@@ -357,6 +357,8 @@ export function initRepository(projectRoot, options) {
         ".agents/skills/waypoint-explore",
         ".agents/skills/waypoint-research",
         ".agents/skills/visual-explanations",
+        ".agents/skills/execution-reset",
+        ".agents/skills/plan-start",
         ".agents/skills/work-tracker",
         ".agents/skills/docs-sync",
         ".agents/skills/break-it-qa",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "1.1.1",
+  "version": "1.1.3",
   "description": "Make Codex better by default with stronger planning, code quality, reviews, tracking, and repo guidance.",
   "license": "MIT",
   "type": "module",

package/templates/.agents/skills/pr-review/SKILL.md

@@ -20,6 +20,8 @@ Run this loop until exit criteria are satisfied.
 1. Load PR state:
 - collect all current review threads and comments, including existing comments present before the skill started
 - collect CI/CD status for required checks
+- for each reviewer (`Codex`, `CodeRabbit`), identify only that reviewer's latest top-level PR comment as the source of truth for the current reviewer state
+- do not bind Codex parsing to one exact phrase; use author identity plus the latest comment/findings content (including explicit "no meaningful issues" style outcomes)
 
 2. Triage and act:
 - classify each reviewer finding as either major (`P1+`) or minor/nitpick
@@ -27,21 +29,31 @@ Run this loop until exit criteria are satisfied.
 - fix all non-false-positive major (`P1+`) findings in code/docs/tests
 - minor/nitpick findings may be accepted without code changes, but must still be replied to inline and resolved
 - if CI/CD has failures, fix those failures as part of the same loop
+- for CodeRabbit state handling:
+- if latest CodeRabbit comment is `Actions performed -> Review triggered`, treat CodeRabbit as `pending` and wait for its next latest comment before triaging CodeRabbit findings
+- do not use CodeRabbit CI/CD or check-run status as reviewer truth; comments are authoritative
 
 3. Thread discipline for every addressed or skipped finding:
 - post an inline reply on that thread explaining the fix or why it is a false positive
 - resolve the thread after replying
 
-4. Push and re-request automated review:
+4. Push and request reviewer-specific re-review only when needed:
 - push commits
-- post comment: `@coderabbitai review`
-- post comment: `@codex review`
+- determine which reviewer findings were addressed this round:
+- if Codex findings were addressed, post comment: `@codex review`
+- if CodeRabbit findings were addressed, post comment: `@coderabbitai review`
+- if both were addressed, post both comments
+- if neither reviewer's findings were addressed, do not trigger either reviewer
 
 5. Wait for review/check updates:
 - wait up to 30 minutes total
 - check every 5 minutes using a sleep interval (`sleep 300`)
 - on each check, re-read both review and CI/CD status
 - if major (`P1+`) findings or CI/CD failures appear, continue the loop immediately
+- when both reviewers' latest completed comments (not pending triggers) contain no major (`P1+`) findings, enter terminal cleanup mode:
+- fix and resolve that round's remaining findings
+- push commits if needed
+- do not post any further `@codex review` or `@coderabbitai review` comments
 
 ## Exit Criteria
 
@@ -51,12 +63,16 @@ You may end the loop only when all are true:
 - no unresolved major (`P1+`) Codex findings remain
 - every addressed or skipped finding has an inline reply and is resolved
 - CI/CD is green (or explicitly non-blocking per repo policy)
-- the latest reviewer rounds contain only nitpicks/minor issues (no major `P1+` issues)
+- the latest completed reviewer comments from both bots contain only nitpicks/minor issues (no major `P1+` issues)
+- terminal cleanup mode has been completed (remaining minor/nitpick findings handled, with no retrigger afterward)
 
 ## Required Behavior
 
 - Do not ignore existing comments that were already open when the skill was invoked.
 - Do not stop after one pass if reviewer bots are still producing new findings.
+- Distinguish reviewer ownership of findings and retrigger only the reviewer whose findings were addressed.
+- Use each reviewer's latest comment as reviewer truth; do not infer reviewer completion from CodeRabbit CI/CD status.
+- Treat CodeRabbit `Actions performed -> Review triggered` as pending review, not as final findings.
 - Do not mark false positives without a concrete reason in the inline reply.
 - Do not leave handled threads unresolved.
 - Do not declare completion while CI/CD is failing for actionable reasons.

package/templates/.agents/skills/pr-review/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "PR Review"
   short_description: "Close the review loop with CodeRabbit, Codex, and CI/CD"
-  default_prompt: "Use $pr-review: address all existing PR review findings, fix actionable CI/CD failures, reply inline and resolve each handled thread, push fixes, comment '@coderabbitai review' and '@codex review', then poll every 5 minutes for up to 30 minutes per round until no major (P1+) issues remain and latest comments are only minor or nitpicks."
+  default_prompt: "Use $pr-review: address all existing PR review findings, fix actionable CI/CD failures, reply inline and resolve each handled thread, and request re-review per reviewer ownership (`@codex review` only if Codex findings were addressed, `@coderabbitai review` only if CodeRabbit findings were addressed). Treat each reviewer's latest comment as source of truth (CodeRabbit `Actions performed -> Review triggered` means pending); for Codex, do not key detection to one exact phrase, use latest authored comment/findings content. When both reviewers' latest completed comments have no major (P1+) findings, do one terminal cleanup pass and do not retrigger either reviewer."

package/templates/.agents/skills/execution-reset/SKILL.md

@@ -1,92 +0,0 @@
----
-name: execution-reset
-description: Recover stalled mid-execution work on a referenced implementation plan when progress has degraded into local edits, repeated patching, or phase drift. Use only after a phase has already started and the current session is no longer advancing a concrete milestone. Reconstruct actual progress from the codebase, test for a stall, and select the next substantial work package that advances or completes the active phase.
----
-
-## Core Instruction
-Reset execution from evidence, not memory, when an in-progress phase has stalled and the next meaningful unit of work is unclear.
-
-## Required Inputs
-You must have all of the following before you act:
-1. A referenced plan or roadmap.
-2. The active phase or checkpoint within that plan.
-3. The relevant workspace or codebase context needed to inspect current state.
-
-## Blocked Behavior
-If any required input is missing, do not infer it, do not continue, and do not propose a reset package.
-State exactly which input is missing and request it.
-
-## Trigger Boundary
-Use this skill only when:
-1. Work on the current phase has already started.
-2. The current session is not advancing the phase toward completion.
-3. The problem is execution drift, not plan creation, backlog grooming, or initial scoping.
-
-Do not use this skill at plan start or for ordinary planning questions.
-
-## Stall Test
-Treat execution as stalled when inspection shows at least one of the following:
-- Three consecutive implementation attempts have changed files or run checks without moving any acceptance condition from missing or partial to complete.
-- The same local area has been patched twice or more in the current phase without producing a measurable milestone change.
-- The current state is still partial, broken, or stale after a review of the codebase, and no next step can be named that clearly advances the phase end-to-end.
-- Progress is limited to micro-edits, reformatting, or cleanup that does not change the phase outcome.
-
-The stall test is objective: if none of the conditions above hold, do not declare a reset.
-
-## Workflow
-1. Identify the active phase and its intended outcome from the plan.
-2. Inspect the codebase and classify the phase state as complete, partial, missing, or broken/stale.
-3. Apply the stall test.
-4. If stalled, restate the phase as concrete system behavior and identify one work package that will complete a sub-milestone, unblock the main dependency, or complete the end-to-end path.
-5. Execute only that work package.
-6. Re-check whether the change moved at least one acceptance condition from missing or partial to complete.
-
-## Rules
-- Do not continue with micro-edits unless they directly unblock the selected work package.
-- Do not polish incomplete phases.
-- Do not trust prior session context over the codebase.
-- Do not select more than one work package per reset cycle.
-- Do not expand scope to adjacent cleanup unless it is required for the chosen package to finish.
-
-## Exception Rule
-You may relax the stall test only when the workspace evidence shows a phase-critical blocker outside the current code path, such as a missing prerequisite, unavailable dependency, or an upstream change that makes the current plan invalid. This exception is bounded:
-- The blocker must be named.
-- The blocker must be evidenced in the inspected state.
-- The response must switch to blocker resolution, not continued execution.
-
-## Stop Condition
-Stop the reset cycle immediately when one of these is true:
-- The selected package cannot be executed because a required input is still missing.
-- The selected package fails to move at least one acceptance condition from missing or partial to complete after a concrete attempt.
-- The inspected codebase shows the phase is no longer the right unit of work.
-
-## Next Action If Reset Package Fails
-If the chosen package fails, do not chain into a second package. Report the blocker, the evidence, and the smallest next question or dependency needed to continue.
-
-## Output Contract
-Use this shape:
-
-### Execution Reset
-### Active Phase
-[phase]
-
-### Objective
-[what this phase must accomplish]
-
-### Actual Status
-- Complete: [...]
-- Partial: [...]
-- Missing: [...]
-- Broken/stale: [...]
-
-### Stall Diagnosis
-[why the stall test passed, or why it did not]
-
-### Next Work Package
-[one substantial chunk, or the blocker if execution is stopped]
-
-### Definition of Done
-[concrete completion conditions for the package]
-
-### Plan Correction
-[only if the plan is locally stale]

package/templates/.agents/skills/execution-reset/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Execution Reset"
-  short_description: "Recover stalled mid-execution work on an active plan phase"
-  default_prompt: "Use $execution-reset only after a plan phase has already started and execution has stalled; provide the referenced plan, the active phase, and the relevant workspace context so the skill can inspect current state, test for a stall, and pick one substantial next work package."

package/templates/.agents/skills/plan-start/SKILL.md

@@ -1,79 +0,0 @@
----
-name: plan-start
-description: Bootstrap a fresh session onto an existing implementation plan. Use when a referenced plan already exists, execution has not meaningfully started in the current session, and Codex needs to reconstruct the active phase from the plan plus current repository state before beginning the first substantial work package.
----
-
-# Plan Start
-
-## Core Instruction
-Convert a referenced plan into the first executable work package for a fresh session.
-
-## Trigger Boundary
-Use this skill when:
-- a durable plan, roadmap, or phase list already exists
-- the current session has not yet become a stalled execution loop
-- the task is to re-enter the plan, recover the active phase, and begin substantive work
-
-Do not use this skill when:
-- the session is already mid-execution and progress has degraded into micro-edits, repeated patching, or phase drift
-- the current problem is recovering momentum on a stuck phase
-- the request is to revise the plan itself before execution can begin
-
-In those cases, route to:
-- `$execution-reset` for stalled or compacted plan execution
-- `$planning` when the plan is missing, non-durable, or too underspecified to execute
-
-## Required Inputs
-Do not proceed until you have:
-- a plan path, plan identifier, or equivalent durable plan reference
-- the current repository/worktree state relevant to that plan
-- enough current context to tell whether the referenced plan is still actionable
-
-If any required input is missing, stop and route to `$planning` or ask for the missing reference instead of guessing.
-
-## Workflow
-1. Read the referenced plan end to end.
-2. Inspect the current repository state relevant to the plan.
-3. Determine:
-   - which phases are complete
-   - which phase is active
-   - what remains inside the active phase
-4. Restate the active phase as concrete system behavior.
-5. Select the first substantial work package that most directly advances that phase.
-6. Begin execution on that package.
-
-## Rules
-- Do not re-plan the whole project unless the referenced plan is locally stale.
-- Do not use this skill to recover from a stalled session; that is `$execution-reset`.
-- Do not spend the session on summaries, narration, or cosmetic cleanup when a substantive work package is available.
-- Do not choose a micro-edit as the first move unless it is the smallest change that unblocks the first substantial package.
-- Select the work package that most directly advances the active phase.
-
-## Bounded Exception
-If the plan is locally stale, allow one bounded re-anchoring pass:
-- reconcile the active phase against the current codebase
-- update the phase boundary only as needed to make execution possible
-- do not rewrite the whole roadmap
-
-If the plan still cannot be executed after that pass, stop and route to `$planning`.
-
-## Output Contract
-### Normal
-Return:
-- `Active Phase`
-- `Objective`
-- `Current State`
-- `First Work Package`
-- `Definition of Done`
-
-### Blocked
-Return `Blocked` when required inputs are missing or the plan cannot be safely actioned yet. Include:
-- what is missing
-- why execution cannot start
-- the exact reroute target: `$planning` or `$execution-reset`
-
-### Reroute
-Return `Reroute` when the request belongs to another skill. Include:
-- `Reroute Target`
-- `Reason`
-- the minimal handoff needed to continue

package/templates/.agents/skills/plan-start/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Plan Start"
-  short_description: "Bootstrap a fresh session onto an existing implementation plan"
-  default_prompt: "Use $plan-start when a durable implementation plan already exists and this is a fresh-session bootstrap, not a stalled execution recovery. Read the plan, inspect the current repo state, identify the active phase, pick the first substantial work package, and begin execution. If the plan is missing or underspecified, route to $planning; if the session is already stalled, route to $execution-reset."