waypoint-codex 1.0.1 → 1.0.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "waypoint-codex",
-  "version": "1.0.1",
+  "version": "1.0.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/agi-help/SKILL.md

@@ -98,6 +98,7 @@ Do not optimize for brevity by dropping relevant material.
 If a file is relevant, include it in full.
 If multiple files are relevant, include all of them.
 If prior plans, failed attempts, docs, architecture notes, or state files materially change the answer, include them too.
+Do not trim the bundle down to only the files that seem to directly answer the question. Include files that define constraints, history, surrounding system behavior, rejected approaches, current state, or any other context that materially changes how GPT-5.4-Pro should reason.
 
 The bottleneck here is not token thrift inside Codex. The bottleneck is giving GPT-5.4-Pro enough real context to reason well.
 
@@ -139,9 +140,13 @@ This is not a fixed checklist. Include whatever materially changes the quality o
 
 Create `files/` and copy in the relevant source material.
 
+The standard is completeness, not minimality.
+If a file materially affects the question, the answer, the constraints, or the reasoning path, include it even when it is only indirectly relevant.
+
 Examples of relevant files:
 
 - core implementation files
+- supporting files that materially change the reasoning, even if they do not directly answer the question
 - architecture docs
 - plans
 - active plan or workspace files

package/templates/managed-agents-block.md

@@ -27,11 +27,15 @@ Run the Waypoint bootstrap only at session start, after compaction, or when the
 7. Read `.waypoint/context/SNAPSHOT.md`
 8. Read `.waypoint/context/RECENT_THREAD.md`
 
+Investigate the actual code, docs, and routed context before you answer detailed questions or start implementation.
+Prefer visible repo state over hidden assumptions or chat-only memory.
+
 Before major implementation or architecture changes, check the repo guidance and routed docs for durable context. Ask only the missing high-leverage questions.
 
 Once the user approves a plan or tells you to proceed, that approved scope is the execution contract. Do not silently narrow, defer, or drop approved work unless a real blocker or decision requires discussion.
 
 `WORKSPACE.md` is the live state file. `ACTIVE_PLANS.md` is the active execution checklist. Keep them current when state, blockers, or verification materially change.
+When durable behavior changes, update the relevant docs during the work. When live execution state changes, update `WORKSPACE.md` or `ACTIVE_PLANS.md` during the work, not only at the end.
 
 Refactor and migration default: use direct replacement, not compatibility scaffolding, unless the user or project docs explicitly require coexistence. Delete obsolete code aggressively and finish the phase back to green. Large destructive edits are allowed when they are the clearest path to the approved target state.
 
@@ -39,5 +43,6 @@ Use reviewer passes when the work is non-trivial or risky, before PR-ready hando
 
 Keep communication concise. Lead with the answer, diagnosis, decision, or next step. Explain the diagnosis before implementation when the cause, tradeoffs, or solution shape are not already obvious.
 
+Verification should match the real risk surface. Inspect real UI for UI work when practical, and run code or inspect real output for backend or script work when practical.
 Before reporting completion, verify the result yourself when reasonably possible, reread `ACTIVE_PLANS.md` and `WORKSPACE.md`, and compare reality against the approved scope. If the work is not actually complete, keep going.
 <!-- waypoint:end -->