waypoint-codex 0.9.7 → 0.9.9

package/README.md

@@ -156,6 +156,8 @@ Waypoint scaffolds these reviewer agents by default:
 
 The intended workflow is closeout-based: run `code-reviewer` before considering any non-trivial implementation slice complete, and run `code-health-reviewer` before considering medium or large changes complete, especially when they add structure, duplicate logic, or introduce new abstractions. If both apply, run them in parallel. A recent self-authored commit is the preferred scope anchor when one cleanly represents the slice, but it is not the only valid trigger.
 
+For planning work, run `plan-reviewer` before presenting a non-trivial implementation plan to the user and iterate until it has no meaningful review findings left.
+
 ## What makes it different
 
 Waypoint is not trying to hide everything behind hooks and background machinery.

package/package.json

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

package/templates/.agents/skills/backend-context-interview/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: backend-context-interview
-description: Gather and persist durable backend project context when missing or insufficient for implementation, architecture decisions, or ship-readiness review. Use when backend choices depend on scale, criticality, compliance, tenant model, compatibility, reliability, security posture, or similar context that is not clearly documented.
+description: Gather and persist durable backend project context when missing or insufficient for implementation, architecture decisions, or ship-readiness review. Use this to ask project-level questions about deployment reality, scale, criticality, compatibility, tenant model, security posture, reliability expectations, and other durable backend context that is not clearly documented. This is not a feature-discovery skill.
 ---
 
 # Backend Context Interview
 
-Use this skill when relevant backend context is missing, stale, contradictory, or too weak to support correct implementation or review decisions.
+Use this skill when relevant backend project context is missing, stale, contradictory, or too weak to support correct implementation or review decisions.
 
 ## Goals
 
@@ -14,6 +14,8 @@ Use this skill when relevant backend context is missing, stale, contradictory, o
 3. persist durable context into the project root guidance file
 4. avoid repeated questioning in future tasks
 
+This skill is for project-level operating context, not feature requirements gathering.
+
 ## When to use
 
 Use this skill when the current task depends on context such as:
@@ -29,6 +31,7 @@ Use this skill when the current task depends on context such as:
 - infrastructure constraints that materially affect design
 
 Do not use this skill when the answer is already clearly present in `AGENTS.md`, architecture docs, runbooks, or the task itself.
+Do not use this skill to ask about feature-specific behavior, UX details, endpoint shapes, acceptance criteria, implementation preferences, or other concrete requirements that belong in planning or normal task clarification.
 
 ## Workflow
 
@@ -57,6 +60,7 @@ Good triggers:
 - tenant model changes authorization and data-isolation design
 
 Do not ask broad or low-value questions.
+Do not ask feature-specific product questions.
 
 ### 3. Ask concise grouped questions
 
@@ -68,3 +72,9 @@ Suggested categories:
 - data sensitivity and compliance
 
 Do not ask generic product questions that do not affect backend engineering.
+Do ask project-level questions like:
+- whether the product is internal, customer-facing, partner-facing, or public
+- whether there are real users yet or only development/staging use
+- expected traffic, concurrency, or import/job intensity
+- whether backward compatibility is required
+- how costly outages, corruption, or security mistakes would be

package/templates/.agents/skills/frontend-context-interview/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: frontend-context-interview
-description: Gather and persist durable frontend project context when missing or insufficient for implementation or review work. Use when frontend decisions depend on product type, audience, support matrix, accessibility, SEO, localization, design-system constraints, or similar context that is not clearly documented.
+description: Gather and persist durable frontend project context when missing or insufficient for implementation or review work. Use this to ask project-level questions about audience, deployment surface, browser/device expectations, accessibility, SEO, localization, analytics obligations, and other durable frontend context that is not clearly documented. This is not a feature-discovery skill.
 ---
 
 # Frontend Context Interview
 
