agentsclimarketplace

Git trackability check

Skill bakerstreetco/skills/git-trackability-check

Reusable agent skills for real repository work: review, implementation, release, documentation, and project hygiene.

Install
npx -y skills add bakerstreetco/skills --skill git-trackability-check

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Check current local git work and decide which changed, untracked, generated, ignored, or local-only files should be tracked versus ignored. Use when asked whether new files belong in git, whether .gitignore should change, or which local work should be staged before committing.

SKILL.md

2.4 KB, 452 tokens by cl100k_base, as published. Nobody here has run it

Git Trackability Check

Use this skill to review local git work before staging. The goal is to decide what belongs in source control and what should remain ignored or local-only.

Workflow

  1. Identify the repository root with git rev-parse --show-toplevel.
  2. Inspect local state:
git status --short --ignored
git diff --stat
git diff --name-only
git ls-files --others --exclude-standard
  1. Read .gitignore, nested ignore files, package metadata, build scripts, docs, CI, and deployment config when they explain the changed paths.
  2. Classify every local path that appears relevant:
    • Track source, config, docs, lockfiles, workflow files, public assets, migrations, fixtures, and intentional generated files.
    • Ignore dependencies, build output, caches, logs, editor files, OS files, local secrets, downloaded binaries, and machine-specific config.
  3. Check whether ignored paths are already covered by existing patterns before recommending .gitignore changes.
  4. Do not add broad ignore rules that would hide real source files.
  5. Do not stage, commit, delete, or rewrite files unless the user explicitly asks.

Repository Skill Folders

For skill repositories like this one, treat each skill folder as the source of record. New or updated SKILL.md, metadata, adapter files, scripts, references, and assets are meant to be tracked when they define installable repo-wide skills.

Prefer updating an existing skill folder when the behavior belongs to an existing workflow. Create a new skill folder only when the job has a distinct trigger, workflow, and output.

Output

Start with a direct yes/no answer when the user asks whether current files should be tracked.

Use this shape:

Yes, the new docs files are meant to be trackable.

Track these:
- `path`: why it belongs in git

Ignore these:
- `path`: why it should remain ignored or local-only

So I would not add any of those new source files to `.gitignore`. The current ignore behavior is right.

Mention any .gitignore changes only when the current ignore behavior is wrong or incomplete.

What ships with it: 2 files

783 B alongside SKILL.md

agents/

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.