メニュー
YC-style product discovery session. Six forcing questions that reframe the product before code is written. Pushes back on framing, challenges premises, generates implementation alternatives. Design doc output feeds all downstream skills.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Builds production-grade Claude Projects and CustomGPTs, improves AI output quality using meta-thinking prompts, and architects self-improving AI systems. Use proactively when a founder wants to build a reliable AI workflow, automate a repeatable task with AI, improve the quality of AI outputs they're getting, feels stuck with generic AI responses, or wants to build internal tools powered by Claude. Trigger for "build a Claude project", "my AI outputs are generic", "how do I make Claude more specific", "build an AI workflow", "automate this with AI", or "my prompts aren't working".
One-command review pipeline. Chains CEO review → design review → eng review automatically. Surfaces only taste decisions for PD approval. Everything else runs autonomously.
Performance baseline measurement. Captures page load times, Core Web Vitals, and resource sizes. Compare before/after on every PR.
Playbook for bootstrapped and early-stage SaaS founders based on proven case studies ($0 to $5M ARR with 6 people, and creator-to-business flywheel models). Use proactively when a founder is bootstrapped or capital-efficient, needs to grow without paid acquisition, is facing a churn crisis, wants to build a freemium or usage-based model, or asks "how do I grow without VC money". Also trigger for "PLG", "inbound-led outbound", "creator-led growth", "build in public", or "how did [bootstrapped company] grow".
Real browser automation for testing, QA, and demo verification. Provides Playwright-based browser control for navigating the live app, clicking elements, filling forms, taking screenshots, and verifying visual state.
Post-deploy monitoring. After release-engineer pushes to production, canary watches the live site for errors, performance regressions, and page failures.
| name | office-hours |
| description | YC-style product discovery session. Six forcing questions that reframe the product before code is written. Pushes back on framing, challenges premises, generates implementation alternatives. Design doc output feeds all downstream skills. |
| used_by | ["ceo-thinking-partner"] |
This is where every feature starts. Before writing a PRD, before planning, before code — run office hours.
Ask PD each question. Wait for the answer. Do NOT move on until answered.
"What's the pain? Give me a specific example — a real person, a real moment where this hurt." Purpose: Grounds the feature in reality, not theory.
"Who feels this pain most? The [DOMAIN_ACTOR_1] or the [DOMAIN_ACTOR_2]? How do you know?" Purpose: Marketplace has two sides. Which side is pulling?
"What are they doing today without this feature? Is that workaround tolerable?" Purpose: If the workaround is fine, the feature isn't urgent.
"If this works perfectly, what changes for the user? Describe their Tuesday after launch." Purpose: Forces outcome thinking, not feature thinking.
"What's the smallest version of this that tests whether the pain is real?" Purpose: Prevents over-building. Find the wedge.
"What would make you kill this feature after launching it?" Purpose: Defines failure criteria upfront. Prevents zombie features.
After hearing PD's answers, CEO MUST push back on at least 2 premises:
PD can agree, disagree, or adjust. Document each:
After office hours, write to docs/office-hours/[feature]-[date].md:
Office Hours: [Feature Name]
Date: [date] | Participants: CEO + PD
Pain
[PD's answer to Q1]
User Segment
[PD's answer to Q2]
Current Workaround
[PD's answer to Q3]
Success Vision
[PD's answer to Q4]
Minimum Viable Test
[PD's answer to Q5]
Kill Criteria
[PD's answer to Q6]
Pushback Log
| Premise Challenged | PD Response | Outcome |
|--------------------|-------------|---------|
Recommendation
[CEO's recommendation: build / park / investigate further]
Implementation Approaches (generate 2-3)
| Approach | Effort | Risk | Upside |
|----------|--------|------|--------|
| A: [description] | [sprints] | [risk] | [upside] |
| B: [description] | [sprints] | [risk] | [upside] |
| C: [description] | [sprints] | [risk] | [upside] |
Next Step
If PD approves: hand to product-manager for PRD (load skills/public/plan-ceo-review/SKILL.md for review)
Post to Slack CEO: "OFFICE HOURS: [feature] — [recommendation]. Design doc at docs/office-hours/[feature]-[date].md"
Ensure the directory docs/office-hours/ exists (create if not).