probabl-aiprobabl-ai/skore-skills/skills/setup-git/SKILL.md

setup-git

Skill144 starsChanged 17 days agoBSD-3-ClauseView on GitHub

Initialize safe version control, including an optional commit of the tree before setup changes it. Trigger when the user asks to initialize version control, add ignore rules, or make the first commit. This action owns first-time git setup only. Before the first commit, ask once which unknown hidden files and review paths to keep tracked. When loaded for the pre-change snapshot, commit the current tree before other setup writes, then return.

Reads credentials

1 other project uses a version of this.

Adopted by

Most recently taken up by

probabl-ai/skillsword for word, first seen Oct 27, 2026

Other versions1 project uses a version of this.
Word for word · 1
probabl-ai/skills★ 144100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository26 other files it gives its agents.
- AGENTS.mdAGENTS.md
- add-python-packageSkill
- audit-ml-pipelineSkill
- build-ml-pipelineSkill
- choose-python-librarySkill
- evaluate-ml-pipelineSkill
- explore-ml-dataSkill
- export-ml-notebookSkill
- export-ml-projectSkill
- export-ml-siteSkill
- frame-ml-problemSkill
- manage-ml-backlogSkill
- model-ml-pipelineSkill
- persist-ml-gitSkill
- plot-ml-figureSkill
- research-ml-practiceSkill
- review-ml-choicesSkill
- review-ml-experimentSkill
- search-ml-literatureSkill
- setup-ml-projectSkill
- setup-python-envSkill
- setup-workspaceSkill
- shape-user-ideaSkill
- smoke-test-ml-pipelineSkill
- sync-ml-reportsSkill
- triage-ml-taskSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

25 rules. About 0 are common, 5 are distinctive, and 20 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
20
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific
could be automatic: a setting could enforce it

Very specific:
Run this section only when setup-ml-project loaded this skill for the pre-change snapshot.
line 20
Very specific:
Do not ask whether later stages commit.
line 22
Distinctive:
Do not git init, git add, or git commit.
line 37
Distinctive:
Do not name that branch master.
line 43
Very specific:
If ambiguous_dotfiles or review_paths is non-empty, ask
line 44
Very specific:
Never --keep .env or .skore.
line 61
Very specific:
Run status first. Take the first row that matches, then run its steps from the Sequence below.
line 74
Very specific:
Run python -m skore_skills status.
line 96
Very specific:
If there is no .git directory, run git init -b main.
line 107
Very specific:
Run python -m skore_skills git ignore-merge.
line 111
Very specific:
If policy.git.autocommit is null, ask once: should later stages persist with git commit (on) or never (off)?
line 114
Very specific:
If autocommit is off, stop.
line 125
Distinctive:
Do not git commit. Use the return rule in step 9.
line 126
Very specific:
If autocommit is on and HEAD exists, stop after ignore-merge.
line 127
Very specific:
Do not use this step when policy.git.snapshot is committed and git status is dirty.
line 128
Very specific:
Do not ask which files to keep.
line 130
Very specific:
If autocommit is on and (this repo has no HEAD yet, or policy.git.snapshot is committed and git status is dirty), run python -m …
line 137
Very specific:
When this step is reached from step 1, ignore-merge did not run: use only review_paths.
line 142
Very specific:
Run only the command for a list that was non-empty.
line 171
Very specific:
When setup-ml-project dispatched this turn and is in this session, return control to it.
line 180
Very specific:
Never overwrite .gitignore.
line 186
Very specific:
Never stage .env, .skore, or a review path that was not kept.
line 188
Distinctive:
Never split hidden files and review paths into two questions before the first commit.
line 190
Distinctive:
Never push, create a remote, amend, rebase, or set git identity.
line 192
Very specific:
Do not call python -m skore_skills git end-turn --stage … to create the first commit.
line 195

≈ “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

Set Up Git

Pre-change snapshot

Run this section only when setup-ml-project loaded this skill for the pre-change snapshot. Do not run Lookup. Do not scaffold. Do not ask whether later stages commit. Then return to setup-ml-project.

Run python -m skore_skills git snapshot.
action skip and reason already: return. Do not persist again.
action skip and reason clean or nothing_to_commit: persist python -m skore_skills policy set git.snapshot skipped, then return. Do not ask. Do not git commit.
action ask: AskUserQuestion. Recommend committing. In 2–4 lines, say this commit records the workspace as it is now, so the user can return to it before setup changes anything. It does not change whether later stages commit. A file link is an addition, never the context.
- No: persist python -m skore_skills policy set git.snapshot declined. Do not git init, git add, or git commit. Return.
- Yes: continue. Persist python -m skore_skills policy set git.snapshot committed after the commit exits 0.
On yes, if repo is false, run git init -b main before adding files. The initial branch is main. Do not git config. Do not name that branch master.
If ambiguous_dotfiles or review_paths is non-empty, ask once which of those paths to keep tracked. List every hidden path and each review path with its kind. Say that paths they do not keep are ignored. Do not ask a second question for the other list. Copy paths from the JSON. Then:
- ambiguous_dotfiles was non-empty → python -m skore_skills git ignore-merge --decide plus --keep <path> for each chosen hidden path (no --keep if they keep none).
- review_paths was non-empty → python -m skore_skills git review-decide with --keep <path> for each chosen path and --ignore <path> for every other path in that list (no --keep if they keep none). Pass a folder path through with its trailing slash.
Empty lists: do not ask, and do not run git ignore-merge. Never --keep .env or .skore. Exit code 2 from those commands is structured JSON, not a command failure.
git status. git add -- <paths> only staged paths that are not still listed in review_paths, plus hidden paths the user kept. Never stage .env, .skore, .venv, .pixi, or another must-ignore tool directory. Never stage a review path that was not kept.
git commit -m "<one-line subject>". The subject states that this is the workspace before setup changes it. Only this section uses that subject.

