agentleFS
DenchHQDenchHQ/ironclaw/skills/gstack/plan-ceo-review/SKILL.md

plan-ceo-review

Skill1.7k starsChanged 7 months agoMITView on GitHub

CEO/founder-mode plan review. Rethink the problem, find the 10-star product, challenge premises. Four modes: SCOPE EXPANSION, SELECTIVE EXPANSION, HOLD SCOPE, SCOPE REDUCTION. Use when reviewing strategy, questioning scope, or before engineering review.

49 other projects use a version of this.

Trending

Quiet since February.thin dataabout the whole repository

Dec 2025: 0 mentionsJan 2026: 0 mentionsFeb 2026: 1 mentionMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 0 mentionsJul 2026: 0 mentionsAug 2026: 0 mentionsSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the DenchHQ/ironclaw repository that our weekly crawl found: only 1 in all, so this is a hint, not a trend. There is no adoption data for this file yet.

Most recently taken up by

Who's talking about DenchHQ/ironclaw

The biggest 1 of 1 mention linking to the repository that our crawl found. Each line is their own headline.

Used with

Projects with it also use plan-tune, ios-clean and 9 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • ShreyRaviSkill

    plan-tune

    Self-tuning question sensitivity + developer psychographic for gstack (v1: observational). Review which AskUserQuestion prompts fire across gstack skills, set per-question preferences (never-ask / always-ask / ask-only-for-one-way), inspect the dual-track profile (what you declared vs what your behavior suggests), and enable/disable question tuning. Conversational interface — no CLI syntax required.

    Also in 9 projects that use this

  • Saqlain-811Skill

    ios-clean

    Remove the DebugBridge SPM package and all #if DEBUG wiring from an iOS app. (gstack)

    Also in 5 projects that use this

  • Saqlain-811Skill

    ios-fix

    Autonomous iOS bug fixer. (gstack)

    Also in 5 projects that use this

  • ShreyRaviSkill

    landing-report

    Read-only queue dashboard for workspace-aware ship. Shows which VERSION slots are currently claimed by open PRs, which sibling Conductor workspaces have WIP work likely to ship soon, and what slot /ship would pick next. No mutations — just a snapshot. Use when asked to "landing report", "what's in the queue", "show me open PRs", or "which version do I claim next". (gstack)

    Also in 8 projects that use this

  • timurgaleevSkill

    document-generate

    Generate missing docs for a feature, module or project as tutorials, how-tos, reference and explanation.

    Also in 7 projects that use this

  • seek888Skill

    pair-agent

    Pair a remote AI agent with your browser. One command generates a setup key and prints instructions the other agent can follow to connect. Works with OpenClaw, Hermes, Codex, Cursor, or any agent that can make HTTP requests. The remote agent gets its own tab with scoped access (read+write by default, admin on request). Use when asked to "pair agent", "connect agent", "share browser", "remote browser", "let another agent use my browser", or "give browser access". (gstack) Voice triggers (speech-to-text aliases): "pair agent", "connect agent", "share my browser", "remote browser access".

    Also in 10 projects that use this

  • +1 more from Saqlain-811
  • +2 more from ShreyRavi

The file

We split this skill into the rules it gives an agent

10 rules. 0 are common, 10 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 40 edited versions we read keep these.

  • 10

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before reviewing, understand context:

    line 20
  2. Distinctive:

    Read recent git history (git log --oneline -30)

    line 22
  3. Distinctive:

    Read the diff (git diff --stat)

    line 23
  4. Distinctive:

    Check for existing design docs, TODOs, and architecture docs

    line 24
  5. Distinctive:

    Read any existing CLAUDE.md or project docs

    line 25
  6. Distinctive:

    Ask the user which mode:

    line 66
  7. Distinctive:

    Run all of these for the chosen mode:

    line 77
  8. Distinctive:

    Zero silent failures: Every failure mode must be visible.

    line 94
  9. Distinctive:

    Every error has a name: Don't say "handle errors" — name the exception, trigger, handler.

    line 95
  10. Distinctive:

    After the full review, hand off to plan-eng-review for engineering detail or review for code review.

    line 111

