waypoint-codex 0.9.9 → 0.10.1

package/README.md

@@ -137,6 +137,7 @@ Waypoint ships a strong default skill pack for real coding work:
 - `docs-sync`
 - `code-guide-audit`
 - `break-it-qa`
+- `conversation-retrospective`
 - `frontend-ship-audit`
 - `backend-ship-audit`
 - `workspace-compress`
@@ -144,7 +145,7 @@ Waypoint ships a strong default skill pack for real coding work:
 - `pr-review`
 
 These are repo-local, so the workflow travels with the project.
-`break-it-qa`, `frontend-ship-audit`, and `backend-ship-audit` are user-invoked audit skills, not default autonomous agent steps.
+`conversation-retrospective`, `break-it-qa`, `frontend-ship-audit`, and `backend-ship-audit` are on-demand skills, not default autonomous agent steps.
 
 ## Reviewer agents
 
@@ -158,6 +159,8 @@ 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. 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
 
 Waypoint is not trying to hide everything behind hooks and background machinery.

package/dist/src/core.js

@@ -383,6 +383,7 @@ export function doctorRepository(projectRoot) {
         "docs-sync",
         "code-guide-audit",
         "break-it-qa",
+        "conversation-retrospective",
         "workspace-compress",
         "pre-pr-hygiene",
         "pr-review",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "0.9.9",
+  "version": "0.10.1",
   "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

@@ -0,0 +1,98 @@
+---
+name: conversation-retrospective
+description: Analyze the active conversation for durable repo knowledge, skill improvements, and repeated workflow patterns. Use when the user asks to save what was learned from the current conversation, update memory/docs without more prompting, improve skills that were used or exposed gaps, or propose new skills based on repetitive work in the live thread.
+---
+
+# Conversation Retrospective
+
+Use this skill to harvest the active conversation into the repo's existing memory system.
+
+This skill works from the live conversation already in context. Do not go hunting through archived session files unless the user explicitly asks for that.
+
+This is a closeout and distillation workflow, not a generic planning pass or a broad docs audit.
+
+## Read First
+
+Before persisting anything:
+
+1. Read the repo's main agent guidance and project-context files
+2. Read the repo's current durable memory surfaces, such as docs, workspace/handoff files, trackers, decision logs, or knowledge files
+3. Read the exact docs, notes, and skill files that the conversation touched
+
+Do not assume the repo uses Waypoint. Adapt to the memory structure that already exists.
+
+## Step 1: Distill Durable Knowledge
+
+Review the current conversation and separate:
+
+- durable project knowledge
+- live execution state
+- transient chatter
+
+Persist without asking follow-up questions when the correct destination is clear.
+
+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
+- the repo's standing guidance file for durable project context or long-lived working rules
+- the repo's live handoff or workspace file for current state, blockers, and immediate next steps
+- the repo's tracker or execution-log layer when the conversation created or materially changed a long-running workstream
+
+If the repo uses doc metadata such as `last_updated`, refresh it when needed.
+
+If the repo has no obvious durable home but the need is clear, create the smallest coherent doc or note that fits the surrounding patterns instead of leaving the learning only in chat.
+
+Do not leave important truths only in chat.
+
+## Step 2: Improve Existing Skills
+
+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 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
+- 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.
+
+Do not assume there is only one skill location, and do not assume there are many.
+
+## Step 3: Propose New Skills
+
+When the conversation revealed repetitive work that existing skills do not cover well:
+
+- do not silently scaffold a new skill unless the user asked for implementation
+- record the proposal in the repo's existing docs or idea-capture layer
+
+If there is no obvious place for durable skill proposals, create a small doc such as `skill-ideas.md` in the repo's normal docs area.
+
+Each proposal should include:
+
+- the repeated workflow or problem
+- likely trigger phrases
+- expected outputs or side effects
+- why existing skills were insufficient
+
+Skip this doc when there is no real new-skill candidate.
+
+## Step 4: Refresh Repo Memory
+
+After changing docs, handoff state, trackers, or skills:
+
+- run whatever repo-local refresh or index step the project uses, if one exists
+- otherwise make sure the edited memory surfaces are internally consistent and discoverable
+
+Do not invent a refresh command when the repo does not have one.
+
+## Step 5: Report
+
+Summarize:
+
+- what durable knowledge you saved and where
+- which skills you improved
+- which new skill ideas you recorded, if any
+- what you intentionally left unpersisted because it was transient
+
+If no substantive persistence changes were needed, say that explicitly instead of inventing updates.

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

@@ -0,0 +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."

package/templates/.agents/skills/planning/SKILL.md

@@ -145,6 +145,7 @@ When the plan doc is written:
 - give a short chat summary
 - include the doc path
 - call out any unresolved decisions that still need the user's input
+- if there are no unresolved decisions and the user approves the plan, treat that approval as authorization to execute the plan end to end rather than asking again at each obvious next step
 
 ## Quality Bar
 

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

@@ -10,8 +10,11 @@ Use this skill to drive the PR through review instead of treating review as a on
 ## Step 1: Wait For Review To Settle
 
 - Check the PR's current review and CI status.
+- If CI is red or pending, inspect the failed check logs before triaging review comments so you do not chase comment fixes while a separate blocker is breaking the branch.
 - 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
 
@@ -26,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.
 
@@ -33,10 +38,14 @@ Do not leave comments unanswered.
 
 - Make the needed fixes.
 - 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/.gitignore.snippet

@@ -12,6 +12,7 @@
 .agents/skills/backend-context-interview/
 .agents/skills/frontend-ship-audit/
 .agents/skills/backend-ship-audit/
+.agents/skills/conversation-retrospective/
 .agents/skills/workspace-compress/
 .agents/skills/pre-pr-hygiene/
 .agents/skills/pr-review/

package/templates/.waypoint/SOUL.md

@@ -20,6 +20,10 @@ You're direct, opinionated, and evidence-driven. You read before you write. You
 
 **Correctness beats theater.** No fake verification. No fake confidence. No pretending a shallow answer is good enough.
 
+**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

@@ -43,13 +43,35 @@ If something important lives only in your head or in the chat transcript, the re
 
 - Read code before editing it.
 - Follow the repo's documented patterns when they are healthy.
+- If the user approves a plan or explicitly tells you to proceed, treat that as authorization to finish the approved work end to end.
 - Update `.waypoint/WORKSPACE.md` as live execution state when progress meaningfully changes. In multi-topic sections, prefix new or materially revised bullets with a local timestamp like `[2026-03-06 20:10 PST]`.
 - For large multi-step work, create or update a tracker in `.waypoint/track/`, keep detailed execution state there, and point at it from `## Active Trackers` in `.waypoint/WORKSPACE.md`.
 - Update `.waypoint/docs/` when durable knowledge changes, and refresh each changed routable doc's `last_updated` field.
 - 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
+
+Once the user has approved a plan or otherwise told you to continue, own the work until the slice is genuinely complete.
+
+That means:
+
+- continue through implementation, verification, reviewer passes, and required docs/workspace updates without asking for incremental permission
+- use commentary for short progress updates, not as a handoff back to the user
+- do not stop just to announce the next obvious step and ask whether to do it
+
+Pause only when:
+
+- a real blocker prevents forward progress
+- a hidden-risk or non-obvious decision would materially change scope, behavior, cost, or data safety
+- the user explicitly redirects, pauses, or narrows the work
+
+If none of those are true, keep going.
 
 ## Documentation expectations
 
@@ -102,7 +124,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

@@ -66,6 +66,9 @@ 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
 - For large multi-step work, create or update `.waypoint/track/<slug>.md`, keep detailed execution state there, and point to it from `## Active Trackers` in `.waypoint/WORKSPACE.md`
@@ -81,4 +84,5 @@ Working rules:
 - Before pushing or opening/updating a PR for substantial work, use `pre-pr-hygiene`
 - Use `pr-review` once a PR has active review comments or automated review in progress
 - Treat the generated context bundle as required session bootstrap, not optional reference material
+- After plan approval, own the execution through implementation, verification, review, and repo-memory updates before surfacing a final completion report
 <!-- waypoint:end -->