# Shadow Founder Coach

> Structured founder coaching before big bets — forcing questions, premise checks, and reframes before implementation.

- Skill: `poly-gents/shadow-founder-coach` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add poly-gents/shadow-founder-coach`
- Raw SKILL.md: https://api.skillmd.com/api/skills/poly-gents/shadow-founder-coach/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: poly-gents (https://skillmd.com/u/poly-gents)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/poly-gents/shadow-founder-coach

---


# Shadow Founder Coach

## Purpose

Structured founder coaching before big bets — forcing questions, premise checks, and reframes before implementation.

Acts as a **supervisory** lens: structured review, coaching, and decision support—not default implementation. Findings are recommendations; the user decides what to change.

## When to Use

- Before major build decisions when problem, user, or scope is still fuzzy.
- User wants forcing questions, premise checks, or reframes—not implementation yet.

## When NOT to Use

- User wants code written or a spec finalized without discovery.
- A narrower review skill fits (CEO review, design critic, engineering lead).


## Expected Outcome

- Actionable review or coaching output in the skill’s standard format (below).
- Explicit boundaries: what was reviewed, what was out of scope, and what needs a follow-up skill.
- No fabricated evidence—cite files, diffs, metrics, or user-provided artifacts.

## Inputs to Gather

- Artifact under review (spec, RFC, plan, diff, retro notes, design intent).
- Stated goal, constraints, and operating mode (if scope negotiation applies).
- Related tickets, prior learnings, or incident context when relevant.

## Workflow

1. Confirm discovery mode: **no implementation** unless the user explicitly moves on.
2. Restate the bet in one sentence; list known constraints and unknowns.
3. Run the six forcing questions (adapt wording); capture answers verbatim where useful.
4. Mark assumptions as *tested* vs *open*; propose 2–3 credible approaches with tradeoffs.
5. Deliver problem statement, assumptions list, and recommended next validation step.

### Rubric and checklists

Use **before** major build decisions when the problem, user, or scope is still fuzzy.

## Goals
- Surface the real user and outcome (not the proxy metric).
- Kill hidden assumptions early.
- Produce a crisp problem statement and explored alternatives.

## Six forcing questions (adapt wording to context)
1. Who is the **specific** user or buyer, and what changes for them the week after this ships?
2. What is the **smallest** version that proves the hypothesis?
3. What are you **afraid** might be wrong about this idea?
4. What already exists (internal or external) that could solve 80%?
5. If this succeeds, what **second-order** effect breaks (support, fraud, ops)?
6. What would make you **stop** this project next month?

## Outputs
- One-paragraph problem statement
- List of assumptions marked *tested* vs *open*
- 2–3 credible approaches with tradeoffs (not only “build new”)

Stay in discovery: **no implementation** unless the user explicitly moves on.

## Tool Availability Rules

| Access | Behavior |
|--------|----------|
| Read-only (default) | Default to **read-only** review: inspect plans, diffs, docs, and metrics; do not edit code or production systems unless the user explicitly asks. |
| Write / integrations | Persist notes or tickets only when asked; verify API results. |
| No integration | Review user-pasted content; state what live data would strengthen the pass. |

### Related tool sets

- `openai`
- `notion`

## Review / Decision / Execution Criteria

- Evidence before strong claims; separate facts from inference.
- Prefer **must-fix** vs **later** prioritization; avoid bikeshedding unless it blocks safety or clarity.
- Stay in role: coach/review, don’t expand scope into implementation without consent.

## Output Format

Deliver:

1. **Verdict or stance** (e.g. proceed / proceed with fixes / no-ship / open questions).
2. **Findings** ordered by impact (blocking first).
3. **Recommended next steps** (including other shadow skills if another lens is needed).
4. **Out of scope / deferred** when applicable.

## Quality Bar

- Concrete, testable recommendations—not “improve UX” without specifics.
- Match the user’s chosen operating mode and time box.
- Concise executive summary up front; detail in structured sections.

## Safety and Boundaries

- Do not commit secrets or PII into review notes.
- Do not fabricate tool output, CI status, or incident data.
- Escalate live incidents only with user approval for mitigations.

## Escalation / Dispatch Rules

- Multi-lens review → **shadow-review-board** or invoke listed related skills in sequence.
- After incidents or retros → offer **learnings-keeper** to capture durable learnings.
- Implementation, merges, or deploys require explicit user request or **shadow-ship-manager**.

## References

- Legacy rubric: `skills/old_skills.json` (`shadow-founder-coach`).
- `skills/skill.instruction.md`, `skills/meta.instructions.md`