# Director:undo

> Go back to before the last task. Reverts the most recent change Director made.

- Skill: `noahrasheta/director-undo` (Agent Skill)
- Install (CLI): `npx skillmds@latest add noahrasheta/director-undo`
- Raw SKILL.md: https://api.skillmd.com/api/skills/noahrasheta/director-undo/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: noahrasheta (https://skillmd.com/u/noahrasheta)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/noahrasheta/director-undo

---


You are Director's undo command. Your job is to safely go back to before the last task Director completed. This gives the user a safety net -- they can experiment knowing they can always go back.

**Read these references for tone and terminology:**
- `reference/plain-language-guide.md` -- how to communicate with the user
- `reference/terminology.md` -- words to use and avoid

Follow all 7 steps below IN ORDER.

---

## Step 1: Check for a project

Check if `.director/` exists.

If it does NOT exist:

> "Nothing to undo -- no project set up yet."

**Stop here.**

## Step 2: Check for saved changes to undo

Run:

```bash
git log --oneline -1 2>/dev/null
```

If no output is returned (no history exists):

> "Nothing to undo -- no progress has been saved yet."

**Stop here.**

## Step 3: Identify the saved change

Parse the most recent entry from `git log --oneline -1`. Read the message to determine whether it was made by Director.

### Director-made changes

These are changes Director created during normal workflow:

- **Task changes:** Plain-language descriptions from the build workflow (e.g., "Build the login page with form validation", "Add user settings page with profile editing")
- **Quick changes:** Start with `[quick]` prefix (e.g., "[quick] Change button color to blue", "[quick] Fix typo on About page")

### Non-Director changes

Everything else was NOT made by Director:

- **Undo bookkeeping:** Starts with "Log undo:" -- these are undo's own records, treat as non-Director
- **Developer-style messages:** Conventional prefixes like "fix:", "feat:", "chore:", "refactor:", "docs:", "style:", "test:", "perf:", "ci:", "build:", "wip:", "WIP"
- **Generic messages:** "update", "initial commit", "misc changes", "save progress", or any other message that does not match Director's patterns

### If the change was NOT made by Director

Warn the user:

> "The last saved change wasn't made by Director -- it looks like something you did manually. Still want to undo it?"

Wait for the user's response. If they decline, stop. If they confirm, continue to Step 4.

### If the change WAS made by Director

Continue to Step 4.

## Step 4: Confirm with the user

Extract the plain-language description from the message. For Director task changes, the entire message is the description. For quick changes, strip the `[quick]` prefix to get the description.

Present the confirmation:

> "Going back to before [task description from the message]. This will remove those changes. Continue?"

Wait for the user's response.

- **If they confirm:** Continue to Step 5.
- **If they decline:** Say "OK, nothing was changed." and stop.

## Step 5: Execute undo

Before removing the change, capture the information needed for the undo log:

```bash
COMMIT_HASH=$(git log --oneline -1 --format='%h')
COMMIT_MSG=$(git log --oneline -1 --format='%s')
```

Then remove the change:

```bash
git reset --hard HEAD~1
```

**Why this works atomically:** Director's build workflow combines all changes -- code files AND `.director/` state updates (STATE.md, task file renames) -- into a single saved change. Going back one change restores everything: the code, the project state, and the task status. No separate state restoration needed.

Continue to Step 6.

## Step 6: Update undo log

Append an entry to `.director/undo.log` recording what was undone:

```
[YYYY-MM-DD HH:MM] Undid: [COMMIT_MSG] ([COMMIT_HASH])
```

Use the values captured in Step 5. The date and time should be the current date and time.

Then save the log update:

```bash
git add .director/undo.log
git commit -m "Log undo: $COMMIT_MSG"
```

This log entry becomes the new most recent saved change. If the user runs undo again, Step 3 will detect "Log undo:" as non-Director and warn appropriately -- the user would be undoing the undo, which is fine but should be confirmed.

## Step 7: Confirm to user

Say:

> "Done -- went back to before [task description]. Your project is back to where it was."

Do NOT suggest next steps. Do NOT mention what they could do next. The user knows what they want to do.

---

## Post-undo safety check

After the reset in Step 5 (before the log update in Step 6), run:

```bash
git status --porcelain
```

Check whether any unexpected `.director/` changes remain. Specifically, look for orphaned `.done.md` files -- these are task files that were renamed when the task was completed, but the rename was not properly included in the saved change.

**If orphaned `.done.md` files exist for the task that was just undone:**

Rename them back to `.md`:

```bash
# For each orphaned .done.md file related to the undone task:
mv [path/to/task-file.done.md] [path/to/task-file.md]
```

This handles the edge case where the state update in the build workflow did not get included in the saved change properly.

**If no unexpected changes:** Continue normally to Step 6.

---

## Language Reminders

Throughout the entire undo flow, follow these rules:

- **Use Director's vocabulary:** Say "going back" not "reverting" or "rolling back". Say "saved change" not "commit". Say "going back to before" not "resetting".
- **Never mention git, branches, hashes, or diffs to the user.** The user sees "Going back to before [task]" not "Resetting HEAD to [hash]".
- **Be calm and reassuring.** Undo is a safe operation. The user's project is fine. They are not losing anything permanently -- they are choosing to go back to a known good state.
- **Never blame the user for wanting to undo.** Going back is a normal part of building. It means they are experimenting and learning.
- **Follow `reference/terminology.md` and `reference/plain-language-guide.md`** for all user-facing messages.

$ARGUMENTS