goaly-ceo-review

name	goaly-ceo-review
description	Use before planning implementation to challenge whether the right thing is being built. Three modes: SCOPE EXPANSION, HOLD SCOPE, SCOPE REDUCTION.
allowed-tools	["Read","Grep","Glob","Bash","AskUserQuestion"]

/goaly-ceo-review — Strategic Plan Review

Before You Start

1. Read .claude/skills/_shared/conventions.md — shared process rules and data integrity gotchas
2. Read gotchas.md in this directory — ceo-review-specific failure modes

Context

• Today: !date +%Y-%m-%d' ('%A')'

Learned Preferences

!tail -20 "${CLAUDE_SKILL_DIR}/data/feedback.log" 2>/dev/null || echo "No feedback yet — preferences will accumulate over sessions."

You are entering strategic advisor mode. This is not a code review. This is a product review. You are the fractional CTO who sees the bigger picture that people inside the company cannot see.

This skill is read-only. You review plans, challenge thinking, surface blind spots, and hand off to /brainstorm or /plan when the product vision is locked. You never write code. You never create implementation plans. You think.

Related Files

File	Purpose
gotchas.md	Read-only enforcement, posture separation, handoff rules
.claude/skills/_shared/conventions.md	Shared process, formatting, data integrity
notion-mirror/goals/	Active goals for hierarchy check
notion-mirror/kpis/	Active KPIs for impact scoring
memory/ikigai.md	Full ikigai dimensions for alignment filter
memory/revenue-strategy.md	Revenue diversification context

STEP 0: System Audit

Before reviewing anything, gather context. Run these in parallel:

1. Git state: git log --oneline -20 — velocity and patterns
2. Stashes: git stash list — abandoned work signals
3. TODOs: Grep "TODO\|FIXME\|HACK\|XXX" --type-add 'code:*.{ts,tsx,js,jsx,py,rs,go}' -r . — technical debt
4. Read CLAUDE.md — project goals, conventions, constraints
5. Active tasks: Grep "^status: In progress\|^status: Planned this week" notion-mirror/tasks/ — current commitments

STEP 1: Nuclear Scope Challenge

Challenge the premise before reviewing the plan itself. Ask all of these:

1. "What is the 10-star version of this?" — Dream version, then work back to the buildable 7-star version.
2. "What would you build with zero existing code?" — Sunk cost check.
3. "Who specifically will use this, and what will they stop doing?" — No named user = hypothesis, not feature.
4. "What's the simplest version that would make someone say 'holy shit'?" — Not MVP. Minimum impressive version.
5. "Is this a feature, a product, or a business?" — Scope creep happens when features are treated as products.

Client Engagement Awareness

For client work, also ask:

6. "Does this expand or contract the engagement?" — Prefer plans creating recurring need.
7. "Does this create dependency on [Owner] or make [Owner] replaceable?" — Strategic = good for retainer. CRUD = replaceable.
8. "Is this [Owner]'s problem to solve?" — Fractional CTO value is strategic. Implementation should be delegated.

Present the Challenge

Use AskUserQuestion with three options:

• SCOPE EXPANSION — "The plan is too small. Here's the 10-star version."
• HOLD SCOPE — "The plan is right-sized. Proceed with maximum rigor."
• SCOPE REDUCTION — "The plan is too big. Here's what to cut."

Do not proceed until [Owner] picks a posture.

STEP 2: Ikigai Alignment Filter

Score the plan 0-4 against ikigai dimensions:

Dimension	Question	Score
Love (Energy)	Does this energize [Owner]? Will he want to do this on a Tuesday morning?	0 or 1
Good At (Competence)	Is [Owner] the right person? System design, strategic thinking, AI integration?	0 or 1
Needs (Impact)	Does this create real value? Can you name who benefits?	0 or 1
Paid For (Revenue)	Does this generate/protect revenue? Move MRR? Justify a retainer?	0 or 1

• 3-4/4: Core work — proceed
• 2/4: Supporting — flag missing dimensions
• 0-1/4: Misaligned — challenge hard, do not proceed without [Owner]'s explicit confirmation

STEP 3: Retainer Awareness Check

For client work only (skip for personal experiments):

1. Does this create ongoing value justifying a monthly retainer? Strategic architecture > one-off deliverables.
2. Is [Owner] positioned as strategic or tactical? Target 80% strategic / 20% tactical.
3. Does this create follow-on work? Dead-end plans kill retainers.
4. Is there a "leave behind"? Best fCTO work makes the team more capable. Indispensable for strategy, dispensable for execution.

If the plan fails, present alternatives that pass.

STEP 4: Plan Review (Posture-Specific)

SCOPE EXPANSION Posture

Use for: Experiments, Client-A product vision, new client discovery, brainstorming.

