Gitignore

.gitignore Builder

Understand the codebase first, then write a correct, well-organized .gitignore. Do not paste a generic template blindly — base every entry on something actually present in this repo.

Step 1 — Understand the codebase

Inspect the repo to learn what it's made of. Look for:

• Languages & package managers: package.json (Node), requirements.txt /

pyproject.toml / Pipfile (Python), go.mod (Go), Cargo.toml (Rust), pom.xml / build.gradle (Java/Kotlin), Gemfile (Ruby), composer.json (PHP), *.csproj / *.sln (.NET), etc.

• Frameworks & build tools: React/Next/Vue/Vite, Django/Flask, Rails, Spring,

webpack/rollup, etc. — each has signature output dirs.

• Generated / dependency dirs already on disk: node_modules/, dist/,

build/, .next/, target/, __pycache__/, venv/, .venv/, vendor/, coverage output, compiled binaries.

• Secrets & local config: .env, .env.*, *.pem, *.key, credential files,

local DB files (*.sqlite, *.db).

• Editor / OS noise: .vscode/, .idea/, .DS_Store, Thumbs.db, *.swp.
• Logs / caches / temp: *.log, .cache/, tmp/, coverage/.

Also:

• Read the existing .gitignore (if any) so you don't add duplicates and you

respect its structure/comments.

• Run git status --porcelain and git ls-files to see what's actually tracked vs

untracked — this reveals junk that's currently committed (e.g. a checked-in node_modules/ or .env).

Step 2 — Decide what to ignore

Build the list from evidence, not assumptions:

• Include rules only for stacks/tools you actually detected.
• Group entries under clear # comment headers (e.g. # Node, # Python,

# Secrets, # Editor, # OS).

• Prefer canonical patterns (node_modules/, not node_modules/*).
• Never ignore things that should be tracked: lockfiles (package-lock.json,

poetry.lock, Cargo.lock, go.sum), .env.example templates, source config. When ignoring env files, keep the example: .env + .env.* but !.env.example.

Step 3 — Write the .gitignore

• If none exists, create one. If one exists, append/merge — keep the user's

existing entries and comments, only add what's missing. Never silently delete their rules.

• Keep it organized and commented so it stays maintainable.
• Show the user the proposed additions (a short diff/summary) before or alongside

writing, so they know what changed.

Step 4 — Flag already-tracked files (important)

Adding a pattern to .gitignore does not untrack files Git already tracks. If Step 1 found tracked files that now match an ignore rule (e.g. a committed .env or node_modules/), tell the user and offer the fix:

git rm -r --cached      # stop tracking, keep the local file
# then commit the removal

If a secret (like a committed .env or key) is already in history, warn that removing it from tracking does NOT scrub git history — recommend rotating the secret and, if needed, history-rewriting tools (git filter-repo, BFG).

Rules

• Evidence-based: every entry should correspond to something in this repo (or a

near-certain artifact of a detected tool). Skip stacks that aren't present.

• Don't clobber an existing .gitignore — merge, don't replace.
• Don't ignore lockfiles or .example templates.
• Surface (don't auto-run) git rm --cached for already-tracked matches; let the

user confirm before changing what's tracked.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: POSTTTT
• Source: POSTTTT/SKILLs
• License: MIT

Install and usage instructions live in the source repository linked above.