@opendirectory.dev/skills 0.1.0

package/skills/pr-description-writer/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: pr-description-writer
+description: ''
+compatibility: [claude-code, gemini-cli, github-copilot]
+author: OpenDirectory
+version: 1.0.0
+---
+
+# PR Description Writer
+
+Read the current branch diff and write a complete GitHub pull request description. Create or update the PR with one command.
+
+## Writing Style
+
+Apply to all generated PR descriptions:
+
+- Active voice. "Adds X" not "X has been added."
+- Present tense for summary ("Adds caching layer"), past tense for context ("The old approach caused N requests per render")
+- Short sentences, one idea per bullet
+- No em dashes — use a comma or period instead
+- No filler: "this PR", "this commit", "as per the discussion"
+- Specifics beat generalities: "reduces p95 latency from 800ms to 90ms" beats "improves performance"
+
+---
+
+## Step 1: Check Setup
+
+Confirm `gh` is authenticated:
+
+```bash
+gh auth status
+```
+
+If not authenticated: `gh auth login` and follow the prompts.
+
+Confirm the current directory is a git repo with an active branch:
+
+```bash
+git branch --show-current
+```
+
+If detached HEAD or no branch, stop and ask the user which branch they want to describe.
+
+---
+
+## Step 2: Gather Diff Context
+
+Run all three commands to build context:
+
+**File summary (what changed):**
+```bash
+git diff main...HEAD --stat
+```
+
+**Commit messages (why it changed):**
+```bash
+git log main...HEAD --oneline
+```
+
+**Full diff (how it changed):**
+
+Use `origin/main` first (always up to date), fall back to local `main`, then `master`:
+```bash
+if git rev-parse origin/main &>/dev/null 2>&1; then
+  BASE=origin/main
+elif git rev-parse main &>/dev/null 2>&1; then
+  BASE=main
+else
+  BASE=master
+fi
+git diff $BASE...HEAD
+```
+
+If the diff is very large (over 500 lines), read the `--stat` summary and the commit messages only. Also read the first 200 lines of the diff to understand the primary changes without processing the entire output.
+
+Also check for an existing PR and read its current title/body:
+```bash
+gh pr view --json title,body,baseRefName 2>/dev/null
+```
+
+---
+
+## Step 3: Read the Format Guide
+
+Read `references/pr-format-guide.md` in full before writing anything. Internalize:
+- Required sections and their order
+- How to write each section
+- What to include vs omit
+- The testing section format
+
+---
+
+## Step 4: Generate the Description
+
+Write the PR description using the format from `references/pr-format-guide.md`.
+
+Rules:
+- Every bullet in the Changes section must trace to something in the diff
+- Do not invent testing steps that are not implied by the code changes
+- If a section has no relevant content, omit it entirely (do not write "N/A" or leave it empty)
+- Screenshots section: only include if there are UI changes visible in the diff
+- If commit messages explain the "why", use that context in the Summary
+
+**QA checkpoint:** Before presenting, verify:
+- [ ] Summary is 1-2 sentences, active voice, no filler
+- [ ] Every change bullet is specific and traces to the diff
+- [ ] No invented metrics or outcomes
+- [ ] Testing steps are actionable (someone could follow them)
+- [ ] No em dashes in any line
+
+---
+
+## Step 5: Create or Update the PR
+
+Present the description to the user and ask: "Ready to create the PR, update the existing one, or output only?"
+
+**Create a new PR:**
+
+Pass the body via stdin to handle backticks, quotes, and newlines safely:
+```bash
+gh pr create --title "TITLE_HERE" --body-file - << 'EOF'
+BODY_HERE
+EOF
+```
+
+Suggest a title based on the commit messages and diff summary. The title should be imperative mood, under 72 characters: "Add Redis caching for user session lookups" not "Added caching".
+
+**Update an existing PR:**
+```bash
+gh pr edit --body-file - << 'EOF'
+BODY_HERE
+EOF
+```
+
+**Output only:** Present the title and body in a code block for manual copy-paste.
+
+After creating or updating, confirm: "PR description updated. View it at: [URL]"
+
+
+
+

package/skills/pr-description-writer/evals/evals.json

