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
In this repository23 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adr-generationSkill
- bash-scriptingSkill
- browser-controlSkill
- github-actionsSkill
- git-operationsSkill
- html-reportSkill
- java-developmentSkill
- mermaid-diagramsSkill
- meta-workspaceSkill
- powershell-scriptingSkill
- project-backlogSkill
- project-documentationSkill
- project-setupSkill
- python-developmentSkill
- refinement-tribunalSkill
- skill-cli-developmentSkill
- technical-writingSkill
- testing-standardsSkill
- typescript-developmentSkill
- web-auth-bridgeSkill
- worktree-isolationSkill
- writing-ai-instructionsSkill
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
- Distinctive: line 18
Use the canonical base template file at references/base-gitignore-template.gitignore.
- Distinctive: line 22
Use this exact section order and heading format:
- Very specific: line 71
Put all project-specific additions or overrides in ### Project-Specific Rules, including re-adding any desired patterns ignored by earlier …
- Distinctive: line 73
Do not add extra section types.
- Very specific: line 79
Every GitHub template has a ### <Name> Template heading.
- Very specific: line 81
Only one ### Project-Specific Rules section exists.
≈ “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.
Files
GitIgnore Standards Skill
Objective
Produce and maintain .gitignore content with exactly three section groups in this order:
- Base template reference
- One or more unaltered GitHub gitignore templates
- 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.templateRules
- Apply this skill to every
.gitignoretask: 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 Rulessection. - 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> Templateheading. - GitHub template text is unmodified.
- Only one
### Project-Specific Rulessection exists. - Exactly one blank line separates adjacent sections.
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
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.

