fix: /office-hours and /ceo-review accidentally contradict Boil the Lake

ETHOS.md

@@ -56,7 +56,44 @@ Read more: https://garryslist.org/posts/boil-the-ocean
 
 ---
 
-## 2. Search Before Building
+## 2. The Two Axes of Scope
+
+Scope is not one thing. It is two completely different axes, and conflating
+them is one of the most common mistakes builders make with AI.
+
+**Product scope** is WHAT you build. This is strategy. Narrowing product scope
+is almost always right early on — find the narrowest wedge someone will pay
+for, strip to the essential feature, do fewer things better. Jobs went from
+350 products to 10. YC's best advice is "launch something small this week."
+This is correct. This is how you find product-market fit.
+
+**Implementation scope** is HOW COMPLETELY you build it. This is engineering.
+Once you've decided what to build, Boil the Lake applies at full force. Every
+edge case. Every error path. Every test. The marginal cost of completeness is
+near-zero with AI. There is no excuse for shipping half-built code when the
+complete version costs minutes more.
+
+The confusion — and it is rampant — is treating these as the same axis.
+Someone hears "narrow your scope" and cuts the test suite. Someone hears
+"minimum viable" and skips error handling. That is a category error. "Minimum
+viable" describes the product surface. Completeness describes the
+implementation quality. They are independent variables.
+
+**Narrow the product. Boil the implementation.**
+
+A narrowest-wedge product with complete implementation beats a broad product
+with shortcuts every time. The wedge is small — maybe one feature, one
+workflow, one automation. But that wedge is bulletproof. Every failure mode
+handled. Every edge case covered. Every test written. Because with AI,
+completeness is cheap.
+
+**Anti-pattern:** "We're just building an MVP, so we don't need tests / error
+handling / edge cases." No. The M in MVP is about the product surface, not the
+engineering quality. Ship a small product. Ship it complete.
+
+---
+
+## 3. Search Before Building
 
 The 1000x engineer's first instinct is "has someone already solved this?" not
 "let me design it from scratch." Before building anything involving unfamiliar
@@ -113,6 +150,10 @@ Boil the Lake says: **do the complete thing.**
 Search Before Building says: **know what exists before you decide what to build.**
 
 Together: search first, then build the complete version of the right thing.
+And when someone tells you to narrow scope, know WHICH axis they mean. Narrow
+the product scope (what you build). Never narrow the implementation scope (how
+completely you build it).
+
 The worst outcome is building a complete version of something that already
 exists as a one-liner. The best outcome is building a complete version of
 something nobody has thought of yet — because you searched, understood the

autoplan/SKILL.md

@@ -218,6 +218,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Repo Ownership — See Something, Say Something
 
 `REPO_MODE` controls how to handle issues outside your branch:

canary/SKILL.md

@@ -211,6 +211,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Contributor Mode
 
 If `_CONTRIB` is `true`: you are in **contributor mode**. At the end of each major workflow step, rate your gstack experience 0-10. If not a 10 and there's an actionable bug or improvement — file a field report.

codex/SKILL.md

@@ -212,6 +212,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Repo Ownership — See Something, Say Something
 
 `REPO_MODE` controls how to handle issues outside your branch:

connect-chrome/SKILL.md

@@ -209,6 +209,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Repo Ownership — See Something, Say Something
 
 `REPO_MODE` controls how to handle issues outside your branch:

cso/SKILL.md

@@ -215,6 +215,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Contributor Mode
 
 If `_CONTRIB` is `true`: you are in **contributor mode**. At the end of each major workflow step, rate your gstack experience 0-10. If not a 10 and there's an actionable bug or improvement — file a field report.

design-consultation/SKILL.md

@@ -216,6 +216,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Repo Ownership — See Something, Say Something
 
 `REPO_MODE` controls how to handle issues outside your branch:

design-review/SKILL.md

@@ -216,6 +216,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Repo Ownership — See Something, Say Something
 
 `REPO_MODE` controls how to handle issues outside your branch:

design-shotgun/SKILL.md

@@ -213,6 +213,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Contributor Mode
 
 If `_CONTRIB` is `true`: you are in **contributor mode**. At the end of each major workflow step, rate your gstack experience 0-10. If not a 10 and there's an actionable bug or improvement — file a field report.

document-release/SKILL.md

@@ -213,6 +213,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Contributor Mode
 
 If `_CONTRIB` is `true`: you are in **contributor mode**. At the end of each major workflow step, rate your gstack experience 0-10. If not a 10 and there's an actionable bug or improvement — file a field report.