@@ -0,0 +1,35 @@
+{
+  "skill_name": "pr-description-writer",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write a PR description for my current branch",
+      "expected_output": "Agent runs git branch --show-current, git diff main...HEAD --stat, git log main...HEAD --oneline, and git diff main...HEAD. Reads references/pr-format-guide.md. Generates a PR description with Summary (1-2 sentences, active voice, present tense), Changes (specific bullets starting with verbs, tracing to diff), and Testing sections. No invented metrics. No em dashes. Presents the description and asks whether to create, update, or output only.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Create a PR for this branch with a good description",
+      "expected_output": "Agent gathers diff context, generates description, suggests a title in imperative mood under 72 characters. Runs gh pr create --title 'suggested title' --body 'generated body'. Returns the PR URL after creation. Title does not start with 'Added' or 'This PR'.",
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Update my existing PR's description",
+      "expected_output": "Agent runs gh pr view --json title,body,baseRefName to check for an existing PR. Finds the PR. Generates a new description from the current diff. Runs gh pr edit --body 'new body'. Confirms the update with the PR URL.",
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "Write a PR description for this large refactor branch",
+      "expected_output": "Agent detects the diff is large (over 500 lines). Falls back to reading --stat and commit messages only, plus the first 200 lines of the diff. Still produces a valid PR description. The Changes section uses sub-headers to group related changes if there are more than 6 bullets. Does not time out or fail on a large diff.",
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "Write a PR description for a branch with only documentation changes",
+      "expected_output": "Agent detects the diff only touches .md or documentation files. Generates a short description: Summary explains what docs were updated, Changes lists the specific files and what changed in them. Omits the Testing section (no behavior change). Final description is 5-10 lines total.",
+      "files": []
+    }
+  ]
+}

package/skills/pr-description-writer/references/pr-format-guide.md

@@ -0,0 +1,145 @@
+# PR Description Format Guide
+
+The format every generated PR description must follow. Read before writing.
+
+---
+
+## Required Sections
+
+### Summary
+
+One to two sentences. What does this PR do and why?
+
+- Use present tense, active voice: "Adds Redis caching to reduce database load on high-traffic endpoints."
+- Include the motivation if it's clear from the diff or commits: "Fixes a race condition in the session store that caused intermittent 401s under load."
+- Do not start with "This PR" or "This commit"
+
+Good:
+```
+Adds Redis caching for user session lookups. Reduces average response time on /api/me from 340ms to 12ms by eliminating a database query on every authenticated request.
+```
+
+Bad:
+```
+This PR adds caching. It should improve performance.
+```
+
+---
+
+### Changes
+
+A bulleted list of what changed. One bullet per logical change.
+
+Rules:
+- Start each bullet with a verb: "Adds", "Removes", "Moves", "Fixes", "Refactors", "Updates"
+- Be specific: file names, function names, config keys where relevant
+- Group related changes under a sub-header if there are more than 6 bullets
+
+Good:
+```
+- Adds `src/cache/redis.ts` with `get`, `set`, and `invalidate` methods
+- Wraps `UserService.getById()` with a 5-minute Redis cache
+- Removes the inline `Map` cache in `auth.middleware.ts` (replaced by Redis)
+- Updates `.env.example` with `REDIS_URL` and `REDIS_TTL_SECONDS`
+```
+
+Bad:
+```
+- Updated files
+- Fixed the bug
+- Added new feature
+```
+
+---
+
+### Testing
+
+How to verify this PR works. Actionable steps someone else can follow.
+
+Format options:
+
+**For code changes with clear test steps:**
+```
+- Run `npm test` — all tests pass
+- Start the server and hit `GET /api/me` 10 times rapidly — confirm only 1 DB query appears in logs
+- Check Redis with `redis-cli monitor` while making requests — confirm cache hits after the first request
+```
+
+**For simple refactors with no behavior change:**
+```
+- Run `npm test` — no regressions
+- No behavior change expected
+```
+
+**For infrastructure / config changes:**
+```
+- Deploy to staging and confirm the service starts without errors
+- Check CloudWatch logs for `[redis] connected` on startup
+```
+
+Omit this section if the change is purely documentation or a trivially safe refactor with no observable behavior.
+
+---
+
+### Screenshots (optional)
+
+Only include if there are UI changes in the diff. Skip entirely for backend-only or infrastructure changes.
+
+```
+Before: [paste screenshot or describe]
+After: [paste screenshot or describe]
+```
+
+---
+
+### Linked Issues (optional)
+
+Only include if the PR closes or references an issue.
+
+```
+Closes #123
+Related to #456
+```
+
+Use GitHub closing keywords: `Closes`, `Fixes`, `Resolves` to auto-close on merge.
+
+---
+
+## What to Omit
+
+- Do not list every file changed — that is what the diff is for
+- Do not repeat the commit messages verbatim
+- Do not include "TODO" items or future work unless the reviewer needs to know about them
+- Do not add "cc @person" — leave that for reviewers
+- Do not add a changelog entry — that belongs in a separate file
+- Do not include a "Why" section — fold motivation into the Summary
+
+---
+
+## Length Guide
+
+| PR size | Description length |
+|---------|-------------------|
+| 1-3 files changed | 5-10 lines total |
+| 4-10 files changed | 10-20 lines total |
+| 10+ files changed | 20-40 lines total, use sub-headers in Changes |
+
+Longer is not better. A clear 8-line description beats a padded 40-line one.
+
+---
+
+## Title Format
+
+Imperative mood, present tense, under 72 characters.
+
+Good:
+- `Add Redis caching for session lookups`
+- `Fix race condition in auth middleware`
+- `Migrate user service to TypeScript`
+- `Remove deprecated /v1 API endpoints`
+
+Bad:
+- `Added caching` (past tense)
+- `This PR fixes the auth bug that was causing issues` (too long, filler)
+- `WIP: caching stuff` (not ready to merge)
+- `JIRA-1234: add caching` (ticket reference in title)

