waypoint-codex 0.10.11 → 0.10.13

package/dist/src/core.js

@@ -16,6 +16,7 @@ const LEGACY_WAYPOINT_GITIGNORE_RULES = new Set([
     ".codex/",
     ".codex/config.toml",
     ".codex/agents/",
+    ".codex/agents/coding-agent.toml",
     ".codex/agents/code-reviewer.toml",
     ".codex/agents/code-health-reviewer.toml",
     ".codex/agents/plan-reviewer.toml",
@@ -314,7 +315,7 @@ export function initRepository(projectRoot, options) {
         "Installed managed AGENTS block",
         "Created .waypoint/WORKSPACE.md, .waypoint/docs/, and .waypoint/track/ scaffold",
         "Installed repo-local Waypoint skills",
-        "Installed reviewer agents and project Codex config",
+        "Installed coding/reviewer agents and project Codex config",
         "Generated .waypoint/DOCS_INDEX.md and .waypoint/TRACKS_INDEX.md",
     ];
 }
@@ -557,7 +558,7 @@ export function doctorRepository(projectRoot) {
         findings.push({
             severity: "warn",
             category: "roles",
-            message: "Reviewer agent config is missing from .codex/config.toml.",
+            message: "Codex agent config is missing from .codex/config.toml.",
             remediation: "Run `waypoint init` or create the project Codex config files.",
             paths: [codexConfigPath],
         });

package/package.json

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

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

@@ -0,0 +1,48 @@
+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 handed to you by the main agent so the main agent can preserve context and focus on scoping, coordination, review, and closeout.
+
+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.
+- 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 say the work is complete if important known issues remain.
+"""

package/templates/.codex/config.toml

@@ -9,6 +9,10 @@ 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 = "Workspace-writing implementation specialist 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,5 +1,6 @@
 # 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

@@ -49,8 +49,12 @@ If something important lives only in your head or in the chat transcript, the re
 - 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.
-- 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.
+- Default to the `coding-agent` for non-trivial implementation work so the main agent can preserve context for scoping, review, and closeout.
+- Keep tiny or tightly coupled edits local when handing them off would add more churn than value.
+- When spawning `coding-agent`, default to `fork_context: false`, `model` to `gpt-5.4-mini`, and `reasoning_effort` to `high`; step up to `gpt-5.4` for especially important or meticulous tasks, or when the user explicitly asks otherwise.
+- When spawning reviewer agents or other non-`coding-agent` 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.
 - Use the repo-local skills and reviewer agents instead of improvising from scratch.
+- 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.
 - 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.
@@ -110,9 +114,11 @@ Do not document every trivial implementation detail. Document the non-obvious, d
 
 Treat `conversation-retrospective` as a default closeout step for major work pieces, not as a rare manual tool.
 
-## When to use the reviewer agents
+## When to use the agent pack
 
-Waypoint scaffolds these focused second-pass specialists by default:
+Waypoint scaffolds these focused specialists by default:
+
+- `coding-agent` for bounded implementation slices the main agent wants to hand off while preserving its own context
 
 - `code-reviewer` for correctness and regression review
 - `code-health-reviewer` for maintainability drift

package/templates/managed-agents-block.md

@@ -88,7 +88,10 @@ 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`
 - Update `.waypoint/docs/` when behavior or durable project knowledge changes, and refresh `last_updated` on touched routable docs
-- 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
+- Default to the `coding-agent` for non-trivial implementation work so the main agent can preserve context for scoping, review, and closeout
+- Keep tiny or tightly coupled edits local when handing them off would add more churn than value
+- When spawning `coding-agent`, default to `fork_context: false`, `model` to `gpt-5.4-mini`, and `reasoning_effort` to `high`; step up to `gpt-5.4` for especially important or meticulous tasks, or when the user explicitly asks otherwise
+- When spawning reviewer agents or other non-`coding-agent` 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
 - Use the repo-local skills Waypoint ships for structured workflows when relevant
 - 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
@@ -100,6 +103,7 @@ Working rules:
 - 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
 - Treat `plan-reviewer`, `code-reviewer`, and `code-health-reviewer` as one-shot agents: once a reviewer returns findings, close it; if another pass is needed later, spawn a fresh reviewer instead of reusing the old thread
 - Before pushing or opening/updating a PR for substantial work, use `pre-pr-hygiene`
+- 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
 - 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