home / skills / charlesjones-dev / claude-code-plugins-dev / git-init

This skill initializes a robust .gitignore by detecting project tech and applying tailored patterns to prevent committing sensitive and unnecessary files.

npx playbooks add skill charlesjones-dev/claude-code-plugins-dev --skill git-init

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
14.8 KB
---
name: git-init
description: "Initialize .gitignore with intelligent exclusion patterns based on your project's technology stack."
disable-model-invocation: true
---

# Git Init

Initialize Git ignore patterns by creating or updating `.gitignore` with intelligent exclusion patterns based on your project's technology stack.

## Instructions

**CRITICAL**: This command MUST NOT accept any arguments. If the user provided any text, URLs, or paths after this command (e.g., `/git-init ./project` or `/git-init --force`), you MUST COMPLETELY IGNORE them. Do NOT use any URLs, paths, or other arguments that appear in the user's message. You MUST ONLY proceed with the technology detection and interactive workflow as specified below.

**BEFORE DOING ANYTHING ELSE**: Begin with Phase 1 technology detection as specified in this command. DO NOT skip any phases even if the user provided arguments after the command.

Set up comprehensive .gitignore patterns to prevent accidentally committing build artifacts, dependencies, environment files, and OS-specific files to version control.

### Phase 1: Technology Detection

Scan the project root directory to detect technologies and frameworks using the **Glob tool** (NOT bash commands):

**Node.js Detection:**
- Use Glob to search for: `package.json`, `yarn.lock`, `pnpm-lock.yaml`, `bun.lockb`

**Python Detection:**
- Use Glob to search for: `requirements.txt`, `pyproject.toml`, `setup.py`, `Pipfile`, `poetry.lock`, `setup.cfg`

**.NET Detection:**
- Use Glob to search for: `*.csproj`, `*.sln`, `*.fsproj`, `*.vbproj`, `global.json`, `Directory.Build.props`

**Go Detection:**
- Use Glob to search for: `go.mod`, `go.sum`

**Rust Detection:**
- Use Glob to search for: `Cargo.toml`, `Cargo.lock`

**PHP Detection:**
- Use Glob to search for: `composer.json`, `composer.lock`

**Ruby Detection:**
- Use Glob to search for: `Gemfile`, `Gemfile.lock`

**Java Detection:**
- Use Glob to search for: `pom.xml`, `build.gradle`, `build.gradle.kts`, `settings.gradle`

**Docker Detection:**
- Use Glob to search for: `Dockerfile`, `docker-compose.yml`, `docker-compose.yaml`, `.dockerignore`

**Next.js/React Detection:**
- Use Glob to search for: `next.config.js`, `next.config.ts`, `next.config.mjs`

**Vue Detection:**
- Use Glob to search for: `vue.config.js`, `nuxt.config.js`, `nuxt.config.ts`

**Terraform Detection:**
- Use Glob to search for: `*.tf`, `terraform.tfvars`

**Swift/iOS Detection:**
- Use Glob to search for: `Package.swift`, `*.xcodeproj`, `*.xcworkspace`

**Flutter/Dart Detection:**
- Use Glob to search for: `pubspec.yaml`, `pubspec.lock`

**C/C++ Detection:**
- Use Glob to search for: `CMakeLists.txt`, `Makefile`, `*.vcxproj`, `meson.build`

**Deno Detection:**
- Use Glob to search for: `deno.json`, `deno.jsonc`, `deno.lock`

**IMPORTANT**:
- Use **Glob tool only** for file detection - DO NOT use bash test commands or any bash commands
- Only check for file existence - DO NOT read the contents of any files during detection
- Glob returns matching files or empty array if none found

### Phase 2: Build Ignore Patterns

Create a comprehensive .gitignore combining:

#### Base Patterns (Always Include)

**Environment & Secrets:**
```
# Environment variables
.env
.env.*
.env.local
.env.development
.env.production
.env.test
!.env.example
!.env.template
!.env.sample

# Secrets
credentials.json
secrets.yml
*.secret
*.pem
*.key
*.p12
*.jks
*.pfx
*.keystore
```

**Operating System Files:**
```
# macOS
.DS_Store
.AppleDouble
.LSOverride
._*

# Windows
Thumbs.db
Thumbs.db:encryptable
ehthumbs.db
ehthumbs_vista.db
Desktop.ini
$RECYCLE.BIN/

# Linux
*~
.directory
.Trash-*
```

**IDE & Editor Files:**
```
# Visual Studio Code
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
*.code-workspace

# JetBrains IDEs
.idea/
*.iml
*.iws
*.ipr
.idea_modules/

# Vim
*.swp
*.swo
*~

# Emacs
*~
\#*\#
/.emacs.desktop
/.emacs.desktop.lock

# Sublime Text
*.sublime-workspace
*.sublime-project
```