Lookup

Run status first. Take the first row that matches, then run its steps from the Sequence below. Do not stop after reading the table.

`policy.git.autocommit`	Situation	Steps	Ask	Commit
`on` or `off`, user asks to change it	HEAD exists, or the new value is `off`	1, 9	the autocommit question only	no
`on` or `off`, user asks to change it	new value `on`, no HEAD	1, 7, 8, 9	autocommit, then one keep question if `review_paths` is non-empty	yes
`null`	any	2, 3, 4, then only the Ask and Commit of the row for the persisted answer. Do not run steps 2 or 3 again	autocommit once	per that row
`off`	any	2, 3, 5, 9	nothing	no
`on`	`policy.git.snapshot` is `committed` and `git status` is dirty	2, 3, 7, 8, 9	one keep question only if `ambiguous_dotfiles` or `review_paths` is non-empty	yes, the setup changes only
`on`	HEAD exists	2, 3, 6, 9	nothing	no
`on`	no HEAD	2, 3, 7, 8, 9	one keep question only if `ambiguous_dotfiles` or `review_paths` is non-empty	yes

The keep question is one question. After step 3 it lists every hidden path and every review path with its kind. The change-to-on row did not run ignore-merge: list only review_paths. Exit code 2 from git ignore-merge, git review, or git review-decide is structured JSON, not a command failure.

Sequence

Run python -m skore_skills status. If the user asked to change the commit choice and policy.git.autocommit is already on or off, re-ask that question and persist on or off. Do not git init. Do not git ignore-merge. If the new value is on and the repo has no HEAD yet, continue at the first-commit review (step 7). If the new value is off, or on and HEAD exists, stop this sequence: use the return rule in step 9 and do not continue at step 2. Do not invent another commit. Later stages follow the new value. Otherwise, if autocommit is already on or off, do not ask that question again.
If there is no .git directory, run git init -b main. The initial branch is main. Do not run git config. Do not name that branch master. Do not rename a branch that already exists.
Run python -m skore_skills git ignore-merge. Keep the JSON ambiguous_dotfiles list. Exit code 2 is that structured list, not a command failure. Do not ask yet.
If policy.git.autocommit is null, ask once: should later stages persist with git commit (on) or never (off)? State in 2–4 lines what the answer authorizes — commits at the end of later stages, starting with the first commit this turn — and which paths stay ignored; a file link is an addition, never the context. Persist with python -m skore_skills policy set git.autocommit on or off. That answer is also consent for the first commit. It does not authorize tracking ambiguous_dotfiles or review_paths. When setup-ml-project already persisted on or off this turn, do not ask again.
If autocommit is off, stop. Do not ask which files to keep. Do not git commit. Use the return rule in step 9.
If autocommit is on and HEAD exists, stop after ignore-merge. Do not use this step when policy.git.snapshot is committed and git status is dirty; that row commits the setup changes. Do not ask which files to keep. Do not invent another commit. Later stages use python -m skore_skills git end-turn --stage <stage> then persist-ml-git, where <stage> is setup, data_analysis, implement, evaluate, or backlog. When that skill is not installed, those stages report the pending paths instead of committing.
If autocommit is on and (this repo has no HEAD yet, or policy.git.snapshot is committed and git status is dirty), run python -m skore_skills git review. When git.snapshot is committed, the step 8 commit is only the changes since that snapshot. Do not ask to snapshot again. When this step is reached from step 1, ignore-merge did not run: use only review_paths. If ambiguous_dotfiles and review_paths are both empty, do not ask. If either list is non-empty, ask once which of those paths to keep tracked. List every hidden path and each review path with its kind. Say that paths they do not keep are ignored. Do not ask a second question for the other list. Copy paths from the JSON; do not reclassify them. Do not ask about file size, artifacts, or datasets when review_paths is empty, and do not ask about hidden files when ambiguous_dotfiles is empty. Then:
- ambiguous_dotfiles was non-empty → re-run python -m skore_skills git ignore-merge --decide plus --keep <path> for each chosen hidden path (no --keep if they keep none).
- review_paths was non-empty → python -m skore_skills git review-decide with --keep <path> for each chosen path and --ignore <path> for every other path in that list (no --keep if they keep none). Pass a folder path through with its trailing slash so the ignore line is that folder. Exit code 2 from git review or git review-decide is the structured review outcome, not a generic command failure: read its JSON. The question in this step is that decision; do not ask again. If review-decide still lists paths, rerun it with the same choices.
Run only the command for a list that was non-empty. Do not re-ask paths gone from the next JSON. Never --keep .env or .skore.
Then git status. git add -- <paths> only paths that are not still listed in review_paths, and git commit -m "<one-line subject>" from this setup turn. The subject describes the files committed now. It does not say this commit is the state before setup changes. Do not ask a second time about autocommit. Never stage .env or .skore.
When setup-ml-project dispatched this turn and is in this session, return control to it. Otherwise load triage-ml-task if status.skills reports it installed, else stop.

Stop conditions

Never overwrite .gitignore; git ignore-merge unions packaged rules.
Never stage .env, .skore, or a review path that was not kept.
Never split hidden files and review paths into two questions before the first commit.
Never push, create a remote, amend, rebase, or set git identity.
The initial branch is main. Do not name it master. Do not rename a branch that already exists.
Do not call python -m skore_skills git end-turn --stage … to create the first commit.
The pre-change snapshot does not scaffold. It does not run git ignore-merge unless ambiguous_dotfiles was non-empty.
Lookup does not use the pre-change snapshot commit subject.

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.

Check your setup, free