package/skills/producthunt-launch-kit/.env.example

@@ -0,0 +1,7 @@
+# producthunt-launch-kit — Environment Variables
+# =================================================
+# Gemini is required for generating all launch copy.
+
+# Required: Google Gemini API key for launch copy generation
+# Get it: aistudio.google.com, Get API key
+GEMINI_API_KEY=your_gemini_api_key_here

package/skills/producthunt-launch-kit/README.md

@@ -0,0 +1,95 @@
+# producthunt-launch-kit
+
+<img width="1280" height="640" alt="producthunt-launch-kit" src="https://github.com/user-attachments/assets/dc16bde9-9bc4-4022-94a8-a4db024cbd95" />
+
+
+Generates a complete Product Hunt launch kit from your product description: tagline variants (60 chars max), listing description, maker comment, launch day tweet thread, LinkedIn post, and a 4-email sequence.
+
+## What It Does
+
+- Generates 5 tagline variants with character counts (all under 60 chars)
+- Writes a listing description under 500 characters
+- Drafts a maker comment (300-400 words) that opens with the builder story, not "Hi PH!"
+- Creates a launch day tweet thread (5-7 tweets, no hashtags)
+- Writes a LinkedIn post for launch day
+- Generates a 4-email sequence: existing users, newsletter, day-of reminder, follow-up
+- Includes a launch checklist with timing and community guidelines
+
+## Requirements
+
+| Requirement | Purpose | How to Set Up |
+|------------|---------|--------------|
+| Gemini API key | All copy generation | aistudio.google.com, Get API key |
+
+## Setup
+
+```bash
+cp .env.example .env
+# Add GEMINI_API_KEY
+```
+
+## How to Use
+
+Full launch kit:
+```
+"Generate a Product Hunt launch kit for my product"
+"Prepare my PH listing and launch copy"
+"Help me launch on Product Hunt"
+```
+
+Specific assets:
+```
+"Write my Product Hunt tagline for [product description]"
+"Draft a maker comment for my PH launch"
+"Write PH launch tweets"
+```
+
+From README:
+```
+"Generate a Product Hunt kit: my README is in this repo"
+```
+
+## Copy Constraints
+
+| Asset | Limit | Notes |
+|-------|-------|-------|
+| Tagline | 60 chars | Hard limit, enforced by PH form |
+| Description | 500 chars | Appears in search and email digests |
+| Maker comment | 300-400 words | Post within 60 seconds of launch |
+| Tweets | 280 chars each | No hashtags on technical threads |
+
+## Maker Comment Strategy
+
+The maker comment drives more PH success than any other single action. It should:
+
+- Open with the real builder story (not "Hi PH! We're excited to announce...")
+- Include at least one technical detail about how it works
+- Acknowledge what the product does NOT do
+- End with a specific question that invites comments
+
+The comment goes live as your first reply to your own listing, within 60 seconds of the product going live at 12:01 AM PST.
+
+## Launch Timing
+
+Best days: Tuesday, Wednesday, Thursday
+
+Avoid: Friday afternoons, holiday weeks, major tech conference days
+
+The first 4 hours determine front page placement. Notify your audience before midnight PST on launch day so they are ready.
+
+## Project Structure
+
+```
+producthunt-launch-kit/
+├── SKILL.md
+├── README.md
+├── .env.example
+├── evals/
+│   └── evals.json
+└── references/
+    └── copy-rules.md
+```
+
+## License
+
+MIT