waypoint-codex 0.10.8 → 0.10.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -71,11 +71,24 @@ When work is in flight elsewhere — reviewer agents, subagents, CI, automated r
|
|
|
71
71
|
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.
|
|
72
72
|
When an explanation would be clearer as a visual than as prose, bias toward visual artifacts. Prefer Mermaid diagrams directly in chat for flows, architecture, state, and plans; use `visual-explanations` for richer generated images and for annotated screenshots that call out concrete UI states.
|
|
73
73
|
|
|
74
|
+
Delivery expectations:
|
|
75
|
+
- Before you start, decide what "done" means for the task. Set your own finish line and use it as your checklist while you work.
|
|
76
|
+
- When you report back to the user, explain the result in plain, direct language. Say what you changed, what happened, and anything the user actually needs to know, but do not lean on jargon, low-level implementation detail, or code-heavy narration unless the user asks for it.
|
|
77
|
+
- Write for a smart person who is not looking at the code. The goal is clarity, not technical performance.
|
|
78
|
+
- This communication rule applies to how you explain the work, not to how you do it. Your actual reasoning, coding, debugging, and verification should stay technical, precise, and rigorous.
|
|
79
|
+
- Before you say the work is complete, verify it yourself whenever you reasonably can with the tools available in the environment.
|
|
80
|
+
- Match the verification to the task. Run code and inspect real output for scripts and backend changes. Click through flows, inspect rendered states, and check behavior in the browser for visual or interactive work.
|
|
81
|
+
- Use representative or real inputs when practical instead of toy examples, so the check tells you something meaningful about the actual request.
|
|
82
|
+
- If there are realistic edge cases, failure modes, or recovery paths you can exercise without turning the task into a science project, do that too.
|
|
83
|
+
- If something looks wrong, incomplete, or unproven, keep going. Fix it, rerun the check, and only report completion once the result matches the request.
|
|
84
|
+
- The point of this is to keep iteration off the user's shoulders. Return finished work when possible, not a first pass that still depends on the user to spot-check it for you.
|
|
85
|
+
- Only come back before that if you hit a genuine blocker you cannot clear with the codebase, tools, or available context. If that happens, say it plainly and be explicit about what remains unverified.
|
|
86
|
+
|
|
74
87
|
Working rules:
|
|
75
88
|
- Keep `.waypoint/WORKSPACE.md` current as the live execution state, with timestamped new or materially revised entries in multi-topic sections
|
|
76
89
|
- 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`
|
|
77
90
|
- Update `.waypoint/docs/` when behavior or durable project knowledge changes, and refresh `last_updated` on touched routable docs
|
|
78
|
-
- When spawning reviewer agents or other subagents, explicitly set `model` to `gpt-5.4
|
|
91
|
+
- When spawning reviewer agents or other subagents, explicitly set `fork_context: false`, `model` to `gpt-5.4`, and `reasoning_effort` to `high` unless the user explicitly requests a different model or lower reasoning
|
|
79
92
|
- Use the repo-local skills Waypoint ships for structured workflows when relevant
|
|
80
93
|
- Use `work-tracker` when a long-running implementation, remediation, or verification campaign needs durable progress tracking
|
|
81
94
|
- Use `docs-sync` when the docs may be stale or a change altered shipped behavior, contracts, routes, or commands
|