fix(ce-brainstorm): distinguish verification from technical design in Phase 1.1#465
Merged
Conversation
… Phase 1.1 Phase 1.1 conflated checking what exists (fact-checking) with deciding what to build (technical design). The blanket "avoid low-level architecture" instruction prevented the skill from reading schema files, routes, or config to verify infrastructure claims — causing unverified "X does not exist" statements to be written as fact into requirements documents. Reframes the guardrail: defer implementation decisions to planning, but always permit verifying current state. Adds a verification-before-claiming rule for infrastructure existence claims. Closes #457 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e2b4365fac
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The previous commit dropped the "unless the brainstorm is itself about a technical decision" clause that existed in the original text. This caused the skill to categorically defer implementation decisions even when the brainstorm was inherently about architecture or schema design, conflicting with Core Principle 4 and Phase 3 guidance. Restores the exception while keeping the verification-before-claiming rule unconditional — fact-checking current state is always appropriate regardless of brainstorm type. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
… anchoring on prohibition Restructure the verification/design rules as a numbered list with verification first. The previous prose format led with "Do not drift" which risks agents anchoring on the prohibition before processing the exceptions that follow. The new structure gives both rules equal visual weight and frames the technical-brainstorm exception positively. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
…ecklist The verification-before-claiming rule in Phase 1.1 only covers the initial scan. Infrastructure claims that emerge mid-conversation could still be written into the requirements doc as fact. Adding a check to the Phase 3 finalization checklist catches unverified absence claims before they propagate to downstream skills. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Specific examples like "table X does not exist" narrow the pattern and risk agents not recognizing other phrasings of the same class of claim. Replaced with general language — "any claim that something is absent" — so the rule applies regardless of how the absence is phrased. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
…unding A general rule without examples risks being too abstract for agents to apply consistently. Added diverse inline examples (missing table, nonexistent endpoint, absent dependency, unsupported config) to show the breadth of what counts as an absence claim without narrowing to specific phrasings. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Phase 1.1's "don't drift into technical planning" instruction conflated two activities: checking what currently exists (fact-checking) and deciding what to build (technical design). The blanket prohibition on inspecting "low-level architecture" prevented the skill from reading schema files, routes, or config — even when the brainstorm was about database tables. This caused unverified "table X does not exist" claims to be stated as fact and propagated into requirements documents.
The fix reframes the guardrail around the right distinction: defer implementation decisions (schemas, migration strategies, endpoint structure) to planning, but always permit verification of current state. Adds a rule that infrastructure existence claims must be verified against source files before being stated as fact — unverified claims must be labeled as assumptions.
Closes #457
🤖 Generated with Claude Opus 4.6 (1M context, extended thinking) via Claude Code