agentleFS
Sign inStart free
jaydubya818jaydubya818/MissionControl/skills/new-feature/SKILL.md

new-feature

Skill2 starsChanged 8 months agoMITView on GitHub

Create or use a task-owned Git worktree for repository edits. Use for features, fixes, or documentation changes; skip read-only work.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 38 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Scope check: run gh pr list and skim the open PRs' changed files (gh pr diff <n> --name-only).

    line 31
  2. Very specific:

    Use a directory outside the checkout, or a gitignored directory inside it, so worktrees cannot be committed by accident.

    line 50
  3. Distinctive:

    Keep the worktree until the PR is merged or closed.

    line 72

“Common” is measured: kept by at least 6 in 10 of the 38 edited versions of this file we could read. “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

New Feature

Each editing task gets its own worktree and branch, created from the latest origin/main unless the user specifies a different base. Read-only work can use the existing checkout. Never build on main or reuse another task's work.

Check existing isolation first

Inspect git worktree list, git status --short, the current branch, and the session's task assignment. If the environment already created a worktree for this task, keep its path and branch and skip steps 3 and 4. In step 5, use the actual assigned path. Do not infer isolation from the editor name or a branch prefix alone. Otherwise follow all steps.

Steps

  1. Sync: git fetch origin.
  2. Scope check: run gh pr list and skim the open PRs' changed files (gh pr diff <n> --name-only). For shared files, read the overlapping diffs. Independent edits may proceed in your own worktree. Ask for direction only when the changes conflict in behavior, require another task's unfinished work, or ownership is unclear. Check shared checkouts for uncommitted work without changing it. On another hosting platform, use its equivalent PR/MR tools; if unavailable, report the scope-check limitation and still isolate.
  3. Name the task: lowercase-with-hyphens plus a short unique suffix, e.g. user-auth-0816a. If git worktree add fails because the name exists, pick a different name — never force or reuse.

  4. Create the worktree from the repo root:

    git worktree add <worktrees-dir>/<task-name> \
  -b <branch-prefix>/<task-name> origin/main

    Use a directory outside the checkout, or a gitignored directory inside it, so worktrees cannot be committed by accident. Use a consistent branch prefix (e.g. agent/). Follow the repo's conventions if it defines them.

  5. Enter and verify:

    cd <worktrees-dir>/<task-name>
git branch --show-current   # must print your new branch, not main

    Confirm the required runtime version. Install dependencies inside the worktree when needed for the task's checks. Documentation-only work does not require installing an unrelated application toolchain.

Remember

  • Worktrees do not isolate dev-server ports or shared databases. Tracked dependency lockfiles are separate in each worktree. Confirm a port answers your process (lsof -i :<port>) before trusting what it serves, and resolve lockfile conflicts by regenerating, never by hand-merging.

  • Keep the worktree until the PR is merged or closed. Cleanup after merge:

    git worktree remove <worktrees-dir>/<task-name>
git branch -D <branch-prefix>/<task-name>

    -D is expected: after a squash- or rebase-merge, -d refuses even though the work is merged.

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