agentleFS
mikejhillmikejhill/agent-skills/skills/gitignore-standards/SKILL.md

gitignore-standards

Skill0 starsChanged 8 months agoMITView on GitHub

Use for all .gitignore tasks. Apply these standards whenever creating, updating, reviewing, or refactoring .gitignore content.

  • Reads credentials

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use the canonical base template file at references/base-gitignore-template.gitignore.

    line 18
  2. Distinctive:

    Use this exact section order and heading format:

    line 22
  3. Very specific:

    Put all project-specific additions or overrides in ### Project-Specific Rules, including re-adding any desired patterns ignored by earlier …

    line 71
  4. Distinctive:

    Do not add extra section types.

    line 73
  5. Very specific:

    Every GitHub template has a ### <Name> Template heading.

    line 79
  6. Very specific:

    Only one ### Project-Specific Rules section exists.

    line 81

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

GitIgnore Standards Skill

Objective

Produce and maintain .gitignore content with exactly three section groups in this order:

  1. Base template reference
  2. One or more unaltered GitHub gitignore templates
  3. One project-specific rules section

Base .gitignore Template Reference

Use the canonical base template file at references/base-gitignore-template.gitignore.

Required Structure

Use this exact section order and heading format:

### Base Template
<unaltered content from ./references/base-gitignore-template.gitignore>

### <Name> Template
<unaltered content from github/gitignore>

### <Name> Template
<unaltered content from github/gitignore>

### Project-Specific Rules
<custom project patterns>

Complete Example (Trimmed)

This is a concise end-to-end example with multiple template sections and short content excerpts:

### Base Template
# Agent and Developer Temporary Files
.tmp/

### Python Template
__pycache__/
*.py[cod]
.venv/

### Terraform Template
.terraform/
*.tfstate
*.tfstate.*

### Project-Specific Rules
# Repository-specific additions
coverage-final/
terraform.local.tfvars
!.env.production.template

Rules

  • Apply this skill to every .gitignore task: create, update, review, and refactor.
  • The base template section MUST copy unaltered content from Base .gitignore Template into the generated output.
  • Each imported GitHub template section MUST start with exactly one heading line in this format: ### <Name> Template.
  • Imported GitHub templates MUST remain unaltered from their original source text.
  • There MUST be exactly one ### Project-Specific Rules section.
  • Put all project-specific additions or overrides in ### Project-Specific Rules, including re-adding any desired patterns ignored by earlier templates.
  • Separate sections with exactly one blank line.
  • Do not add extra section types.

Validation Checklist

  • Order is Base -> GitHub templates -> Project-Specific Rules.
  • Base template content is copied unaltered from references/base-gitignore-template.gitignore and embedded inline.
  • Every GitHub template has a ### <Name> Template heading.
  • GitHub template text is unmodified.
  • Only one ### Project-Specific Rules section exists.
  • Exactly one blank line separates adjacent sections.

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.