Releazer Skill
Releazer turns the traces your coding agent already leaves behind — commits, PRs, diffs, changelogs, README edits — into launch marketing that real people can find and Google can index. It does not write product code; it markets what the code shipped.
When to Use
- You just shipped a feature, fix, or release and want it to spread.
- You have a repo with real activity but zero marketing.
- You want journalists to notice the product and Google to index it.
Don't use for: writing product code, or internal-only changes with no external value.
Prerequisites
- A git repo with commit history (the "traces").
- API keys — provide only the channels you actually want to use:
GITHUB_TOKEN — read commits/PRs, publish releases.DEVTO_API_KEY — publish articles.- Google Ads MCP — paid campaigns (optional).
- Any other channel the launch needs (social, media outlets, etc.).
How to Run
Install once (see README), then after a release point Releazer at the repo. It scans the traces, extracts what shipped, and produces a marketing package in exactly the formats the release needs.
Procedure
- Scan traces — use the
scan_traces.py helper in this repo's scripts/ directory, or read git log + git diff manually. Completion: a plain-language list of what actually changed.
- Understand the product — read the logic, not the release claims: work out how the product actually works. Then write the story: what shipped, who it's for, what it gives them.
- Rewrite to human language — turn technical diffs into "what this means for you", stripping jargon.
- Triage importance — full launch, or just a log entry? Small/dull changes accumulate quietly; meaningful ones get the full package.
- Generate the package — in every format the release needs:
- Media/PR: find relevant outlets, draft email + submission-form pitches.
- Social: draft and schedule posts.
- Paid: Google Ads / retargeting campaign, if budget exists.
- Video/training: if the feature needs onboarding.
- Docs + knowledge-base entry.
- Distribute — send pitches, publish posts, launch campaigns, update docs.
- Verify — confirm each channel actually went out and log the result.
Pitfalls
- Market only what the traces actually show — never invent features.
- API keys are secrets; never commit them.
- A release with no external value will not get traction regardless of format — flag it instead of forcing a launch.
Verification
- The generated story matches
git log and the release diffs.
- Every publish action returned a success handle (URL, ID, or confirmation).
1---2name: releazer3description: Turn shipped code into launch marketing — scan git history, PRs and diffs, then generate media pitches, social posts, ad campaigns, release notes and docs. Use when a developer just shipped a feature or release and wants it announced, needs launch PR, a changelog turned into a launch post, journalists to notice the product, or Google to index it — "launch marketing", "product launch", "announce my release", "PR for my repo".4license: MIT5---67# Releazer Skill89Releazer turns the traces your coding agent already leaves behind — commits, PRs, diffs, changelogs, README edits — into launch marketing that real people can find and Google can index. It does not write product code; it markets what the code shipped.1011## When to Use12- You just shipped a feature, fix, or release and want it to spread.13- You have a repo with real activity but zero marketing.14- You want journalists to notice the product and Google to index it.1516Don't use for: writing product code, or internal-only changes with no external value.1718## Prerequisites19- A git repo with commit history (the "traces").20- API keys — provide only the channels you actually want to use:21 - `GITHUB_TOKEN` — read commits/PRs, publish releases.22 - `DEVTO_API_KEY` — publish articles.23 - Google Ads MCP — paid campaigns (optional).24 - Any other channel the launch needs (social, media outlets, etc.).2526## How to Run27Install once (see README), then after a release point Releazer at the repo. It scans the traces, extracts what shipped, and produces a marketing package in exactly the formats the release needs.2829## Procedure301. **Scan traces** — use the `scan_traces.py` helper in this repo's `scripts/` directory, or read `git log` + `git diff` manually. Completion: a plain-language list of what actually changed.312. **Understand the product** — read the logic, not the release claims: work out how the product *actually* works. Then write the story: what shipped, who it's for, what it gives them.323. **Rewrite to human language** — turn technical diffs into "what this means for you", stripping jargon.334. **Triage importance** — full launch, or just a log entry? Small/dull changes accumulate quietly; meaningful ones get the full package.345. **Generate the package** — in every format the release needs:35 - Media/PR: find relevant outlets, draft email + submission-form pitches.36 - Social: draft and schedule posts.37 - Paid: Google Ads / retargeting campaign, if budget exists.38 - Video/training: if the feature needs onboarding.39 - Docs + knowledge-base entry.406. **Distribute** — send pitches, publish posts, launch campaigns, update docs.417. **Verify** — confirm each channel actually went out and log the result.4243## Pitfalls44- Market only what the traces actually show — never invent features.45- API keys are secrets; never commit them.46- A release with no external value will not get traction regardless of format — flag it instead of forcing a launch.4748## Verification49- The generated story matches `git log` and the release diffs.50- Every publish action returned a success handle (URL, ID, or confirmation).
axelfreeman