LuckyCody

Folder Lock — AI skill for Claude Code

AI community

Many AI agents, one repo, no conflicting saves - a Claude Code skill: one lock per workfolder, handoffs instead of cross-folder edits, typed resume pointers, and a model-agnostic git pre-commit guard.

How to install Folder Lock

This entry records only its repository, not the path inside it, so there is no exact command to give. Open LuckyCody/folder-lock and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Folder Lock does

Many AI agents, one repo, no conflicting saves - a Claude Code skill: one lock per workfolder, handoffs instead of cross-folder edits, typed resume pointers, and a model-agnostic git pre-commit guard (no commits into another session's lock, no plain commits on main) that is only 'installed' once a self-test has tried to break it.

Alternatives in AI

  • Codesight — Universal AI context generator 979 ★
  • Create Module — Scaffold a fully-typed module with controller, service, router, schema, and model files 325 ★
  • Real-World Pain Points — Project: https://github.com/Narwhal-Lab/MagicSkills For many teams building multi-agent systems, the first thi 277 ★

README

folder-lock — many agents, one repo, no conflicting saves

A Claude Code skill (works with any agent runner that reads `SKILL.md`, and the hooks work with **no** agent at all) for running several AI agents in parallel on one working tree without them overwriting each other or dirtying `main`.

Distilled from a live human+agent monorepo where 3–6 sessions run at once across ~40 workfolders, after two real incidents: a parallel session's commit sweep picked up another session's lock-protected in-flight edits, and an agent wrote straight to `main` because a small task "didn't feel like it counted".

The idea in three sentences

The unit of coordination is the **folder** — not the task, not the project, not the agent — because folders are where files collide. Each session takes **one lock per folder** as its first act, edits only inside it, writes a **handoff** into any other folder it needs touched, and leaves a **typed resume pointer** behind as its last act. A **git pre-commit guard** makes two of those rules unskippable: no commit into another session's fresh lock, no plain commit on `main` — and it is only considered installed once a self-test has tried to break it.

Why a git hook and not an agent rule

A rule that lives only as text in the context window gets skipped the second a task feels low-stakes. Agent-side hooks (Claude hooks, MCP guards) are better, but they are tied to one runner. `git` refusing is model-agnostic, runner-agnostic, and works when a human forgets too.

Install

# as a skill (project-level)
git clone https://github.com/LuckyCody/folder-lock .claude/skills/folder-lock

# or user-level (all projects)
git clone https://github.com/LuckyCody/folder-lock ~/.claude/skills/folder-lock

# then install + PROVE the hooks in a repo (re-run in every clone and worktree)
python .claude/skills/folder-lock/scripts/install.py

Expected tail of the install output:

  PASS  hooksPath points at the hooks under test and pre-commit is e