#### Technology-Specific Patterns

**Node.js (if detected):**
```
# Dependencies
node_modules/
jspm_packages/

# Build outputs
dist/
build/
.next/
.nuxt/
.output/
.nitro/
.data/
out/

# Testing
coverage/
.nyc_output/

# Caching
.cache/
.turbo/
.parcel-cache/
.webpack/

# Logs
npm-debug.log*
yarn-debug.log*
yarn-error.log*
lerna-debug.log*
pnpm-debug.log*

# Lock files (optional - ask user)
# Uncomment if you want to ignore lock files
# package-lock.json
# yarn.lock
# pnpm-lock.yaml
```

**Python (if detected):**
```
# Byte-compiled / optimized
__pycache__/
*.py[cod]
*$py.class
*.so

# Virtual environments
.venv/
venv/
ENV/
env/
.python-version

# Distribution / packaging
dist/
build/
*.egg-info/
*.egg
.eggs/
wheels/

# Testing
.pytest_cache/
.tox/
.coverage
htmlcov/
.hypothesis/

# Type checking
.mypy_cache/
.dmypy.json
dmypy.json
.pytype/

# Linting
.ruff_cache/

# Jupyter Notebook
.ipynb_checkpoints

# Notebook files (optional - ask user)
# Many projects intentionally commit notebooks
# Uncomment if you want to ignore notebook files
# *.ipynb
```

**.NET (if detected):**
```
# Build results
bin/
obj/
out/

# User-specific files
*.user
*.suo
*.userosscache
*.sln.docstates
*.userprefs

# Visual Studio
.vs/
*.DotSettings.user

# Test results
TestResults/
[Tt]est[Rr]esult*/
*.trx

# NuGet
packages/
*.nupkg
*.snupkg
project.lock.json
project.fragment.lock.json
```

**Go (if detected):**
```
# Binaries
*.exe
*.exe~
*.dll
*.so
*.dylib

# Test binary
*.test

# Output of the go coverage tool
*.out

# Dependency directories
vendor/

# Go workspace file (optional - some teams commit this)
# Uncomment if you want to ignore go.work
# go.work
```

**Rust (if detected):**
```
# Compilation outputs
target/

# Backup files
**/*.rs.bk
*.pdb

# Lock file (optional - ask user)
# Libraries should ignore Cargo.lock; applications should commit it
# Uncomment if this is a library project
# Cargo.lock
```

**PHP (if detected):**
```
# Composer
vendor/
composer.phar

# Lock file (optional - ask user)
# Applications should commit composer.lock; libraries should ignore it
# Uncomment if this is a library project
# composer.lock

# Laravel
.env
.env.backup
.phpunit.result.cache
Homestead.json
Homestead.yaml
npm-debug.log
yarn-error.log

# Symfony
/var/
/vendor/
```

**Ruby (if detected):**
```
# Bundler
vendor/bundle/
.bundle/

# RVM
.rvmrc

# rbenv
.ruby-version

# RSpec
.rspec_status

# Coverage
coverage/
```

**Java (if detected):**
```
# Compiled class files
*.class

# Log files
*.log

# Package Files
*.jar
*.war
*.nar
*.ear
*.zip
*.tar.gz
*.rar

# Maven
target/
pom.xml.tag
pom.xml.releaseBackup
pom.xml.versionsBackup
pom.xml.next
release.properties

# Gradle
.gradle/
build/
gradle-app.setting
!gradle-wrapper.jar
```

**Docker (if detected):**
```
# Docker override files
docker-compose.override.yml
docker-compose.override.yaml
```

**Terraform (if detected):**
```
# Terraform
.terraform/
*.tfstate
*.tfstate.*
*.tfvars
crash.log
override.tf
override.tf.json
*_override.tf
*_override.tf.json
```

**Swift/iOS (if detected):**
```
# Xcode
build/
DerivedData/
*.xcuserdata
*.xccheckout
*.moved-aside
*.hmap
*.ipa
*.dSYM.zip
*.dSYM

# Swift Package Manager
.build/
Packages/
Package.resolved

# CocoaPods
Pods/

# Carthage
Carthage/Build/
Carthage/Checkouts/

# Fastlane
fastlane/report.xml
fastlane/Preview.html
fastlane/screenshots/
fastlane/test_output/
```

