agentleFS
Sign inStart free
2389-research2389-research/git-repo-prep/skills/prepare/SKILL.md

prepare

Skill2 starsChanged 48 days agoMITView on GitHub

Audits and prepares a codebase for public or open-source release through 9 interactive phases covering secrets, license, documentation, gitignore, hardening, and metadata. Use when releasing a private or internal repository publicly or open-sourcing a project. For a standalone read-only audit without the preparation workflow, use git-repo-prep:review.

  • Reads credentials

5 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions5 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 5

    1. samueltuoyo15/Dokugen★ 345same name
    2. iliasedelkin/jobissimo★ 8same name
    3. mik2win/foureyes★ 2same name
    4. Aquilo-Solution-S/tesla-valve★ 1same name
    5. Mharbulous/probanda-dev★ 1same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository3 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 8 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Create a TodoWrite checklist for all 9 phases:

    line 12
  2. Distinctive:

    Every phase follows this loop:

    line 26
  3. Very specific:

    Commit with descriptive message (e.g., docs: add CONTRIBUTING.md)

    line 34
  4. Distinctive:

    DO mention ecosystem-specific items: when a known stack is detected.

    line 45
  5. Very specific:

    Use the file-to-ecosystem mapping defined in the Ecosystem Detection section of git-repo-prep:review — the same indicators apply here.

    line 55
  6. Very specific:

    Create or update LICENSE file

    line 112
  7. Distinctive:

    Update package metadata license field:

    line 113
  8. Distinctive:

    Add license section to README (or update if present)

    line 117
  9. Distinctive:

    Check for these sections (present or missing):

    line 126
  10. Very specific:

    If the project already uses AI tools or has complex setup, suggest a CLAUDE.md with build/test/lint commands and architectural notes.

    line 152
  11. Very specific:

    Check current .gitignore against ecosystem best practices:

    line 158
  12. Distinctive:

    Ask the user what level of hardening they want: before proposing anything.

    line 182
  13. Distinctive:

    Ask which provider (GitHub Actions is most common).

    line 190
  14. Very specific:

    Use the Skill tool: skill: "git-repo-prep:review"

    line 241

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Prepare for Open-Source Release

Announce: "I'm using git-repo-prep:prepare to walk through open-source preparation."

Setup

Create a TodoWrite checklist for all 9 phases:

  1. Discovery
  2. Secrets & Personal Info Audit
  3. License
  4. Documentation
  5. Gitignore Refinement
  6. Project Hardening
  7. Repository Metadata
  8. Backlog & Honesty
  9. Final Review

Phase Pattern

Every phase follows this loop:

  1. Mark this phase's task in_progress
  2. Scan/audit current state for this phase
  3. Present findings to user
  4. Propose specific changes
  5. AskUserQuestion — skip / approve / modify
  6. Implement approved changes
  7. Commit with descriptive message (e.g., docs: add CONTRIBUTING.md)
  8. Mark phase task complete, move to next

Rules

  • DO NOT prescribe choices — always ask via AskUserQuestion (license, CI provider, test framework, etc.)
  • DO NOT drift into code quality review — stay focused on what matters for making the repo public. Ignore code style, error handling, architecture, performance.
  • DO NOT over-engineer — don't add dotenv, validation, startup checks, or error handling beyond what the user asks for. The goal is open-source readiness, not refactoring.
  • DO NOT dump everything at once — work one phase at a time, wait for user approval before moving on.
  • DO treat personal info as a separate concern from secrets — emails, usernames, and real names in config or metadata are privacy issues even if they aren't credentials.
  • DO check license consistency across LICENSE file, package metadata, and README.
  • DO mention ecosystem-specific items when a known stack is detected.

Phase 1: Discovery

Detect the ecosystem and scan project structure.

Detect ecosystem by looking for:

Use the file-to-ecosystem mapping defined in the Ecosystem Detection section of git-repo-prep:review — the same indicators apply here.

Report what exists (present/missing):

  • README
  • LICENSE
  • .gitignore
  • CI/CD config (.github/workflows/, .gitlab-ci.yml, etc.)
  • Tests directory
  • CONTRIBUTING.md
  • SECURITY.md
  • CHANGELOG

Present findings to user before proceeding.

Phase 2: Secrets & Personal Info

Two separate scans. Both matter for making a repo public.

Secrets scan

  • Hardcoded API keys, passwords, tokens, connection strings in source files
  • .env files or config files containing real credentials
  • AWS keys, GitHub tokens, database URLs with passwords, SMTP credentials
  • Private keys (.pem, .key files)

