菜单
Generate, audit, or update GitHub READMEs with project-type-aware structure, voice calibration, and SEO/AEO discoverability guidance. Three modes: generate (new), audit (check existing), update (patch). Detects repo type and adapts sections, tone, and badges accordingly.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Klaviyo marketing operations and analyst expertise. Audit flows, segments, campaigns, deliverability, and revenue attribution. Use when the user asks about Klaviyo marketing strategy, email/SMS automation, customer segmentation, flow optimization, or lifecycle marketing. For API integration, SDK, webhook, or developer questions, see the klaviyo-developer skill.
Klaviyo API and developer integration expertise. Event tracking, SDKs, webhooks, rate limits, OAuth, catalog sync, and code patterns. Use when the user asks about Klaviyo API, integrating with Klaviyo, tracking events, building custom integrations, webhook handling, or developer implementation. For marketing strategy, flow optimization, and campaign auditing, see the klaviyo-analyst skill.
Pre-push hygiene check for GitHub repositories. Scans for PII, secrets, and sensitive data before pushing. Audits commit messages, enforces repo-specific blocklists, and rate-limits pushes to avoid GitHub abuse detection. Use before any git push, especially to public repos.
Google Tag Manager expertise. Audit GTM containers, design tag and trigger architecture, debug firing issues, implement consent mode v2, and advise on server-side tagging. Use when the user asks about GTM, tag management, container audits, consent mode, server-side tagging, or tracking implementation.
Comprehensive content marketing toolkit with brand voice analysis, SEO optimization scripts, content frameworks, social media strategy, and content calendar planning. Use when writing blog posts, creating social media content, analyzing brand voice, optimizing SEO, planning content calendars, or developing content strategy. For deep SEO writing optimization, see the seo-content-writer skill.
One-command GitHub repository health audit. Checks for missing standard files, GitHub configuration, branch protection, documentation quality, and code hygiene. Produces a scored health report with prioritized fix recommendations.
| name | github-readme |
| description | Generate, audit, or update GitHub READMEs with project-type-aware structure, voice calibration, and SEO/AEO discoverability guidance. Three modes: generate (new), audit (check existing), update (patch). Detects repo type and adapts sections, tone, and badges accordingly. |
| license | MIT |
| origin | custom |
| author | Rebecca Rae Barton |
| author_url | https://github.com/thatrebeccarae |
| metadata | {"version":"2.0.0","category":"devops","domain":"github","updated":"2026-03-19T00:00:00.000Z","tested":"2026-03-19T00:00:00.000Z","tested_with":"Claude Code v2.1"} |
Generate, audit, or update repository READMEs with project-type detection, voice calibration, discoverability guidance, and scored quality audits.
git clone https://github.com/thatrebeccarae/claude-marketing.git && cp -r claude-marketing/skills/github-readme ~/.claude/skills/
/github:readme generate [repo-path] # Scan repo, detect type, generate README
/github:readme audit [repo-path] # Score existing README (read-only, 0-100)
/github:readme update [repo-path] # Re-scan, silent audit, patch with approval
Default repo-path is the current working directory if omitted.
Expect: /github:readme {mode} [repo-path]
generate, audit, or update. Any other value or missing → error with usage hint. STOP..git. If not → error. STOP.Store repo_path (absolute) and mode.
Gather context by reading available files. Skip gracefully if a file does not exist.
Package/config files (tech stack detection):
package.json — Node/TypeScript/ReactCargo.toml — Rustpyproject.toml, setup.py, requirements.txt — Pythongo.mod — Gotsconfig.json — TypeScript confirmationDockerfile, docker-compose.yml — containerizationMakefile, justfile — build system.github/workflows/ — CI/CDDirectory structure:
ls at repo root for top-level layoutsrc/, bin/, lib/, scripts/, docs/, tests/, skills/, templates/, plugins/, .github/Existing docs:
README.md, CONTRIBUTING.md, SECURITY.md, LICENSE, ARCHITECTURE.md, CHANGELOG.md, CODE_OF_CONDUCT.md, llms.txtGit remote:
git -C {repo_path} remote get-url origin{owner} and {repo} from the URL.public-repo marker → public; -dev suffix or no marker → ask userClassify the repo into exactly one type based on scan signals:
| Type | Signals |
|---|---|
| tool/CLI | Has bin field in package.json, CLI entry points, man pages, command parsers (yargs, clap, cobra) |
| library/SDK | Has main/exports/module field, published to npm/PyPI/crates.io, no CLI entry |
| collection/marketplace | Contains multiple independent items: skills/, templates/, plugins/, recipes/ directories with 3+ subdirectories |
| web-app | Has React/Vue/Svelte/Next/Nuxt, server framework (Express, FastAPI, Actix), deployment config (Vercel, Dockerfile) |
| personal/experimental | Small repo (<20 files), no package publishing config, no CI, no semver tags |
If ambiguous, ask the user to confirm. Store as project_type.
Before generating or auditing README content, check these repo-level discoverability signals. Present findings and suggestions to the user.
Repo name:
markdown-lint-action > my-linter)app, project, tool, my-thingGitHub About/description:
gh repo view if availableTopics:
typescript, cli) and specific (markdown-parser, github-action) topicsSocial preview image:
llms.txt (optional):
llms.txt filePresent discoverability suggestions. User can accept, skip, or defer. These do NOT block README generation.
4a. Check for existing README — if present, confirm overwrite or suggest update mode instead.
4b. Select sections based on project type (see Section Menu below).
4c. Voice calibration:
4d. Generate each section:
4e. Run PII/infrastructure scrub (see below). Remove violations before writing.
4f. Write {repo_path}/README.md and display summary.
Read existing README. Do NOT modify any files.
Run quality-signal checks and score against weighted rubric:
| Category | Weight | Checks |
|---|---|---|
| Clarity | 25 | Clear one-line description? Title is descriptive? |
| Usability | 25 | Working install/setup command? Code examples? Getting started under 20 lines? |
| Credibility | 15 | Badges present? Badge URLs resolve? License section present? |
| Currency | 15 | Version numbers match package config? Tech stack matches repo? No stale links? |
| Security | 20 | No PII or infrastructure leaks? No API keys/tokens? No private hostnames/IPs? |
Scoring: Each category scored 0-100, final score = weighted average.
=== README Audit: {repo-name} ===
Score: {X}/100
Clarity: {X}/25
Usability: {X}/25
Credibility: {X}/15
Currency: {X}/15
Security: {X}/20
PASS:
- {passing checks}
WARN:
- {warnings with specific detail}
FAIL:
- {failures with specific detail and fix suggestion}
[STRUCTURE] — missing/outdated sections, badge changes[CONTENT] — stale version numbers, outdated tech references[VOICE] — hedge language, marketing fluff, passive voice[SECURITY] — PII/infra violations (applied automatically)y (all), N (cancel), or comma-separated numbers| Section | tool/CLI | library/SDK | collection | web-app | personal |
|---|---|---|---|---|---|
| Title + description | Required | Required | Required | Required | Required |
| Badges | Required | Required | Required | Required | Optional |
| Getting Started / Install | Required | Required | Required | Required | Required |
| Usage / Commands | Required | -- | -- | -- | -- |
| API Reference | -- | Required | -- | -- | -- |
| Catalog / Index | -- | -- | Required | -- | -- |
| Features | Recommended | Recommended | -- | Required | -- |
| Configuration | Recommended | Recommended | -- | Recommended | -- |
| Architecture | -- | -- | -- | Recommended | -- |
| Why I Built This | -- | -- | -- | -- | Required |
| Who This Is For | Recommended | Recommended | Recommended | -- | -- |
| Contributing | Recommended | Required | Recommended | Recommended | -- |
| License | Required | Required | Required | Required | Required |
| Type | Default Tone | Example Opening |
|---|---|---|
| tool/CLI | Direct, practical | "Fast Markdown linting for CI pipelines." |
| library/SDK | Technical, precise | "A typed HTTP client for the Stripe API." |
| collection | Organized, scannable | "50+ reusable GitHub Actions workflows." |
| web-app | Product-focused, clear | "Real-time project dashboard with team analytics." |
| personal | First-person, opinionated | "I needed a better way to track reading habits." |
Always: direct, specific, opinionated, short paragraphs (4 sentences max). Never: hedge language, marketing fluff, passive voice in problem statements, emojis in prose.
Based on detected tech stack, generate 1-3 tech badges + license badge minimum.
Use style=for-the-badge for all badges. Generic patterns:
Badge order: tech stack (left) → stars → license (right).
Run in ALL modes. Scan generated or existing README text for:
sk-, token_, ghp_, Bearer, long alphanumeric strings)If violations found: list each, remove or redact, show user what was removed. Security violations are never optional — applied automatically in update mode.