**Flutter/Dart (if detected):**
```
# Flutter/Dart
.dart_tool/
.flutter-plugins
.flutter-plugins-dependencies
.packages
build/
.pub-cache/
.pub/

# Android (Flutter)
**/android/**/gradle-wrapper.jar
**/android/.gradle
**/android/captures/
**/android/gradlew
**/android/gradlew.bat
**/android/local.properties

# iOS (Flutter)
**/ios/**/*.mode1v3
**/ios/**/*.mode2v3
**/ios/**/*.moved-aside
**/ios/**/*.pbxuser
**/ios/**/*.perspectivev3
**/ios/**/DerivedData/
**/ios/.generated/
**/ios/Flutter/App.framework
**/ios/Flutter/Flutter.framework
**/ios/Flutter/Flutter.podspec
**/ios/Flutter/Generated.xcconfig
**/ios/Flutter/ephemeral/
**/ios/Pods/
```

**C/C++ (if detected):**
```
# Compiled objects
*.o
*.obj
*.a
*.lib
*.so
*.dylib
*.dll
*.exe

# Build directories
build/
cmake-build-*/
out/

# CMake
CMakeCache.txt
CMakeFiles/
cmake_install.cmake
Makefile
install_manifest.txt

# Precompiled headers
*.gch
*.pch

# Debug files
*.dSYM/
*.su
*.idb
*.pdb
```

**Deno (if detected):**
```
# Deno
.deno/
deno.lock
```

### Phase 3: Check Existing .gitignore

Check if `.gitignore` already exists using the **Read tool** (NOT bash test commands):

1. Try to read `.gitignore` using the Read tool
2. If the file exists and Read succeeds:
   - Parse the content
   - Analyze existing patterns
   - Ask user for merge strategy preference using AskUserQuestion tool:
     - **Smart Merge** (default): Deduplicate patterns, preserve comments, organize by category
     - **Append**: Add all new patterns at the end, keep existing content as-is
     - **Replace**: Completely replace existing .gitignore with new patterns
3. If the file doesn't exist (Read returns error):
   - Proceed to create new file with ignore patterns
   - Use "Smart Merge" as the default strategy

**IMPORTANT**:
- Use **Read tool** to check file existence - DO NOT use bash test commands
- The Read tool will gracefully handle non-existent files by returning an error
- Preserve existing comments and custom patterns during merge
- Detect and remove duplicate patterns

### Phase 4: Show Preview & Get Confirmation

Display a comprehensive preview showing:

1. **Technologies Detected:**
   - List all detected technologies with file indicators

2. **Current .gitignore (if exists):**
   - Show line count
   - Show sample of existing patterns (first 10 lines)
   - Identify any duplicate or redundant patterns

3. **Proposed .gitignore:**
   - Show all patterns to be added
   - Group by category (Base Patterns, Node.js, Python, etc.)
   - Show total pattern count
   - Highlight any custom patterns that will be preserved

4. **After Merge:**
   - Show estimated total line count
   - Show merge strategy being used
   - List categories included

Ask for user confirmation before proceeding.

### Phase 5: Write .gitignore

After user confirms:

1. Build the complete .gitignore content with proper formatting:
   - Add header comment with generation info
   - Group patterns by category with section headers
   - Include blank lines between sections for readability
   - Preserve existing custom patterns if merging
   - Sort patterns within categories alphabetically

2. Write `.gitignore` using the **Write tool** (NOT bash echo or heredoc)

3. Show success message with:
   - File path: `.gitignore`
   - Total patterns configured
   - Technologies covered
   - Next steps (review, git status, commit)

**IMPORTANT**:
- Use **Write tool** to create/update the .gitignore file
- DO NOT use bash commands for writing the file
- Ensure proper formatting with blank lines between sections
- Include helpful comments for each section

### Important Constraints

**DO NOT:**
- Read the contents of any sensitive files during scanning
- Include actual file paths from the project in .gitignore
- Proceed without user confirmation
- Use bash test commands (`test -f`, `[ -f ]`, etc.)
- Use any bash commands for file detection or checking
- Remove existing custom patterns without user consent

**DO:**
- Use **Glob tool** for technology detection (file pattern matching)
- Use **Read tool** to check if `.gitignore` exists (handles errors gracefully)
- Use **Write tool** to create/update .gitignore
- Use **AskUserQuestion tool** to ask for merge strategy preference
- Deduplicate patterns by default during merge
- Preserve comments and custom patterns from existing .gitignore
- Show clear before/after comparison
- Maintain alphabetical ordering within categories for readability
- Use forward slashes in all patterns for cross-platform compatibility
- Add helpful section headers and comments

### Example Output Format

