agentleFS
codebycoreycodebycorey/delta-spec/skills/drop/SKILL.md

drop

Skill4 starsChanged 9 months agoMITView on GitHub

Abandon a change and clean up its directory and dependency references. Use when canceling a change, discarding a proposal, or removing planned work.

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 5 are distinctive, and 5 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.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Delete a change that is no longer needed.

    line 9
  2. Very specific:

    Arguments: If $ARGUMENTS is provided, use it as the name parameter.

    line 11
  3. Distinctive:

    Look for references to the change being dropped

    line 27
  4. Distinctive:

    If other changes depend on this one, ask:

    line 29
  5. Distinctive:

    Ask for confirmation unless the user already confirmed in Step 2.

    line 50
  6. Distinctive:

    If user chose "Drop and clean references":

    line 54
  7. Very specific:

    Remove the line referencing the dropped change from ## Dependencies

    line 56
  8. Very specific:

    If Dependencies section becomes empty, leave as None or remove section

    line 57
  9. Very specific:

    Delete the entire specs/.delta/<name>/ directory

    line 61
  10. Very specific:

    If references were cleaned: "Updated dependencies in: <dependent-1>, <dependent-2>"

    line 63

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

/ds:drop [name] - Abandon a change

Delete a change that is no longer needed.

Arguments: If $ARGUMENTS is provided, use it as the name parameter. Otherwise, follow the determination logic below.

Note: This skill performs permanent operations (deleting change directories) and requires explicit user invocation.

Step 0: Version Check

See version-check.md for the standard version compatibility check procedure.

Step 1: Determine which change

See determine-change.md for the standard change resolution procedure. For drop: confirm with user even when only one change exists (destructive operation). If none → nothing to drop.

Step 2: Check for dependents

Scan all other changes in specs/.delta/ for their Dependencies sections:

  • Parse each proposal.md for ## Dependencies section
  • Look for references to the change being dropped

If other changes depend on this one, ask:

"The following changes depend on <name>:"

  • <dependent-1> - [reason from their Dependencies]
  • <dependent-2> - [reason from their Dependencies]

Options:

  • Drop and clean references - Remove from their Dependencies sections
  • Drop all - Also drop the dependent changes (cascade)
  • Cancel - Keep the change

Step 3: Confirm deletion

Show what will be deleted:

Will delete: specs/.delta/<name>/
Contents:
  - proposal.md
  - design.md (if exists)
  - specs/*.md (if any)

Ask for confirmation unless the user already confirmed in Step 2.

Step 4: Clean up references

If user chose "Drop and clean references":

  • For each dependent change, edit their proposal.md
  • Remove the line referencing the dropped change from ## Dependencies
  • If Dependencies section becomes empty, leave as None or remove section

Step 5: Delete

  • Delete the entire specs/.delta/<name>/ directory
  • Confirm deletion: "Dropped change <name>"
  • If references were cleaned: "Updated dependencies in: <dependent-1>, <dependent-2>"

Notes

  • This is permanent - the change is not archived
  • To preserve work, use /ds:archive instead
  • Dropped changes leave no trace (unlike archived changes)

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.