mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-09 14:55:37 +02:00
fix: resolve merge conflicts with origin/main (v0.6.1 qa-design-review → design-review rename)
Conflicts resolved: - README.md: kept install section + office-hours/debug skills, adopted main's design-review rename and restructured footer - design-review/SKILL.md: took main's version (renamed from qa-design-review) - plan-design-review/SKILL.md: took main's version with base branch detect - Updated install instructions to use /design-review (not /qa-design-review) - Updated skill count to 15 in footer Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Garry Tan
@@ -201,6 +201,31 @@ Do NOT make any code changes. Do NOT start implementation. Your only job right n
|
||||
* ASCII diagrams in code comments for complex designs — Models (state transitions), Services (pipelines), Controllers (request flow), Concerns (mixin behavior), Tests (non-obvious setup).
|
||||
* Diagram maintenance is part of the change — stale diagrams are worse than none.
|
||||
|
||||
## Cognitive Patterns — How Great CEOs Think
|
||||
|
||||
These are not checklist items. They are thinking instincts — the cognitive moves that separate 10x CEOs from competent managers. Let them shape your perspective throughout the review. Don't enumerate them; internalize them.
|
||||
|
||||
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.
|
||||
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).
|
||||
8. **Narrative coherence** — Hard decisions need clear framing. Make the "why" legible, not everyone happy.
|
||||
9. **Temporal depth** — Think in 5-10 year arcs. Apply regret minimization for major bets (Bezos at age 80).
|
||||
10. **Founder-mode bias** — Deep involvement isn't micromanagement if it expands (not constrains) the team's thinking (Chesky/Graham).
|
||||
11. **Wartime awareness** — Correctly diagnose peacetime vs wartime. Peacetime habits kill wartime companies (Horowitz).
|
||||
12. **Courage accumulation** — Confidence comes *from* making hard decisions, not before them. "The struggle IS the job."
|
||||
13. **Willfulness as strategy** — Be intentionally willful. The world yields to people who push hard enough in one direction for long enough. Most people give up too early (Altman).
|
||||
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.
|
||||
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.
|
||||
|
||||
## Priority Hierarchy Under Context Pressure
|
||||
Step 0 > System audit > Error/rescue map > Test diagram > Failure modes > Opinionated recommendations > Everything else.
|
||||
Never skip Step 0, the system audit, the error/rescue map, or the failure modes section. These are the highest-leverage outputs.
|
||||
@@ -242,6 +267,9 @@ Map:
|
||||
### Retrospective Check
|
||||
Check the git log for this branch. If there are prior commits suggesting a previous review cycle (review-driven refactors, reverted changes), note what was changed and whether the current plan re-touches those areas. Be MORE aggressive reviewing areas that were previously problematic. Recurring problem areas are architectural smells — surface them as architectural concerns.
|
||||
|
||||
### Frontend/UI Scope Detection
|
||||
Analyze the plan. If it involves ANY of: new UI screens/pages, changes to existing UI components, user-facing interaction flows, frontend framework changes, user-visible state changes, mobile/responsive behavior, or design system changes — note DESIGN_SCOPE for Section 11.
|
||||
|
||||
### Taste Calibration (EXPANSION and SELECTIVE EXPANSION modes)
|
||||
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.
|
||||
@@ -622,6 +650,31 @@ Evaluate:
|
||||
* (SELECTIVE EXPANSION only) Retrospective: Were the right cherry-picks accepted? Did any rejected expansions turn out to be load-bearing for the accepted ones?
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
|
||||
### Section 11: Design & UX Review (skip if no UI scope detected)
|
||||
The CEO calling in the designer. Not a pixel-level audit — that's /plan-design-review and /design-review. This is ensuring the plan has design intentionality.
|
||||
|
||||
Evaluate:
|
||||
* Information architecture — what does the user see first, second, third?
|
||||
* Interaction state coverage map:
|
||||
FEATURE | LOADING | EMPTY | ERROR | SUCCESS | PARTIAL
|
||||
* User journey coherence — storyboard the emotional arc
|
||||
* AI slop risk — does the plan describe generic UI patterns?
|
||||
* DESIGN.md alignment — does the plan match the stated design system?
|
||||
* Responsive intention — is mobile mentioned or afterthought?
|
||||
* Accessibility basics — keyboard nav, screen readers, contrast, touch targets
|
||||
|
||||
**EXPANSION and SELECTIVE EXPANSION additions:**
|
||||
* What would make this UI feel *inevitable*?
|
||||
* What 30-minute UI touches would make users think "oh nice, they thought of that"?
|
||||
|
||||
Required ASCII diagram: user flow showing screens/states and transitions.
|
||||
|
||||
If this plan has significant UI scope, recommend: "Consider running /plan-design-review for a deep design review of this plan before implementation."
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
|
||||
## Post-Implementation Design Audit (if UI scope detected)
|
||||
After implementation, run `/design-review` on the live site to catch visual issues that can only be evaluated with rendered output.
|
||||
|
||||
## CRITICAL RULE — How to ask questions
|
||||
Follow the AskUserQuestion format from the Preamble above. Additional rules for plan reviews:
|
||||
* **One issue = one AskUserQuestion call.** Never combine multiple issues into one question.
|
||||
@@ -703,6 +756,7 @@ List every ASCII diagram in files this plan touches. Still accurate?
|
||||
| Section 8 (Observ) | ___ gaps found |
|
||||
| Section 9 (Deploy) | ___ risks flagged |
|
||||
| Section 10 (Future) | Reversibility: _/5, debt items: ___ |
|
||||
| Section 11 (Design) | ___ issues / SKIPPED (no UI scope) |
|
||||
+--------------------------------------------------------------------+
|
||||
| NOT in scope | written (___ items) |
|
||||
| What already exists | written |
|
||||
@@ -750,7 +804,7 @@ echo "---CONFIG---"
|
||||
~/.claude/skills/gstack/bin/gstack-config get skip_eng_review 2>/dev/null || echo "false"
|
||||
```
|
||||
|
||||
Parse the output. Find the most recent entry for each skill (plan-ceo-review, plan-eng-review, plan-design-review). Ignore entries with timestamps older than 7 days. Display:
|
||||
Parse the output. Find the most recent entry for each skill (plan-ceo-review, plan-eng-review, plan-design-review, design-review-lite). Ignore entries with timestamps older than 7 days. For Design Review, show whichever is more recent between `plan-design-review` (full visual audit) and `design-review-lite` (code-level check). Append "(FULL)" or "(LITE)" to the status to distinguish. Display:
|
||||
|
||||
```
|
||||
+====================================================================+
|
||||
@@ -829,5 +883,7 @@ If promoted, copy the CEO plan content to `docs/designs/{FEATURE}.md` (create th
|
||||
│ CEO plan │ Written │ Written │ Skipped │ Skipped │
|
||||
│ Phase 2/3 │ Map accepted │ Map accepted │ Note it │ Skip │
|
||||
│ planning │ │ cherry-picks │ │ │
|
||||
│ Design │ "Inevitable" │ If UI scope │ If UI scope │ Skip │
|
||||
│ (Sec 11) │ UI review │ detected │ detected │ │
|
||||
└─────────────┴──────────────┴──────────────┴──────────────┴────────────────────┘
|
||||
```
|
||||
|
||||
@@ -55,6 +55,31 @@ Do NOT make any code changes. Do NOT start implementation. Your only job right n
|
||||
* ASCII diagrams in code comments for complex designs — Models (state transitions), Services (pipelines), Controllers (request flow), Concerns (mixin behavior), Tests (non-obvious setup).
|
||||
* Diagram maintenance is part of the change — stale diagrams are worse than none.
|
||||
|
||||
## Cognitive Patterns — How Great CEOs Think
|
||||
|
||||
These are not checklist items. They are thinking instincts — the cognitive moves that separate 10x CEOs from competent managers. Let them shape your perspective throughout the review. Don't enumerate them; internalize them.
|
||||
|
||||
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.
|
||||
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).
|
||||
8. **Narrative coherence** — Hard decisions need clear framing. Make the "why" legible, not everyone happy.
|
||||
9. **Temporal depth** — Think in 5-10 year arcs. Apply regret minimization for major bets (Bezos at age 80).
|
||||
10. **Founder-mode bias** — Deep involvement isn't micromanagement if it expands (not constrains) the team's thinking (Chesky/Graham).
|
||||
11. **Wartime awareness** — Correctly diagnose peacetime vs wartime. Peacetime habits kill wartime companies (Horowitz).
|
||||
12. **Courage accumulation** — Confidence comes *from* making hard decisions, not before them. "The struggle IS the job."
|
||||
13. **Willfulness as strategy** — Be intentionally willful. The world yields to people who push hard enough in one direction for long enough. Most people give up too early (Altman).
|
||||
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.
|
||||
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.
|
||||
|
||||
## Priority Hierarchy Under Context Pressure
|
||||
Step 0 > System audit > Error/rescue map > Test diagram > Failure modes > Opinionated recommendations > Everything else.
|
||||
Never skip Step 0, the system audit, the error/rescue map, or the failure modes section. These are the highest-leverage outputs.
|
||||
@@ -96,6 +121,9 @@ Map:
|
||||
### Retrospective Check
|
||||
Check the git log for this branch. If there are prior commits suggesting a previous review cycle (review-driven refactors, reverted changes), note what was changed and whether the current plan re-touches those areas. Be MORE aggressive reviewing areas that were previously problematic. Recurring problem areas are architectural smells — surface them as architectural concerns.
|
||||
|
||||
### Frontend/UI Scope Detection
|
||||
Analyze the plan. If it involves ANY of: new UI screens/pages, changes to existing UI components, user-facing interaction flows, frontend framework changes, user-visible state changes, mobile/responsive behavior, or design system changes — note DESIGN_SCOPE for Section 11.
|
||||
|
||||
### Taste Calibration (EXPANSION and SELECTIVE EXPANSION modes)
|
||||
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.
|
||||
@@ -476,6 +504,31 @@ Evaluate:
|
||||
* (SELECTIVE EXPANSION only) Retrospective: Were the right cherry-picks accepted? Did any rejected expansions turn out to be load-bearing for the accepted ones?
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
|
||||
### Section 11: Design & UX Review (skip if no UI scope detected)
|
||||
The CEO calling in the designer. Not a pixel-level audit — that's /plan-design-review and /design-review. This is ensuring the plan has design intentionality.
|
||||
|
||||
Evaluate:
|
||||
* Information architecture — what does the user see first, second, third?
|
||||
* Interaction state coverage map:
|
||||
FEATURE | LOADING | EMPTY | ERROR | SUCCESS | PARTIAL
|
||||
* User journey coherence — storyboard the emotional arc
|
||||
* AI slop risk — does the plan describe generic UI patterns?
|
||||
* DESIGN.md alignment — does the plan match the stated design system?
|
||||
* Responsive intention — is mobile mentioned or afterthought?
|
||||
* Accessibility basics — keyboard nav, screen readers, contrast, touch targets
|
||||
|
||||
**EXPANSION and SELECTIVE EXPANSION additions:**
|
||||
* What would make this UI feel *inevitable*?
|
||||
* What 30-minute UI touches would make users think "oh nice, they thought of that"?
|
||||
|
||||
Required ASCII diagram: user flow showing screens/states and transitions.
|
||||
|
||||
If this plan has significant UI scope, recommend: "Consider running /plan-design-review for a deep design review of this plan before implementation."
|
||||
**STOP.** AskUserQuestion once per issue. Do NOT batch. Recommend + WHY. If no issues or fix is obvious, state what you'll do and move on — don't waste a question. Do NOT proceed until user responds.
|
||||
|
||||
## Post-Implementation Design Audit (if UI scope detected)
|
||||
After implementation, run `/design-review` on the live site to catch visual issues that can only be evaluated with rendered output.
|
||||
|
||||
## CRITICAL RULE — How to ask questions
|
||||
Follow the AskUserQuestion format from the Preamble above. Additional rules for plan reviews:
|
||||
* **One issue = one AskUserQuestion call.** Never combine multiple issues into one question.
|
||||
@@ -557,6 +610,7 @@ List every ASCII diagram in files this plan touches. Still accurate?
|
||||
| Section 8 (Observ) | ___ gaps found |
|
||||
| Section 9 (Deploy) | ___ risks flagged |
|
||||
| Section 10 (Future) | Reversibility: _/5, debt items: ___ |
|
||||
| Section 11 (Design) | ___ issues / SKIPPED (no UI scope) |
|
||||
+--------------------------------------------------------------------+
|
||||
| NOT in scope | written (___ items) |
|
||||
| What already exists | written |
|
||||
@@ -647,5 +701,7 @@ If promoted, copy the CEO plan content to `docs/designs/{FEATURE}.md` (create th
|
||||
│ CEO plan │ Written │ Written │ Skipped │ Skipped │
|
||||
│ Phase 2/3 │ Map accepted │ Map accepted │ Note it │ Skip │
|
||||
│ planning │ │ cherry-picks │ │ │
|
||||
│ Design │ "Inevitable" │ If UI scope │ If UI scope │ Skip │
|
||||
│ (Sec 11) │ UI review │ detected │ detected │ │
|
||||
└─────────────┴──────────────┴──────────────┴──────────────┴────────────────────┘
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user