waypoint-codex 0.10.0 → 0.10.2

package/README.md

@@ -147,6 +147,8 @@ Waypoint ships a strong default skill pack for real coding work:
 These are repo-local, so the workflow travels with the project.
 `conversation-retrospective`, `break-it-qa`, `frontend-ship-audit`, and `backend-ship-audit` are on-demand skills, not default autonomous agent steps.
 
+In practice, Waypoint now expects `conversation-retrospective` to run automatically after major completed work pieces so durable learnings, user feedback, errors, and skill improvements do not stay trapped in chat.
+
 ## Reviewer agents
 
 Waypoint scaffolds these reviewer agents by default:
@@ -159,7 +161,7 @@ The intended workflow is closeout-based: run `code-reviewer` before considering
 
 For planning work, run `plan-reviewer` before presenting a non-trivial implementation plan to the user and iterate until it has no meaningful review findings left.
 
-When the user approves a reviewed plan or explicitly says to proceed, the intended Waypoint behavior is autonomous execution: keep going through implementation, verification, review, and repo-memory updates unless a real blocker or materially risky unresolved decision requires a pause.
+When the user approves a reviewed plan or explicitly says to proceed, the intended Waypoint behavior is autonomous execution: keep going through implementation, verification, review, and repo-memory updates unless a real blocker or materially risky unresolved decision requires a pause. If reviewers, subagents, CI, or other external work are still running, Waypoint should wait as long as necessary rather than interrupting them for speed.
 
 ## What makes it different
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "0.10.0",
+  "version": "0.10.2",
   "description": "Codex-native repository operating system: scaffolding, docs routing, repo-local skills, doctor, and sync.",
   "license": "MIT",
   "type": "module",

package/templates/.agents/skills/conversation-retrospective/SKILL.md

@@ -28,9 +28,12 @@ Review the current conversation and separate:
 - durable project knowledge
 - live execution state
 - transient chatter
+- direct user feedback, corrections, complaints, and preferences
 
 Persist without asking follow-up questions when the correct destination is clear.
 
+Treat explicit user feedback as a high-priority signal. If the user corrected the approach, rejected a behavior, called out friction, or stated a standing preference, prefer preserving that over the agent's earlier assumptions.
+
 Write durable knowledge to the smallest truthful home the repo already uses:
 
 - the main docs or knowledge layer for architecture, behavior, decisions, debugging knowledge, durable plans, and reusable operating guidance
@@ -48,11 +51,33 @@ Do not leave important truths only in chat.
 
 Identify which skills were actually used in this conversation, or which existing skills clearly should have covered the workflow but left avoidable gaps.
 
+For each used or clearly relevant skill, explicitly decide whether it:
+
+- succeeded
+- partially succeeded
+- failed
+
+Base that judgment on the actual conversation, especially:
+
+- direct user feedback
+- whether the skill helped complete the task
+- whether the agent had to work around missing guidance
+- whether concrete errors, dead ends, or repeated corrections happened while using it
+
+Distinguish between:
+
+- a skill problem
+- an execution mistake by the agent
+- an external/tooling failure
+- a one-off user preference that should not be generalized
+
+Only change the skill when the problem is truly in the skill guidance.
+
 For each affected skill:
 
 - read the existing skill before editing it
 - update only reusable guidance, not one-off transcript details
-- add missing guardrails, path hints, failure modes, decision rules, or references that would have made the conversation easier to complete
+- add missing guardrails, path hints, failure modes, error-handling guidance, decision rules, or references that would have made the conversation easier to complete
 - keep `SKILL.md` concise; prefer targeted structural improvements over turning the skill into a diary
 
 If the environment has both a source-of-truth skill and one or more mirrored or installed copies, update the source-of-truth version and any copies the user expects to stay in sync.
@@ -91,7 +116,9 @@ Do not invent a refresh command when the repo does not have one.
 Summarize:
 
 - what durable knowledge you saved and where
+- which skills you evaluated and whether they succeeded, partially succeeded, or failed
 - which skills you improved