-Use this skill when relevant frontend context is missing, stale, contradictory, or too weak to support correct implementation or review decisions.
+Use this skill when relevant frontend project context is missing, stale, contradictory, or too weak to support correct implementation or review decisions.
 
 ## Goals
 
@@ -14,6 +14,8 @@ Use this skill when relevant frontend context is missing, stale, contradictory,
 3. persist durable context into the project root guidance file
 4. avoid repeated questioning in future tasks
 
+This skill is for project-level operating context, not feature requirements gathering.
+
 ## When to use
 
 Use this skill when the current task depends on context such as:
@@ -29,6 +31,7 @@ Use this skill when the current task depends on context such as:
 - security or privacy expectations that change frontend behavior
 
 Do not use this skill when the answer is already clearly present in `AGENTS.md`, product docs, or the task itself.
+Do not use this skill to ask about feature-specific UX, copy, flows, acceptance criteria, implementation preferences, or detailed product behavior that belongs in planning or normal task clarification.
 
 ## Workflow
 
@@ -58,3 +61,12 @@ Good triggers:
 
 Do not ask broad or low-value questions.
 Do not ask generic discovery questions that do not affect implementation.
+Do not ask feature-specific product questions.
+
+Good project-level question areas include:
+- whether the product is internal, customer-facing, partner-facing, or public marketing
+- whether there are real users yet or only development/staging use
+- expected device mix and browser support
+- accessibility expectations or compliance targets
+- whether SEO matters for any routes
+- whether backward compatibility in user workflows matters

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

@@ -82,7 +82,15 @@ Waypoint scaffolds these focused second-pass specialists by default:
 
 - `code-reviewer` for correctness and regression review
 - `code-health-reviewer` for maintainability drift
-- `plan-reviewer` to challenge weak implementation plans before execution
+- `plan-reviewer` to challenge non-trivial implementation plans before they are shown to the user
+
+## Plan Review
+
+Run `plan-reviewer` before presenting a non-trivial implementation plan to the user.
+
+- Use it when the plan includes meaningful design choices, multiple work phases, migrations, or non-obvious tradeoffs.
+- Skip it for tiny obvious plans or when no plan will be presented.
+- Read the reviewer result, strengthen the plan, and rerun `plan-reviewer` until there are no meaningful issues left before showing the plan to the user.
 
 ## Review Loop
 

package/templates/managed-agents-block.md

@@ -52,9 +52,10 @@ Examples of durable context that can materially change the correct approach:
 
 If relevant context is missing, empty, stale, or insufficient and that gap would materially change the correct approach:
 - do not guess silently
-- use `frontend-context-interview` when frontend or product-surface context is missing
-- use `backend-context-interview` when backend, reliability, tenant, compatibility, or security context is missing
+- use `frontend-context-interview` when project-level frontend context is missing
+- use `backend-context-interview` when project-level backend context is missing
 - ask only the missing high-leverage questions
+- ask about the project, deployment reality, and operating constraints rather than the concrete feature
 - persist only durable context back into the project guidance file
 - do not write transient task-specific details into context sections
 
@@ -74,6 +75,7 @@ Working rules:
 - Use `docs-sync` when the docs may be stale or a change altered shipped behavior, contracts, routes, or commands
 - Use `code-guide-audit` for a targeted coding-guide compliance pass on a specific feature, file set, or change slice
 - Do not invoke `break-it-qa`, `frontend-ship-audit`, or `backend-ship-audit` yourself from the managed AGENTS block workflow; they are user-facing skills for explicit human-requested QA or ship-readiness audits, not default agent steps
+- 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
 - Before considering a non-trivial implementation slice complete, run `code-reviewer`; use a recent self-authored commit as the default scope anchor when one cleanly represents that slice
 - Before considering medium or large changes complete, run `code-health-reviewer`, especially when they add structure, duplicate logic, or introduce new abstractions
 - Before pushing or opening/updating a PR for substantial work, use `pre-pr-hygiene`