niahere 0.2.34 → 0.2.36
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +41 -25
- package/package.json +1 -1
- package/skills/content-strategy/SKILL.md +365 -0
- package/skills/docx/SKILL.md +590 -0
- package/skills/frontend-design/SKILL.md +69 -69
- package/skills/marketing-ideas/SKILL.md +167 -0
- package/skills/marketing-psychology/SKILL.md +455 -0
- package/skills/pptx/SKILL.md +232 -0
- package/skills/pricing-strategy/SKILL.md +231 -0
- package/skills/remotion/SKILL.md +54 -0
- package/skills/taskmaster/SKILL.md +104 -0
- package/skills/yc-office-hours/SKILL.md +204 -0
- package/src/commands/init.ts +16 -2
- package/src/commands/service.ts +9 -1
- package/src/core/daemon.ts +14 -0
|
@@ -0,0 +1,231 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pricing-strategy
|
|
3
|
+
description: "When the user wants help with pricing decisions, packaging, or monetization strategy. Also use when the user mentions 'pricing,' 'pricing tiers,' 'freemium,' 'free trial,' 'packaging,' 'price increase,' 'value metric,' 'Van Westendorp,' 'willingness to pay,' 'monetization,' 'how much should I charge,' 'my pricing is wrong,' 'pricing page,' 'annual vs monthly,' 'per seat pricing,' or 'should I offer a free plan.' Use this whenever someone is figuring out what to charge or how to structure their plans. For in-app upgrade screens, see paywall-upgrade-cro."
|
|
4
|
+
metadata:
|
|
5
|
+
version: 1.1.0
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Pricing Strategy
|
|
9
|
+
|
|
10
|
+
You are an expert in SaaS pricing and monetization strategy. Your goal is to help design pricing that captures value, drives growth, and aligns with customer willingness to pay.
|
|
11
|
+
|
|
12
|
+
## Before Starting
|
|
13
|
+
|
|
14
|
+
**Check for product marketing context first:**
|
|
15
|
+
If `.agents/product-marketing-context.md` exists (or `.claude/product-marketing-context.md` in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.
|
|
16
|
+
|
|
17
|
+
Gather this context (ask if not provided):
|
|
18
|
+
|
|
19
|
+
### 1. Business Context
|
|
20
|
+
- What type of product? (SaaS, marketplace, e-commerce, service)
|
|
21
|
+
- What's your current pricing (if any)?
|
|
22
|
+
- What's your target market? (SMB, mid-market, enterprise)
|
|
23
|
+
- What's your go-to-market motion? (self-serve, sales-led, hybrid)
|
|
24
|
+
|
|
25
|
+
### 2. Value & Competition
|
|
26
|
+
- What's the primary value you deliver?
|
|
27
|
+
- What alternatives do customers consider?
|
|
28
|
+
- How do competitors price?
|
|
29
|
+
|
|
30
|
+
### 3. Current Performance
|
|
31
|
+
- What's your current conversion rate?
|
|
32
|
+
- What's your ARPU and churn rate?
|
|
33
|
+
- Any feedback on pricing from customers/prospects?
|
|
34
|
+
|
|
35
|
+
### 4. Goals
|
|
36
|
+
- Optimizing for growth, revenue, or profitability?
|
|
37
|
+
- Moving upmarket or expanding downmarket?
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## Pricing Fundamentals
|
|
42
|
+
|
|
43
|
+
### The Three Pricing Axes
|
|
44
|
+
|
|
45
|
+
**1. Packaging** — What's included at each tier?
|
|
46
|
+
- Features, limits, support level
|
|
47
|
+
- How tiers differ from each other
|
|
48
|
+
|
|
49
|
+
**2. Pricing Metric** — What do you charge for?
|
|
50
|
+
- Per user, per usage, flat fee
|
|
51
|
+
- How price scales with value
|
|
52
|
+
|
|
53
|
+
**3. Price Point** — How much do you charge?
|
|
54
|
+
- The actual dollar amounts
|
|
55
|
+
- Perceived value vs. cost
|
|
56
|
+
|
|
57
|
+
### Value-Based Pricing
|
|
58
|
+
|
|
59
|
+
Price should be based on value delivered, not cost to serve:
|
|
60
|
+
|
|
61
|
+
- **Customer's perceived value** — The ceiling
|
|
62
|
+
- **Your price** — Between alternatives and perceived value
|
|
63
|
+
- **Next best alternative** — The floor for differentiation
|
|
64
|
+
- **Your cost to serve** — Only a baseline, not the basis
|
|
65
|
+
|
|
66
|
+
**Key insight:** Price between the next best alternative and perceived value.
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## Value Metrics
|
|
71
|
+
|
|
72
|
+
### What is a Value Metric?
|
|
73
|
+
|
|
74
|
+
The value metric is what you charge for—it should scale with the value customers receive.
|
|
75
|
+
|
|
76
|
+
**Good value metrics:**
|
|
77
|
+
- Align price with value delivered
|
|
78
|
+
- Are easy to understand
|
|
79
|
+
- Scale as customer grows
|
|
80
|
+
- Are hard to game
|
|
81
|
+
|
|
82
|
+
### Common Value Metrics
|
|
83
|
+
|
|
84
|
+
| Metric | Best For | Example |
|
|
85
|
+
|--------|----------|---------|
|
|
86
|
+
| Per user/seat | Collaboration tools | Slack, Notion |
|
|
87
|
+
| Per usage | Variable consumption | AWS, Twilio |
|
|
88
|
+
| Per feature | Modular products | HubSpot add-ons |
|
|
89
|
+
| Per contact/record | CRM, email tools | Mailchimp |
|
|
90
|
+
| Per transaction | Payments, marketplaces | Stripe |
|
|
91
|
+
| Flat fee | Simple products | Basecamp |
|
|
92
|
+
|
|
93
|
+
### Choosing Your Value Metric
|
|
94
|
+
|
|
95
|
+
Ask: "As a customer uses more of [metric], do they get more value?"
|
|
96
|
+
- If yes → good value metric
|
|
97
|
+
- If no → price doesn't align with value
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
## Tier Structure Overview
|
|
102
|
+
|
|
103
|
+
### Good-Better-Best Framework
|
|
104
|
+
|
|
105
|
+
**Good tier (Entry):** Core features, limited usage, low price
|
|
106
|
+
**Better tier (Recommended):** Full features, reasonable limits, anchor price
|
|
107
|
+
**Best tier (Premium):** Everything, advanced features, 2-3x Better price
|
|
108
|
+
|
|
109
|
+
### Tier Differentiation
|
|
110
|
+
|
|
111
|
+
- **Feature gating** — Basic vs. advanced features
|
|
112
|
+
- **Usage limits** — Same features, different limits
|
|
113
|
+
- **Support level** — Email → Priority → Dedicated
|
|
114
|
+
- **Access** — API, SSO, custom branding
|
|
115
|
+
|
|
116
|
+
**For detailed tier structures and persona-based packaging**: See [references/tier-structure.md](references/tier-structure.md)
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## Pricing Research
|
|
121
|
+
|
|
122
|
+
### Van Westendorp Method
|
|
123
|
+
|
|
124
|
+
Four questions that identify acceptable price range:
|
|
125
|
+
1. Too expensive (wouldn't consider)
|
|
126
|
+
2. Too cheap (question quality)
|
|
127
|
+
3. Expensive but might consider
|
|
128
|
+
4. A bargain
|
|
129
|
+
|
|
130
|
+
Analyze intersections to find optimal pricing zone.
|
|
131
|
+
|
|
132
|
+
### MaxDiff Analysis
|
|
133
|
+
|
|
134
|
+
Identifies which features customers value most:
|
|
135
|
+
- Show sets of features
|
|
136
|
+
- Ask: Most important? Least important?
|
|
137
|
+
- Results inform tier packaging
|
|
138
|
+
|
|
139
|
+
**For detailed research methods**: See [references/research-methods.md](references/research-methods.md)
|
|
140
|
+
|
|
141
|
+
---
|
|
142
|
+
|
|
143
|
+
## When to Raise Prices
|
|
144
|
+
|
|
145
|
+
### Signs It's Time
|
|
146
|
+
|
|
147
|
+
**Market signals:**
|
|
148
|
+
- Competitors have raised prices
|
|
149
|
+
- Prospects don't flinch at price
|
|
150
|
+
- "It's so cheap!" feedback
|
|
151
|
+
|
|
152
|
+
**Business signals:**
|
|
153
|
+
- Very high conversion rates (>40%)
|
|
154
|
+
- Very low churn (<3% monthly)
|
|
155
|
+
- Strong unit economics
|
|
156
|
+
|
|
157
|
+
**Product signals:**
|
|
158
|
+
- Significant value added since last pricing
|
|
159
|
+
- Product more mature/stable
|
|
160
|
+
|
|
161
|
+
### Price Increase Strategies
|
|
162
|
+
|
|
163
|
+
1. **Grandfather existing** — New price for new customers only
|
|
164
|
+
2. **Delayed increase** — Announce 3-6 months out
|
|
165
|
+
3. **Tied to value** — Raise price but add features
|
|
166
|
+
4. **Plan restructure** — Change plans entirely
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
## Pricing Page Best Practices
|
|
171
|
+
|
|
172
|
+
### Above the Fold
|
|
173
|
+
- Clear tier comparison table
|
|
174
|
+
- Recommended tier highlighted
|
|
175
|
+
- Monthly/annual toggle
|
|
176
|
+
- Primary CTA for each tier
|
|
177
|
+
|
|
178
|
+
### Common Elements
|
|
179
|
+
- Feature comparison table
|
|
180
|
+
- Who each tier is for
|
|
181
|
+
- FAQ section
|
|
182
|
+
- Annual discount callout (17-20%)
|
|
183
|
+
- Money-back guarantee
|
|
184
|
+
- Customer logos/trust signals
|
|
185
|
+
|
|
186
|
+
### Pricing Psychology
|
|
187
|
+
- **Anchoring:** Show higher-priced option first
|
|
188
|
+
- **Decoy effect:** Middle tier should be best value
|
|
189
|
+
- **Charm pricing:** $49 vs. $50 (for value-focused)
|
|
190
|
+
- **Round pricing:** $50 vs. $49 (for premium)
|
|
191
|
+
|
|
192
|
+
---
|
|
193
|
+
|
|
194
|
+
## Pricing Checklist
|
|
195
|
+
|
|
196
|
+
### Before Setting Prices
|
|
197
|
+
- [ ] Defined target customer personas
|
|
198
|
+
- [ ] Researched competitor pricing
|
|
199
|
+
- [ ] Identified your value metric
|
|
200
|
+
- [ ] Conducted willingness-to-pay research
|
|
201
|
+
- [ ] Mapped features to tiers
|
|
202
|
+
|
|
203
|
+
### Pricing Structure
|
|
204
|
+
- [ ] Chosen number of tiers
|
|
205
|
+
- [ ] Differentiated tiers clearly
|
|
206
|
+
- [ ] Set price points based on research
|
|
207
|
+
- [ ] Created annual discount strategy
|
|
208
|
+
- [ ] Planned enterprise/custom tier
|
|
209
|
+
|
|
210
|
+
---
|
|
211
|
+
|
|
212
|
+
## Task-Specific Questions
|
|
213
|
+
|
|
214
|
+
1. What pricing research have you done?
|
|
215
|
+
2. What's your current ARPU and conversion rate?
|
|
216
|
+
3. What's your primary value metric?
|
|
217
|
+
4. Who are your main pricing personas?
|
|
218
|
+
5. Are you self-serve, sales-led, or hybrid?
|
|
219
|
+
6. What pricing changes are you considering?
|
|
220
|
+
|
|
221
|
+
---
|
|
222
|
+
|
|
223
|
+
## Related Skills
|
|
224
|
+
|
|
225
|
+
- **churn-prevention**: For cancel flows, save offers, and reducing revenue churn
|
|
226
|
+
- **page-cro**: For optimizing pricing page conversion
|
|
227
|
+
- **copywriting**: For pricing page copy
|
|
228
|
+
- **marketing-psychology**: For pricing psychology principles
|
|
229
|
+
- **ab-test-setup**: For testing pricing changes
|
|
230
|
+
- **revops**: For deal desk processes and pipeline pricing
|
|
231
|
+
- **sales-enablement**: For proposal templates and pricing presentations
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: remotion
|
|
3
|
+
description: Best practices for Remotion — programmatic video creation in React. Use when working with Remotion code, creating video compositions, adding animations, captions, audio, or rendering video.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Remotion Best Practices
|
|
7
|
+
|
|
8
|
+
Use this skill when dealing with Remotion code for domain-specific knowledge on video creation in React.
|
|
9
|
+
|
|
10
|
+
## Key Concepts
|
|
11
|
+
|
|
12
|
+
- **Compositions** — Define video dimensions, duration, FPS, and default props
|
|
13
|
+
- **Sequences** — Time-based layout for layering and ordering content
|
|
14
|
+
- **Interpolation** — `interpolate()` and `spring()` for smooth animations
|
|
15
|
+
- **useCurrentFrame/useVideoConfig** — Core hooks for frame-based logic
|
|
16
|
+
|
|
17
|
+
## Topics
|
|
18
|
+
|
|
19
|
+
For detailed rules and code examples, load the relevant rule file from `rules/`:
|
|
20
|
+
|
|
21
|
+
- **Animations** (`rules/animations.md`) — Fundamental animation patterns, interpolation, spring physics
|
|
22
|
+
- **Text Animations** (`rules/text-animations.md`) — Typography and text animation patterns
|
|
23
|
+
- **Transitions** (`rules/transitions.md`) — Scene transition patterns
|
|
24
|
+
- **Timing** (`rules/timing.md`) — Interpolation curves: linear, easing, spring
|
|
25
|
+
- **Sequencing** (`rules/sequencing.md`) — Sequencing patterns for multi-scene videos
|
|
26
|
+
- **Compositions** (`rules/compositions.md`) — Defining compositions, stills, folders, default props
|
|
27
|
+
- **Assets** (`rules/assets.md`) — Importing images, videos, audio, and fonts
|
|
28
|
+
- **Videos** (`rules/videos.md`) — Embedding videos: trimming, volume, speed, looping, pitch
|
|
29
|
+
- **Audio** (`rules/audio.md`) — Using audio and sound
|
|
30
|
+
- **Audio Visualization** (`rules/audio-visualization.md`) — Spectrum bars, waveforms, bass-reactive effects
|
|
31
|
+
- **Captions/Subtitles** (`rules/subtitles.md`) — Caption handling and styling
|
|
32
|
+
- **Fonts** (`rules/fonts.md`) — Loading Google Fonts and local fonts
|
|
33
|
+
- **Images** (`rules/images.md`) — Embedding images with the Img component
|
|
34
|
+
- **GIFs** (`rules/gifs.md`) — Displaying GIFs synchronized with timeline
|
|
35
|
+
- **Charts** (`rules/charts.md`) — Chart and data visualization patterns
|
|
36
|
+
- **3D** (`rules/3d.md`) — 3D content using Three.js and React Three Fiber
|
|
37
|
+
- **Lottie** (`rules/lottie.md`) — Embedding Lottie animations
|
|
38
|
+
- **Light Leaks** (`rules/light-leaks.md`) — Light leak overlay effects
|
|
39
|
+
- **Maps** (`rules/maps.md`) — Add maps using Mapbox and animate them
|
|
40
|
+
- **Transparent Videos** (`rules/transparent-videos.md`) — Rendering with transparency
|
|
41
|
+
- **Trimming** (`rules/trimming.md`) — Trimming patterns
|
|
42
|
+
- **TailwindCSS** (`rules/tailwind.md`) — Using TailwindCSS in Remotion
|
|
43
|
+
- **Parameters** (`rules/parameters.md`) — Make videos parametrizable with Zod schemas
|
|
44
|
+
- **Calculate Metadata** (`rules/calculate-metadata.md`) — Dynamically set duration, dimensions, props
|
|
45
|
+
- **Measuring Text** (`rules/measuring-text.md`) — Text dimensions, fitting, overflow checking
|
|
46
|
+
- **Measuring DOM** (`rules/measuring-dom-nodes.md`) — Measuring DOM element dimensions
|
|
47
|
+
- **FFmpeg** (`rules/ffmpeg.md`) — Video operations: trimming, silence detection
|
|
48
|
+
- **Voiceover** (`rules/voiceover.md`) — AI-generated voiceover with ElevenLabs TTS
|
|
49
|
+
- **Sound Effects** (`rules/sound-effects.md`) — Using sound effects
|
|
50
|
+
- **Video Duration** (`rules/get-video-duration.md`) — Getting video duration with Mediabunny
|
|
51
|
+
- **Audio Duration** (`rules/get-audio-duration.md`) — Getting audio duration with Mediabunny
|
|
52
|
+
- **Video Dimensions** (`rules/get-video-dimensions.md`) — Getting video width/height with Mediabunny
|
|
53
|
+
- **Can Decode** (`rules/can-decode.md`) — Check browser decode support with Mediabunny
|
|
54
|
+
- **Extract Frames** (`rules/extract-frames.md`) — Extract frames at specific timestamps
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: taskmaster
|
|
3
|
+
description: |
|
|
4
|
+
Completion guard that prevents premature task abandonment. Use when wrapping up
|
|
5
|
+
any non-trivial task, before claiming work is "done", or when you catch yourself
|
|
6
|
+
writing a summary instead of finishing the work. Also use when the user says
|
|
7
|
+
"don't stop early", "finish everything", "make sure it's actually done", or
|
|
8
|
+
"verify completion". Adapted from github.com/blader/taskmaster.
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# Taskmaster
|
|
12
|
+
|
|
13
|
+
Completion guard. Progress is not completion. Before you stop, prove the work is done.
|
|
14
|
+
|
|
15
|
+
## When to Invoke
|
|
16
|
+
|
|
17
|
+
- Before claiming any non-trivial task is complete
|
|
18
|
+
- When you're about to write a summary of what you did
|
|
19
|
+
- When you notice yourself using phrases like "significant progress", "mostly done", or "remaining work would require..."
|
|
20
|
+
- When the user explicitly asks you to finish everything
|
|
21
|
+
|
|
22
|
+
## The Completion Checklist
|
|
23
|
+
|
|
24
|
+
Run every item. Do not skip any. Do not summarize — execute.
|
|
25
|
+
|
|
26
|
+
### 1. Goal Confrontation (Do This First)
|
|
27
|
+
|
|
28
|
+
Answer these three questions explicitly in your response:
|
|
29
|
+
|
|
30
|
+
a. **What is the user's stated goal or success criterion?** Write it out verbatim.
|
|
31
|
+
b. **Is it achieved RIGHT NOW?** Answer "yes" or "no". Not "partially", not "mostly", not "significant progress was made". Yes or no.
|
|
32
|
+
c. **If no:** you are NOT DONE. Go do more work.
|
|
33
|
+
|
|
34
|
+
The ONLY exception is if the user explicitly told you to stop or deprioritized the goal. There is no other valid reason to stop.
|
|
35
|
+
|
|
36
|
+
### 2. Re-read the Original Request
|
|
37
|
+
|
|
38
|
+
Go back to the user's original message(s). List every discrete request or acceptance criterion. For each one, confirm it is **fully addressed** — not started, not in progress, FULLY done.
|
|
39
|
+
|
|
40
|
+
If the user changed their mind or withdrew a request, treat it as resolved.
|
|
41
|
+
|
|
42
|
+
### 3. Check the Task List
|
|
43
|
+
|
|
44
|
+
Review every task. Any task not marked completed? Do it now — unless the user said to skip it.
|
|
45
|
+
|
|
46
|
+
### 4. Check the Plan
|
|
47
|
+
|
|
48
|
+
Walk through each step of the plan, INCLUDING verification steps. Any step skipped or partially done? Finish it.
|
|
49
|
+
|
|
50
|
+
If the plan includes verification steps (builds, tests, lints, type-checks, smoke tests), you MUST actually run them and see them pass. Do not skip them or claim they pass without evidence.
|
|
51
|
+
|
|
52
|
+
### 5. Check for Errors
|
|
53
|
+
|
|
54
|
+
Did anything fail or remain unfinished? Fix it. This applies to ALL types of problems — logic errors, missing functionality, incomplete refactors, broken scripts, configuration issues, or anything else that prevents the work from being fully done.
|
|
55
|
+
|
|
56
|
+
### 6. Check for Loose Ends
|
|
57
|
+
|
|
58
|
+
- TODO comments you left behind?
|
|
59
|
+
- Placeholder code?
|
|
60
|
+
- Missing tests for new code?
|
|
61
|
+
- Untested changes?
|
|
62
|
+
- Follow-ups you noted but didn't act on?
|
|
63
|
+
|
|
64
|
+
If any exist, resolve them now.
|
|
65
|
+
|
|
66
|
+
### 7. Check for Blockers
|
|
67
|
+
|
|
68
|
+
If something is blocking you, do NOT give up. Try a different approach, read more code, search for examples, re-examine your assumptions.
|
|
69
|
+
|
|
70
|
+
"I didn't cause this bug" is not an excuse to stop — if it blocks your task, fix it. You own the outcome, not just your diff.
|
|
71
|
+
|
|
72
|
+
## Anti-Rationalization Guide
|
|
73
|
+
|
|
74
|
+
These are NOT valid reasons to stop:
|
|
75
|
+
|
|
76
|
+
| Rationalization | Reality |
|
|
77
|
+
|---|---|
|
|
78
|
+
| "Diminishing returns" | The goal isn't met. Keep working. |
|
|
79
|
+
| "Significant progress was made" | Progress is not completion. |
|
|
80
|
+
| "Would require broader architectural changes" | Then make them. |
|
|
81
|
+
| "No single dominant hotspot" | Keep looking. |
|
|
82
|
+
| "Tried N approaches" | Try N+1. |
|
|
83
|
+
| "I can't do X" | You haven't tried X yet. |
|
|
84
|
+
| "This is a pre-existing issue" | If it blocks your task, it's your issue. |
|
|
85
|
+
| "The remaining work is complex" | That's not a reason to stop. That's a description of your job. |
|
|
86
|
+
|
|
87
|
+
## Do Not Narrate — Execute
|
|
88
|
+
|
|
89
|
+
If any incomplete work remains, your ONLY job is to DO that work right now.
|
|
90
|
+
|
|
91
|
+
- Do NOT respond by explaining what the remaining tasks are
|
|
92
|
+
- Do NOT describe their complexity or list their dependencies
|
|
93
|
+
- Do NOT ask for permission to proceed
|
|
94
|
+
- Do NOT write summaries of what is left
|
|
95
|
+
|
|
96
|
+
Open files, write code, run commands, fix bugs. Act.
|
|
97
|
+
|
|
98
|
+
## User Instructions Override
|
|
99
|
+
|
|
100
|
+
The user's latest instructions always take priority. If the user said to stop, move on, or skip something — respect that. Do not force completion of work the user no longer wants.
|
|
101
|
+
|
|
102
|
+
## Attribution
|
|
103
|
+
|
|
104
|
+
Core ideas adapted from [Taskmaster](https://github.com/blader/taskmaster) by blader (MIT).
|
|
@@ -0,0 +1,204 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: yc-office-hours
|
|
3
|
+
description: |
|
|
4
|
+
YC-style office hours. Two modes — Startup: six forcing questions that expose
|
|
5
|
+
demand reality, status quo, desperate specificity, narrowest wedge, observation,
|
|
6
|
+
and future-fit. Builder: design thinking for side projects, hackathons, and learning.
|
|
7
|
+
Use when asked to "brainstorm", "I have an idea", "help me think through this",
|
|
8
|
+
"office hours", or "is this worth building".
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# YC Office Hours
|
|
12
|
+
|
|
13
|
+
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.
|
|
14
|
+
|
|
15
|
+
**HARD GATE:** Do NOT write any code, scaffold any project, or take any implementation action. Your only output is a design document and concrete next steps.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## Phase 1: Context Gathering
|
|
20
|
+
|
|
21
|
+
1. If in a codebase, scan `CLAUDE.md`, recent git log, and relevant files to understand context.
|
|
22
|
+
2. **Ask: what's your goal with this?** Via AskUserQuestion:
|
|
23
|
+
|
|
24
|
+
> Before we dig in — what's your goal with this?
|
|
25
|
+
>
|
|
26
|
+
> - **Building a startup** (or thinking about it)
|
|
27
|
+
> - **Intrapreneurship** — internal project at a company
|
|
28
|
+
> - **Hackathon / demo** — time-boxed, need to impress
|
|
29
|
+
> - **Open source / research** — building for a community
|
|
30
|
+
> - **Learning** — leveling up, vibe coding
|
|
31
|
+
> - **Having fun** — side project, creative outlet
|
|
32
|
+
|
|
33
|
+
**Mode mapping:**
|
|
34
|
+
- Startup, intrapreneurship → **Startup mode** (Phase 2A)
|
|
35
|
+
- Everything else → **Builder mode** (Phase 2B)
|
|
36
|
+
|
|
37
|
+
3. **Startup mode only — assess stage:**
|
|
38
|
+
- Pre-product (idea, no users)
|
|
39
|
+
- Has users (not yet paying)
|
|
40
|
+
- Has paying customers
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## Phase 2A: Startup Mode — YC Product Diagnostic
|
|
45
|
+
|
|
46
|
+
### Operating Principles
|
|
47
|
+
|
|
48
|
+
**Specificity is the only currency.** "Enterprises in healthcare" is not a customer. You need a name, a role, a company, a reason.
|
|
49
|
+
|
|
50
|
+
**Interest is not demand.** Waitlists, signups, "that's interesting" — none of it counts. Behavior counts. Money counts. Panic when it breaks counts.
|
|
51
|
+
|
|
52
|
+
**The user's words beat the founder's pitch.** If your best customers describe your value differently than your marketing copy, rewrite the copy.
|
|
53
|
+
|
|
54
|
+
**The status quo is your real competitor.** Not the other startup — the spreadsheet-and-Slack-messages workaround your user lives with.
|
|
55
|
+
|
|
56
|
+
**Narrow beats wide, early.** The smallest version someone will pay for this week > the full platform vision.
|
|
57
|
+
|
|
58
|
+
### Response Posture
|
|
59
|
+
|
|
60
|
+
- **Be direct, not cruel.** Don't soften a hard truth into uselessness.
|
|
61
|
+
- **Push once, then push again.** The first answer is usually the polished version. The real answer comes after the second push.
|
|
62
|
+
- **Praise specificity when it shows up.**
|
|
63
|
+
- **Name common failure patterns** — "solution in search of a problem," "hypothetical users," "assuming interest equals demand."
|
|
64
|
+
- **End with the assignment.** One concrete action, not a strategy.
|
|
65
|
+
|
|
66
|
+
### The Six Forcing Questions
|
|
67
|
+
|
|
68
|
+
Ask **ONE AT A TIME**. Push until the answer is specific and evidence-based.
|
|
69
|
+
|
|
70
|
+
**Smart routing by stage:**
|
|
71
|
+
- Pre-product → Q1, Q2, Q3
|
|
72
|
+
- Has users → Q2, Q4, Q5
|
|
73
|
+
- Has paying customers → Q4, Q5, Q6
|
|
74
|
+
|
|
75
|
+
#### Q1: Demand Reality
|
|
76
|
+
"What's the strongest evidence someone actually wants this — not 'is interested,' but would be genuinely upset if it disappeared tomorrow?"
|
|
77
|
+
|
|
78
|
+
Push for: specific behavior, payment, usage expansion, panic when it breaks.
|
|
79
|
+
Red flags: "People say it's interesting." "We got 500 waitlist signups."
|
|
80
|
+
|
|
81
|
+
#### Q2: Status Quo
|
|
82
|
+
"What are your users doing right now to solve this — even badly? What does that workaround cost them?"
|
|
83
|
+
|
|
84
|
+
Push for: specific workflow, hours spent, dollars wasted, tools duct-taped together.
|
|
85
|
+
Red flags: "Nothing exists." If no one is doing anything, the problem probably isn't painful enough.
|
|
86
|
+
|
|
87
|
+
#### Q3: Desperate Specificity
|
|
88
|
+
"Name the actual human who needs this most. What's their title? What gets them fired?"
|
|
89
|
+
|
|
90
|
+
Push for: a name, a role, a specific consequence.
|
|
91
|
+
Red flags: "Healthcare enterprises." "SMBs." "Marketing teams." You can't email a category.
|
|
92
|
+
|
|
93
|
+
#### Q4: Narrowest Wedge
|
|
94
|
+
"What's the smallest possible version someone would pay real money for — this week?"
|
|
95
|
+
|
|
96
|
+
Push for: one feature, one workflow, shippable in days not months.
|
|
97
|
+
Red flags: "We need to build the full platform first."
|
|
98
|
+
|
|
99
|
+
#### Q5: Observation & Surprise
|
|
100
|
+
"Have you sat down and watched someone use this without helping them? What surprised you?"
|
|
101
|
+
|
|
102
|
+
Push for: a specific surprise that contradicted assumptions.
|
|
103
|
+
Red flags: "We sent out a survey." "Nothing surprising."
|
|
104
|
+
Gold: users doing something the product wasn't designed for.
|
|
105
|
+
|
|
106
|
+
#### Q6: Future-Fit
|
|
107
|
+
"In 3 years, does your product become more essential or less?"
|
|
108
|
+
|
|
109
|
+
Push for: specific claim about how their users' world changes.
|
|
110
|
+
Red flags: "The market is growing 20% per year." "AI will make everything better."
|
|
111
|
+
|
|
112
|
+
**Smart-skip:** If earlier answers already cover a question, skip it.
|
|
113
|
+
**Escape hatch:** If user says "just do it" or provides a fully formed plan → fast-track to Phase 4.
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Phase 2B: Builder Mode — Design Partner
|
|
118
|
+
|
|
119
|
+
### Operating Principles
|
|
120
|
+
|
|
121
|
+
1. **Delight is the currency** — what makes someone say "whoa"?
|
|
122
|
+
2. **Ship something you can show.** The best version is the one that exists.
|
|
123
|
+
3. **The best side projects solve your own problem.**
|
|
124
|
+
4. **Explore before you optimize.**
|
|
125
|
+
|
|
126
|
+
### Response Posture
|
|
127
|
+
|
|
128
|
+
- Enthusiastic, opinionated collaborator.
|
|
129
|
+
- Help them find the most exciting version of their idea.
|
|
130
|
+
- Suggest cool things they might not have thought of.
|
|
131
|
+
- End with concrete build steps, not business validation tasks.
|
|
132
|
+
|
|
133
|
+
### Questions (generative, not interrogative)
|
|
134
|
+
|
|
135
|
+
Ask **ONE AT A TIME**:
|
|
136
|
+
|
|
137
|
+
- **What's the coolest version of this?** What would make it genuinely delightful?
|
|
138
|
+
- **Who would you show this to?** What would make them say "whoa"?
|
|
139
|
+
- **What's the fastest path to something you can actually use or share?**
|
|
140
|
+
- **What existing thing is closest, and how is yours different?**
|
|
141
|
+
- **What's the 10x version if you had unlimited time?**
|
|
142
|
+
|
|
143
|
+
**If the vibe shifts** — user starts in builder mode but mentions customers, revenue, fundraising → upgrade to Startup mode naturally.
|
|
144
|
+
|
|
145
|
+
---
|
|
146
|
+
|
|
147
|
+
## Phase 3: Premise Challenge
|
|
148
|
+
|
|
149
|
+
Before proposing solutions:
|
|
150
|
+
|
|
151
|
+
1. **Is this the right problem?** Could a different framing yield a simpler solution?
|
|
152
|
+
2. **What happens if we do nothing?** Real pain or hypothetical?
|
|
153
|
+
3. **What existing code/tools partially solve this?**
|
|
154
|
+
|
|
155
|
+
Output premises as clear statements:
|
|
156
|
+
```
|
|
157
|
+
PREMISES:
|
|
158
|
+
1. [statement] — agree/disagree?
|
|
159
|
+
2. [statement] — agree/disagree?
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
Confirm via AskUserQuestion. If user disagrees, revise and loop back.
|
|
163
|
+
|
|
164
|
+
---
|
|
165
|
+
|
|
166
|
+
## Phase 4: Alternatives Generation
|
|
167
|
+
|
|
168
|
+
Produce 2-3 distinct approaches. **Not optional.**
|
|
169
|
+
|
|
170
|
+
For each:
|
|
171
|
+
```
|
|
172
|
+
APPROACH A: [Name]
|
|
173
|
+
Summary: [1-2 sentences]
|
|
174
|
+
Effort: [S/M/L/XL]
|
|
175
|
+
Risk: [Low/Med/High]
|
|
176
|
+
Pros: [2-3 bullets]
|
|
177
|
+
Cons: [2-3 bullets]
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
Rules:
|
|
181
|
+
- One must be **minimal viable** (smallest diff, ships fastest)
|
|
182
|
+
- One must be **ideal architecture** (best long-term)
|
|
183
|
+
- One can be **creative/lateral** (unexpected approach)
|
|
184
|
+
|
|
185
|
+
**RECOMMENDATION:** Choose [X] because [one-line reason].
|
|
186
|
+
|
|
187
|
+
Present via AskUserQuestion. Do NOT proceed without user approval.
|
|
188
|
+
|
|
189
|
+
---
|
|
190
|
+
|
|
191
|
+
## Phase 5: Design Doc
|
|
192
|
+
|
|
193
|
+
Write the output as a structured design document. For startup mode, include: problem statement, demand evidence, status quo, target user, narrowest wedge, premises, approaches, recommendation, open questions, success criteria, and the assignment (one concrete real-world action). For builder mode: problem statement, what makes it cool, premises, approaches, recommendation, next steps.
|
|
194
|
+
|
|
195
|
+
End with a "What I noticed" section — observational reflections referencing specific things the user said. Quote their words back. 2-4 bullets.
|
|
196
|
+
|
|
197
|
+
---
|
|
198
|
+
|
|
199
|
+
## Important Rules
|
|
200
|
+
|
|
201
|
+
- **Never start implementation.** Design docs, not code.
|
|
202
|
+
- **Questions ONE AT A TIME.** Never batch multiple questions.
|
|
203
|
+
- **The assignment is mandatory.** Every session ends with a concrete action.
|
|
204
|
+
- **If user provides a formed plan:** skip Phase 2 but still run Phase 3 (Premise Challenge) and Phase 4 (Alternatives).
|
package/src/commands/init.ts
CHANGED
|
@@ -7,6 +7,7 @@ import { resetConfig } from "../utils/config";
|
|
|
7
7
|
import { runMigrations } from "../db/migrate";
|
|
8
8
|
import { closeDb } from "../db/connection";
|
|
9
9
|
import { startDaemon, isRunning } from "../core/daemon";
|
|
10
|
+
import { registerService, isServiceInstalled } from "./service";
|
|
10
11
|
import { errMsg } from "../utils/errors";
|
|
11
12
|
import { enrichSlackConfig } from "../cli/channels";
|
|
12
13
|
import yaml from "js-yaml";
|
|
@@ -434,12 +435,25 @@ export async function runInit(): Promise<void> {
|
|
|
434
435
|
|
|
435
436
|
resetConfig();
|
|
436
437
|
|
|
438
|
+
// Install system service (launchd/systemd) for auto-restart on crash
|
|
439
|
+
if (!isServiceInstalled()) {
|
|
440
|
+
try {
|
|
441
|
+
await registerService();
|
|
442
|
+
console.log(`\n \u2713 installed system service (auto-restart on crash)`);
|
|
443
|
+
} catch (err) {
|
|
444
|
+
console.log(`\n \u26a0 could not install system service: ${errMsg(err)}`);
|
|
445
|
+
console.log(` run 'nia service install' manually for auto-restart`);
|
|
446
|
+
}
|
|
447
|
+
} else {
|
|
448
|
+
console.log(`\n - system service already installed`);
|
|
449
|
+
}
|
|
450
|
+
|
|
437
451
|
// Auto-start daemon
|
|
438
452
|
if (!isRunning()) {
|
|
439
453
|
const pid = startDaemon();
|
|
440
|
-
console.log(
|
|
454
|
+
console.log(` \u2713 nia started (pid: ${pid})`);
|
|
441
455
|
} else {
|
|
442
|
-
console.log(
|
|
456
|
+
console.log(` - nia already running`);
|
|
443
457
|
}
|
|
444
458
|
|
|
445
459
|
console.log("\nDone.");
|
package/src/commands/service.ts
CHANGED
|
@@ -8,7 +8,15 @@ const PLIST_NAME = "com.niahere.agent";
|
|
|
8
8
|
const SYSTEMD_UNIT = "niahere.service";
|
|
9
9
|
|
|
10
10
|
function getExecCommand(): [string, string] {
|
|
11
|
-
|
|
11
|
+
const execPath = process.execPath;
|
|
12
|
+
// process.argv[1] may be undefined when called outside the normal CLI flow
|
|
13
|
+
// (e.g. from bun -e or programmatic import). Fall back to the known entry point.
|
|
14
|
+
let cliPath = process.argv[1];
|
|
15
|
+
if (!cliPath || cliPath === "undefined") {
|
|
16
|
+
const { resolve } = require("path");
|
|
17
|
+
cliPath = resolve(import.meta.dir, "../cli/index.ts");
|
|
18
|
+
}
|
|
19
|
+
return [execPath, cliPath];
|
|
12
20
|
}
|
|
13
21
|
|
|
14
22
|
// --- macOS launchd ---
|
package/src/core/daemon.ts
CHANGED
|
@@ -162,6 +162,20 @@ export async function runDaemon(): Promise<void> {
|
|
|
162
162
|
}
|
|
163
163
|
}
|
|
164
164
|
|
|
165
|
+
// Crash handlers — ensure PID cleanup and logging on unhandled errors.
|
|
166
|
+
// Without these, an unhandled rejection kills the process silently,
|
|
167
|
+
// leaving a stale PID file that blocks restarts and hides the cause.
|
|
168
|
+
process.on("uncaughtException", (err) => {
|
|
169
|
+
log.fatal({ err }, "uncaught exception — cleaning up");
|
|
170
|
+
removePid();
|
|
171
|
+
process.exit(1);
|
|
172
|
+
});
|
|
173
|
+
process.on("unhandledRejection", (reason) => {
|
|
174
|
+
log.fatal({ reason }, "unhandled rejection — cleaning up");
|
|
175
|
+
removePid();
|
|
176
|
+
process.exit(1);
|
|
177
|
+
});
|
|
178
|
+
|
|
165
179
|
writePid(process.pid);
|
|
166
180
|
log.info({ pid: process.pid }, "daemon started");
|
|
167
181
|
|