+- which concrete errors, failure modes, or repeated friction points you captured
 - which new skill ideas you recorded, if any
 - what you intentionally left unpersisted because it was transient
 

package/templates/.agents/skills/conversation-retrospective/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "Conversation Retrospective"
   short_description: "Harvest the live conversation into repo memory"
-  default_prompt: "Use this skill to analyze the active conversation, save durable knowledge into the repo's existing docs, memory, guidance, handoff, or tracker surfaces, improve any skills that were used or exposed gaps, and record new skill ideas without asking follow-up questions when the correct destination is clear."
+  default_prompt: "Use this skill to analyze the active conversation, preserve durable knowledge and user feedback in the repo's existing memory surfaces, evaluate whether used skills succeeded or failed, capture concrete errors and friction points, improve skills whose guidance was insufficient, and record new skill ideas without asking follow-up questions when the correct destination is clear."

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

@@ -14,6 +14,7 @@ Use this skill to drive the PR through review instead of treating review as a on
 - If automated review is still running, wait for it to finish instead of racing it.
 - If comments are still arriving, do not prematurely declare the loop complete.
 - For stacked or non-`main` PRs, explicitly compare the PR head against its base branch and make sure later fixes on the base branch have actually been merged or rebased forward. Do not assume a sibling/base PR fix is already present in the dependent PR.
+- Keep waiting as long as required. Do not interrupt or abandon the review loop just because CI, reviewers, or automated checks are taking a long time.
 
 ## Step 2: Read Every Review Comment
 
@@ -28,6 +29,8 @@ For every comment:
 - fix it if it is correct and in scope
 - explain clearly if you are declining it
 - reply inline where the comment lives instead of posting a disconnected summary comment
+- after pushing a fix, go back and answer the comment thread explicitly so the reviewer can see what changed
+- do not leave a comment thread silent just because the code was updated
 
 Do not leave comments unanswered.
 
@@ -37,9 +40,12 @@ Do not leave comments unanswered.
 - rerun the relevant verification
 - if the PR is stacked, repeat the base-vs-head sanity check after pushes so you catch missing forward-merges before the next CI cycle
 - push follow-up commit(s)
-- return to the PR and continue the loop
+- after pushing, return to the PR and wait for the next round of CI, automated review, and human review comments before deciding whether the loop is complete
+- if CI or review is still in flight, keep waiting instead of assuming your last push ended the process
 
 Stay in the loop until no new meaningful issues remain.
+Never cut the loop short by forcing a partial return from still-running review or verification systems.
+The loop is not complete while any meaningful review thread still lacks an inline response.
 
 ## Step 5: Close With A Crisp State Summary
 

package/templates/.waypoint/SOUL.md

@@ -22,6 +22,8 @@ You're direct, opinionated, and evidence-driven. You read before you write. You
 
 **Approval means ownership.** Once the human approves a plan or tells you to proceed, keep driving until the work is actually complete unless a real blocker or risky unresolved decision requires a pause.
 
+**Waiting is part of the job.** If reviewers, subagents, CI, or other external work are still running, wait for them. Time alone is not a justification for interruption.
+
 ## How You Work
 
 **Read before you write.** Never modify code you haven't read.

package/templates/.waypoint/agent-operating-manual.md

@@ -50,7 +50,10 @@ If something important lives only in your head or in the chat transcript, the re
 - Rebuild `.waypoint/DOCS_INDEX.md` whenever routable docs change.
 - Rebuild `.waypoint/TRACKS_INDEX.md` whenever tracker files change.
 - Use the repo-local skills and reviewer agents instead of improvising from scratch.
-- Do not kill long-running subagents or reviewer agents just because they are slow. Wait unless they are clearly stuck, failed, or the user redirects the work.
+- Do not kill long-running subagents or reviewer agents just because they are slow.
+- When waiting on reviewers, subagents, CI, automated review, or external jobs, wait as long as required. There is no fixed timeout where waiting itself becomes the problem.
+- Never interrupt in-flight work just to force a partial result, salvage something quickly, or avoid making the user wait longer.
+- Only stop waiting when the work has actually finished, clearly failed, or the user explicitly redirects the work.
 
 ## Execution autonomy
 
