diff --git a/.agents/skills/gstack-design-consultation/SKILL.md b/.agents/skills/gstack-design-consultation/SKILL.md index 1199a828..29e1a222 100644 --- a/.agents/skills/gstack-design-consultation/SKILL.md +++ b/.agents/skills/gstack-design-consultation/SKILL.md @@ -343,7 +343,12 @@ If browse is not available, rely on WebSearch results and your built-in design k **Step 3: Synthesize findings** -The goal of research is NOT to copy. It is to get in the ballpark — to understand the visual language users in this category already expect. This gives you the baseline. The interesting design work starts after you have the baseline: deciding where to follow conventions (so the product feels literate) and where to break from them (so the product is memorable). +**Three-layer synthesis:** +- **Layer 1 (tried and true):** What design patterns does every product in this category share? These are table stakes — users expect them. +- **Layer 2 (new and popular):** What are the search results and current design discourse saying? What's trending? What new patterns are emerging? +- **Layer 3 (first principles):** Given what we know about THIS product's users and positioning — is there a reason the conventional design approach is wrong? Where should we deliberately break from the category norms? + +**Eureka check:** If Layer 3 reasoning reveals a genuine design insight — a reason the category's visual language fails THIS product — name it: "EUREKA: Every [category] product does X because they assume [assumption]. But this product's users [evidence] — so we should do Y instead." Log the eureka moment (see preamble). Summarize conversationally: > "I looked at what's out there. Here's the landscape: they converge on [patterns]. Most of them feel [observation — e.g., interchangeable, polished but generic, etc.]. The opportunity to stand out is [gap]. Here's where I'd play it safe and where I'd take a risk..." diff --git a/.agents/skills/gstack-investigate/SKILL.md b/.agents/skills/gstack-investigate/SKILL.md index 46571cc9..edfb21b2 100644 --- a/.agents/skills/gstack-investigate/SKILL.md +++ b/.agents/skills/gstack-investigate/SKILL.md @@ -309,6 +309,12 @@ Also check: - `TODOS.md` for related known issues - `git log` for prior fixes in the same area — **recurring bugs in the same files are an architectural smell**, not a coincidence +**External pattern search:** If the bug doesn't match a known pattern above, WebSearch for: +- "{framework} {error message or symptom}" +- "{library} {component} known issues" + +If WebSearch is unavailable, skip this search and proceed with hypothesis testing. If a documented solution or known dependency bug surfaces, present it as a candidate hypothesis in Phase 3. + --- ## Phase 3: Hypothesis Testing @@ -317,7 +323,7 @@ Before writing ANY fix, verify your hypothesis. 1. **Confirm the hypothesis:** Add a temporary log statement, assertion, or debug output at the suspected root cause. Run the reproduction. Does the evidence match? -2. **If the hypothesis is wrong:** Return to Phase 1. Gather more evidence. Do not guess. +2. **If the hypothesis is wrong:** Before forming the next hypothesis, WebSearch for the exact error message (quoted) and "{component} {unexpected behavior} {framework version}". This often surfaces version-specific regressions or known issues that save hypothesis cycles. If WebSearch is unavailable, skip and proceed. Then return to Phase 1. Gather more evidence. Do not guess. 3. **3-strike rule:** If 3 hypotheses fail, **STOP**. Use AskUserQuestion: ``` diff --git a/.agents/skills/gstack-office-hours/SKILL.md b/.agents/skills/gstack-office-hours/SKILL.md index 2153e3b2..4c3adbf2 100644 --- a/.agents/skills/gstack-office-hours/SKILL.md +++ b/.agents/skills/gstack-office-hours/SKILL.md @@ -467,6 +467,37 @@ If no matches found, proceed silently. --- +## Phase 2.75: Landscape Awareness + +Read ETHOS.md for the full Search Before Building framework (three layers, eureka moments). The preamble's Search Before Building section has the ETHOS.md path. + +After understanding the problem through questioning, search for what the world thinks. This is NOT competitive research (that's /design-consultation's job). This is understanding conventional wisdom so you can evaluate where it's wrong. + +If WebSearch is unavailable, skip this phase and note: "Search unavailable — proceeding with in-distribution knowledge only." + +**Startup mode:** WebSearch for: +- "[problem space] startup approach {current year}" +- "[problem space] common mistakes" +- "why [incumbent solution] fails" OR "why [incumbent solution] works" + +**Builder mode:** WebSearch for: +- "[thing being built] existing solutions" +- "[thing being built] open source alternatives" +- "best [thing category] {current year}" + +Read the top 2-3 results. Run the three-layer synthesis: +- **[Layer 1]** What does everyone already know about this space? +- **[Layer 2]** What are the search results and current discourse saying? +- **[Layer 3]** Given what WE learned in Phase 2A/2B — is there a reason the conventional approach is wrong? + +**Eureka check:** If Layer 3 reasoning reveals a genuine insight, name it: "EUREKA: Everyone does X because they assume [assumption]. But [evidence from our conversation] suggests that's wrong here. This means [implication]." Log the eureka moment (see preamble). + +If no eureka moment exists, say: "The conventional wisdom seems sound here. Let's build on it." Proceed to Phase 3. + +**Important:** This search feeds Phase 3 (Premise Challenge). If you found reasons the conventional approach fails, those become premises to challenge. If conventional wisdom is solid, that raises the bar for any premise that contradicts it. + +--- + ## Phase 3: Premise Challenge Before proposing solutions, challenge the premises: diff --git a/.agents/skills/gstack-plan-ceo-review/SKILL.md b/.agents/skills/gstack-plan-ceo-review/SKILL.md index 3de79a0d..d14dc831 100644 --- a/.agents/skills/gstack-plan-ceo-review/SKILL.md +++ b/.agents/skills/gstack-plan-ceo-review/SKILL.md @@ -397,6 +397,22 @@ Analyze the plan. If it involves ANY of: new UI screens/pages, changes to existi Identify 2-3 files or patterns in the existing codebase that are particularly well-designed. Note them as style references for the review. Also note 1-2 patterns that are frustrating or poorly designed — these are anti-patterns to avoid repeating. Report findings before proceeding to Step 0. +### Landscape Check + +Read ETHOS.md for the Search Before Building framework (the preamble's Search Before Building section has the path). Before challenging scope, understand the landscape. WebSearch for: +- "[product category] landscape {current year}" +- "[key feature] alternatives" +- "why [incumbent/conventional approach] [succeeds/fails]" + +If WebSearch is unavailable, skip this check and note: "Search unavailable — proceeding with in-distribution knowledge only." + +Run the three-layer synthesis: +- **[Layer 1]** What's the tried-and-true approach in this space? +- **[Layer 2]** What are the search results saying? +- **[Layer 3]** First-principles reasoning — where might the conventional wisdom be wrong? + +Feed into the Premise Challenge (0A) and Dream State Mapping (0C). If you find a eureka moment, surface it during the Expansion opt-in ceremony as a differentiation opportunity. Log it (see preamble). + ## Step 0: Nuclear Scope Challenge + Mode Selection ### 0A. Premise Challenge diff --git a/.agents/skills/gstack-plan-eng-review/SKILL.md b/.agents/skills/gstack-plan-eng-review/SKILL.md index 5c40b469..942d5822 100644 --- a/.agents/skills/gstack-plan-eng-review/SKILL.md +++ b/.agents/skills/gstack-plan-eng-review/SKILL.md @@ -313,7 +313,15 @@ Before reviewing anything, answer these questions: 1. **What existing code already partially or fully solves each sub-problem?** Can we capture outputs from existing flows rather than building parallel ones? 2. **What is the minimum set of changes that achieves the stated goal?** Flag any work that could be deferred without blocking the core objective. Be ruthless about scope creep. 3. **Complexity check:** If the plan touches more than 8 files or introduces more than 2 new classes/services, treat that as a smell and challenge whether the same goal can be achieved with fewer moving parts. -4. **TODOS cross-reference:** Read `TODOS.md` if it exists. Are any deferred items blocking this plan? Can any deferred items be bundled into this PR without expanding scope? Does this plan create new work that should be captured as a TODO? +4. **Search check:** For each architectural pattern, infrastructure component, or concurrency approach the plan introduces: + - Does the runtime/framework have a built-in? Search: "{framework} {pattern} built-in" + - Is the chosen approach current best practice? Search: "{pattern} best practice {current year}" + - Are there known footguns? Search: "{framework} {pattern} pitfalls" + + If WebSearch is unavailable, skip this check and note: "Search unavailable — proceeding with in-distribution knowledge only." + + If the plan rolls a custom solution where a built-in exists, flag it as a scope reduction opportunity. Annotate recommendations with **[Layer 1]**, **[Layer 2]**, **[Layer 3]**, or **[EUREKA]** (see preamble's Search Before Building section). If you find a eureka moment — a reason the standard approach is wrong for this case — present it as an architectural insight. +5. **TODOS cross-reference:** Read `TODOS.md` if it exists. Are any deferred items blocking this plan? Can any deferred items be bundled into this PR without expanding scope? Does this plan create new work that should be captured as a TODO? 5. **Completeness check:** Is the plan doing the complete version or a shortcut? With AI-assisted coding, the cost of completeness (100% test coverage, full edge case handling, complete error paths) is 10-100x cheaper than with a human team. If the plan proposes a shortcut that saves human-hours but only saves minutes with CC+gstack, recommend the complete version. Boil the lake. diff --git a/.agents/skills/gstack-retro/SKILL.md b/.agents/skills/gstack-retro/SKILL.md index 994c6f1d..a0b796ba 100644 --- a/.agents/skills/gstack-retro/SKILL.md +++ b/.agents/skills/gstack-retro/SKILL.md @@ -389,6 +389,20 @@ If TODOS.md doesn't exist, skip the Backlog Health row. If the JSONL file doesn't exist or has no entries in the window, skip the Skill Usage row. +**Eureka Moments (if logged):** Read `~/.gstack/analytics/eureka.jsonl` if it exists. Filter entries within the retro time window by `ts` field. For each eureka moment, show the skill that flagged it, the branch, and a one-line summary of the insight. Present as: + +``` +| Eureka Moments | 2 this period | +``` + +If moments exist, list them: +``` + EUREKA /office-hours (branch: garrytan/auth-rethink): "Session tokens don't need server storage — browser crypto API makes client-side JWT validation viable" + EUREKA /plan-eng-review (branch: garrytan/cache-layer): "Redis isn't needed here — Bun's built-in LRU cache handles this workload" +``` + +If the JSONL file doesn't exist or has no entries in the window, skip the Eureka Moments row. + ### Step 3: Commit Time Distribution Show hourly histogram in local time using bar chart: diff --git a/.agents/skills/gstack-review/SKILL.md b/.agents/skills/gstack-review/SKILL.md index e2d6ec78..de1a0674 100644 --- a/.agents/skills/gstack-review/SKILL.md +++ b/.agents/skills/gstack-review/SKILL.md @@ -339,6 +339,13 @@ Apply the checklist against the diff in two passes: **Enum & Value Completeness requires reading code OUTSIDE the diff.** When the diff introduces a new enum value, status, tier, or type constant, use Grep to find all files that reference sibling values, then Read those files to check if the new value is handled. This is the one category where within-diff review is insufficient. +**Search-before-recommending:** When recommending a fix pattern (especially for concurrency, caching, auth, or framework-specific behavior): +- Verify the pattern is current best practice for the framework version in use +- Check if a built-in solution exists in newer versions before recommending a workaround +- Verify API signatures against current docs (APIs change between versions) + +Takes seconds, prevents recommending outdated patterns. If WebSearch is unavailable, note it and proceed with in-distribution knowledge. + Follow the output format specified in the checklist. Respect the suppressions — do NOT flag items listed in the "DO NOT flag" section. --- diff --git a/design-consultation/SKILL.md b/design-consultation/SKILL.md index fe25fb2f..f707f5b3 100644 --- a/design-consultation/SKILL.md +++ b/design-consultation/SKILL.md @@ -353,7 +353,12 @@ If browse is not available, rely on WebSearch results and your built-in design k **Step 3: Synthesize findings** -The goal of research is NOT to copy. It is to get in the ballpark — to understand the visual language users in this category already expect. This gives you the baseline. The interesting design work starts after you have the baseline: deciding where to follow conventions (so the product feels literate) and where to break from them (so the product is memorable). +**Three-layer synthesis:** +- **Layer 1 (tried and true):** What design patterns does every product in this category share? These are table stakes — users expect them. +- **Layer 2 (new and popular):** What are the search results and current design discourse saying? What's trending? What new patterns are emerging? +- **Layer 3 (first principles):** Given what we know about THIS product's users and positioning — is there a reason the conventional design approach is wrong? Where should we deliberately break from the category norms? + +**Eureka check:** If Layer 3 reasoning reveals a genuine design insight — a reason the category's visual language fails THIS product — name it: "EUREKA: Every [category] product does X because they assume [assumption]. But this product's users [evidence] — so we should do Y instead." Log the eureka moment (see preamble). Summarize conversationally: > "I looked at what's out there. Here's the landscape: they converge on [patterns]. Most of them feel [observation — e.g., interchangeable, polished but generic, etc.]. The opportunity to stand out is [gap]. Here's where I'd play it safe and where I'd take a risk..." diff --git a/design-consultation/SKILL.md.tmpl b/design-consultation/SKILL.md.tmpl index 1e8b0bff..ed9a4efa 100644 --- a/design-consultation/SKILL.md.tmpl +++ b/design-consultation/SKILL.md.tmpl @@ -112,7 +112,12 @@ If browse is not available, rely on WebSearch results and your built-in design k **Step 3: Synthesize findings** -The goal of research is NOT to copy. It is to get in the ballpark — to understand the visual language users in this category already expect. This gives you the baseline. The interesting design work starts after you have the baseline: deciding where to follow conventions (so the product feels literate) and where to break from them (so the product is memorable). +**Three-layer synthesis:** +- **Layer 1 (tried and true):** What design patterns does every product in this category share? These are table stakes — users expect them. +- **Layer 2 (new and popular):** What are the search results and current design discourse saying? What's trending? What new patterns are emerging? +- **Layer 3 (first principles):** Given what we know about THIS product's users and positioning — is there a reason the conventional design approach is wrong? Where should we deliberately break from the category norms? + +**Eureka check:** If Layer 3 reasoning reveals a genuine design insight — a reason the category's visual language fails THIS product — name it: "EUREKA: Every [category] product does X because they assume [assumption]. But this product's users [evidence] — so we should do Y instead." Log the eureka moment (see preamble). Summarize conversationally: > "I looked at what's out there. Here's the landscape: they converge on [patterns]. Most of them feel [observation — e.g., interchangeable, polished but generic, etc.]. The opportunity to stand out is [gap]. Here's where I'd play it safe and where I'd take a risk..." diff --git a/investigate/SKILL.md b/investigate/SKILL.md index 858244fa..429300f8 100644 --- a/investigate/SKILL.md +++ b/investigate/SKILL.md @@ -16,6 +16,7 @@ allowed-tools: - Grep - Glob - AskUserQuestion + - WebSearch hooks: PreToolUse: - matcher: "Edit" @@ -328,6 +329,12 @@ Also check: - `TODOS.md` for related known issues - `git log` for prior fixes in the same area — **recurring bugs in the same files are an architectural smell**, not a coincidence +**External pattern search:** If the bug doesn't match a known pattern above, WebSearch for: +- "{framework} {error message or symptom}" +- "{library} {component} known issues" + +If WebSearch is unavailable, skip this search and proceed with hypothesis testing. If a documented solution or known dependency bug surfaces, present it as a candidate hypothesis in Phase 3. + --- ## Phase 3: Hypothesis Testing @@ -336,7 +343,7 @@ Before writing ANY fix, verify your hypothesis. 1. **Confirm the hypothesis:** Add a temporary log statement, assertion, or debug output at the suspected root cause. Run the reproduction. Does the evidence match? -2. **If the hypothesis is wrong:** Return to Phase 1. Gather more evidence. Do not guess. +2. **If the hypothesis is wrong:** Before forming the next hypothesis, WebSearch for the exact error message (quoted) and "{component} {unexpected behavior} {framework version}". This often surfaces version-specific regressions or known issues that save hypothesis cycles. If WebSearch is unavailable, skip and proceed. Then return to Phase 1. Gather more evidence. Do not guess. 3. **3-strike rule:** If 3 hypotheses fail, **STOP**. Use AskUserQuestion: ``` diff --git a/investigate/SKILL.md.tmpl b/investigate/SKILL.md.tmpl index 4db09f30..532e4b7a 100644 --- a/investigate/SKILL.md.tmpl +++ b/investigate/SKILL.md.tmpl @@ -16,6 +16,7 @@ allowed-tools: - Grep - Glob - AskUserQuestion + - WebSearch hooks: PreToolUse: - matcher: "Edit" @@ -104,6 +105,12 @@ Also check: - `TODOS.md` for related known issues - `git log` for prior fixes in the same area — **recurring bugs in the same files are an architectural smell**, not a coincidence +**External pattern search:** If the bug doesn't match a known pattern above, WebSearch for: +- "{framework} {error message or symptom}" +- "{library} {component} known issues" + +If WebSearch is unavailable, skip this search and proceed with hypothesis testing. If a documented solution or known dependency bug surfaces, present it as a candidate hypothesis in Phase 3. + --- ## Phase 3: Hypothesis Testing @@ -112,7 +119,7 @@ Before writing ANY fix, verify your hypothesis. 1. **Confirm the hypothesis:** Add a temporary log statement, assertion, or debug output at the suspected root cause. Run the reproduction. Does the evidence match? -2. **If the hypothesis is wrong:** Return to Phase 1. Gather more evidence. Do not guess. +2. **If the hypothesis is wrong:** Before forming the next hypothesis, WebSearch for the exact error message (quoted) and "{component} {unexpected behavior} {framework version}". This often surfaces version-specific regressions or known issues that save hypothesis cycles. If WebSearch is unavailable, skip and proceed. Then return to Phase 1. Gather more evidence. Do not guess. 3. **3-strike rule:** If 3 hypotheses fail, **STOP**. Use AskUserQuestion: ``` diff --git a/office-hours/SKILL.md b/office-hours/SKILL.md index c9535130..6f7c7f86 100644 --- a/office-hours/SKILL.md +++ b/office-hours/SKILL.md @@ -19,6 +19,7 @@ allowed-tools: - Write - Edit - AskUserQuestion + - WebSearch --- @@ -476,6 +477,37 @@ If no matches found, proceed silently. --- +## Phase 2.75: Landscape Awareness + +Read ETHOS.md for the full Search Before Building framework (three layers, eureka moments). The preamble's Search Before Building section has the ETHOS.md path. + +After understanding the problem through questioning, search for what the world thinks. This is NOT competitive research (that's /design-consultation's job). This is understanding conventional wisdom so you can evaluate where it's wrong. + +If WebSearch is unavailable, skip this phase and note: "Search unavailable — proceeding with in-distribution knowledge only." + +**Startup mode:** WebSearch for: +- "[problem space] startup approach {current year}" +- "[problem space] common mistakes" +- "why [incumbent solution] fails" OR "why [incumbent solution] works" + +**Builder mode:** WebSearch for: +- "[thing being built] existing solutions" +- "[thing being built] open source alternatives" +- "best [thing category] {current year}" + +Read the top 2-3 results. Run the three-layer synthesis: +- **[Layer 1]** What does everyone already know about this space? +- **[Layer 2]** What are the search results and current discourse saying? +- **[Layer 3]** Given what WE learned in Phase 2A/2B — is there a reason the conventional approach is wrong? + +**Eureka check:** If Layer 3 reasoning reveals a genuine insight, name it: "EUREKA: Everyone does X because they assume [assumption]. But [evidence from our conversation] suggests that's wrong here. This means [implication]." Log the eureka moment (see preamble). + +If no eureka moment exists, say: "The conventional wisdom seems sound here. Let's build on it." Proceed to Phase 3. + +**Important:** This search feeds Phase 3 (Premise Challenge). If you found reasons the conventional approach fails, those become premises to challenge. If conventional wisdom is solid, that raises the bar for any premise that contradicts it. + +--- + ## Phase 3: Premise Challenge Before proposing solutions, challenge the premises: diff --git a/office-hours/SKILL.md.tmpl b/office-hours/SKILL.md.tmpl index e0ff98a7..2db4c72f 100644 --- a/office-hours/SKILL.md.tmpl +++ b/office-hours/SKILL.md.tmpl @@ -19,6 +19,7 @@ allowed-tools: - Write - Edit - AskUserQuestion + - WebSearch --- {{PREAMBLE}} @@ -235,6 +236,37 @@ If no matches found, proceed silently. --- +## Phase 2.75: Landscape Awareness + +Read ETHOS.md for the full Search Before Building framework (three layers, eureka moments). The preamble's Search Before Building section has the ETHOS.md path. + +After understanding the problem through questioning, search for what the world thinks. This is NOT competitive research (that's /design-consultation's job). This is understanding conventional wisdom so you can evaluate where it's wrong. + +If WebSearch is unavailable, skip this phase and note: "Search unavailable — proceeding with in-distribution knowledge only." + +**Startup mode:** WebSearch for: +- "[problem space] startup approach {current year}" +- "[problem space] common mistakes" +- "why [incumbent solution] fails" OR "why [incumbent solution] works" + +**Builder mode:** WebSearch for: +- "[thing being built] existing solutions" +- "[thing being built] open source alternatives" +- "best [thing category] {current year}" + +Read the top 2-3 results. Run the three-layer synthesis: +- **[Layer 1]** What does everyone already know about this space? +- **[Layer 2]** What are the search results and current discourse saying? +- **[Layer 3]** Given what WE learned in Phase 2A/2B — is there a reason the conventional approach is wrong? + +**Eureka check:** If Layer 3 reasoning reveals a genuine insight, name it: "EUREKA: Everyone does X because they assume [assumption]. But [evidence from our conversation] suggests that's wrong here. This means [implication]." Log the eureka moment (see preamble). + +If no eureka moment exists, say: "The conventional wisdom seems sound here. Let's build on it." Proceed to Phase 3. + +**Important:** This search feeds Phase 3 (Premise Challenge). If you found reasons the conventional approach fails, those become premises to challenge. If conventional wisdom is solid, that raises the bar for any premise that contradicts it. + +--- + ## Phase 3: Premise Challenge Before proposing solutions, challenge the premises: diff --git a/plan-ceo-review/SKILL.md b/plan-ceo-review/SKILL.md index 5f36c5f1..f209143b 100644 --- a/plan-ceo-review/SKILL.md +++ b/plan-ceo-review/SKILL.md @@ -17,6 +17,7 @@ allowed-tools: - Glob - Bash - AskUserQuestion + - WebSearch --- @@ -405,6 +406,22 @@ Analyze the plan. If it involves ANY of: new UI screens/pages, changes to existi Identify 2-3 files or patterns in the existing codebase that are particularly well-designed. Note them as style references for the review. Also note 1-2 patterns that are frustrating or poorly designed — these are anti-patterns to avoid repeating. Report findings before proceeding to Step 0. +### Landscape Check + +Read ETHOS.md for the Search Before Building framework (the preamble's Search Before Building section has the path). Before challenging scope, understand the landscape. WebSearch for: +- "[product category] landscape {current year}" +- "[key feature] alternatives" +- "why [incumbent/conventional approach] [succeeds/fails]" + +If WebSearch is unavailable, skip this check and note: "Search unavailable — proceeding with in-distribution knowledge only." + +Run the three-layer synthesis: +- **[Layer 1]** What's the tried-and-true approach in this space? +- **[Layer 2]** What are the search results saying? +- **[Layer 3]** First-principles reasoning — where might the conventional wisdom be wrong? + +Feed into the Premise Challenge (0A) and Dream State Mapping (0C). If you find a eureka moment, surface it during the Expansion opt-in ceremony as a differentiation opportunity. Log it (see preamble). + ## Step 0: Nuclear Scope Challenge + Mode Selection ### 0A. Premise Challenge diff --git a/plan-ceo-review/SKILL.md.tmpl b/plan-ceo-review/SKILL.md.tmpl index 8dce40eb..88c00925 100644 --- a/plan-ceo-review/SKILL.md.tmpl +++ b/plan-ceo-review/SKILL.md.tmpl @@ -17,6 +17,7 @@ allowed-tools: - Glob - Bash - AskUserQuestion + - WebSearch --- {{PREAMBLE}} @@ -147,6 +148,22 @@ Analyze the plan. If it involves ANY of: new UI screens/pages, changes to existi Identify 2-3 files or patterns in the existing codebase that are particularly well-designed. Note them as style references for the review. Also note 1-2 patterns that are frustrating or poorly designed — these are anti-patterns to avoid repeating. Report findings before proceeding to Step 0. +### Landscape Check + +Read ETHOS.md for the Search Before Building framework (the preamble's Search Before Building section has the path). Before challenging scope, understand the landscape. WebSearch for: +- "[product category] landscape {current year}" +- "[key feature] alternatives" +- "why [incumbent/conventional approach] [succeeds/fails]" + +If WebSearch is unavailable, skip this check and note: "Search unavailable — proceeding with in-distribution knowledge only." + +Run the three-layer synthesis: +- **[Layer 1]** What's the tried-and-true approach in this space? +- **[Layer 2]** What are the search results saying? +- **[Layer 3]** First-principles reasoning — where might the conventional wisdom be wrong? + +Feed into the Premise Challenge (0A) and Dream State Mapping (0C). If you find a eureka moment, surface it during the Expansion opt-in ceremony as a differentiation opportunity. Log it (see preamble). + ## Step 0: Nuclear Scope Challenge + Mode Selection ### 0A. Premise Challenge diff --git a/plan-eng-review/SKILL.md b/plan-eng-review/SKILL.md index 59d9b8eb..74bc8464 100644 --- a/plan-eng-review/SKILL.md +++ b/plan-eng-review/SKILL.md @@ -16,6 +16,7 @@ allowed-tools: - Glob - AskUserQuestion - Bash + - WebSearch --- @@ -322,7 +323,15 @@ Before reviewing anything, answer these questions: 1. **What existing code already partially or fully solves each sub-problem?** Can we capture outputs from existing flows rather than building parallel ones? 2. **What is the minimum set of changes that achieves the stated goal?** Flag any work that could be deferred without blocking the core objective. Be ruthless about scope creep. 3. **Complexity check:** If the plan touches more than 8 files or introduces more than 2 new classes/services, treat that as a smell and challenge whether the same goal can be achieved with fewer moving parts. -4. **TODOS cross-reference:** Read `TODOS.md` if it exists. Are any deferred items blocking this plan? Can any deferred items be bundled into this PR without expanding scope? Does this plan create new work that should be captured as a TODO? +4. **Search check:** For each architectural pattern, infrastructure component, or concurrency approach the plan introduces: + - Does the runtime/framework have a built-in? Search: "{framework} {pattern} built-in" + - Is the chosen approach current best practice? Search: "{pattern} best practice {current year}" + - Are there known footguns? Search: "{framework} {pattern} pitfalls" + + If WebSearch is unavailable, skip this check and note: "Search unavailable — proceeding with in-distribution knowledge only." + + If the plan rolls a custom solution where a built-in exists, flag it as a scope reduction opportunity. Annotate recommendations with **[Layer 1]**, **[Layer 2]**, **[Layer 3]**, or **[EUREKA]** (see preamble's Search Before Building section). If you find a eureka moment — a reason the standard approach is wrong for this case — present it as an architectural insight. +5. **TODOS cross-reference:** Read `TODOS.md` if it exists. Are any deferred items blocking this plan? Can any deferred items be bundled into this PR without expanding scope? Does this plan create new work that should be captured as a TODO? 5. **Completeness check:** Is the plan doing the complete version or a shortcut? With AI-assisted coding, the cost of completeness (100% test coverage, full edge case handling, complete error paths) is 10-100x cheaper than with a human team. If the plan proposes a shortcut that saves human-hours but only saves minutes with CC+gstack, recommend the complete version. Boil the lake. diff --git a/plan-eng-review/SKILL.md.tmpl b/plan-eng-review/SKILL.md.tmpl index 09782a9d..bc254d4f 100644 --- a/plan-eng-review/SKILL.md.tmpl +++ b/plan-eng-review/SKILL.md.tmpl @@ -16,6 +16,7 @@ allowed-tools: - Glob - AskUserQuestion - Bash + - WebSearch --- {{PREAMBLE}} @@ -81,7 +82,15 @@ Before reviewing anything, answer these questions: 1. **What existing code already partially or fully solves each sub-problem?** Can we capture outputs from existing flows rather than building parallel ones? 2. **What is the minimum set of changes that achieves the stated goal?** Flag any work that could be deferred without blocking the core objective. Be ruthless about scope creep. 3. **Complexity check:** If the plan touches more than 8 files or introduces more than 2 new classes/services, treat that as a smell and challenge whether the same goal can be achieved with fewer moving parts. -4. **TODOS cross-reference:** Read `TODOS.md` if it exists. Are any deferred items blocking this plan? Can any deferred items be bundled into this PR without expanding scope? Does this plan create new work that should be captured as a TODO? +4. **Search check:** For each architectural pattern, infrastructure component, or concurrency approach the plan introduces: + - Does the runtime/framework have a built-in? Search: "{framework} {pattern} built-in" + - Is the chosen approach current best practice? Search: "{pattern} best practice {current year}" + - Are there known footguns? Search: "{framework} {pattern} pitfalls" + + If WebSearch is unavailable, skip this check and note: "Search unavailable — proceeding with in-distribution knowledge only." + + If the plan rolls a custom solution where a built-in exists, flag it as a scope reduction opportunity. Annotate recommendations with **[Layer 1]**, **[Layer 2]**, **[Layer 3]**, or **[EUREKA]** (see preamble's Search Before Building section). If you find a eureka moment — a reason the standard approach is wrong for this case — present it as an architectural insight. +5. **TODOS cross-reference:** Read `TODOS.md` if it exists. Are any deferred items blocking this plan? Can any deferred items be bundled into this PR without expanding scope? Does this plan create new work that should be captured as a TODO? 5. **Completeness check:** Is the plan doing the complete version or a shortcut? With AI-assisted coding, the cost of completeness (100% test coverage, full edge case handling, complete error paths) is 10-100x cheaper than with a human team. If the plan proposes a shortcut that saves human-hours but only saves minutes with CC+gstack, recommend the complete version. Boil the lake. diff --git a/qa-only/SKILL.md b/qa-only/SKILL.md index 6cdcd4e5..a46233a3 100644 --- a/qa-only/SKILL.md +++ b/qa-only/SKILL.md @@ -12,6 +12,7 @@ allowed-tools: - Read - Write - AskUserQuestion + - WebSearch --- diff --git a/qa-only/SKILL.md.tmpl b/qa-only/SKILL.md.tmpl index e85d643a..293a7b36 100644 --- a/qa-only/SKILL.md.tmpl +++ b/qa-only/SKILL.md.tmpl @@ -12,6 +12,7 @@ allowed-tools: - Read - Write - AskUserQuestion + - WebSearch --- {{PREAMBLE}} diff --git a/retro/SKILL.md b/retro/SKILL.md index 1a77bc23..635b5747 100644 --- a/retro/SKILL.md +++ b/retro/SKILL.md @@ -396,6 +396,20 @@ If TODOS.md doesn't exist, skip the Backlog Health row. If the JSONL file doesn't exist or has no entries in the window, skip the Skill Usage row. +**Eureka Moments (if logged):** Read `~/.gstack/analytics/eureka.jsonl` if it exists. Filter entries within the retro time window by `ts` field. For each eureka moment, show the skill that flagged it, the branch, and a one-line summary of the insight. Present as: + +``` +| Eureka Moments | 2 this period | +``` + +If moments exist, list them: +``` + EUREKA /office-hours (branch: garrytan/auth-rethink): "Session tokens don't need server storage — browser crypto API makes client-side JWT validation viable" + EUREKA /plan-eng-review (branch: garrytan/cache-layer): "Redis isn't needed here — Bun's built-in LRU cache handles this workload" +``` + +If the JSONL file doesn't exist or has no entries in the window, skip the Eureka Moments row. + ### Step 3: Commit Time Distribution Show hourly histogram in local time using bar chart: diff --git a/retro/SKILL.md.tmpl b/retro/SKILL.md.tmpl index a81b12c9..b3fe8046 100644 --- a/retro/SKILL.md.tmpl +++ b/retro/SKILL.md.tmpl @@ -172,6 +172,20 @@ If TODOS.md doesn't exist, skip the Backlog Health row. If the JSONL file doesn't exist or has no entries in the window, skip the Skill Usage row. +**Eureka Moments (if logged):** Read `~/.gstack/analytics/eureka.jsonl` if it exists. Filter entries within the retro time window by `ts` field. For each eureka moment, show the skill that flagged it, the branch, and a one-line summary of the insight. Present as: + +``` +| Eureka Moments | 2 this period | +``` + +If moments exist, list them: +``` + EUREKA /office-hours (branch: garrytan/auth-rethink): "Session tokens don't need server storage — browser crypto API makes client-side JWT validation viable" + EUREKA /plan-eng-review (branch: garrytan/cache-layer): "Redis isn't needed here — Bun's built-in LRU cache handles this workload" +``` + +If the JSONL file doesn't exist or has no entries in the window, skip the Eureka Moments row. + ### Step 3: Commit Time Distribution Show hourly histogram in local time using bar chart: diff --git a/review/SKILL.md b/review/SKILL.md index 1dfda89f..83a145f5 100644 --- a/review/SKILL.md +++ b/review/SKILL.md @@ -14,6 +14,7 @@ allowed-tools: - Grep - Glob - AskUserQuestion + - WebSearch --- @@ -348,6 +349,13 @@ Apply the checklist against the diff in two passes: **Enum & Value Completeness requires reading code OUTSIDE the diff.** When the diff introduces a new enum value, status, tier, or type constant, use Grep to find all files that reference sibling values, then Read those files to check if the new value is handled. This is the one category where within-diff review is insufficient. +**Search-before-recommending:** When recommending a fix pattern (especially for concurrency, caching, auth, or framework-specific behavior): +- Verify the pattern is current best practice for the framework version in use +- Check if a built-in solution exists in newer versions before recommending a workaround +- Verify API signatures against current docs (APIs change between versions) + +Takes seconds, prevents recommending outdated patterns. If WebSearch is unavailable, note it and proceed with in-distribution knowledge. + Follow the output format specified in the checklist. Respect the suppressions — do NOT flag items listed in the "DO NOT flag" section. --- diff --git a/review/SKILL.md.tmpl b/review/SKILL.md.tmpl index 34a25018..3e65ce27 100644 --- a/review/SKILL.md.tmpl +++ b/review/SKILL.md.tmpl @@ -14,6 +14,7 @@ allowed-tools: - Grep - Glob - AskUserQuestion + - WebSearch --- {{PREAMBLE}} @@ -107,6 +108,13 @@ Apply the checklist against the diff in two passes: **Enum & Value Completeness requires reading code OUTSIDE the diff.** When the diff introduces a new enum value, status, tier, or type constant, use Grep to find all files that reference sibling values, then Read those files to check if the new value is handled. This is the one category where within-diff review is insufficient. +**Search-before-recommending:** When recommending a fix pattern (especially for concurrency, caching, auth, or framework-specific behavior): +- Verify the pattern is current best practice for the framework version in use +- Check if a built-in solution exists in newer versions before recommending a workaround +- Verify API signatures against current docs (APIs change between versions) + +Takes seconds, prevents recommending outdated patterns. If WebSearch is unavailable, note it and proceed with in-distribution knowledge. + Follow the output format specified in the checklist. Respect the suppressions — do NOT flag items listed in the "DO NOT flag" section. ---