waypoint-codex 0.10.1 → 0.10.3

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:
@@ -161,6 +163,8 @@ For planning work, run `plan-reviewer` before presenting a non-trivial implement
 
 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.
 
+When browser-based reproduction or verification is part of the work, Waypoint should also send screenshots of the relevant UI states so the user can see the evidence directly.
+
 ## What makes it different
 
 Waypoint is not trying to hide everything behind hooks and background machinery.

package/package.json

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

package/templates/.agents/skills/break-it-qa/SKILL.md

@@ -118,6 +118,7 @@ Anti-cheating rules:
 - Use `playwright-interactive`.
 - Exercise the actual UI instead of mocking the flow in code.
 - Keep the scope focused on the feature the user asked you to verify.
+- Capture screenshots of the important states you observe so the user can see the evidence directly.
 
 ## Step 7: Try To Break It On Purpose
 
@@ -151,6 +152,7 @@ As you test, keep expanding the break log with new "What if...?" cases that emer
 - Update docs when the verification exposes stale assumptions about how the feature works.
 - Update the break log entry for each attempted action with what happened and whether the feature survived.
 - Require a short observed-result note for every executed item. "Worked" is too weak; capture what actually happened.
+- Save screenshots for the key broken, risky, or fixed states as you go.
 
 Do not stop at the first bug.
 
@@ -174,6 +176,7 @@ Summarize:
 - the path to the break log markdown file
 - how many attack items were recorded and exercised
 - how coverage was distributed across steps and categories
+- which screenshots you captured and what each one shows
 - what break attempts you tried
 - which issues you found
 - what you fixed

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/.waypoint/agent-operating-manual.md

@@ -54,6 +54,9 @@ If something important lives only in your head or in the chat transcript, the re
 - 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.
+- When browser work is part of reproduction or verification, send screenshots of the relevant UI states to the user so they can visually confirm what you observed.
+- Capture the states that matter, such as the broken state, the fixed state, or an important intermediate state that explains the issue.
+- If the current environment cannot provide screenshots, state that explicitly instead of silently omitting visual evidence.
 
 ## Execution autonomy
 
@@ -92,12 +95,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:

package/templates/managed-agents-block.md

@@ -68,6 +68,7 @@ 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.
+When using a browser to reproduce a bug, verify behavior, or confirm that a fix works, send the user screenshots of the relevant UI states so they can see the evidence directly. If screenshots are not possible in the current environment, say so explicitly.
 
 Working rules:
 - Keep `.waypoint/WORKSPACE.md` current as the live execution state, with timestamped new or materially revised entries in multi-topic sections
@@ -77,6 +78,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