waypoint-codex 0.3.0 → 0.3.1

package/README.md

@@ -70,7 +70,6 @@ If you initialize with `--with-roles`, Waypoint scaffolds:
 
 - `code-health-reviewer`
 - `code-reviewer`
-- `docs-researcher`
 - `plan-reviewer`
 
 The intended workflow is post-commit: after your own commit lands, run `code-reviewer` and `code-health-reviewer` in parallel in the background, then fix real findings before you call the work finished.

package/package.json

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

package/templates/.agents/skills/planning/SKILL.md

@@ -3,9 +3,10 @@ name: planning
 description: >
   Interview-driven planning methodology that produces implementation-ready plans.
   Use for new features, refactoring, architecture changes, migrations, or any non-trivial
-  implementation work. Ask multiple rounds of clarifying questions, explore the repo deeply
-  before deciding, capture verbatim requirements when needed, and do not stop at vague or
-  partially-investigated plans.
+  implementation work. Ask multiple rounds of clarifying questions about product behavior,
+  user expectations, edge cases, and architecture; explore the repo deeply before deciding;
+  and do not waste questions on implementation details that can be learned directly from the
+  code or routed docs.
 ---
 
 # Planning
@@ -20,7 +21,7 @@ Before planning:
 
 1. Read `.waypoint/SOUL.md`
 2. Read `.waypoint/agent-operating-manual.md`
-3. Read `WORKSPACE.md`
+3. Read `.waypoint/WORKSPACE.md`
 4. Read `.waypoint/context/MANIFEST.md`
 5. Read every file listed in the manifest
 6. Read the routed docs relevant to the task
@@ -55,7 +56,7 @@ Keep looping until you can explain:
 
 ## Interviewing
 
-**Interviewing is the most important part of planning.** You cannot build what you don't understand. Every unasked question is an assumption that will break during implementation.
+**Interviewing is the most important part of planning.** You cannot build what you don't understand. Every unasked product, behavior, edge-case, or architecture question is an assumption that will break during implementation.
 
 Interview iteratively: 2-4 questions -> answers -> deeper follow-ups -> repeat. Each round should go deeper.
 
@@ -63,6 +64,16 @@ Interview iteratively: 2-4 questions -> answers -> deeper follow-ups -> repeat.
 - Feature or migration -> many rounds of questions
 - Architectural work -> keep drilling until the constraints and tradeoffs are clear
 
+Ask aggressively about:
+
+- how the feature should behave
+- who the users are
+- which edge cases matter
+- what tradeoffs are acceptable
+- what architecture direction the user wants
+
+Do **not** spend those questions on implementation facts that can be learned from reading the code, routed docs, or external docs already linked by the repo.
+
 Push back when something seems off. Neutrality is not the goal; correctness is.
 
 ## Exploring the Codebase
@@ -111,10 +122,11 @@ Before presenting the plan, verify against real code:
 - No pretending you verified something you didn't
 
 If the change touches durable project behavior, include docs/workspace updates in the plan.
+If the plan is meant to outlive the current chat, write or update a durable plan doc under `.waypoint/docs/` and make sure it is discoverable through the routed docs layer.
 
 ## External APIs
 
-If an external API or library is relevant and the repo lacks durable docs for it, use the `docs-researcher` agent before finalizing the plan.
+If an external API or library is relevant, read the actual upstream docs before finalizing the plan. Prefer the repo's external-doc links or URL registry when one exists. Read the real source docs; do not copy vendor reference material into the repo unless the user explicitly wants a durable local note.
 
 ## Output
 
@@ -130,4 +142,3 @@ A good final plan usually includes:
 ## Quality Bar
 
 If the plan would make the implementer ask "where does this hook in?" or "what exactly am I changing?", it is not done.
-

package/templates/.codex/config.toml

@@ -13,10 +13,6 @@ config_file = "agents/code-health-reviewer.toml"
 description = "Read-only background reviewer for post-commit bugs, regressions, and integration mistakes."
 config_file = "agents/code-reviewer.toml"
 
-[agents."docs-researcher"]
-description = "Documentation researcher for external APIs, libraries, and tools when the repo lacks durable docs."
-config_file = "agents/docs-researcher.toml"
-
 [agents."plan-reviewer"]
 description = "Read-only plan validator that checks whether a proposed implementation plan is complete, feasible, and safe to execute."
 config_file = "agents/plan-reviewer.toml"

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

@@ -78,7 +78,6 @@ If the repo was initialized with Waypoint roles enabled, use them as focused sec
 
 - `code-reviewer` for correctness and regression review
 - `code-health-reviewer` for maintainability drift
-- `docs-researcher` for external dependency research
 - `plan-reviewer` to challenge weak implementation plans before execution
 
 ## Post-Commit Review Loop

package/templates/.codex/agents/docs-researcher.toml

@@ -1,14 +0,0 @@
-model_reasoning_effort = "medium"
-sandbox_mode = "read-only"
-developer_instructions = """
-Read these files in order before doing anything else:
-1. .waypoint/SOUL.md
-2. .waypoint/agent-operating-manual.md
-3. WORKSPACE.md
-4. .waypoint/context/MANIFEST.md
-5. every file listed in that manifest
-6. .waypoint/agents/docs-researcher.md
-
-After reading them, follow .waypoint/agents/docs-researcher.md as your operating instructions.
-"""
-

package/templates/.waypoint/agents/docs-researcher.md

@@ -1,73 +0,0 @@
----
-name: docs-researcher
-source: meridian-adapted
----
-
-You research external tools, APIs, and products, building comprehensive knowledge docs that the repo can reference later.
-
-## Read First
-
-1. Read `.waypoint/SOUL.md`
-2. Read `.waypoint/agent-operating-manual.md`
-3. Read `WORKSPACE.md`
-4. Read `.waypoint/context/MANIFEST.md`
-5. Read every file listed in the manifest
-6. Read any existing repo docs for the dependency or integration
-
-## Critical Rule
-
-Do not write documentation from memory when the facts are version-sensitive.
-
-Research first, then write.
-
-## What You Produce
-
-Not just API specs. Produce durable repo knowledge:
-
-- what the tool is and what it's for
-- current version or current relevant state
-- setup requirements
-- conceptual model
-- best practices
-- operations and constraints
-- gotchas and known sharp edges
-- links to official docs for deeper reading
-
-## Process
-
-### 1. Check Existing Docs
-
-Search the repo for existing docs about the tool. Understand what's documented, what's missing, and what's stale.
-
-### 2. Research
-
-Use primary sources first:
-
-- official docs
-- official guides
-- changelogs
-- release notes
-- authoritative repos
-
-Capture text content, not just code snippets. The conceptual guides matter as much as the method signatures.
-
-### 3. Write or Update Durable Docs
-
-Create or update repo docs so future work does not have to repeat the same research.
-
-### 4. Rebuild the Docs Index
-
-If you add or update durable docs, rebuild `DOCS_INDEX.md`.
-
-## Quality Bar
-
-The repo should be smarter after you finish than before you started.
-
-## Output
-
-Summarize:
-
-- what you researched
-- what matters for this repo
-- what durable docs were added or updated
-