waypoint-codex 0.16.0 → 0.17.0

package/README.md

@@ -31,10 +31,18 @@ Or try it without a global install:
 npx waypoint-codex@latest --help
 ```
 
+Inside the repo you want to prepare for Codex:
+
+```bash
+waypoint init
+waypoint doctor
+```
+
 Keep an existing repo up to date:
 
 ```bash
 waypoint upgrade
+waypoint doctor
 ```
 
 ## What gets better

package/dist/src/core.js

@@ -347,6 +347,7 @@ export function initRepository(projectRoot, options) {
         "docs/README.md",
         "docs/code-guide.md",
         "docs/legacy-import",
+        ".codex/agents/coding-agent.toml",
         ".agents/skills/error-audit",
         ".agents/skills/observability-audit",
         ".agents/skills/ux-states-audit",

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "waypoint-codex",
-  "version": "0.16.0",
-  "description": "Codex-native repository operating system: scaffolding, docs routing, repo-local skills, doctor, and sync.",
+  "version": "0.17.0",
+  "description": "Make Codex better by default with stronger planning, code quality, reviews, tracking, and repo guidance.",
   "license": "MIT",
   "type": "module",
   "bin": {

package/templates/.agents/skills/work-tracker/SKILL.md

@@ -88,7 +88,7 @@ A good tracker usually includes:
 - `Decisions`
 - `Notes`
 
-Use checklists when there are many concrete items. Use timestamped bullets for materially revised state.
+Use `- [ ]` checkboxes when there are many concrete tasks to track. Use status-style entries when the work is better expressed as phase/state updates than as a task list. Use timestamped bullets for materially revised state.
 
 ## Step 4: Link It From The Workspace
 
@@ -100,7 +100,7 @@ The tracker should answer "what exactly is happening across the whole workstream
 ## Step 5: Maintain It During Execution
 
 - Update `last_updated` whenever you materially change the tracker.
-- Mark completed items done instead of deleting the record.
+- Keep task lists or status entries current instead of deleting history. Mark completed checkbox items as `- [x]`, and update status-style entries when the phase or state changes.
 - Add blockers, new tasks, and verification status as the work evolves.
 - Update the tracker during the work, not only at the end. If a milestone, blocker, review round, or verification result changed reality, the tracker should already reflect it.
 - When the workstream finishes, set `status: done` or `status: archived`.

package/templates/.codex/config.toml

@@ -9,10 +9,6 @@ max_threads = 24
 description = "Read-only background reviewer for post-commit maintainability drift, dead code, duplication, and refactoring opportunities worth fixing."
 config_file = "agents/code-health-reviewer.toml"
 
-[agents."coding-agent"]
-description = "Optional workspace-writing implementation helper for bounded coding tasks that should follow the code guide, verify changes, and hand the slice back cleanly."
-config_file = "agents/coding-agent.toml"
-
 [agents."code-reviewer"]
 description = "Read-only background reviewer for post-commit bugs, regressions, and integration mistakes."
 config_file = "agents/code-reviewer.toml"

package/templates/.gitignore.snippet

@@ -1,6 +1,5 @@
 # Waypoint state
 .codex/config.toml
-.codex/agents/coding-agent.toml
 .codex/agents/code-reviewer.toml
 .codex/agents/code-health-reviewer.toml
 .codex/agents/plan-reviewer.toml

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

@@ -65,11 +65,10 @@ If something important lives only in your head or in the chat transcript, the re
 - Update `.waypoint/docs/` when durable project knowledge changes, update `.waypoint/plans/` when durable plans change, 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.
-- Keep most work in the main agent. Use skills, trackers, `coding-agent`, or reviewer agents when they clearly add leverage, not as default ceremony.
+- Keep most work in the main agent. Use skills, trackers, and reviewer agents when they clearly add leverage, not as default ceremony.
 - Let skills carry their own invocation guidance. The always-on contract should only keep the high-level rule: use repo-local skills deliberately when they help the current task.
-- When spawning `coding-agent`, default to `fork_context: false` and choose the model/reasoning pair that fits the slice. Use stronger models when the delegated slice is user-visible, architecturally important, or hard to unwind.
-- When spawning reviewer agents or other non-`coding-agent` subagents, explicitly set `fork_context: false` and choose the model/reasoning pair that matches the risk and importance of the second pass.
 - Use the repo-local skills and reviewer agents deliberately, but do not underuse them on work that is expensive to get wrong.
+- When spawning reviewer agents or other subagents, explicitly set `fork_context: false` and choose the model/reasoning pair that matches the risk and importance of the second pass.
 - For non-trivial work, strongly prefer reviewer-agent passes between major implementation milestones, before opening or updating a PR, after fixing substantial findings, and before final closeout when the environment allows those agents to run.
 - If you created a PR earlier in the current session and need to push more work, first confirm that PR is still open. If it is closed, create a fresh branch from `origin/main` and open a fresh PR instead of pushing more commits to the old PR branch.
 - Treat reviewer agents as one-shot workers: once a reviewer returns findings, read the result and close it. If another review pass is needed later, spawn a fresh reviewer instead of reusing the same thread.
@@ -118,7 +117,6 @@ Do not document every trivial implementation detail. Document the non-obvious, d
 
 Waypoint scaffolds these focused specialists by default:
 
-- `coding-agent` for bounded implementation slices the main agent deliberately wants to hand off because parallelism or context preservation will clearly help
 - `code-reviewer` for correctness and regression review
 - `code-health-reviewer` for maintainability drift
 - `plan-reviewer` to challenge non-trivial implementation plans when an independent second pass would materially improve the result

package/templates/managed-agents-block.md

@@ -101,7 +101,7 @@ Working rules:
 - Update user-scoped `AGENTS.md` when you learn a durable preference, standing rule, or default that should apply across projects and your environment allows you to edit that file
 - Update the project-scoped repo `AGENTS.md` when you learn durable repo truth, project constraints, or stable project-specific collaboration rules
 - Update `.waypoint/docs/` when durable project knowledge changes, update `.waypoint/plans/` when a durable plan changes, and refresh `last_updated` on touched routable docs
-- Keep most work in the main agent. Use repo-local skills, trackers, reviewer agents, or `coding-agent` when they create clear leverage, not as default ceremony.
+- Keep most work in the main agent. Use repo-local skills, trackers, and reviewer agents when they create clear leverage, not as default ceremony.
 - Let repo-local skills describe their own triggers. The managed block should keep only the high-level rule: use those tools deliberately when they clearly help the task.
 - Use reviewer agents proactively at meaningful milestones when the work is non-trivial, risky, user-facing, merge-bound, or otherwise expensive to get wrong.
 - Strong default moments for reviewer-agent passes are: after a meaningful implementation milestone, before opening or updating a PR, after fixing substantial review findings, and before finally calling the work clear.

package/templates/.codex/agents/coding-agent.toml

@@ -1,49 +0,0 @@
-model = "gpt-5.4-mini"
-model_reasoning_effort = "high"
-sandbox_mode = "workspace-write"
-developer_instructions = """
-Read these files in order before doing anything else:
-1. .waypoint/SOUL.md
-2. .waypoint/agent-operating-manual.md
-3. .waypoint/WORKSPACE.md
-4. .waypoint/context/MANIFEST.md
-5. every file listed in that manifest
-6. .waypoint/docs/code-guide.md
-
-After reading them, follow these operating instructions:
-
-You are the coding agent. You implement a bounded slice that the main agent deliberately handed to you because delegation is useful here.
-
-You are a single-slice execution worker:
-- Finish the specific implementation task you were handed, then stop.
-- Do not silently broaden scope.
-- If the handoff is missing something essential, inspect the repo first and make the narrowest reasonable assumption instead of bouncing the task back immediately.
-
-Working rules:
-- Read the files you plan to change before editing them.
-- Read the docs relevant to the area you touch.
-- Follow `.waypoint/docs/code-guide.md` as an active contract, not background reading.
-- Prefer direct, explicit code over speculative abstraction.
-- Keep changes reviewable and easy to explain.
-- When the handed-off slice involves a bug or broken behavior, investigate first and explain the likely cause plainly in your handoff.
-- Do not revert user work you did not create.
-- Do not make unrelated cleanup changes unless they are required to land the slice safely.
-
-Implementation expectations:
-- Resolve the exact files and entry points involved in the handed-off slice before editing.
-- Validate inputs, state changes, and integration points at the boundaries you touch.
-- Update tests when behavior changes.
-- Update docs or workspace state when the slice changes durable behavior or repo memory.
-- Run the most relevant verification you can for the owned slice before handing back.
-- If verification fails, keep iterating when you can fix it yourself.
-
-Output:
-Return a concise implementation handoff that includes:
-- what you changed
-- files changed
-- verification run and outcome
-- any assumptions, follow-ups, or risks the main agent should know about
-
-Do not pretend the slice is verified if you did not run verification.
-Do not use readiness-disclaimer language as the main point of the handoff. If important known issues remain, say what they are, why they matter, and what needs to happen next.
-"""