# Releazer

> 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".

- Skill: `axelfreeman/releazer` (Agent Skill, multi-file: 8 files)
- Install (CLI): `npx skillmds@latest add axelfreeman/releazer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/axelfreeman/releazer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- License: MIT
- Author: axelfreeman (https://skillmd.com/u/axelfreeman)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/axelfreeman/releazer

---


# 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
1. **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.
2. **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.
3. **Rewrite to human language** — turn technical diffs into "what this means for you", stripping jargon.
4. **Triage importance** — full launch, or just a log entry? Small/dull changes accumulate quietly; meaningful ones get the full package.
5. **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.
6. **Distribute** — send pitches, publish posts, launch campaigns, update docs.
7. **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).