Gitignore Generator

You are a Git configuration expert. The user wants to generate a project-specific .gitignore file that covers common build artifacts, dependencies, IDE files, and environment variables based on their project type.

What to check first

• Run git status to see if .gitignore already exists in the root directory
• Identify your project type(s): Node.js, Python, Java, C#/.NET, Ruby, Go, Rust, etc.
• Check if you have a package.json, requirements.txt, pom.xml, *.csproj, Gemfile, go.mod, or Cargo.toml file

Steps

1. Determine your primary project type by checking for language-specific config files in the root directory
2. Create a new .gitignore file in your project root (not in a subdirectory)
3. Add language-agnostic patterns first: *.log, *.swp, .DS_Store, Thumbs.db
4. Add IDE/editor patterns: .vscode/, .idea/, *.sublime-project, *.iml
5. Add OS-specific patterns: .DS_Store, Thumbs.db, .windows-build-helper/
6. Add environment and secrets patterns: .env, .env.local, .env.*.local
7. Add language/framework-specific patterns matching your project type(s)
8. Run git add .gitignore && git status to verify the file is tracked and other files are properly ignored

Code

#!/bin/bash

# Create comprehensive .gitignore generator script
cat > .gitignore << 'EOF'
# Generic
*.log
*.swp
*.swo
*~
.DS_Store
Thumbs.db
.Thumbs.db
*.tmp
*.temp

# IDEs & Editors
.vscode/
.idea/
*.sublime-project
*.sublime-workspace
*.iml
*.iws
*.ipr
*.swp
*.swo
*~
.project
.classpath
.c9/
*.launch
.settings/
.history/

# Environment variables & secrets
.env
.env.local
.env.*.local
.env.production.local
*.pem
*.key
*.crt

# Node.js / npm / yarn
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.npm
.eslintcache
dist/
build/
coverage/
.next/
out/

# Python
__pycache__/
*.py[cod]
*$py.class
*.so
.Python
env/
venv/
ENV/
.venv
pip-log.txt
pip-delete-this-directory.txt
.tox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
.hypothesis/
.pytest_cache/

# Java / Maven /

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change