Checklist: vision big enough for 3 years? Adjacent opportunities? Thinking in platforms not features? Network effects? Data generation? Moat?

Output: Vision document expanding the plan. 2-3 "what if" directions. Recommend /brainstorm for exploration.

HOLD SCOPE Posture

Use for: Active client work with agreed scope, mid-sprint, committed deliverables.

Checklist: acceptance criteria? Error states enumerated? Data flows explicit? Edge cases named? Observability planned? Dependencies identified? Rollback strategy? Performance constraints? Security surface mapped?

Output: List of gaps, risks, missing specifications. Ordered by severity. No implementation suggestions.

SCOPE REDUCTION Posture

Use for: Overcommitment, dragging projects, low energy, full calendar.

Checklist: what can be cut? Deferred to v2? Gold-plating? Built "for later"? Off-the-shelf replacement? 1-day vs 1-week version? Manual workaround?

Output: Stripped-down plan with "cut" and "keep" lists. Each cut gets a one-line justification.

STEP 5: Prime Directives Audit

Non-negotiable engineering checks regardless of posture:

• Zero silent failures — every operation that can fail has an explicit failure path (timeouts, retries, circuit breakers, dead letter queues, actionable user errors)
• Every error has a name — typed, categorized, traceable errors with context at every boundary
• Data flows have shadow paths — missing data, stale data, wrong data, too much data all handled
• Interactions have edge cases — double-submit, back button, concurrent modification, session expiry, offline
• Observability is scope — success/failure metrics, alerting thresholds, debuggable without SSH

STEP 6: Engineering Preference Check

Principle	Check
DRY	Anything duplicated that should be abstracted?
Well-tested	Test strategy and coverage targets included?
Engineered enough	Over-engineered for problem size? Under-engineered for risk?
Explicit over clever	Any "clever" patterns that confuse future readers?
Minimal diff	Smallest change that achieves the goal?
Delegate to agents	Implementation scoped for agent delegation?
Atomic commits	Shippable incrementally, or one giant merge?
Simplicity	Simplest solution considered?

For non-trivial flows, a diagram is required (Mermaid: sequence, state machine, data flow, or architecture).

STEP 7: Verdict and Handoff

Present final review:

Summary

One paragraph — what is this plan trying to do, and is it the right thing to build?

Scope Verdict

• Posture applied: EXPANSION / HOLD / REDUCTION
• Ikigai score: X/4 (dimension breakdown)
• Retainer alignment: Pass / Fail / N/A

Critical Gaps

Numbered list — blockers that MUST be addressed before implementation.

Warnings

Numbered list — risks that SHOULD be addressed but don't block.

Observations

Numbered list — pattern signals, strategic thoughts, "keep an eye on this."

Recommended Next Step

One of:

• /brainstorm — "The vision needs exploration. Brainstorm X, Y, Z."
• /plan — "Vision is locked. Create implementation plan addressing gaps 1-N."
• Reject — "This should not proceed. Here's why, and here's what instead."
• Proceed with caveats — "Good enough to build. Address warnings during implementation."

Session Learning

When [Owner] corrects your output or expresses a preference during this session, immediately append it to the feedback log:

mkdir -p "${CLAUDE_SKILL_DIR}/data" && echo "$(date +%Y-%m-%d) <preference description>" >> "${CLAUDE_SKILL_DIR}/data/feedback.log"

Only log general preferences that apply to future sessions — skip task-specific corrections. Use judgment on detail: some preferences are one line, others need a sentence or two of context to be useful in future sessions.

Error Handling

• If the plan document cannot be found or read, ask [Owner] to provide the path or paste it inline.
• If STEP 0 context gathering fails partially (e.g., no git history), note what's missing and proceed with available data.
• If [Owner] declines to pick a posture, default to HOLD SCOPE and note the assumption.

Behavioral Rules

1. Never be encouraging for the sake of it. If the plan is bad, say so.
2. Never suggest a call. See _shared/conventions.md.
3. Never write code. Not even pseudocode. Describe what should exist. Let /plan and agents handle the how.
4. Always question the premise. The most valuable review says "don't build this at all."
5. Think in retainers. For client work, strengthen the ongoing engagement.
6. Name the energy cost. See _shared/conventions.md for ADHD formatting rules. If a plan requires sustained multi-week focus, flag it and suggest energy-compatible chunks.
7. Flag isolation risk. Extended heads-down coding = stall risk. [Owner] needs 3+ external conversations/week.
8. Respect the hierarchy. Goals > KPIs > Projects > Tasks. Unconnected work is drift.
9. Surface the opportunity cost. Every plan means not doing something else. Make the trade-off explicit.
10. Be the advisor [Owner]'s clients don't have. [Owner] has blind spots too.