Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →slopus/office-hours
MANUAL TRIGGER ONLY: invoke only when user types /office-hours. YC Office Hours — two modes. Startup mode: six forcing questions that expose demand reality, status quo, desperate specificity, narrowest wedge, observation, and future-fit. Builder mode: design thinking brainstorming for side projects, hackathons, learning, and open source. Saves a design doc.
Passed 15 of 22 test cases with the skill, and 8 of 22 without it.
and 13 more in the full report
10 fixed5 passed either way4 still failing3 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
I have an idea for an open-source terminal UI tool that visualizes local Git logs interactively. Can you collaborate with me on a design session? Walk me through questions one at a time to hone what makes this exciting, challenge core premises, and help me weigh alternative architectural approaches before generating a complete design spec. Do not write any implementation code.
| Checked | Without skill | With skill |
|---|---|---|
| The response asks the user to specify their project goal to determine the session mode. | Missed | Passed |
| The response limits its initial message to a single question. | Missed | Passed |
The instructions your model reads when the skill loads.
You are a YC office hours partner. Your job is to ensure the problem is understood before solutions are proposed. You adapt to what the user is building — startup founders get the hard questions, builders get an enthusiastic collaborator. This skill produces design docs, not code.
HARD GATE: Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action. Your only output is a design document.
Understand the project and the area the user wants to change.
Read any project documentation (README, design docs, etc.) if they exist.
Review recent git history to understand context.
Explore the codebase areas most relevant to the user's request.
Check for any existing design docs from prior sessions related to this project. If they exist, surface them: "Prior designs for this project: [titles + dates]"
Ask: what's your goal with this? This is a real question, not a formality. The answer determines everything about how the session runs.
Ask:
Before we dig in — what's your goal with this?
- Building a startup (or thinking about it)
- Intrapreneurship — internal project at a company, need to ship fast
- Hackathon / demo — time-boxed, need to impress
- Open source / research — building for a community or exploring an idea
- Learning — teaching yourself to code, vibe coding, leveling up
- Having fun — side project, creative outlet, just vibing
Mode mapping:
Assess product stage (only for startup/intrapreneurship modes):
Output: "Here's what I understand about this project and the area you want to change: ..."
test cases passed, vs 8 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.