Github Readme

GitHub README Generator

Generate, audit, or update repository READMEs with project-type detection, voice calibration, discoverability guidance, and scored quality audits.

Install

git clone https://github.com/thatrebeccarae/claude-marketing.git && cp -r claude-marketing/skills/github-readme ~/.claude/skills/

When to Use

• Starting a new public repo and need a solid README from scratch
• Auditing an existing README for quality, discoverability, and security issues
• Updating a README after the repo has evolved (new deps, features, structure)
• Preparing a repo for public release and want discoverability optimized

Modes

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

---

Step 0: Parse and Validate

Expect: /github:readme {mode} [repo-path]

1. Extract mode — generate, audit, or update. Any other value or missing → error with usage hint. STOP. 2. Extract repo-path — second argument, or current working directory if omitted. 3. Validate — confirm path exists, is a directory, and contains .git. If not → error. STOP.

Store repo_path (absolute) and mode.

---

Step 1: Scan the Repo

Gather context by reading available files. Skip gracefully if a file does not exist.

Package/config files (tech stack detection):

• package.json — Node/TypeScript/React
• Cargo.toml — Rust
• pyproject.toml, setup.py, requirements.txt — Python
• go.mod — Go
• tsconfig.json — TypeScript confirmation
• Dockerfile, docker-compose.yml — containerization
• Makefile, justfile — build system
• .github/workflows/ — CI/CD

Directory structure:

• Run ls at repo root for top-level layout
• Note: src/, 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.txt

Git remote:

• Run git -C {repo_path} remote get-url origin
• Extract {owner} and {repo} from the URL
• Determine public/private: .public-repo marker → public; -dev suffix or no marker → ask user

---

Step 2: Detect Project Type

Classify the repo into exactly one type based on scan signals:

If ambiguous, ask the user to confirm. Store as project_type.

---

Step 3: Discoverability Audit

Before generating or auditing README content, check these repo-level discoverability signals. Present findings and suggestions to the user.

Repo name:

• Is it keyword-rich and searchable? (e.g., markdown-lint-action > my-linter)
• Flag generic names: app, project, tool, my-thing

GitHub About/description:

• Read via gh repo view if available
• Should be 3-8 words, front-loaded with primary keyword
• Suggest improvement if missing or generic

Topics:

• GitHub allows up to 20 topics
• Suggest relevant topics based on detected tech stack, project type, and domain
• Include both broad (typescript, cli) and specific (markdown-parser, github-action) topics

Social preview image:

• Flag if missing — suggest creating one (1280x640px recommended)

llms.txt (optional):

• If repo is a library/SDK or tool/CLI, suggest generating an llms.txt file
• Purpose: helps LLMs understand and recommend the project accurately

Present discoverability suggestions. User can accept, skip, or defer. These do NOT block README generation.

---

Step 4: Generate / Audit / Update

Generate Mode

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:

• Default: professional product voice — clear, direct, no hedge language, no marketing fluff
• Personal/experimental repos OR explicit user opt-in: first-person voice allowed
• Never: passive voice in problem statements, emojis in prose, marketing fluff

4d. Generate each section:

• Title + description — derive name from package config or directory; one-line bold description under 120 chars
• Badges — see Badge Selection below
• Getting Started / Install — prerequisites with versions, install steps, first-run command. Under 20 lines.
• Type-specific sections — per Section Menu. Only include if enough scanned context exists.
• "Why" section (personal/experimental only) — ask user for 2-3 sentences. Do not fabricate.
• License — read LICENSE file type. One line linking to the file.

4e. Run PII/infrastructure scrub (see below). Remove violations before writing.

4f. Write {repo_path}/README.md and display summary.

Audit Mode (read-only)

Read existing README. Do NOT modify any files.

Run quality-signal checks and score against weighted rubric:

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}

Update Mode

1. Re-scan repo (Step 1) to detect current state 2. Run silent audit — store results, do not display 3. Generate update plan — diff-style, grouped by category:

• [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)

4. Show preview — numbered list of proposed changes 5. User approval — y (all), N (cancel), or comma-separated numbers 6. Apply, run final PII scrub, write file, display summary

---

Section Menu by Project Type

---

Voice Guidelines

Always: direct, specific, opinionated, short paragraphs (4 sentences max). Never: hedge language, marketing fluff, passive voice in problem statements, emojis in prose.

---

Badge Selection

Based on detected tech stack, generate 1-3 tech badges + license badge minimum.

