office-hours

Convert vague ideas into a review-ready YC-style design document.

10|3|Updated Mar 25, 2026
One-click install
npx skills add https://github.com/olaafrossi/FoamPilot --skill office-hours-olaafrossi
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: office-hours
Source: https://github.com/olaafrossi/FoamPilot/tree/main/.claude/skills/office-hours
Command: npx skills add https://github.com/olaafrossi/FoamPilot --skill office-hours-olaafrossi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Converts vague ideas into a concrete, review-ready YC-style design doc that guides discussions and decisions.

Core Features & Use Cases

  • Phase 1 Context Gathering to surface goals, constraints, and success metrics.
  • Phase 2A Startup Mode: YC Product Diagnostic to push for specific evidence and actionable steps.
  • Phase 2B Builder Mode: Design-thinking prompts for side projects, hackathons, and open source initiatives.
  • Outputs: a structured design doc with clear objectives, scope, milestones, and KPIs ready for stakeholder review.

Quick Start

Describe your goal and context, and I will produce a complete YC-style design doc ready for review.

Frequently Asked Questions about office-hours

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I turn a vague product idea into a structured design doc for stakeholder review?

To turn a vague idea into a structured design doc, you need to capture goals, constraints, audience, and success criteria. This process outputs a review-ready YC-style document with clear objectives, scope, milestones, and KPIs to guide decisions.

What is a YC-style design doc and when do I need one for product management?

A YC-style design doc is a concrete, review-ready document that pushes for specific evidence and actionable steps. You need one during context gathering to surface goals and success metrics, ensuring stakeholder discussions remain focused and actionable.

How do I write a design doc for a hackathon or open source side project?

To write a design doc for a side project, use design-thinking prompts tailored for builder mode contexts like hackathons. This approach captures project goals and constraints, producing a structured outline with milestones and KPIs ready for review.

Does this design doc generation process work for both startup diagnostics and builder mode projects?

Yes, the design doc process supports both contexts. It applies a YC product diagnostic for startup mode to push for specific evidence, and design-thinking prompts for builder mode to handle side projects, hackathons, and open source initiatives effectively.

What context do I need to provide to generate a complete design doc with milestones and KPIs?

You must provide clear goals and context input describing your audience and constraints. This context gathering phase is required to produce a complete, stakeholder-ready design document containing structured sections, an outline, scope, milestones, and KPIs.