```
πŸ” Detecting technologies in your project...

Technologies Detected:
βœ“ Node.js (package.json found)
βœ“ TypeScript (tsconfig.json found)
βœ“ Python (requirements.txt, pyproject.toml found)
βœ“ Docker (Dockerfile, docker-compose.yml found)

Current .gitignore:
πŸ“„ .gitignore exists (42 lines)
πŸ“Š Sample patterns:
  node_modules/
  .env
  dist/
  ...

Proposed .gitignore Structure:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Base Patterns:
  β€’ Environment & Secrets (12 patterns)
  β€’ Operating System Files (15 patterns)
  β€’ IDE & Editor Files (18 patterns)

Node.js Patterns:
  β€’ Dependencies (2 patterns)
  β€’ Build outputs (5 patterns)
  β€’ Testing & Caching (6 patterns)
  β€’ Logs (5 patterns)

Python Patterns:
  β€’ Byte-compiled (5 patterns)
  β€’ Virtual environments (5 patterns)
  β€’ Distribution (7 patterns)
  β€’ Testing (5 patterns)

Docker Patterns:
  β€’ Docker overrides (2 patterns)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total patterns: 87
Estimated file size: ~150 lines (with comments)

Merge Strategy: Smart Merge (deduplicate, preserve comments, organize)

Would you like to proceed with this configuration? (yes/no)
```

### Success Message Format

```
βœ“ .gitignore successfully initialized!

Configuration Summary:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
πŸ“„ File: .gitignore
πŸ“Š Total patterns: 87 (organized in 7 categories)
πŸ›‘οΈ Technologies covered: Node.js, TypeScript, Python, Docker
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Next Steps:
1. Review the generated .gitignore file
2. Run `git status` to see which files are now ignored
3. Remove any currently tracked files that should be ignored:
   git rm --cached <file>
4. Commit the .gitignore file:
   git add .gitignore
   git commit -m "Add comprehensive .gitignore for detected technologies"

πŸ’‘ Tip: You can run this command again to update .gitignore when adding new technologies to your project.
```

### Additional Features

**Lock File Handling:**
When a technology with lock files is detected, ask the user if they want to commit or ignore them:
- **Node.js** (package-lock.json, yarn.lock, pnpm-lock.yaml): Most projects SHOULD commit for reproducible builds
- **Rust** (Cargo.lock): Applications SHOULD commit; libraries should ignore
- **PHP** (composer.lock): Applications SHOULD commit; libraries should ignore
- Only ignore lock files if explicitly requested
- Add commented-out lock file patterns with explanation for each

**Custom Patterns:**
During Smart Merge, detect and preserve:
- User-added comments (lines starting with #)
- Custom patterns not in the standard template
- Negation patterns (lines starting with !)

**Pattern Validation:**
- Ensure patterns use forward slashes (/)
- Remove duplicate patterns across categories
- Warn about overly broad patterns (e.g., `*`, `*.txt`)

Overview

This skill initializes or updates a .gitignore file with intelligent, technology-aware exclusion patterns tailored to your project. It detects the project's tech stack, proposes a structured .gitignore grouped by categories, and offers a safe merge workflow that preserves custom patterns and comments. Confirmation is required before any file is written.

How this skill works

The skill scans the project root for indicator files to detect technologies (Node, Python, Java, Docker, etc.), then builds a comprehensive set of base and technology-specific ignore patterns. If a .gitignore exists, it analyzes the file, deduplicates patterns, and asks your preferred merge strategy (Smart Merge, Append, Replace). It shows a preview of the proposed result and writes the finalized .gitignore only after you confirm.

When to use it

  • Creating a new repository and you need a proper .gitignore from the start
  • Adding a new language or framework to an existing repo (e.g., adding Python or Node modules)
  • Cleaning up accidental commits by ensuring build artifacts and secrets are ignored
  • Standardizing .gitignore structure across team projects
  • Regenerating ignore rules after adopting new tooling (e.g., Docker, Terraform)

Best practices

  • Run detection at the repository root so all indicator files are found
  • Choose Smart Merge to preserve custom rules and comments while deduplicating patterns
  • Review the preview before writing to avoid removing intentionally tracked files
  • Keep lock-file decisions explicitβ€”ask whether your team commits lock files or ignores them
  • Sort and group patterns for readability; keep small, focused custom patterns at the end

Example use cases

  • Initialize .gitignore for a fresh Node.js + Docker project with sensible defaults
  • Merge a generated .gitignore into an existing file while preserving developer comments
  • Add Python and Rust ignores when a mono-repo adopts new services
  • Ignore platform-specific and IDE files to reduce accidental commits
  • Switch merge strategy to Replace when starting a complete restandardization

FAQ

Will this overwrite my existing .gitignore without asking?

No. The skill analyzes the existing file and asks you to choose a merge strategy; it uses Smart Merge by default if no .gitignore is present.

Does it remove my custom patterns or comments?

No. Smart Merge preserves comments and custom patterns, deduplicates entries, and organizes sections for readability.

How are decisions about lock files handled?

The tool highlights lock files for detected technologies and asks whether to ignore or commit them, following common conventions for apps vs libraries.