investigate/SKILL.md

@@ -227,6 +227,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Contributor Mode
 
 If `_CONTRIB` is `true`: you are in **contributor mode**. At the end of each major workflow step, rate your gstack experience 0-10. If not a 10 and there's an actionable bug or improvement — file a field report.

land-and-deploy/SKILL.md

@@ -210,6 +210,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Repo Ownership — See Something, Say Something
 
 `REPO_MODE` controls how to handle issues outside your branch:

office-hours/SKILL.md

@@ -218,6 +218,8 @@ AI makes completeness near-free. Always recommend the complete option over short
 
 Include `Completeness: X/10` for each option (10=all edge cases, 7=happy path, 3=shortcut).
 
+**Two axes of scope:** "Scope" is two things, not one. **Product scope** (WHAT you build) should often be narrow — narrowest wedge, focus as subtraction, fewer things done better. **Implementation scope** (HOW COMPLETELY you build it) should always be maximal — Boil the Lake. When someone says "reduce scope," they mean the product surface. Never cut implementation quality. Narrow the product, boil the implementation.
+
 ## Repo Ownership — See Something, Say Something
 
 `REPO_MODE` controls how to handle issues outside your branch:
@@ -442,7 +444,7 @@ These are non-negotiable. They shape every response in this mode.
 
 **The status quo is your real competitor.** Not the other startup, not the big company — the cobbled-together spreadsheet-and-Slack-messages workaround your user is already living with. If "nothing" is the current solution, that's usually a sign the problem isn't painful enough to act on.
 
-**Narrow beats wide, early.** The smallest version someone will pay real money for this week is more valuable than the full platform vision. Wedge first. Expand from strength.
+**Narrow beats wide, early.** The smallest version someone will pay real money for this week is more valuable than the full platform vision. Wedge first. Expand from strength. But "narrow" means the product surface — what you ship. Once you've chosen the wedge, build it completely. Every edge case, every test, every error path. Completeness is cheap. (See the Completeness Principle above.)
 
 ### Response Posture
 
@@ -547,6 +549,8 @@ If the framing is imprecise, **reframe constructively** — don't dissolve the q
 
 **Bonus push:** "What if the user didn't have to do anything at all to get value? No login, no integration, no setup. What would that look like?"
 
+**Important distinction:** Narrowest wedge is about PRODUCT scope — the smallest feature set someone pays for. It is NOT about implementation quality. Once the wedge is chosen, Boil the Lake applies: complete error handling, full test coverage, all edge cases. The wedge is small. The engineering is thorough. That's how you ship something someone trusts enough to pay for.
+
 #### Q5: Observation & Surprise
 
 **Ask:** "Have you actually sat down and watched someone use this without helping them? What did they do that surprised you?"

office-hours/SKILL.md.tmpl

@@ -97,7 +97,7 @@ These are non-negotiable. They shape every response in this mode.
 
 **The status quo is your real competitor.** Not the other startup, not the big company — the cobbled-together spreadsheet-and-Slack-messages workaround your user is already living with. If "nothing" is the current solution, that's usually a sign the problem isn't painful enough to act on.
 
-**Narrow beats wide, early.** The smallest version someone will pay real money for this week is more valuable than the full platform vision. Wedge first. Expand from strength.
+**Narrow beats wide, early.** The smallest version someone will pay real money for this week is more valuable than the full platform vision. Wedge first. Expand from strength. But "narrow" means the product surface — what you ship. Once you've chosen the wedge, build it completely. Every edge case, every test, every error path. Completeness is cheap. (See the Completeness Principle above.)
 
 ### Response Posture
 
@@ -202,6 +202,8 @@ If the framing is imprecise, **reframe constructively** — don't dissolve the q
 
 **Bonus push:** "What if the user didn't have to do anything at all to get value? No login, no integration, no setup. What would that look like?"
 
+**Important distinction:** Narrowest wedge is about PRODUCT scope — the smallest feature set someone pays for. It is NOT about implementation quality. Once the wedge is chosen, Boil the Lake applies: complete error handling, full test coverage, all edge cases. The wedge is small. The engineering is thorough. That's how you ship something someone trusts enough to pay for.
+
 #### Q5: Observation & Surprise
 
 **Ask:** "Have you actually sat down and watched someone use this without helping them? What did they do that surprised you?"