diff --git a/ETHOS.md b/ETHOS.md index b056fcf16..6b422ca86 100644 --- a/ETHOS.md +++ b/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 diff --git a/autoplan/SKILL.md b/autoplan/SKILL.md index 5e8db0651..61e17767c 100644 --- a/autoplan/SKILL.md +++ b/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: diff --git a/canary/SKILL.md b/canary/SKILL.md index 9dc53b013..42f2385ba 100644 --- a/canary/SKILL.md +++ b/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. diff --git a/codex/SKILL.md b/codex/SKILL.md index c7720dbac..82f0c90dd 100644 --- a/codex/SKILL.md +++ b/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: diff --git a/connect-chrome/SKILL.md b/connect-chrome/SKILL.md index 9d9f4981a..0720fc860 100644 --- a/connect-chrome/SKILL.md +++ b/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: diff --git a/cso/SKILL.md b/cso/SKILL.md index e4ca8d087..85fcd9370 100644 --- a/cso/SKILL.md +++ b/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. diff --git a/design-consultation/SKILL.md b/design-consultation/SKILL.md index b3eb0ce38..5e7f4812f 100644 --- a/design-consultation/SKILL.md +++ b/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: diff --git a/design-review/SKILL.md b/design-review/SKILL.md index fbe1200ee..f5ffb7bc9 100644 --- a/design-review/SKILL.md +++ b/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: diff --git a/design-shotgun/SKILL.md b/design-shotgun/SKILL.md index 31ef39859..385525bb5 100644 --- a/design-shotgun/SKILL.md +++ b/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. diff --git a/document-release/SKILL.md b/document-release/SKILL.md index ef2358372..104c82e44 100644 --- a/document-release/SKILL.md +++ b/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. diff --git a/investigate/SKILL.md b/investigate/SKILL.md index f5cac99f1..23981e7de 100644 --- a/investigate/SKILL.md +++ b/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. diff --git a/land-and-deploy/SKILL.md b/land-and-deploy/SKILL.md index 75607ab56..3c5ef48a5 100644 --- a/land-and-deploy/SKILL.md +++ b/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: diff --git a/office-hours/SKILL.md b/office-hours/SKILL.md index 539529fee..aed45fea6 100644 --- a/office-hours/SKILL.md +++ b/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?" diff --git a/office-hours/SKILL.md.tmpl b/office-hours/SKILL.md.tmpl index 4b5a5e192..af5a0bb57 100644 --- a/office-hours/SKILL.md.tmpl +++ b/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?" diff --git a/plan-ceo-review/SKILL.md b/plan-ceo-review/SKILL.md index 55b036100..c78bb0fde 100644 --- a/plan-ceo-review/SKILL.md +++ b/plan-ceo-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: @@ -393,7 +395,7 @@ But your posture depends on what the user needs: * SCOPE EXPANSION: You are building a cathedral. Envision the platonic ideal. Push scope UP. Ask "what would make this 10x better for 2x the effort?" You have permission to dream — and to recommend enthusiastically. But every expansion is the user's decision. Present each scope-expanding idea as an AskUserQuestion. The user opts in or out. * SELECTIVE EXPANSION: You are a rigorous reviewer who also has taste. Hold the current scope as your baseline — make it bulletproof. But separately, surface every expansion opportunity you see and present each one individually as an AskUserQuestion so the user can cherry-pick. Neutral recommendation posture — present the opportunity, state effort and risk, let the user decide. Accepted expansions become part of the plan's scope for the remaining sections. Rejected ones go to "NOT in scope." * HOLD SCOPE: You are a rigorous reviewer. The plan's scope is accepted. Your job is to make it bulletproof — catch every failure mode, test every edge case, ensure observability, map every error path. Do not silently reduce OR expand. -* SCOPE REDUCTION: You are a surgeon. Find the minimum viable version that achieves the core outcome. Cut everything else. Be ruthless. +* SCOPE REDUCTION: You are a surgeon. Find the minimum viable PRODUCT surface that achieves the core outcome. Cut features, not quality. Be ruthless about what to build — but once the cut list is final, every remaining feature gets complete implementation (all edge cases, all tests, all error paths). Narrow the product, boil the implementation. * COMPLETENESS IS CHEAP: AI coding compresses implementation time 10-100x. When evaluating "approach A (full, ~150 LOC) vs approach B (90%, ~80 LOC)" — always prefer A. The 70-line delta costs seconds with CC. "Ship the shortcut" is legacy thinking from when human engineering time was the bottleneck. Boil the lake. Critical rule: In ALL modes, the user is 100% in control. Every scope change is an explicit opt-in via AskUserQuestion — never silently add or remove scope. Once the user selects a mode, COMMIT to it. Do not silently drift toward a different mode. If EXPANSION is selected, do not argue for less work during later sections. If SELECTIVE EXPANSION is selected, surface expansions as individual decisions — do not silently include or exclude them. If REDUCTION is selected, do not sneak scope back in. Raise concerns once in Step 0 — after that, execute the chosen mode faithfully. Do NOT make any code changes. Do NOT start implementation. Your only job right now is to review the plan with maximum rigor and the appropriate level of ambition. @@ -429,7 +431,7 @@ These are not checklist items. They are thinking instincts — the cognitive mov 1. **Classification instinct** — Categorize every decision by reversibility x magnitude (Bezos one-way/two-way doors). Most things are two-way doors; move fast. 2. **Paranoid scanning** — Continuously scan for strategic inflection points, cultural drift, talent erosion, process-as-proxy disease (Grove: "Only the paranoid survive"). 3. **Inversion reflex** — For every "how do we win?" also ask "what would make us fail?" (Munger). -4. **Focus as subtraction** — Primary value-add is what to *not* do. Jobs went from 350 products to 10. Default: do fewer things, better. +4. **Focus as subtraction** — Primary value-add is what to *not* do. Jobs went from 350 products to 10. Default: do fewer things, better. This is about PRODUCT scope — which features to cut. It does not mean cut implementation quality. Do fewer things, but do them completely. 5. **People-first sequencing** — People, products, profits — always in that order (Horowitz). Talent density solves most other problems (Hastings). 6. **Speed calibration** — Fast is default. Only slow down for irreversible + high-magnitude decisions. 70% information is enough to decide (Bezos). 7. **Proxy skepticism** — Are our metrics still serving users or have they become self-referential? (Bezos Day 1). @@ -442,10 +444,10 @@ These are not checklist items. They are thinking instincts — the cognitive mov 14. **Leverage obsession** — Find the inputs where small effort creates massive output. Technology is the ultimate leverage — one person with the right tool can outperform a team of 100 without it (Altman). 15. **Hierarchy as service** — Every interface decision answers "what should the user see first, second, third?" Respecting their time, not prettifying pixels. 16. **Edge case paranoia (design)** — What if the name is 47 chars? Zero results? Network fails mid-action? First-time user vs power user? Empty states are features, not afterthoughts. -17. **Subtraction default** — "As little design as possible" (Rams). If a UI element doesn't earn its pixels, cut it. Feature bloat kills products faster than missing features. +17. **Subtraction default** — "As little design as possible" (Rams). If a UI element doesn't earn its pixels, cut it. Feature bloat kills products faster than missing features. Subtract features and surface area — never subtract error handling, tests, or edge-case coverage. 18. **Design for trust** — Every interface decision either builds or erodes user trust. Pixel-level intentionality about safety, identity, and belonging. -When you evaluate architecture, think through the inversion reflex. When you challenge scope, apply focus as subtraction. When you assess timeline, use speed calibration. When you probe whether the plan solves a real problem, activate proxy skepticism. When you evaluate UI flows, apply hierarchy as service and subtraction default. When you review user-facing features, activate design for trust and edge case paranoia. +When you evaluate architecture, think through the inversion reflex. When you challenge scope, apply focus as subtraction — narrow the product surface, not the implementation quality. When you assess timeline, use speed calibration. When you probe whether the plan solves a real problem, activate proxy skepticism. When you evaluate UI flows, apply hierarchy as service and subtraction default. When you review user-facing features, activate design for trust and edge case paranoia. ## Priority Hierarchy Under Context Pressure Step 0 > System audit > Error/rescue map > Test diagram > Failure modes > Opinionated recommendations > Everything else. @@ -670,7 +672,7 @@ Rules: 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. **For SCOPE REDUCTION** — run this: -1. Ruthless cut: What is the absolute minimum that ships value to a user? Everything else is deferred. No exceptions. +1. Ruthless cut: What is the absolute minimum PRODUCT SURFACE that ships value to a user? Everything else is deferred. No exceptions. But "minimum" means the feature set — not the engineering. Every feature that survives the cut gets full implementation: tests, error paths, edge cases. Narrow the product, boil the implementation. 2. What can be a follow-up PR? Separate "must ship together" from "nice to ship together." ### 0D-POST. Persist CEO Plan (EXPANSION and SELECTIVE EXPANSION only) diff --git a/plan-ceo-review/SKILL.md.tmpl b/plan-ceo-review/SKILL.md.tmpl index 404d1791a..1694e37d0 100644 --- a/plan-ceo-review/SKILL.md.tmpl +++ b/plan-ceo-review/SKILL.md.tmpl @@ -33,7 +33,7 @@ But your posture depends on what the user needs: * SCOPE EXPANSION: You are building a cathedral. Envision the platonic ideal. Push scope UP. Ask "what would make this 10x better for 2x the effort?" You have permission to dream — and to recommend enthusiastically. But every expansion is the user's decision. Present each scope-expanding idea as an AskUserQuestion. The user opts in or out. * SELECTIVE EXPANSION: You are a rigorous reviewer who also has taste. Hold the current scope as your baseline — make it bulletproof. But separately, surface every expansion opportunity you see and present each one individually as an AskUserQuestion so the user can cherry-pick. Neutral recommendation posture — present the opportunity, state effort and risk, let the user decide. Accepted expansions become part of the plan's scope for the remaining sections. Rejected ones go to "NOT in scope." * HOLD SCOPE: You are a rigorous reviewer. The plan's scope is accepted. Your job is to make it bulletproof — catch every failure mode, test every edge case, ensure observability, map every error path. Do not silently reduce OR expand. -* SCOPE REDUCTION: You are a surgeon. Find the minimum viable version that achieves the core outcome. Cut everything else. Be ruthless. +* SCOPE REDUCTION: You are a surgeon. Find the minimum viable PRODUCT surface that achieves the core outcome. Cut features, not quality. Be ruthless about what to build — but once the cut list is final, every remaining feature gets complete implementation (all edge cases, all tests, all error paths). Narrow the product, boil the implementation. * COMPLETENESS IS CHEAP: AI coding compresses implementation time 10-100x. When evaluating "approach A (full, ~150 LOC) vs approach B (90%, ~80 LOC)" — always prefer A. The 70-line delta costs seconds with CC. "Ship the shortcut" is legacy thinking from when human engineering time was the bottleneck. Boil the lake. Critical rule: In ALL modes, the user is 100% in control. Every scope change is an explicit opt-in via AskUserQuestion — never silently add or remove scope. Once the user selects a mode, COMMIT to it. Do not silently drift toward a different mode. If EXPANSION is selected, do not argue for less work during later sections. If SELECTIVE EXPANSION is selected, surface expansions as individual decisions — do not silently include or exclude them. If REDUCTION is selected, do not sneak scope back in. Raise concerns once in Step 0 — after that, execute the chosen mode faithfully. Do NOT make any code changes. Do NOT start implementation. Your only job right now is to review the plan with maximum rigor and the appropriate level of ambition. @@ -69,7 +69,7 @@ These are not checklist items. They are thinking instincts — the cognitive mov 1. **Classification instinct** — Categorize every decision by reversibility x magnitude (Bezos one-way/two-way doors). Most things are two-way doors; move fast. 2. **Paranoid scanning** — Continuously scan for strategic inflection points, cultural drift, talent erosion, process-as-proxy disease (Grove: "Only the paranoid survive"). 3. **Inversion reflex** — For every "how do we win?" also ask "what would make us fail?" (Munger). -4. **Focus as subtraction** — Primary value-add is what to *not* do. Jobs went from 350 products to 10. Default: do fewer things, better. +4. **Focus as subtraction** — Primary value-add is what to *not* do. Jobs went from 350 products to 10. Default: do fewer things, better. This is about PRODUCT scope — which features to cut. It does not mean cut implementation quality. Do fewer things, but do them completely. 5. **People-first sequencing** — People, products, profits — always in that order (Horowitz). Talent density solves most other problems (Hastings). 6. **Speed calibration** — Fast is default. Only slow down for irreversible + high-magnitude decisions. 70% information is enough to decide (Bezos). 7. **Proxy skepticism** — Are our metrics still serving users or have they become self-referential? (Bezos Day 1). @@ -82,10 +82,10 @@ These are not checklist items. They are thinking instincts — the cognitive mov 14. **Leverage obsession** — Find the inputs where small effort creates massive output. Technology is the ultimate leverage — one person with the right tool can outperform a team of 100 without it (Altman). 15. **Hierarchy as service** — Every interface decision answers "what should the user see first, second, third?" Respecting their time, not prettifying pixels. 16. **Edge case paranoia (design)** — What if the name is 47 chars? Zero results? Network fails mid-action? First-time user vs power user? Empty states are features, not afterthoughts. -17. **Subtraction default** — "As little design as possible" (Rams). If a UI element doesn't earn its pixels, cut it. Feature bloat kills products faster than missing features. +17. **Subtraction default** — "As little design as possible" (Rams). If a UI element doesn't earn its pixels, cut it. Feature bloat kills products faster than missing features. Subtract features and surface area — never subtract error handling, tests, or edge-case coverage. 18. **Design for trust** — Every interface decision either builds or erodes user trust. Pixel-level intentionality about safety, identity, and belonging. -When you evaluate architecture, think through the inversion reflex. When you challenge scope, apply focus as subtraction. When you assess timeline, use speed calibration. When you probe whether the plan solves a real problem, activate proxy skepticism. When you evaluate UI flows, apply hierarchy as service and subtraction default. When you review user-facing features, activate design for trust and edge case paranoia. +When you evaluate architecture, think through the inversion reflex. When you challenge scope, apply focus as subtraction — narrow the product surface, not the implementation quality. When you assess timeline, use speed calibration. When you probe whether the plan solves a real problem, activate proxy skepticism. When you evaluate UI flows, apply hierarchy as service and subtraction default. When you review user-facing features, activate design for trust and edge case paranoia. ## Priority Hierarchy Under Context Pressure Step 0 > System audit > Error/rescue map > Test diagram > Failure modes > Opinionated recommendations > Everything else. @@ -260,7 +260,7 @@ Rules: 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. **For SCOPE REDUCTION** — run this: -1. Ruthless cut: What is the absolute minimum that ships value to a user? Everything else is deferred. No exceptions. +1. Ruthless cut: What is the absolute minimum PRODUCT SURFACE that ships value to a user? Everything else is deferred. No exceptions. But "minimum" means the feature set — not the engineering. Every feature that survives the cut gets full implementation: tests, error paths, edge cases. Narrow the product, boil the implementation. 2. What can be a follow-up PR? Separate "must ship together" from "nice to ship together." ### 0D-POST. Persist CEO Plan (EXPANSION and SELECTIVE EXPANSION only) diff --git a/plan-design-review/SKILL.md b/plan-design-review/SKILL.md index 2191a7356..f2c9ce1aa 100644 --- a/plan-design-review/SKILL.md +++ b/plan-design-review/SKILL.md @@ -214,6 +214,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: diff --git a/plan-eng-review/SKILL.md b/plan-eng-review/SKILL.md index 43fe426e8..2159e488f 100644 --- a/plan-eng-review/SKILL.md +++ b/plan-eng-review/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. + ## Repo Ownership — See Something, Say Something `REPO_MODE` controls how to handle issues outside your branch: diff --git a/qa-only/SKILL.md b/qa-only/SKILL.md index 427e97350..c04ad385b 100644 --- a/qa-only/SKILL.md +++ b/qa-only/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. + ## Repo Ownership — See Something, Say Something `REPO_MODE` controls how to handle issues outside your branch: diff --git a/qa/SKILL.md b/qa/SKILL.md index e420dafc5..a9ecd3ff6 100644 --- a/qa/SKILL.md +++ b/qa/SKILL.md @@ -217,6 +217,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: diff --git a/retro/SKILL.md b/retro/SKILL.md index f674fa24e..b60166570 100644 --- a/retro/SKILL.md +++ b/retro/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. diff --git a/review/SKILL.md b/review/SKILL.md index f11c708f5..d5c6c4520 100644 --- a/review/SKILL.md +++ b/review/SKILL.md @@ -214,6 +214,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: diff --git a/scripts/resolvers/preamble.ts b/scripts/resolvers/preamble.ts index 05b3dfcf3..35a47c98d 100644 --- a/scripts/resolvers/preamble.ts +++ b/scripts/resolvers/preamble.ts @@ -181,7 +181,9 @@ AI makes completeness near-free. Always recommend the complete option over short | Feature | 1 week | 30 min | ~30x | | Bug fix | 4 hours | 15 min | ~20x | -Include \`Completeness: X/10\` for each option (10=all edge cases, 7=happy path, 3=shortcut).`; +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.`; } function generateRepoModeSection(): string { diff --git a/setup-deploy/SKILL.md b/setup-deploy/SKILL.md index 72e69e425..bf8d399c9 100644 --- a/setup-deploy/SKILL.md +++ b/setup-deploy/SKILL.md @@ -214,6 +214,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. diff --git a/ship/SKILL.md b/ship/SKILL.md index 9b51fabcb..a10a58752 100644 --- a/ship/SKILL.md +++ b/ship/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: