Dont Mind Me

Don't Mind Me

Authored and maintained by Ivan De Marino.

This skill manages the creation, combination, and update of ignore files (such as .gitignore, .dockerignore, .npmignore, and more) within any repository. It uses the community-vetted templates from the official github/gitignore repository as well as other reliable online sources, supporting multi-technology projects and sub-directory specific rules.

When to Use

• Bootstrapping a new repository with standard ignore rules for a language (e.g., Rust, Python, Go) or IDE (e.g., VS Code, IntelliJ, Xcode).
• Updating an existing .gitignore or other ignore files when adding a new framework, language, or developer tool to a project.
• Setting up specialized ignore files such as .dockerignore (to reduce container build context size) or .npmignore (to exclude test/development files from npm packages).
• Adding sub-directory specific ignores to restrict or customize rules within complex or monorepo layouts.

When Not to Use

• Standard code refactoring tasks that do not involve configuring file ignore patterns.
• Managing git repository configurations (e.g., .gitattributes, .gitconfig) or performing standard version control operations (e.g., branch switching, merging), unless specifically committing the newly created ignore files.

Inputs

I Know, For Example, About Those Types of Ignores

Below is a non-exhaustive list of the diverse types of ignore files used across version control, build systems, deployment platforms, formatters, and search tools that this skill knows how to configure:

Workflow

Step 1: Detect Targets & Directory Scope

Before writing any ignore file, clarify the scope and targets:

1. Identify Target Directory: Check if the file goes to the repository root (e.g., ./.gitignore) or to a specific subdirectory (e.g., ./services/api/.gitignore).
   • Why: Path-based rules act differently when defined inside a subdirectory. If a pattern like /target is declared in a root-level ignore file, it matches only target at the root. If it is declared in services/api/.gitignore, it matches services/api/target.
2. Determine Ignore Type: Check if you are writing .gitignore or another ignore file (e.g., .dockerignore, .npmignore).
3. Scan Project Tech: Look at the project files to suggest the best languages, IDEs, and environments if the user didn't specify them.
   • For example: if a Cargo.toml exists, suggest Rust. If package.json exists, suggest Node.

Step 2: Fetch Base Templates from github/gitignore

Retrieve official, community-tested templates from the github/gitignore repository using your high-level platform fetch tool (like fetch or agentic_fetch):

1. Determine Template Filename:
   • Language templates reside at:

     https://raw.githubusercontent.com/github/gitignore/main/<Language>.gitignore
     

     (e.g., Rust.gitignore, Python.gitignore, Go.gitignore)
   • Global templates (IDEs, OSs, Global tools) reside at:

     https://raw.githubusercontent.com/github/gitignore/main/Global/<IDE-or-OS>.gitignore
     

     (e.g., VisualStudioCode.gitignore, macOS.gitignore, JetBrains.gitignore)
2. Handle Capitalization & Spacing: The GitHub repository is case-sensitive. Ensure proper capitalization (e.g. Rust rather than rust, Go rather than go).
3. Handle Missing Templates / Alternatives:
   • If a specific tool or framework isn't listed in the official github/gitignore repo, perform a search or fetch from alternative reliable sources (like https://www.toptal.com/developers/gitignore/api/<tech>).

Step 3: Combine and Deduplicate

When combining templates for multiple technologies (e.g., Python + VS Code + macOS):

1. Separate with Clear Headers: Add a clear header for each template to make the file easy to read and update later.

   # ==========================================
   # Created by dont-mind-me: Rust
   # ==========================================
   ... (Rust rules here) ...
   
   # ==========================================
   # Created by dont-mind-me: VisualStudioCode
   # ==========================================
   ... (VS Code rules here) ...
   

2. Deduplicate Rules: Keep track of identical rules across different templates (e.g., .DS_Store appearing in both macOS and other templates) and only include the rule in the first section it appears, or group common global files into their own section.
   • Why: Clean files prevent confusion and reduce processing overhead for git or build systems.

Step 4: Adapt Syntax for Other Ignore Formats

If configuring an ignore file other than .gitignore, translate Git-style patterns into the correct target format:

• .dockerignore:
  • Why: Docker build contexts are loaded from the root context path. Rules are resolved using Go's filepath.Match, which doesn't support unanchored directory matching like Git does (e.g., build ignores both build file and build/ directory recursively in git, but in Docker, you should use **/build or specify nested paths).
  • How: Convert unanchored directory patterns by ensuring they are covered recursively. Keep rules specific to the files needed for the container build.
• .npmignore:
  • Why: .npmignore prevents shipping internal development artifacts to registry bundles, making packages lightweight and secure.
  • How: Maintain a subset of .gitignore targets, ensuring files like compiled binaries, tests, mock files, and configuration dotfiles are excluded.
• .hgignore:
  • Why: Mercurial supports regexes as well as globs.
  • How: Write a syntax: glob header at the top to safely reuse standard globbing patterns.

Step 5: Write and Verify the Ignore File

1. Verify Existing Content: If the target ignore file already exists, do not overwrite it blindly. Read it first to identify if there are any custom rules defined by the user. Preserve those custom rules in their own section (e.g., # Custom Rules).
2. Write the Content: Write the newly constructed ignore content to the target path.
3. Run Verification:
   • Run git status or checking tools to verify that previously untracked build artifacts are now ignored correctly.

Validation

• The ignore file is created at the correct relative path (target_directory).
• Each included technology or environment template has a clear, separated header.
• Duplicated lines across combined templates are eliminated.
• Existing custom rules are fully preserved and not overwritten.
• The syntax matches the requirements of the requested ignore_type (e.g., .dockerignore or .hgignore).

Common Pitfalls