Use style=for-the-badge for all badges. Generic patterns:

![License](https://img.shields.io/github/license/{owner}/{repo}?style=for-the-badge)
![GitHub Stars](https://img.shields.io/github/stars/{owner}/{repo}?style=for-the-badge)
![TypeScript](https://img.shields.io/badge/TypeScript-3178C6?style=for-the-badge&logo=typescript&logoColor=white)
![Python](https://img.shields.io/badge/Python-3776AB?style=for-the-badge&logo=python&logoColor=white)
![Node.js](https://img.shields.io/badge/Node.js-339933?style=for-the-badge&logo=nodedotjs&logoColor=white)
![React](https://img.shields.io/badge/React-61DAFB?style=for-the-badge&logo=react&logoColor=black)

Badge order: tech stack (left) → stars → license (right).

---

PII / Infrastructure Scrub

Run in ALL modes. Scan generated or existing README text for:

• [ ] Private hostnames
• [ ] IP addresses (especially 10.x, 172.16-31.x, 192.168.x, 100.x Tailscale)
• [ ] Internal network/VLAN names
• [ ] Device identifiers or serial numbers
• [ ] Client or employer names that should not be public
• [ ] Personal email addresses
• [ ] API keys or tokens (sk-, token_, ghp_, Bearer, long alphanumeric strings)
• [ ] Internal Docker/service config (private port mappings, container names)
• [ ] SSH config references (aliases, private key paths)

If violations found: list each, remove or redact, show user what was removed. Security violations are never optional — applied automatically in update mode.

---

Key Principles

• Detect, don't assume. Scan the repo and adapt structure to what actually exists.
• Professional by default. First-person voice is opt-in, not the default.
• Discoverability matters. Repo name, description, topics, and llms.txt are part of the README story.
• Quality over completeness. Fewer well-written sections beat bloated README with empty placeholders.
• Security is non-negotiable. PII/infra scrub runs in every mode, every time.
• Audit mode is read-only. Never modify files during an audit.

GitHub README — Examples

---

Example 1: Generate README for a TypeScript CLI Tool

Prompt:

Generate a README for this repo. It's a CLI tool for bulk-renaming files with regex patterns.

Expected output: Title + badges (TypeScript, Node.js >=18, MIT license, GitHub stars), one-line description, and these sections:

• Why I Built This — Skill asks user for motivation, never fabricates
• Getting Started — Prerequisites (Node >= 18), npm install -g rename-cli
• Commands — Table format:

• Configuration — .renamerc options
• Contributing — Fork/branch/PR instructions
• License — MIT

Professional voice. No emojis in prose. No "Why I Built This" fabrication. for-the-badge style on all badges.

---

Example 2: Generate README for a Python Library

Prompt:

Generate a README for this Python library that provides rate-limiting decorators for async functions.

Expected output: Title + badges (Python 3.11+, PyPI version, MIT license, stars), then:

• Why I Built This — User-provided
• Getting Started — pip install ratelimit-async / poetry add ratelimit-async
• Quick Start — Working code example:

from ratelimit_async import limit

@limit(calls=10, period=60)
async def fetch_data(url: str) -> dict:
    ...

• API Reference — Function signatures with parameter docs:
• @limit(calls, period, strategy="sliding_window") — params, types, defaults
• @limit_concurrent(max_concurrent) — concurrency cap
• RateLimitExceeded — exception class
• Contributing / License

Technical voice. Function signatures are exact. Install commands cover pip and poetry.

---

Example 3: Generate README for a Skill/Template Collection

Prompt:

Generate a README for this repo. It contains 30+ Claude Code skills for marketing.

Expected output: Title + badges (Claude Code, MIT, stars, LinkedIn, X — social badges because user confirms flagship), then:

• Why I Built This — User-provided
• Quick Start — Clone, copy to ~/.claude/skills/, invoke with /skill-name
• Skills Catalog — Categorized tables (not a flat list):

• How Skills Work — SKILL.md structure, tool access
• Composing Skills — Chaining workflows (research -> produce -> review)
• Configuration / Contributing / License

Catalog voice — organized, browsable. Skills grouped by category with tables.

---

Example 4: Audit an Existing README

Prompt:

Audit the README for this repo.

Expected output (read-only, no files modified):

=== README Audit: rename-cli ===
Score: 68/100

  Description:   12/15 — Clear but doesn't mention target audience
  Installation:  15/20 — npm command works but missing prerequisites
  Usage:          8/20 — No code examples, only text description
  Badges:         5/10 — License badge missing, npm badge stale
  Structure:     10/15 — Good order but missing Contributing section
  Completeness:   8/10
  Freshness:     10/10

FAIL:
  - Required badge missing: License
  - npm badge URL returns 404 (package name mismatch)
  - No Contributing section (public repo)

WARN:
  - Badge style inconsistent (mixing flat and for-the-badge)
  - "Install" should be "Getting Started"
  - One paragraph exceeds 4 sentences

Discoverability:
  - Repo description empty — add: "Bulk-rename files with regex patterns"
  - No topics — suggest: typescript, cli, file-rename, regex
  - No social preview image

Suggested fixes:
  - Add: [![License: MIT](https://img.shields.io/github/license/...)]
  - Fix npm badge package name: "rename-cli" not "rename"
  - Add Contributing section with fork/branch/PR instructions

Scored with category breakdown per REFERENCE.md rubric. Includes discoverability audit for repo metadata (description, topics, social preview).

---

Example 5: Update README After Adding Features

Prompt:

Update the README. We added a --dry-run flag and dropped Node 16 support.

Expected output — diff-style preview:

=== README Update Plan: rename-cli ===
5 changes proposed:

1. [BADGE] Node.js version
   - Node.js-%3E%3D16
   + Node.js-%3E%3D18

2. [SECTION] Commands table — add --dry-run
   + | `rename apply --dry-run` | Preview renames without executing |

3. [SECTION] Getting Started — prerequisites
   - Node.js >= 16
   + Node.js >= 18

4. [STRUCTURE] Nav anchors missing Configuration link

5. [VOICE] Hedge language in Why I Built This
   - "This might be useful if you need to..."
   + "I built this because renaming files in bulk shouldn't require..."

Apply all changes? [y/N/select]

User responds select 1,2,3 — applies badge update, new command row, and prerequisites only. Skips nav anchors and voice rewrite.

=== README Updated: rename-cli ===
Changes applied: 3 of 5
PII/Infra scrub: PASS
Updated: /path/to/repo/README.md

Selective apply lets user accept feature updates while deferring style fixes. PII scrub runs on final output regardless.

GitHub README — Reference

Technical data, templates, and patterns for the github-readme skill.

---

Badge URL Patterns

All badges use shields.io. Default style is style=for-the-badge. Append &style=flat for inline/compact use.

Repository Badges

<!-- GitHub stars -->
[![Stars](https://img.shields.io/github/stars/{owner}/{repo}?style=for-the-badge&logo=github&color=121011)](https://github.com/{owner}/{repo}/stargazers)

<!-- License (auto-detect from repo) -->
[![License](https://img.shields.io/github/license/{owner}/{repo}?style=for-the-badge&labelColor=353535)](LICENSE)

<!-- License (hardcoded MIT) -->
[![License](https://img.shields.io/badge/License-MIT-555?style=for-the-badge&labelColor=353535)](LICENSE)

<!-- Build status (GitHub Actions) -->
[![Build](https://img.shields.io/github/actions/workflow/status/{owner}/{repo}/{workflow}.yml?branch=main&style=for-the-badge&logo=githubactions&logoColor=white)](https://github.com/{owner}/{repo}/actions)

<!-- Last commit -->
[![Last Commit](https://img.shields.io/github/last-commit/{owner}/{repo}?style=for-the-badge)](https://github.com/{owner}/{repo}/commits)

<!-- npm version -->
[![npm](https://img.shields.io/npm/v/{package}?style=for-the-badge&logo=npm&logoColor=white)](https://npmjs.com/package/{package})

<!-- PyPI version -->
[![PyPI](https://img.shields.io/pypi/v/{package}?style=for-the-badge&logo=pypi&logoColor=white)](https://pypi.org/project/{package})

<!-- crates.io version -->
[![Crates.io](https://img.shields.io/crates/v/{crate}?style=for-the-badge&logo=rust&logoColor=white)](https://crates.io/crates/{crate})

<!-- Docker pulls -->
[![Docker](https://img.shields.io/docker/pulls/{owner}/{image}?style=for-the-badge&logo=docker&logoColor=white)](https://hub.docker.com/r/{owner}/{image})

<!-- Coverage (Codecov) -->
[![Coverage](https://img.shields.io/codecov/c/github/{owner}/{repo}?style=for-the-badge&logo=codecov&logoColor=white)](https://codecov.io/gh/{owner}/{repo})

<!-- npm downloads -->
[![Downloads](https://img.shields.io/npm/dm/{package}?style=for-the-badge)](https://npmjs.com/package/{package})

Tech Stack Badges

Pattern: brand color on LEFT (labelColor), gray #555 on RIGHT.

<!-- TypeScript -->
[![TypeScript](https://img.shields.io/badge/TypeScript-ESM-555?style=for-the-badge&labelColor=007ACC&logo=typescript&logoColor=white)](#)

<!-- Node.js -->
[![Node](https://img.shields.io/badge/Node-%3E%3D22-555?style=for-the-badge&labelColor=6DA55F&logo=node.js&logoColor=white)](#)

<!-- Python -->
[![Python](https://img.shields.io/badge/Python-3.11+-555?style=for-the-badge&labelColor=3670A0&logo=python&logoColor=ffdd54)](https://python.org)

<!-- Rust -->
[![Rust](https://img.shields.io/badge/Rust-2021-555?style=for-the-badge&labelColor=000000&logo=rust&logoColor=white)](https://rust-lang.org)

<!-- Go -->
[![Go](https://img.shields.io/badge/Go-1.22+-555?style=for-the-badge&labelColor=00ADD8&logo=go&logoColor=white)](https://go.dev)

<!-- React -->
[![React](https://img.shields.io/badge/React-61DAFB?style=for-the-badge&labelColor=20232a&logo=react&logoColor=61DAFB)](https://react.dev)

<!-- Vue -->
[![Vue](https://img.shields.io/badge/Vue-3.x-555?style=for-the-badge&labelColor=4FC08D&logo=vue.js&logoColor=white)](https://vuejs.org)

<!-- Next.js -->
[![Next.js](https://img.shields.io/badge/Next.js-15-555?style=for-the-badge&labelColor=000000&logo=next.js&logoColor=white)](https://nextjs.org)

<!-- Docker -->
[![Docker](https://img.shields.io/badge/Docker-Compose-555?style=for-the-badge&labelColor=2496ED&logo=docker&logoColor=white)](https://docker.com)

<!-- Tauri -->
[![Tauri](https://img.shields.io/badge/Tauri-v2-555?style=for-the-badge&labelColor=24C8DB&logo=tauri&logoColor=white)](https://v2.tauri.app)

<!-- Claude Code -->
[![Claude Code](https://img.shields.io/badge/Claude_Code-Skills-555?style=for-the-badge&labelColor=D97757&logo=claude&logoColor=white)](https://docs.anthropic.com/en/docs/claude-code)

<!-- Tailwind CSS -->
[![Tailwind](https://img.shields.io/badge/Tailwind-v4-555?style=for-the-badge&labelColor=06B6D4&logo=tailwindcss&logoColor=white)](https://tailwindcss.com)

<!-- Prisma -->
[![Prisma](https://img.shields.io/badge/Prisma-ORM-555?style=for-the-badge&labelColor=2D3748&logo=prisma&logoColor=white)](https://prisma.io)

<!-- PostgreSQL -->
[![PostgreSQL](https://img.shields.io/badge/PostgreSQL-16-555?style=for-the-badge&labelColor=4169E1&logo=postgresql&logoColor=white)](https://postgresql.org)

<!-- SQLite -->
[![SQLite](https://img.shields.io/badge/SQLite-WAL-555?style=for-the-badge&labelColor=003B57&logo=sqlite&logoColor=white)](https://sqlite.org)

<!-- n8n -->
[![n8n](https://img.shields.io/badge/n8n-Workflows-555?style=for-the-badge&labelColor=EA4B71&logo=n8n&logoColor=white)](https://n8n.io)

<!-- Framer -->
[![Framer](https://img.shields.io/badge/Framer-Components-555?style=for-the-badge&labelColor=000000&logo=framer&logoColor=0055FF)](https://framer.com)

Social Badges (flagship repos only)

[![LinkedIn](https://img.shields.io/badge/LinkedIn-Rebecca%20Rae%20Barton-555?style=for-the-badge&labelColor=0077B5&logo=linkedin&logoColor=white)](https://linkedin.com/in/rebeccaraebarton)
[![X](https://img.shields.io/badge/X-@rebeccarae-555?style=for-the-badge&labelColor=000000&logo=x&logoColor=white)](https://x.com/rebeccarae)

Clone Badge

[![Clone](https://img.shields.io/badge/Clone-git%20clone-555?style=for-the-badge&labelColor=F05033&logo=git&logoColor=white)](https://github.com/{owner}/{repo})

---

Section Templates

Title Block (Hero)

<div align="center">

# Project Name

**One-line description under 120 characters stating what this does.**

[![Badge](url)](#) [![Badge](url)](#) [![Stars](url)](#) [![License](url)](#)

<br>

git clone https://github.com/{owner}/{repo}.git

<br>

<!-- Screenshot or demo (width="760") -->

<br><br>

[Why I Built This](#why-i-built-this) · [Getting Started](#getting-started) · [Features](#features) · [License](#license)

</div>

---

Features List

## Features

**Category One**
- **Feature name** — What it does and why it matters
- **Feature name** — What it does and why it matters

**Category Two**
- **Feature name** — What it does and why it matters

Installation

## Getting Started

### Prerequisites

- Node.js >= 22
- npm >= 10

### Install

npm

npm install {package}

yarn

yarn add {package}

pnpm

pnpm add {package}

pip

pip install {package}

uv

uv add {package}

cargo

cargo install {crate}

go

go install github.com/{owner}/{repo}@latest

git clone

git clone https://github.com/{owner}/{repo}.git cd {repo} npm install

Quick Start

## Quick Start

import { Client } from "{package}";

const client = new Client({ apiKey: process.env.API_KEY }); const result = await client.doSomething({ input: "value" }); console.log(result);

CLI Commands Table

## Commands

| Command | Description |
|---------|-------------|
| `tool init [name]` | Initialize a new project |
| `tool build` | Build for production |
| `tool dev` | Start dev server with hot reload |
| `tool test` | Run test suite |
| `tool lint` | Lint and format |

### `tool init`

tool init [project-name] [--template <name>] [--no-git]

**Options:**
| Flag | Default | Description |
|------|---------|-------------|
| `--template` | `basic` | Starter template |
| `--no-git` | `false` | Skip git initialization |

API Reference (Expandable)

## API Reference

<details>
<summary><code>GET /v1/resources</code> — List all resources</summary>

**Parameters:**

| Param | Type | Required | Description |
|-------|------|----------|-------------|
| `limit` | integer | No | Max results (default: 20) |
| `offset` | integer | No | Pagination offset |

**Response:**

{ "data": [], "total": 100, "limit": 20, "offset": 0 }

</details>

<details>
<summary><code>POST /v1/resources</code> — Create a resource</summary>

**Body:**

{ "name": "string (required)", "type": "string" }

**Response:** `201 Created`

</details>

Environment Variables Table

## Configuration

| Variable | Required | Default | Description |
|----------|----------|---------|-------------|
| `API_KEY` | Yes | -- | API key from dashboard |
| `PORT` | No | `3000` | Server port |
| `LOG_LEVEL` | No | `info` | `debug`, `info`, `warn`, `error` |
| `DATABASE_URL` | Yes | -- | PostgreSQL connection string |

Copy `.env.example` to `.env` and fill in values:

cp .env.example .env

Architecture Overview

## Architecture

repo/ ├── src/ │ ├── core/ # Core business logic │ ├── api/ # API routes and handlers │ ├── lib/ # Shared utilities │ └── index.ts # Entry point ├── config/ # Configuration files ├── scripts/ # Build and deploy scripts └── tests/ # Test suites

Brief explanation of data flow or key design decisions (2-3 sentences).

Contributing

## Contributing

Contributions welcome. See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines.

1. Fork the repo
2. Create a feature branch (`git checkout -b feature/thing`)
3. Commit changes (`git commit -m 'Add thing'`)
4. Push (`git push origin feature/thing`)
5. Open a Pull Request

License

## License

MIT -- see [LICENSE](LICENSE) for details.

---

Project Type Detection Signals

---

Audit Scoring Rubric

Total: 100 points. Each category is weighted and scored independently.

Scoring formula: sum(category_score * weight) rounded to nearest integer.

Grade thresholds:

• 90-100: Excellent -- no action needed
• 70-89: Good -- minor improvements recommended
• 50-69: Needs work -- several sections require attention
• Below 50: Poor -- consider running generate mode

---

Discoverability Reference

GitHub Search Ranking Factors

Priority order for how GitHub search weights content:

1. Repository name — exact and partial matches rank highest 2. Description — the About field on the repo page 3. Topics — tagged topics visible below description 4. README content — full-text indexed but lowest weight

Topic Best Practices

• Use lowercase, hyphenated terms (cli-tool, not CLI Tool)
• Prefer single-concept topics (typescript, readme-generator)
• Max 20 topics per repo (GitHub hard limit)
• Include: language, framework, domain, use-case
• Avoid: generic terms (awesome, tool), version numbers, duplicating the repo name

Social Preview Image

• Dimensions: 1280 x 640 px (2:1 ratio)
• Format: PNG or JPG, under 1MB
• Set via repo Settings > Social Preview
• Should include: project name, one-line description, visual identity
• Avoid: small text, busy backgrounds, screenshots at low resolution

llms.txt Specification

A llms.txt file tells LLMs what a project does and how to use it.

• Location: repo root (/llms.txt)
• Format: plain text, structured sections
• Sections: Title, Description, Quick Start, API surface, Key concepts
• Purpose: LLM-optimized alternative to README -- dense, no marketing, no images
• Spec: https://llmstxt.org
• Also generate llms-full.txt for comprehensive reference if project is complex

AEO (Answer Engine Optimization) Patterns

Structure README content so AI assistants and search engines can extract direct answers:

• Semantic headings: Use descriptive H2/H3 that match common questions (## Installation, ## How It Works, not ## Section 3)
• Direct answers first: Lead each section with a 1-2 sentence summary before details
• Cited data points: Include specific numbers, versions, benchmarks where relevant
• Definition patterns: "X is a Y that does Z" in the first paragraph
• Comparison-friendly: When relevant, name alternatives and state differentiators
• Structured data: Tables and lists over prose for reference material

---

PII/Infrastructure Scrub Patterns

Regex patterns for detecting common leaks. Run against all generated README text before writing.

Email Addresses

[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

Allowlist: noreply@github.com, action@github.com, example.com domain.

IP Addresses (RFC 1918 Private Ranges)

# 10.x.x.x
10\.\d{1,3}\.\d{1,3}\.\d{1,3}

# 172.16-31.x.x
172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}

# 192.168.x.x
192\.168\.\d{1,3}\.\d{1,3}

# Tailscale (100.x.x.x CGNAT range)
100\.(6[4-9]|[7-9]\d|1[0-2]\d)\.\d{1,3}\.\d{1,3}

API Keys and Tokens

# AWS access key
AKIA[0-9A-Z]{16}

# AWS secret key (generic 40-char base64)
[A-Za-z0-9/+=]{40}

# GitHub token (classic and fine-grained)
gh[ps]_[A-Za-z0-9_]{36,}
github_pat_[A-Za-z0-9_]{22,}

# Slack token
xox[bpors]-[A-Za-z0-9-]+

# Slack webhook
hooks\.slack\.com/services/T[A-Z0-9]+/B[A-Z0-9]+/[A-Za-z0-9]+

# Generic bearer/API key patterns
(sk|pk|api|key|token|secret|password)[_-]?[A-Za-z0-9]{20,}

# OpenAI
sk-[A-Za-z0-9]{48}

# Anthropic
sk-ant-[A-Za-z0-9-]{40,}

Internal Hostnames

# Specific known hostnames (case-insensitive) — replace with your own
(?i)\b(internal-host-a|internal-host-b)\b

# Generic internal hostname patterns
\b[a-z]+-?(dev|staging|internal|local)\.[a-z]+\.(local|internal|lan)\b

Private Key Material

-----BEGIN (RSA |EC |DSA |OPENSSH )?PRIVATE KEY-----

File Paths Containing Usernames

# macOS home directories
/Users/[a-zA-Z][a-zA-Z0-9._-]+/

# Linux home directories
/home/[a-zA-Z][a-zA-Z0-9._-]+/

# Windows user directories
C:\\Users\\[a-zA-Z][a-zA-Z0-9._-]+\\

Client Names and Internal References

# Replace with your client names and internal codenames
(?i)\b(client-name-a|client-name-b|project-codename)\b

Device Identifiers

\b[A-Z]{5,8}\b  # Serial-like patterns (review matches manually)

---

Voice Calibration Matrix

Adapt tone and structure based on detected project type.

Voice Examples by Type

CLI tool -- lead sentence:

{tool} finds unused dependencies in your Node.js project and removes them.

Library -- lead sentence:

A TypeScript client for the {service} API with full type safety and automatic retry.

Collection -- lead sentence:

55 Claude Code skills for content marketing, developer tools, and design workflows.

Personal project -- lead sentence:

I needed a way to track time without leaving the terminal, so I built one.

---