“Common” is measured: kept by at least 6 in 10 of the 40 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

CEO Plan Review — Think Bigger, Ship Smarter

You are not here to rubber-stamp this plan. You are here to make it extraordinary.

Related skills: office-hours | plan-eng-review | plan-design-review


Pre-Review System Audit

Before reviewing, understand context:

  1. Read recent git history (git log --oneline -30)
  2. Read the diff (git diff --stat)
  3. Check for existing design docs, TODOs, and architecture docs
  4. Read any existing CLAUDE.md or project docs

Step 0: Nuclear Scope Challenge + Mode Selection

0A. Premise Challenge

  1. Is this the right problem to solve? Could a different framing yield a dramatically simpler or more impactful solution?
  2. What is the actual user/business outcome? Is the plan the most direct path?
  3. What would happen if we did nothing? Real pain point or hypothetical?

0B. Existing Code Leverage

  1. What existing code already partially solves each sub-problem?
  2. Is this plan rebuilding anything that already exists?

0C. Dream State Mapping

CURRENT STATE          →    THIS PLAN           →    12-MONTH IDEAL
[describe]                  [describe delta]          [describe target]

0D. Implementation Alternatives (MANDATORY)

Produce 2-3 distinct approaches:

APPROACH A: [Name]
  Summary: [1-2 sentences]
  Effort:  [S/M/L/XL]
  Risk:    [Low/Med/High]
  Pros:    [2-3 bullets]
  Cons:    [2-3 bullets]

At least one "minimal viable" approach and one "ideal architecture" approach.

0E. Mode Selection

Ask the user which mode:

  • SCOPE EXPANSION — Dream big. Push scope UP. "What's 10x better for 2x effort?"
  • SELECTIVE EXPANSION — Hold scope as baseline, but surface expansion opportunities individually for cherry-picking.
  • HOLD SCOPE — Make the current scope bulletproof. No silent expansion or reduction.
  • SCOPE REDUCTION — Surgeon mode. Find the minimum viable version. Cut everything else.

Review Sections (1-10)

Run all of these for the chosen mode:

  1. Architecture Integrity — Data flow diagrams, state machines, dependency graphs
  2. Error/Rescue Map — Every error has a name, trigger, handler, user-visible message, and test
  3. Security & Trust Boundaries — Threat model for new codepaths
  4. Data Flow Shadow Paths — Happy path + nil, empty, upstream error
  5. Interaction Edge Cases — Double-click, navigate-away, slow connection, stale state, back button
  6. Observability — New dashboards, alerts, runbooks as first-class deliverables
  7. Test Strategy — Test matrix, coverage gaps, regression risks
  8. Deployment Plan — Partial states, rollbacks, feature flags
  9. Performance Impact — Bundle size, query count, cold start
  10. Documentation Impact — What docs need updating?

Prime Directives

  1. Zero silent failures. Every failure mode must be visible.
  2. Every error has a name. Don't say "handle errors" — name the exception, trigger, handler.
  3. Data flows have shadow paths. Happy path + nil, empty, upstream error.
  4. Interactions have edge cases. Double-click, navigate-away, slow connection.
  5. Observability is scope, not afterthought.
  6. Diagrams are mandatory. ASCII art for every non-trivial flow.
  7. Everything deferred must be written down.

Cognitive Patterns

  • Inversion reflex — For every "how do we win?" also ask "what would make us fail?"
  • Focus as subtraction — Primary value is what to NOT do.
  • Speed calibration — Fast is default. Only slow down for irreversible + high-magnitude decisions.
  • Proxy skepticism — Are our metrics serving users or becoming self-referential?

After the full review, hand off to plan-eng-review for engineering detail or review for code review.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.