Personal info scan

  • Email addresses in package metadata (package.json author, pyproject.toml authors, Cargo.toml authors)
  • Email addresses in source code comments or config
  • Real names or usernames hardcoded in source (e.g., DEFAULT_AUTHOR = "jsmith")
  • Usernames in URLs or paths

If secrets or personal info found:

  • Warn that git history also contains these values
  • Recommend key rotation/revocation for any real credentials
  • Suggest git filter-repo or BFG Repo Cleaner for history rewriting if needed
  • Propose replacing secrets with environment variables and creating .env.example
  • Propose replacing personal info with generic values or removing it

Do not add dotenv packages, validation, or startup checks unless the user asks.

Phase 3: License

Ask the user which license they want. Present common options:

  • MIT — permissive, simple
  • Apache-2.0 — permissive, patent grant
  • GPL-3.0 — copyleft
  • Other — ask user to specify

Then:

  1. Create or update LICENSE file
  2. Update package metadata license field:
    • package.json → "license": "MIT"
    • pyproject.toml → license field
    • Cargo.toml → license field
  3. Add license section to README (or update if present)
  4. Check for mismatches — if LICENSE file says MIT but metadata says ISC, flag it

Phase 4: Documentation

README

Check for these sections (present or missing):

  • What the project does and why
  • Installation / getting started
  • Usage with examples
  • Configuration (if applicable)
  • License section
  • Limitations / known issues

Don't write the full docs without asking. Propose the structure, ask user for approval, then help draft.

CONTRIBUTING.md

Propose including:

  • How to report bugs
  • How to submit changes (PR workflow)
  • Code style / conventions
  • Testing expectations
  • Any CLA or DCO requirements

SECURITY.md

Propose a vulnerability reporting process. At minimum: an email or instructions for responsible disclosure.

CLAUDE.md (optional)

If the project already uses AI tools or has complex setup, suggest a CLAUDE.md with build/test/lint commands and architectural notes. Ask first — don't create by default.

Phase 5: Gitignore Refinement

Check current .gitignore against ecosystem best practices:

EcosystemMust ignore
Node.jsnode_modules/, .env, dist/, coverage/
Python__pycache__/, *.pyc, .env, *.egg-info/, dist/, .venv/
Rusttarget/, .env
Govendor/ (if not vendoring), .env
General.env, .env.*, *.log, .DS_Store, *.pem, *.key

Always check:

  • .env and .env.* patterns excluded
  • Credentials directories excluded
  • Build artifacts excluded
  • IDE/OS files excluded (.idea/, .vscode/, .DS_Store, Thumbs.db)

If sensitive files are already tracked:

  • Flag them: "These files are tracked by git and need git rm --cached"
  • Propose the commands, get approval before running

Phase 6: Project Hardening

Ask the user what level of hardening they want before proposing anything. Options:

  • Minimal — just CI basics
  • Standard — CI + dependency updates
  • Full — CI + dependency updates + hooks + coverage

CI/CD

Ask which provider (GitHub Actions is most common). Propose a workflow that:

  • Runs tests
  • Runs linter (if project has one)
  • Runs on push and PR

Dependency management

Suggest Dependabot (GitHub) or Renovate. Brief config.

Pre-commit hooks

Suggest only if project doesn't already have them. Keep it simple — lint + format.

Coverage enforcement

Suggest only if tests already exist. Don't add test frameworks — that's beyond open-source prep scope.

Phase 7: Repository Metadata

Ecosystem-specific metadata that helps with discoverability and distribution:

EcosystemCheck for
Node.jsrepository URL, engines field, files field (or .npmignore), keywords, description
Python[project.urls], classifiers, requires-python, keywords, description
Rustrepository, keywords, categories, rust-version, description
Gomodule path matches repo URL, godoc comment on package

Flag anything missing. Propose additions. Don't prescribe values — ask the user for descriptions, keywords, etc.

Phase 8: Backlog & Honesty

Building trust with contributors by being upfront about the project's state.

  • BACKLOG.md — Suggest creating one if the project has known gaps, unfinished features, or planned work. Ask user what to include.
  • Limitations section in README — If not already present, suggest adding known limitations, unsupported use cases, or stability caveats.

These are optional. Ask before creating.

Phase 9: Final Review

Invoke git-repo-prep:review as a final validation pass.

This catches anything missed during the prepare phases and gives the user a clean summary of the repo's openness state.

Use the Skill tool: skill: "git-repo-prep:review"

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free