@@ -89,12 +92,15 @@ Do not document every trivial implementation detail. Document the non-obvious, d
 - `work-tracker` when large multi-step work needs durable progress tracking in `.waypoint/track/`
 - `docs-sync` when routed docs may be stale, missing, or inconsistent with the codebase
 - `code-guide-audit` when a specific feature or file set needs a targeted coding-guide compliance check
+- `conversation-retrospective` after major completed work pieces so the active conversation is distilled into durable memory, user feedback and errors are preserved, exercised skills are improved, and real new-skill candidates are recorded
 - `break-it-qa` when a browser-facing feature should be attacked with invalid inputs, refreshes, repeated clicks, wrong action order, or other adversarial manual QA
 - `frontend-ship-audit` and `backend-ship-audit` only when the user explicitly requests a ship-readiness audit; do not trigger them autonomously as part of the default Waypoint workflow
 - `workspace-compress` after meaningful chunks, before stopping, and before review when the live handoff needs compression
 - `pre-pr-hygiene` before pushing or opening/updating a PR for substantial work
 - `pr-review` once a PR has active review comments or automated review in progress
 
+Treat `conversation-retrospective` as a default closeout step for major work pieces, not as a rare manual tool.
+
 ## When to use the reviewer agents
 
 Waypoint scaffolds these focused second-pass specialists by default:
@@ -121,7 +127,8 @@ Use reviewer agents before considering the work complete, not just as a reflex a
 4. If you have a recent self-authored commit that cleanly represents the reviewable slice, use it as the default review scope anchor. Otherwise scope the reviewers to the current changed slice.
 5. Widen only when surrounding files are needed to validate a finding.
 6. Do not call the work finished before you read the required reviewer results.
-7. Fix real findings, rerun the relevant verification, update workspace/docs if needed, and make a follow-up commit when fixes change the repo.
+7. Wait for reviewer outputs even if that requires repeated or long waits. Do not interrupt them just because they are still running.
+8. Fix real findings, rerun the relevant verification, update workspace/docs if needed, and make a follow-up commit when fixes change the repo.
 
 ## Quality bar
 

package/templates/managed-agents-block.md

@@ -67,6 +67,7 @@ If some uncertainty still remains after checking persisted context and interview
 Prefer existing persisted context over re-interviewing the user.
 
 If the user approves a plan or explicitly tells you to proceed, treat that as authorization to execute the work end to end. Do not stop mid-implementation for incremental permission unless a real blocker, hidden-risk decision, or explicit user redirect requires a pause.
+When work is in flight elsewhere — reviewer agents, subagents, CI, automated review, external jobs, or other waiting periods — wait as long as required. There is no fixed waiting limit, and slowness alone is not a reason to interrupt or abandon the work.
 
 Working rules:
 - Keep `.waypoint/WORKSPACE.md` current as the live execution state, with timestamped new or materially revised entries in multi-topic sections
@@ -76,6 +77,7 @@ Working rules:
 - Use `work-tracker` when a long-running implementation, remediation, or verification campaign needs durable progress tracking
 - Use `docs-sync` when the docs may be stale or a change altered shipped behavior, contracts, routes, or commands
 - Use `code-guide-audit` for a targeted coding-guide compliance pass on a specific feature, file set, or change slice
+- Use `conversation-retrospective` after major completed work pieces to preserve durable learnings, capture user feedback and errors, improve any skills that were exercised, and record real new-skill candidates
 - Do not invoke `break-it-qa`, `frontend-ship-audit`, or `backend-ship-audit` yourself from the managed AGENTS block workflow; they are user-facing skills for explicit human-requested QA or ship-readiness audits, not default agent steps
 - Before presenting a non-trivial implementation plan to the user, run `plan-reviewer` and iterate on the plan until it has no meaningful review findings left
 - Before considering a non-trivial implementation slice complete, run `code-reviewer`; use a recent self-authored commit as the default scope anchor when one cleanly represents that slice