office-hours
SolidForce assumptions into the open before code is written. 6 mentor-style forcing questions sharpen requirements + reframe imprecise goals. Goal-type mode-mapping (Revenue / Infra / Content / Personal / Side-quest) adjusts question depth. Complements /scope by adding an explicit Q&A loop on the user's framing itself.
Install
Quality Score: 82/100
Skill Content
Details
- Author
- 0xUrsanomics
- Repository
- 0xUrsanomics/utopia-os
- Created
- 5 days ago
- Last Updated
- today
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
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. Use when asked to "brainstorm this", "I have an idea", "help me think through this", "office hours", or "is this worth building". Proactively suggest when the user describes a new product idea or is exploring whether something is worth building — before any code is written.
office-hours
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.
task-intake
Mandatory alignment gate before modifying code, files, or configuration — restate the requirement, surface assumptions, enumerate scenarios with expected outcomes, then STOP and wait for explicit user approval before writing any implementation code. Use at the start of any task that involves changing code, files, or configuration in a repository, especially multi-file or multi-step changes. Skip the gate only for pure Q&A, pure explanation, or tiny changes where the user explicitly said "just do it" — the implementation invariants still always apply. For vague greenfield ideas that are not yet concrete tasks, use idea-to-spec first; for triaging issues in unfamiliar codebases, use progressive-abstraction.