agentleFS
Sign inStart free
samwelmungasamwelmunga/jenga-npm/.agents/skills/j-gitignore/SKILL.md

j.gitignore

Skill0 starsChanged 22 days agoApache-2.0View on GitHub

Retroactively repair an already-scaffolded project's Jenga gitignore state — strips the stray heredoc `EOF` line left by pre-fix /init scaffolds, adds or removes the Jenga-owned path entries via a managed block, and untracks those paths from git (and from origin) while leaving every file on disk.

  • 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
  • could be automatic: a setting could enforce it
  1. Very specific:

    All three ship without the executable bit — invoke via bash.

    line 50
  2. Distinctive:

    Always dry-run first and show the diff:

    line 101
  3. Very specific:

    If the user genuinely wants to ignore a file literally named EOF, pass --keep-eof.

    line 110
  4. Distinctive:

    Stop here — just the .gitignore change

    line 127
  5. Very specific:

    It is not a secret scrubber: If a .env or credential was committed, treat it as compromised, rotate it, and use git-filter-repo separately.

    line 142
  6. Distinctive:

    It never deletes from disk: Every removal is git rm --cached, and the script re-verifies each path is still present before reporting …

    line 145

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

j.gitignore

Repairs the Jenga-related git state of a project that was already scaffolded. /init does this correctly for new projects; this skill is the retroactive path for projects created before the fix, or projects whose ignore rules have drifted.

When to use this

  • .gitignore contains a stray EOF line (the signature of the botched cat > .gitignore <<EOF in pre-fix /init scaffolds).
  • .claude/, .agents/, jenga.config.json, .jenga-version etc. are being committed even though you expected Jenga to ignore them.
  • You want the Jenga scaffold gone from the remote, but still working locally.
  • You want to reverse any of the above and commit the scaffold deliberately.

Why /init cannot do this

skills/j-init/SKILL.md hard-stops on already-scaffolded, and for good reason: init.sh does an unconditional cp "$ASSETS_DIR/.gitignore_template" .gitignore, which would clobber the project's existing .gitignore, and later steps overwrite PROJECT_SUMMARY.md, workflow.json and test-config.json with fresh stubs. The upstream fixes (E31_S07_T02/T03, E42_S06_T01) repaired the template, which is forward-only. Nothing repairs a project already on disk. That is this skill's entire reason to exist.

apply-project-visibility.sh and apply-scaffold-visibility.sh remain the init-time path and are not replaced. They only ever append project/, .claude/ and .agents/ as loose lines — they do not remove a stray EOF, do not cover the file-level paths, and cannot untrack anything.

Scripts

All three ship without the executable bit — invoke via bash. All are bash 3.2 compatible (macOS).

ScriptRole
scripts/audit-gitignore.shRead-only. Reports stray terminators, per-path entry/ignored/tracked state, and what is present on origin. Exit 10 means findings, 0 means clean.
scripts/repair-gitignore.shStrips stray EOF lines, then adds (ignored) or removes (visible) the entries inside a managed block. Atomic write, verified after.
scripts/untrack-jenga-files.shgit rm -r --cached — stops tracking, never deletes from disk. Optional --commit, opt-in --push.
assets/jenga-paths.txtThe single catalog of Jenga-owned paths, tiered. All three scripts read it.

Path tiers

--tiers selects what to act on. Default is scaffold — the safe set.

TierContentsDefault
scaffold.claude/, .agents/, .jenga/, .jenga-version, jenga.config.json, .github/hooks/jenga.json, J-CLAUDE.md, J-AGENTS.md — entirely Jenga-owned, regenerated by postinstall//distribute.✅ on
hybridCLAUDE.md, AGENTS.md, .github/copilot-instructions.md — Jenga writes a managed block and preserves your content around it. Ignoring these hides your prose too.opt-in
boardproject/ — governed by project_files_visibility. Teams sharing a board want it tracked.opt-in
optional.copilot/ — not generated by any current Jenga version. Defensive only.opt-in

Procedure

1. Audit

bash <skill>/scripts/audit-gitignore.sh . --tiers scaffold

Present the three summary counts to the user. If AUDIT_RESULT=clean, say so and stop — there is nothing to repair.

2. Confirm scope

The audit's per-path table shows what is tracked. Before changing anything, ask:

Which Jenga paths should this project ignore?
1. Scaffold only — .claude/, .agents/, jenga.config.json, .jenga-version, hook + J- files (recommended)
2. Scaffold + the board (project/) — adds your scrum board, todo.md, queue, rapports, logs
3. Scaffold + CLAUDE.md / AGENTS.md / copilot-instructions.md — note these may contain your own prose
4. Everything, including the defensive .copilot/ entry
5. Other (describe below)

Two warnings to surface if they are in scope:

  • jenga.config.json holds project_files_visibility and scaffold_visibility. Ignoring it means a fresh clone loses those settings and the next /init-style run re-prompts for them.
  • hybrid tier files contain user-authored content outside Jenga's managed block. Ignoring them removes that content from the repo too.

3. Repair the .gitignore

Always dry-run first and show the diff:

bash <skill>/scripts/repair-gitignore.sh ignored . --tiers <tiers> --dry-run

Then apply without --dry-run. This step is purely local and reversible (visible mode removes the block again), so it does not need separate confirmation beyond the scope choice in step 2.

If the user genuinely wants to ignore a file literally named EOF, pass --keep-eof.

4. Untrack

.gitignore has no effect on files git already tracks, so step 3 alone changes nothing for anything already committed. Dry-run first:

bash <skill>/scripts/untrack-jenga-files.sh . --tiers <tiers> --dry-run

Then choose how far to go:

The .gitignore is fixed. How far should I take the untracking?
1. Stage the removals only — I review `git status` and commit myself
2. Stage and commit locally — nothing reaches the remote until I push
3. Stage, commit, and push — removes them from origin's branch tip
4. Stop here — just the .gitignore change
5. Other (describe below)

Map to --commit / --commit --push accordingly. Never pass --push without the user explicitly choosing option 3 — it is the only outward-facing step and cannot be undone by re-running the skill.

5. Report

Re-run the audit to confirm AUDIT_RESULT=clean, then state plainly what changed, and always include the history caveat below.

What this does NOT do

  • It does not rewrite history. --push removes the paths from the branch tip. Every earlier commit still contains them, and the blobs stay reachable. A fresh clone is clean; git log is not.
  • It is not a secret scrubber. If a .env or credential was committed, treat it as compromised, rotate it, and use git-filter-repo separately. Say this out loud if the audit shows anything credential-shaped.
  • It never deletes from disk. Every removal is git rm --cached, and the script re-verifies each path is still present before reporting success.

Edge cases

SituationBehavior
No .gitignore at the rootignored creates one; visible exits 0 as a no-op.
No git repoAll three exit 1 with a clear message — this skill needs git.
No upstream branchAudit says nothing was ever pushed. --push refuses rather than guessing a remote; the commit is already safe locally.
Unrelated staged changesuntrack-jenga-files.sh refuses (exit 4) so it cannot sweep your work into its commit. A staged .gitignore alone is allowed through and folded in, since it is the companion change.
Unterminated managed blockrepair-gitignore.sh refuses to write (exit 3) rather than risk eating the rest of the file.
Path tracked but absent from diskReported as a warning; nothing was lost, git simply tracked something the working tree did not have.

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