@opendirectory.dev/skills 0.1.44 → 0.1.46
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/package.json +1 -1
- package/registry.json +16 -0
- package/skills/noise-to-linkedin-carousel/README.md +81 -0
- package/skills/noise-to-linkedin-carousel/SKILL.md +53 -0
- package/skills/noise-to-linkedin-carousel/cover.png +0 -0
- package/skills/noise-to-linkedin-carousel/references/hook-patterns.md +45 -0
- package/skills/noise-to-linkedin-carousel/references/output-format.md +59 -0
- package/skills/noise-to-linkedin-carousel/references/quality-checklist.md +12 -0
- package/skills/noise-to-linkedin-carousel/references/slide-types.md +57 -0
- package/skills/oss-launch-kit/.env.example +2 -0
- package/skills/oss-launch-kit/PRD.md +122 -0
- package/skills/oss-launch-kit/README.md +27 -0
- package/skills/oss-launch-kit/SKILL.md +33 -0
- package/skills/oss-launch-kit/TECHNICAL_DESIGN.md +187 -0
- package/skills/oss-launch-kit/evals/cli-cli.full.md +49 -0
- package/skills/oss-launch-kit/evals/evals.json +44 -0
- package/skills/oss-launch-kit/evals/octocat-hello-world.full.md +53 -0
- package/skills/oss-launch-kit/evals/pydantic-pydantic.full.md +152 -0
- package/skills/oss-launch-kit/evals/vercel-next-js.full.md +152 -0
- package/skills/oss-launch-kit/hero.png +0 -0
- package/skills/oss-launch-kit/references/channel_rules.md +9 -0
- package/skills/oss-launch-kit/references/launch_framework.md +10 -0
- package/skills/oss-launch-kit/references/output_template.md +3 -0
- package/skills/oss-launch-kit/scripts/__pycache__/build_product_brief.cpython-313.pyc +0 -0
- package/skills/oss-launch-kit/scripts/__pycache__/generate_assets.cpython-313.pyc +0 -0
- package/skills/oss-launch-kit/scripts/build_product_brief.py +335 -0
- package/skills/oss-launch-kit/scripts/fetch_repo_context.py +169 -0
- package/skills/oss-launch-kit/scripts/generate_assets.py +526 -0
- package/skills/oss-launch-kit/scripts/run.py +41 -0
- package/skills/oss-launch-kit/scripts/test_logic.py +99 -0
package/package.json
CHANGED
package/registry.json
CHANGED
|
@@ -196,6 +196,14 @@
|
|
|
196
196
|
"version": "1.0.0",
|
|
197
197
|
"path": "skills/newsletter-digest"
|
|
198
198
|
},
|
|
199
|
+
{
|
|
200
|
+
"name": "noise-to-linkedin-carousel",
|
|
201
|
+
"description": "Transforms messy, unstructured source material (transcripts, rough notes, etc.",
|
|
202
|
+
"tags": [],
|
|
203
|
+
"author": "ajaycodesitbetter",
|
|
204
|
+
"version": "1.0.0",
|
|
205
|
+
"path": "skills/noise-to-linkedin-carousel"
|
|
206
|
+
},
|
|
199
207
|
{
|
|
200
208
|
"name": "noise2blog",
|
|
201
209
|
"description": "Turns rough notes, bullet points, voice transcripts, or tweet dumps into a polished, publication-ready blog post.",
|
|
@@ -217,6 +225,14 @@
|
|
|
217
225
|
"version": "0.0.1",
|
|
218
226
|
"path": "skills/npm-downloads-to-leads"
|
|
219
227
|
},
|
|
228
|
+
{
|
|
229
|
+
"name": "oss-launch-kit",
|
|
230
|
+
"description": "Higher-level OSS launch orchestrator that analyzes repos, selects channels, and coordinates launch plans.",
|
|
231
|
+
"tags": [],
|
|
232
|
+
"author": "OpenDirectory",
|
|
233
|
+
"version": "0.2.0",
|
|
234
|
+
"path": "skills/oss-launch-kit"
|
|
235
|
+
},
|
|
220
236
|
{
|
|
221
237
|
"name": "outreach-sequence-builder",
|
|
222
238
|
"description": "Takes a buying signal and generates a personalized multi-channel outreach sequence across email, LinkedIn, and phone.",
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+

|
|
2
|
+
|
|
3
|
+
# noise-to-linkedin-carousel
|
|
4
|
+
|
|
5
|
+
**noise-to-linkedin-carousel** turns rough notes, transcripts, and idea dumps into a LinkedIn-ready carousel content pack with a strong hook, clear slide-by-slide structure, and a CTA — built for founders, GTM teams, and technical marketers who think faster than they write.
|
|
6
|
+
|
|
7
|
+
## Why This Skill?
|
|
8
|
+
|
|
9
|
+
Founders and technical operators often think in fragments: voice notes, bullet dumps, rambling transcripts, or Slack thoughts. They have valuable insights but lack a repeatable workflow to convert those noisy inputs into highly readable, LinkedIn-native carousel content.
|
|
10
|
+
|
|
11
|
+
LinkedIn carousels routinely outperform single-image or text-only posts because they encourage swipe-through engagement and let you teach in a structured, visual way. While `linkedin-post-generator` focuses on crafting a single post, **noise-to-linkedin-carousel** is designed specifically to turn messy raw thinking into a multi-slide narrative that a founder, GTM engineer, or designer can immediately turn into a carousel asset.
|
|
12
|
+
|
|
13
|
+
This agent skill helps by taking that unstructured "noise" and transforming it into a structured asset pack containing:
|
|
14
|
+
- 3 strong cover hook options
|
|
15
|
+
- 5-9 correctly sized insight slides (one idea per slide)
|
|
16
|
+
- A clear narrative progression
|
|
17
|
+
- A custom CTA slide
|
|
18
|
+
- A supporting LinkedIn caption
|
|
19
|
+
|
|
20
|
+
## Prerequisites
|
|
21
|
+
|
|
22
|
+
- [OpenDirectory CLI](https://github.com/Varnan-Tech/opendirectory)
|
|
23
|
+
- An OpenDirectory-compatible agent (e.g., **Anti-Gravity** or **OpenCode**)
|
|
24
|
+
|
|
25
|
+
## Installation
|
|
26
|
+
|
|
27
|
+
Install directly into your agent via OpenDirectory:
|
|
28
|
+
```bash
|
|
29
|
+
npx "@opendirectory.dev/skills" install noise-to-linkedin-carousel --target anti-gravity
|
|
30
|
+
```
|
|
31
|
+
*(Replace `anti-gravity` with your preferred agent target.)*
|
|
32
|
+
|
|
33
|
+
## Usage Examples
|
|
34
|
+
|
|
35
|
+
Once installed, you can simply message your agent with noisy source material.
|
|
36
|
+
|
|
37
|
+
**Example Prompt:**
|
|
38
|
+
> I recorded this rough voice note about why most devtools marketing fails. It’s a rant, not a clean outline. Here’s the transcript — turn this into a LinkedIn carousel I can hand to my designer:
|
|
39
|
+
>
|
|
40
|
+
> “okay so basically what i realized is that most devtools fail because they market features not use cases like everyone lists api endpoints and configs but nobody explains when you’d actually use this thing in production you know what i mean and founders think more features will solve it but the buyer just wants to know what problem disappears after they install you and how fast they get there”
|
|
41
|
+
|
|
42
|
+
**Sample Output Shape:**
|
|
43
|
+
|
|
44
|
+
- **Thesis:**
|
|
45
|
+
Most devtools fail because they market features instead of clear, real-world use cases.
|
|
46
|
+
|
|
47
|
+
- **Hooks (3 options):**
|
|
48
|
+
1. “90% of devtools die because they market features, not outcomes.”
|
|
49
|
+
2. “Your devtool doesn’t have a feature problem. It has a use-case problem.”
|
|
50
|
+
3. “If your devtool landing page looks like an API manual, this is for you.”
|
|
51
|
+
|
|
52
|
+
- **Slide Breakdown (example):**
|
|
53
|
+
- **Slide 1 – Cover (Hook):** One of the hooks above.
|
|
54
|
+
- **Slide 2 – Problem:** What most devtools marketing looks like today.
|
|
55
|
+
- **Slide 3 – Insight:** Buyers buy outcomes and solved problems, not endpoints.
|
|
56
|
+
- **Slide 4 – Insight:** Why “more features” doesn’t fix the positioning gap.
|
|
57
|
+
- **Slide 5 – Example:** Before/after example of reframing features as use cases.
|
|
58
|
+
- **Slide 6 – Framework:** Simple checklist to rewrite your own devtool pitch.
|
|
59
|
+
- **Slide 7 – CTA:** Ask readers to audit their landing page or share with a founder.
|
|
60
|
+
|
|
61
|
+
- **Caption:**
|
|
62
|
+
A LinkedIn-ready caption that tees up the carousel, adds 1–2 sentences of context, and ends with a natural CTA (e.g., “Reply ‘DEVS’ if you want a teardown of your current page”), plus 2–4 relevant hashtags.
|
|
63
|
+
|
|
64
|
+
## Under the Hood
|
|
65
|
+
|
|
66
|
+
Unlike simple text generators, this skill operates as a structured workflow:
|
|
67
|
+
1. **Thesis Extraction** - It strips away the noise to find the actual point.
|
|
68
|
+
2. **Hook Selection** - It maps the thesis to known high-performing LinkedIn hook patterns.
|
|
69
|
+
3. **Slide Constraint Enforcement** – It forces one main idea per slide and short, punchy copy so the deck feels like a high-signal LinkedIn carousel, not a pasted blog post.
|
|
70
|
+
|
|
71
|
+
## File Architecture
|
|
72
|
+
|
|
73
|
+
- `SKILL.md` - Core workflow instructions and formatting constraints.
|
|
74
|
+
- `references/output-format.md` - The deterministic output schema.
|
|
75
|
+
- `references/hook-patterns.md` - High-performing hook structures.
|
|
76
|
+
- `references/slide-types.md` - Rules for cover, context, insight, and CTA slides.
|
|
77
|
+
- `references/quality-checklist.md` - GTM-aligned checks run before returning output.
|
|
78
|
+
|
|
79
|
+
## Contributing
|
|
80
|
+
|
|
81
|
+
Pull requests to refine hook patterns, add new slide structures, or include helper scripts that refine raw transcripts are welcome.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: noise-to-linkedin-carousel
|
|
3
|
+
description: Transforms messy, unstructured source material (transcripts, rough notes, etc.) into a polished, structured LinkedIn carousel content pack for founders and GTM teams.
|
|
4
|
+
author: ajaycodesitbetter
|
|
5
|
+
version: 1.0.0
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# noise-to-linkedin-carousel
|
|
9
|
+
|
|
10
|
+
You are an expert ghostwriter, technical marketer, and content strategist specializing in LinkedIn distribution. Your task is to take noisy source material and transform it into a structured, highly valuable LinkedIn carousel content pack.
|
|
11
|
+
|
|
12
|
+
## Input Considerations
|
|
13
|
+
The user will provide source material which may be:
|
|
14
|
+
- Raw voice note transcripts
|
|
15
|
+
- Bulleted brain dumps
|
|
16
|
+
- Launch notes or Slack thoughts
|
|
17
|
+
- Article or blog excerpts
|
|
18
|
+
|
|
19
|
+
## Core Workflow
|
|
20
|
+
|
|
21
|
+
You must follow these steps precisely to fulfill the user's request:
|
|
22
|
+
|
|
23
|
+
### Step 1: Analyze and Extract Formulation
|
|
24
|
+
Read the noisy input. Before drafting any content:
|
|
25
|
+
1. Extract the strongest Distilled Thesis.
|
|
26
|
+
2. Determine the Audience Angle.
|
|
27
|
+
3. Identify the Content Goal (educate, provoke, summarize, convert, or inspire).
|
|
28
|
+
If the input is weak or ambiguous, distill a plausible thesis and document your assumption in the `Assumptions` section of the output schema (see `references/output-format.md`). Omit that section if no assumptions are needed.
|
|
29
|
+
|
|
30
|
+
### Step 2: Establish the Structure
|
|
31
|
+
Determine the optimal length (5-9 slides). Map out a narrative arc determining which Slide Role each slide will play (Cover, Problem, Reframe, Insight, Framework, Example, Proof, Takeaway, CTA).
|
|
32
|
+
*Refer to `references/slide-types.md` for understanding the exact nature and execution rules of these slide roles.*
|
|
33
|
+
|
|
34
|
+
### Step 3: Generate Hooks
|
|
35
|
+
Draft 3 distinct cover hook options explicitly labeled with the pattern used.
|
|
36
|
+
*Refer to `references/hook-patterns.md` for the formulas needed.*
|
|
37
|
+
|
|
38
|
+
### Step 4: Draft the Slide-by-Slide Content
|
|
39
|
+
Create the content. You must adhere strictly to the quality constraints:
|
|
40
|
+
- One main idea per slide.
|
|
41
|
+
- Short, punchy copy. Absolutely no large paragraphs.
|
|
42
|
+
- Provide a visual direction/intent for each slide indicating how a designer should construct it.
|
|
43
|
+
*Review `references/quality-checklist.md` during drafting and perform a strict rubric check to ensure high standards.*
|
|
44
|
+
|
|
45
|
+
### Step 5: Final Output Generation
|
|
46
|
+
Format the final response strictly and deterministically according to the schema provided in `references/output-format.md`.
|
|
47
|
+
|
|
48
|
+
## Tone and Style Constraints
|
|
49
|
+
- Clear, sharp, and founder-friendly.
|
|
50
|
+
- Educational, credible, and practical.
|
|
51
|
+
- AVOID: Vague motivational fluff, heavy jargon without context, or cliché "growth-hacking" tones.
|
|
52
|
+
|
|
53
|
+
Return ONLY the structured markdown response expected by the output schema.
|
|
Binary file
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
# Hook Patterns
|
|
2
|
+
|
|
3
|
+
A strong hook on Slide 1 is critical for LinkedIn carousels. Expand beyond generic statements and use these specific patterns when generating the "Hook Options":
|
|
4
|
+
|
|
5
|
+
## 1. The Contrarian Hook
|
|
6
|
+
- **What it does:** Goes against common industry advice or accepted "best practices."
|
|
7
|
+
- **When to use it:** When the source material debunks a myth or introduces a paradigm shift.
|
|
8
|
+
- **Examples:**
|
|
9
|
+
- "Stop prioritizing features. Here is why the best product teams ship less."
|
|
10
|
+
- "The 'best' marketing channels are dead. Do this instead."
|
|
11
|
+
|
|
12
|
+
## 2. The Mistake Hook
|
|
13
|
+
- **What it does:** Agitates a specific pain point or error the audience is currently making.
|
|
14
|
+
- **When to use it:** When the carousel acts as a corrective guide.
|
|
15
|
+
- **Examples:**
|
|
16
|
+
- "90% of GTM engineers make this one mistake when launching Open Source tools."
|
|
17
|
+
- "Your devtool doesn't have a feature problem. It has a use-case problem."
|
|
18
|
+
|
|
19
|
+
## 3. The Operator Lesson Hook
|
|
20
|
+
- **What it does:** Shares a hard-won, tactical lesson from the trenches.
|
|
21
|
+
- **When to use it:** When the source material shares personal, company, or team learnings.
|
|
22
|
+
- **Examples:**
|
|
23
|
+
- "We spent 6 months building the wrong API. Here are the 5 red flags we missed."
|
|
24
|
+
- "How we scaled our technical documentation to 10k readers with 0 budget."
|
|
25
|
+
|
|
26
|
+
## 4. The Framework Hook
|
|
27
|
+
- **What it does:** Promises a clear, structured, step-by-step path to success.
|
|
28
|
+
- **When to use it:** When the input provides a highly structured methodology to follow.
|
|
29
|
+
- **Examples:**
|
|
30
|
+
- "The 4-step framework we use to write product docs that developers actually read."
|
|
31
|
+
- "A simple, repeatable system to onboard enterprise users in 5 days."
|
|
32
|
+
|
|
33
|
+
## 5. The Teardown Hook
|
|
34
|
+
- **What it does:** Analyzes a recognizable success or failure.
|
|
35
|
+
- **When to use it:** When the source material reviews other companies, products, or strategies.
|
|
36
|
+
- **Examples:**
|
|
37
|
+
- "Stripe's documentation is a masterclass. Here is a 5-minute teardown of why."
|
|
38
|
+
- "Why [Company X] failed their launch (and the 3 things you can learn from it)."
|
|
39
|
+
|
|
40
|
+
## 6. The Pattern-Break Hook
|
|
41
|
+
- **What it does:** Uses extreme brevity or bold formatting to stop the scroll immediately.
|
|
42
|
+
- **When to use it:** When the thesis is incredibly simple but powerful.
|
|
43
|
+
- **Examples:**
|
|
44
|
+
- "Nobody cares about your features."
|
|
45
|
+
- "Your pricing model is broken."
|
|
@@ -0,0 +1,59 @@
|
|
|
1
|
+
# Output Format Schema
|
|
2
|
+
|
|
3
|
+
When returning the LinkedIn carousel content pack, you MUST format your response deterministically according to this exact schema.
|
|
4
|
+
|
|
5
|
+
## Assumptions *(optional)*
|
|
6
|
+
Use this section **only** when the source input is weak, ambiguous, or too sparse to extract a clear thesis. State what you assumed and why.
|
|
7
|
+
**Omit this section entirely when the input is sufficient.**
|
|
8
|
+
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
## 1. Distilled Thesis
|
|
12
|
+
**Thesis:** *[One sharp, clear sentence capturing the core idea that the entire carousel will communicate. No jargon.]*
|
|
13
|
+
|
|
14
|
+
## 2. Audience Angle
|
|
15
|
+
**Target Audience & Angle:** *[A short statement explaining exactly who this carousel is for, and why this specific angle is highly relevant to them.]*
|
|
16
|
+
|
|
17
|
+
## 3. Content Goal
|
|
18
|
+
**Goal:** *[Educate, provoke, summarize, convert, or inspire. What should the reader feel at the end?]*
|
|
19
|
+
|
|
20
|
+
## 4. Hook Options
|
|
21
|
+
**Hooks:**
|
|
22
|
+
Offer 3 alternative cover-slide hook lines to grab attention, citing the pattern used.
|
|
23
|
+
- **Option 1 ([Hook Pattern Name]):** *[Text]*
|
|
24
|
+
- **Option 2 ([Hook Pattern Name]):** *[Text]*
|
|
25
|
+
- **Option 3 ([Hook Pattern Name]):** *[Text]*
|
|
26
|
+
|
|
27
|
+
## 5. Recommended Carousel Structure
|
|
28
|
+
**Slide Count:** *[e.g., 7 slides]*
|
|
29
|
+
|
|
30
|
+
## 6. Slide-by-Slide Breakdown
|
|
31
|
+
|
|
32
|
+
Produce a detailed breakdown for each slide. Each slide should focus on ONE core idea.
|
|
33
|
+
|
|
34
|
+
### Slide 1: Cover
|
|
35
|
+
- **Slide Role:** Cover
|
|
36
|
+
- **Slide Title / Headline:** *[The chosen best hook from above]*
|
|
37
|
+
- **Visual Direction:** *[e.g., Large bold text centered, dark background with subtle neon accent]*
|
|
38
|
+
|
|
39
|
+
### Slide 2: [Slide Role (e.g., Problem)]
|
|
40
|
+
- **Slide Role:** *[e.g., Problem, Reframe, Insight, Proof, etc.]*
|
|
41
|
+
- **Slide Title / Headline:** *[Short, punchy headline]*
|
|
42
|
+
- **Slide Body Copy:** *[Concise body copy (no long paragraphs, bullet points preferred)]*
|
|
43
|
+
- **Visual Direction:** *[e.g., Two-column layout: text on left, simple diagram on right]*
|
|
44
|
+
|
|
45
|
+
*[Repeat for Slides 3 to N-1 as appropriate, ensuring fluid narrative progression...]*
|
|
46
|
+
|
|
47
|
+
### Slide [N]: CTA (Call to Action)
|
|
48
|
+
- **Slide Role:** CTA
|
|
49
|
+
- **Slide Title / Headline:** *[Clear takeaway or action prompt]*
|
|
50
|
+
- **Slide Body Copy:** *[What the user should do next (e.g., Follow, subscribe, comment)]*
|
|
51
|
+
- **Visual Direction:** *[e.g., Profile picture, arrow pointing to the "Follow" button]*
|
|
52
|
+
|
|
53
|
+
## 7. Supporting LinkedIn Caption
|
|
54
|
+
**Caption:**
|
|
55
|
+
*[A caption to post alongside the document on LinkedIn. It should complement the slide deck, add 1-2 sentences of context without repeating verbatim, pose a question or brief hook, and include 3-5 relevant hashtags.]*
|
|
56
|
+
|
|
57
|
+
## 8. Designer Handoff (Optional)
|
|
58
|
+
**Visual/Formatting Guidance:**
|
|
59
|
+
*[Brief notes for the person or tool building the carousel (e.g., formatting styles, hierarchy, or structural intent limits).]*
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
# Quality Checklist Rubric
|
|
2
|
+
|
|
3
|
+
Before finalizing the output for the user, aggressively evaluate the draft against this strict grading rubric:
|
|
4
|
+
|
|
5
|
+
- [ ] **One idea per slide:** Does any slide contain more than one distinct point? If yes, split it into two slides or delete one point.
|
|
6
|
+
- [ ] **No duplicated points:** Does Insight 3 just re-say Insight 1 differently? Ensure every slide earns its place.
|
|
7
|
+
- [ ] **No paragraph-heavy slides:** Are there walls of text? Ensure all body copy is scannable (short sentences or 2-3 bullets).
|
|
8
|
+
- [ ] **Intentional slide flow:** Does the progression (Problem -> Reframe -> Insight -> Framework) logically build momentum?
|
|
9
|
+
- [ ] **Meaningfully distinct hooks:** Are the 3 provided cover hooks truly different from one another (using different formulas)?
|
|
10
|
+
- [ ] **Specific CTA:** Does the call-to-action make a specific request tied to the topic, rather than a generic "like and subscribe"?
|
|
11
|
+
- [ ] **Complementary caption:** Does the LinkedIn caption add value without just summarizing the slides verbatim?
|
|
12
|
+
- [ ] **Target audience alignment:** Does the output fit a founder, GTM engineer, or technical marketing use case? (No overly generic life-coach fluff.)
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# Slide Types & Taxonomy
|
|
2
|
+
|
|
3
|
+
Use these defined slide roles when structuring the slide sequence in the content pack.
|
|
4
|
+
|
|
5
|
+
## Cover
|
|
6
|
+
- **Purpose:** Stops the scroll. The hook that buys you attention.
|
|
7
|
+
- **When to Use:** Always the first slide (Slide 1).
|
|
8
|
+
- **Copy:** Massive contrast, highly clickable headline. Very little other text.
|
|
9
|
+
- **Avoid:** Subtitles that are too long, or introducing the solution immediately.
|
|
10
|
+
|
|
11
|
+
## Problem
|
|
12
|
+
- **Purpose:** Agitates the pain point or sets the stage. Why does the reader need to keep swiping?
|
|
13
|
+
- **When to Use:** Usually Slide 2, right after the cover.
|
|
14
|
+
- **Copy:** Short statement of the status quo and why it hurts.
|
|
15
|
+
- **Avoid:** Blaming the reader directly without empathy; getting bogged down in edge cases.
|
|
16
|
+
|
|
17
|
+
## Reframe
|
|
18
|
+
- **Purpose:** Shifts the reader's perspective on the problem.
|
|
19
|
+
- **When to Use:** After the problem, before the deep insights.
|
|
20
|
+
- **Copy:** "Instead of X, think Y." A punchy paradigm shift.
|
|
21
|
+
- **Avoid:** Generic platitudes. It must be a specific paradigm shift.
|
|
22
|
+
|
|
23
|
+
## Insight
|
|
24
|
+
- **Purpose:** The "meat" of the carousel. One specific, strong point per slide.
|
|
25
|
+
- **When to Use:** The core body of the carousel (Slides 3-6).
|
|
26
|
+
- **Copy:** One clear, declarative sentence and optionally 1-3 crisp bullets.
|
|
27
|
+
- **Avoid:** Mixing multiple ideas. If there are 3 insights, use 3 separate insight slides.
|
|
28
|
+
|
|
29
|
+
## Framework
|
|
30
|
+
- **Purpose:** A sequential or structured piece of advice.
|
|
31
|
+
- **When to Use:** When teaching an actionable method or process.
|
|
32
|
+
- **Copy:** Step 1, Step 2, Step 3, or a named methodology.
|
|
33
|
+
- **Avoid:** Overcomplicating the steps. Keep it scannable.
|
|
34
|
+
|
|
35
|
+
## Example
|
|
36
|
+
- **Purpose:** Demonstrates the insight in action.
|
|
37
|
+
- **When to Use:** Immediately after a complex insight or framework.
|
|
38
|
+
- **Copy:** A quick case study, before/after metric, story, or screenshot description.
|
|
39
|
+
- **Avoid:** Long-winded stories. Keep it grounded and brief.
|
|
40
|
+
|
|
41
|
+
## Proof
|
|
42
|
+
- **Purpose:** Builds immediate credibility.
|
|
43
|
+
- **When to Use:** Towards the end, or right after introducing a controversial reframe.
|
|
44
|
+
- **Copy:** Hard numbers, recognized logos, or direct quotes.
|
|
45
|
+
- **Avoid:** Vague statements like "many companies do this."
|
|
46
|
+
|
|
47
|
+
## Takeaway
|
|
48
|
+
- **Purpose:** Brings the previous slides together into one lesson.
|
|
49
|
+
- **When to Use:** The second to last slide, right before the CTA.
|
|
50
|
+
- **Copy:** The "TL;DR" summary of the carousel.
|
|
51
|
+
- **Avoid:** Introducing new information not covered in the carousel.
|
|
52
|
+
|
|
53
|
+
## CTA (Call to Action)
|
|
54
|
+
- **Purpose:** Converts the attention into an action.
|
|
55
|
+
- **When to Use:** Always the final slide.
|
|
56
|
+
- **Copy:** Tells the reader exactly what to do next (e.g., Follow, DM me, Drop a comment).
|
|
57
|
+
- **Avoid:** Asking for multiple conflicting actions (e.g., "Like, subscribe, click the link, and comment").
|
|
@@ -0,0 +1,122 @@
|
|
|
1
|
+
# oss-launch-kit PRD
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
`oss-launch-kit` is an advanced OpenDirectory skill that turns a public GitHub repo URL into a grounded launch package for open-source projects.
|
|
5
|
+
|
|
6
|
+
The v1 output is a single Markdown document containing:
|
|
7
|
+
- executive summary & launch readiness
|
|
8
|
+
- Launch Readiness Fix Plan
|
|
9
|
+
- soft launch strategy (for medium readiness)
|
|
10
|
+
- coordinated launch timeline (for medium/high readiness)
|
|
11
|
+
- channel strategy hooks (Show HN, PH, Reddit, X)
|
|
12
|
+
- explicit handoffs to specialized skills ([!TIP])
|
|
13
|
+
- full confidence notes & assumptions
|
|
14
|
+
|
|
15
|
+
## Problem Statement
|
|
16
|
+
Open-source maintainers often know how to build and ship the product, but not how to package it for launch. The hardest part is not writing generic marketing copy; it is translating a repo’s real signal into channel-specific content that is honest, specific, and usable.
|
|
17
|
+
|
|
18
|
+
This skill solves that by taking one repo URL and generating launch assets that a maintainer can post or adapt with minimal editing.
|
|
19
|
+
|
|
20
|
+
### Why a repo URL is enough for v1
|
|
21
|
+
A GitHub repo already exposes the highest-signal inputs for launch copy:
|
|
22
|
+
- repository name and description
|
|
23
|
+
- README content
|
|
24
|
+
- topics and homepage
|
|
25
|
+
- primary language
|
|
26
|
+
- stars, forks, license
|
|
27
|
+
- optional release metadata
|
|
28
|
+
|
|
29
|
+
That is enough to infer what the project is, who it is for, what problem it solves, and what makes it worth announcing. V1 does not need deeper scraping or user-provided briefs.
|
|
30
|
+
|
|
31
|
+
### Why this is better scoped than the previous FAQ attempt
|
|
32
|
+
The closed `api-error-to-faq-builder` idea tried to infer support content from noisy inputs and broad product repos, which made hallucination and generic output more likely.
|
|
33
|
+
|
|
34
|
+
`oss-launch-kit` is narrower in three ways:
|
|
35
|
+
- input is a single public repo with structured metadata
|
|
36
|
+
- output is a bounded launch kit, not open-ended support material
|
|
37
|
+
- the skill can stay grounded in the repo’s own README and metadata
|
|
38
|
+
|
|
39
|
+
That makes the challenge more mergeable and easier to validate.
|
|
40
|
+
|
|
41
|
+
## Goals
|
|
42
|
+
- Analyze repo context to determine appropriate launch channels and project maturity.
|
|
43
|
+
- Act as a Phase 0 orchestrator: decide *if* and *how* to launch, not to write every post.
|
|
44
|
+
- Provide a prioritized, actionable Launch Readiness Fix Plan for missing signals.
|
|
45
|
+
- Generate strategic hooks and positioning for key channels.
|
|
46
|
+
- Provide a coordinated, day-by-day launch strategy.
|
|
47
|
+
- Minimize hallucinations and unsupported claims.
|
|
48
|
+
- Explicitly flag low-confidence areas when the README or metadata is sparse.
|
|
49
|
+
|
|
50
|
+
## Non-Goals
|
|
51
|
+
- No direct posting to Product Hunt, Reddit, HN, or X.
|
|
52
|
+
- No scraping of private sites.
|
|
53
|
+
- No invented traction, testimonials, users, or metrics.
|
|
54
|
+
- No attempt to infer hidden business strategy or audience beyond available evidence.
|
|
55
|
+
|
|
56
|
+
## User Input Contract
|
|
57
|
+
### Required CLI input
|
|
58
|
+
- `--repo-url <url>`: public GitHub repository URL.
|
|
59
|
+
|
|
60
|
+
### Optional CLI inputs
|
|
61
|
+
- `--output <path>`: write Markdown to a file instead of stdout.
|
|
62
|
+
- default: `launch-kit.md`
|
|
63
|
+
|
|
64
|
+
### Environment variables
|
|
65
|
+
- `GITHUB_TOKEN`: optional, used to raise GitHub API rate limits.
|
|
66
|
+
- `OPENAI_API_KEY` or equivalent model credentials only if the implementation uses a hosted LLM.
|
|
67
|
+
|
|
68
|
+
### Validation rules
|
|
69
|
+
- Repo URL must resolve to a public GitHub repository.
|
|
70
|
+
- Invalid or private repos should fail with a clear message.
|
|
71
|
+
- If README is missing, the skill should continue with lowered confidence and flag the gap.
|
|
72
|
+
|
|
73
|
+
## Output Contract
|
|
74
|
+
The output must be a single Markdown document with stable headings.
|
|
75
|
+
|
|
76
|
+
### Required structure
|
|
77
|
+
1. `# Launch Orchestrator for <repo>`
|
|
78
|
+
2. `## Executive Summary & Launch Readiness` (with readiness score and CAUTION nodes)
|
|
79
|
+
3. `## Launch Readiness Fix Plan` (Condition: Readiness is LOW/MEDIUM)
|
|
80
|
+
4. `## Soft Launch Strategy` (Condition: Readiness is MEDIUM)
|
|
81
|
+
5. `## Coordinated Launch Timeline` (Condition: Readiness is MEDIUM/HIGH)
|
|
82
|
+
6. `## Channel Strategy & Positioning` (Condition: Readiness is HIGH)
|
|
83
|
+
7. `## Full Confidence Notes & Assumptions`
|
|
84
|
+
|
|
85
|
+
### Content expectations
|
|
86
|
+
- Executive Summary cites only verified repo facts and computed project maturity.
|
|
87
|
+
- Fix Plan provides prioritized, actionable steps (e.g., "Add Quickstart", "Add License").
|
|
88
|
+
- Channel Strategy provides hooks, taglines, and niche community targets.
|
|
89
|
+
- Coordinated Launch Timeline is a practical, day-based coordination plan.
|
|
90
|
+
- Integration uses `[!TIP]` handoffs to specialized skills (`producthunt-launch-kit`, `show-hn-writer`, etc.).
|
|
91
|
+
- Low-confidence areas must explicitly list anything inferred rather than verified.
|
|
92
|
+
|
|
93
|
+
## Data Sources
|
|
94
|
+
### Essential
|
|
95
|
+
- repo name
|
|
96
|
+
- repo description
|
|
97
|
+
- README
|
|
98
|
+
- topics
|
|
99
|
+
- homepage
|
|
100
|
+
- primary language
|
|
101
|
+
- stars
|
|
102
|
+
- forks
|
|
103
|
+
- license
|
|
104
|
+
|
|
105
|
+
### Optional
|
|
106
|
+
- latest release metadata
|
|
107
|
+
- release notes
|
|
108
|
+
- repo archived/fork status
|
|
109
|
+
- README badges if easily parsed
|
|
110
|
+
|
|
111
|
+
### Priority order
|
|
112
|
+
1. README
|
|
113
|
+
2. repo description
|
|
114
|
+
3. topics and homepage
|
|
115
|
+
4. language, stars, forks, license
|
|
116
|
+
5. optional release info
|
|
117
|
+
|
|
118
|
+
## Success Criteria
|
|
119
|
+
- Launch assets feel specific to the repo, not generic.
|
|
120
|
+
- No fabricated claims.
|
|
121
|
+
- The user can use the drafts with light editing.
|
|
122
|
+
- Weak repos still produce honest output with confidence notes.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
<img src="./hero.png" width="100%" alt="OSS Launch Kit Cover" />
|
|
2
|
+
|
|
3
|
+
# oss-launch-kit (Orchestrator)
|
|
4
|
+
|
|
5
|
+
The high-level **OSS Launch Orchestrator** for GitHub repositories. It serves as the strategic entry point that analyzes your repo and coordinates a multi-channel launch plan.
|
|
6
|
+
|
|
7
|
+
## Features
|
|
8
|
+
|
|
9
|
+
- **Project Analysis**: Differentiates between CLI tools, libraries, apps, and templates.
|
|
10
|
+
- **Enhanced Readiness**: Checks for installation guides, usage examples, license, and metadata.
|
|
11
|
+
- **Channel Orchestration**: Recommends the best channels (PH, HN, Reddit, X) based on fitness.
|
|
12
|
+
- **Skill Hand-offs**: Provides hooks and pointers to `show-hn-writer`, `producthunt-launch-kit`, and `reddit-post-engine`.
|
|
13
|
+
- **Honest Feedback**: Explicitly flags low-readiness repos and recommends documentation sprints.
|
|
14
|
+
|
|
15
|
+
## Usage
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
# Generate a launch strategy and checklist for a repo
|
|
19
|
+
python scripts/run.py --repo-url https://github.com/owner/repo
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
## Differentiation
|
|
23
|
+
|
|
24
|
+
Unlike single-channel generators, `oss-launch-kit` acts as the **Root Strategy Layer**:
|
|
25
|
+
1. It tells you **if and where** you should launch.
|
|
26
|
+
2. It provides a **timed checklist** for coordination.
|
|
27
|
+
3. It hands off to **specialized skills** for channel-specific drafting.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oss-launch-kit
|
|
3
|
+
description: Higher-level OSS launch orchestrator that analyzes repos, selects channels, and coordinates launch plans.
|
|
4
|
+
compatibility: [claude-code, gemini-cli, github-copilot]
|
|
5
|
+
author: OpenDirectory
|
|
6
|
+
version: 0.2.0
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# OSS Launch Kit (Orchestrator)
|
|
10
|
+
|
|
11
|
+
The `oss-launch-kit` is the **root orchestration layer** for open-source launches in OpenDirectory. It turns a GitHub repository URL into a grounded, coordinated launch strategy.
|
|
12
|
+
|
|
13
|
+
Rather than just writing generic copy, this skill serves as the **Strategic Entry Point**: it evaluates readiness, determines channel fitness (Show HN vs. Product Hunt vs. Reddit), and provides the coordination logic needed to use specialized skills effectively.
|
|
14
|
+
|
|
15
|
+
## How it works
|
|
16
|
+
|
|
17
|
+
- **Project Analysis**: Differentiates between CLI tools, libraries, apps, and templates.
|
|
18
|
+
- **Launch Readiness**: Stronger checks for installation guides, examples, and licenses.
|
|
19
|
+
- **Skill Orchestration**: Provides hooks and explicit handoffs to `show-hn-writer`, `producthunt-launch-kit`, and `reddit-post-engine`.
|
|
20
|
+
- **Coordinated Strategy**: A timed checklist for multi-channel launches.
|
|
21
|
+
- **Honest Feedback**: Proactively flags sparse READMEs and recommends documentation sprints.
|
|
22
|
+
|
|
23
|
+
## When to use
|
|
24
|
+
|
|
25
|
+
- **Primary Entry Point**: Use this first to map out your launch strategy.
|
|
26
|
+
- **Readiness Assessment**: Determine if your repo is actually ready for high-friction channels.
|
|
27
|
+
- **Skill Orchestration**: Get hooks and handoffs to specialized skills:
|
|
28
|
+
- `show-hn-writer` (for technical deep-dives)
|
|
29
|
+
- `producthunt-launch-kit` (for PH assets and badges)
|
|
30
|
+
- `reddit-post-engine` (for community-specific variants)
|
|
31
|
+
- `tweet-thread-from-blog` (for Twitter/X threads)
|
|
32
|
+
- `linkedin-post-generator` (for LinkedIn posts)
|
|
33
|
+
- **Coordinated Strategy**: Get a realistic, timed checklist for multiple platforms.
|