agentleFS
drobins25drobins25/craft/skills/approve/SKILL.md

approve

Skill73 starsChanged 32 days agoMITView on GitHub

Request write permission from the user before making file changes. MUST be invoked before any write attempt when the write gate is closed. Creates scoped approval via AskUserQuestion + TaskCreate, opens the write gate, and closes it when work is done. Triggers: write hook blocks an edit, agent is about to write files outside .craft/, agent needs to modify project source files. This skill requires user approval 100% of the time - never bypass AskUserQuestion.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. 0 are common, 7 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 3 edited versions we read keep these.

  • 7

    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. Distinctive:

    Call this skill BEFORE your first write attempt when:

    line 13
  2. Very specific:

    Do NOT call this for writes to .craft/ or .claude/ directories - those are always allowed.

    line 19
  3. Distinctive:

    Before asking for approval, gather what you're about to do.

    line 25
  4. Distinctive:

    Use AskUserQuestion. This step CANNOT be skipped.

    line 32
  5. Distinctive:

    Create exactly two tasks:

    line 54
  6. Distinctive:

    When the approved work is done, the caller MUST close the gate:

    line 93
  7. Distinctive:

    AskUserQuestion is mandatory: Every invocation. No exceptions.

    line 112
  8. Distinctive:

    No nesting: If the gate is already open (from a story or another approval), this skill is not needed.

    line 115
  9. Very specific:

    If already true, skip this skill.

    line 119

“Common” is measured: kept by at least 6 in 10 of the 3 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

Write Approval

You are requesting permission to write files. This skill gates ALL writes outside .craft/ and .claude/ directories. It requires explicit user approval every single time - no exceptions, no bypass, no auto-approve.

When to Use

Call this skill BEFORE your first write attempt when:

  • The write hook has blocked you (or will block you)
  • You're about to modify project source files
  • You're about to create new files outside .craft/
  • Any workflow stage involves writing to the project

Do NOT call this for writes to .craft/ or .claude/ directories - those are always allowed.

The Flow

Step 1: Describe the Scope

Before asking for approval, gather what you're about to do. Be specific:

  • Which files will be created or modified
  • What changes will be made (brief, not the full diff)
  • Why (what triggered this - workflow stage, fix, feature work)

Step 2: Ask for Approval (MANDATORY)

Use AskUserQuestion. This step CANNOT be skipped. Ever.

question: "I need write access to make these changes. Approve?"
header: "Write Access"
options:
  - label: "Approve"
    description: "{summary of what will be changed}"
  - label: "Deny"
    description: "Block these changes"
  - label: "Modify scope"
    description: "I want to adjust what's allowed"

If "Deny" -> Stop. Do not open the gate. Report to the caller that writes were denied.

If "Modify scope" -> Let the user describe the adjusted scope. Re-present the AskUserQuestion with the new scope. Loop until approved or denied.

If "Approve" -> Continue to Step 3.

Step 3: Create Approval Tasks

Create exactly two tasks:

Task 1 - The approved work:

TaskCreate({
  subject: "Approved: {brief description of changes}",
  description: "Files: {file list}. Scope: {what was approved}.",
  activeForm: "Writing approved changes"
})

Set this task to in_progress immediately.

Task 2 - Close the gate:

TaskCreate({
  subject: "Close write gate",
  description: "Set CRAFT_WRITE_ENABLED='' after approved work is done.",
  activeForm: "Closing write gate"
})

Set addBlockedBy to Task 1's ID so it can't complete before the work is done.

Step 4: Open the Gate

Run via Bash:

${CLAUDE_PLUGIN_ROOT}/hooks/scripts/update-global-state.sh CRAFT_WRITE_ENABLED true

The write gate is now open. The agent can write files.

Step 5: Do the Work

The caller (workflow, fix skill, implementer, etc.) performs the approved changes. As work completes, the approved-work task stays in_progress.

This skill does NOT do the writing itself. It opens the gate and returns control to the caller. The caller writes, then calls back to close.

Step 6: Close the Gate

When the approved work is done, the caller MUST close the gate:

  1. Mark the approved-work task as completed:
TaskUpdate({ taskId: "{task-1-id}", status: "completed" })
  1. Close the write gate:
${CLAUDE_PLUGIN_ROOT}/hooks/scripts/update-global-state.sh CRAFT_WRITE_ENABLED ""
  1. Mark the close-gate task as completed:
TaskUpdate({ taskId: "{task-2-id}", status: "completed" })

Safety Rules

  1. AskUserQuestion is mandatory. Every invocation. No exceptions. If the skill is called 5 times in a session, the user is asked 5 times.
  2. Scope is enforced by visibility. The user sees exactly what was approved via the Task description. If the agent writes files outside the approved scope, that's visible in the task trail.
  3. Gate closes explicitly. The gate does not auto-close on a timer. The caller must close it. If the session ends with the gate open, session-start.sh will detect CRAFT_WRITE_ENABLED=true with no active story/workflow and reset it.
  4. No nesting. If the gate is already open (from a story or another approval), this skill is not needed. Check first:
grep "CRAFT_WRITE_ENABLED" "${CRAFT_PROJECT_ROOT:-.}/.craft/.global-state"

If already true, skip this skill.

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.