skills fix beginner 5 minutes

Edit Tool Fails the Second Time the Same Field Gets Updated — Use sed Instead

The Edit tool is confident right up until it's wrong. Once another write already changed the target string, there's nothing to match — and you get a warning that looks like a permissions error but isn't. Any field that might get updated twice on the same day deserves a different tool.

 Tony confirms the task was added. Then, immediately after: a warning that the file edit failed.

The task is in the file. That part worked fine. What failed was the step that followed — updating the *Last updated:* date at the bottom of the file. The date was already today’s date, set by an earlier /add command. The Edit tool had nothing to find.

The Problem

A skill that adds a task to a markdown file also updates a footer timestamp:

*Last updated: 2026-03-10*

The first time the skill runs in a day, it replaces that line with today’s date. Works perfectly.

The second time the skill runs, it tries the same replacement — but the file now says 2026-03-11, not 2026-03-10. The Edit tool’s old_string doesn’t match anything. The write fails.

The error looks like this:

✅ Added to Urgent: your task here
⚠️ 📝 Edit: in /path/to/TASKS.md (30 chars) failed

It’s not a permissions issue. It’s not a lock. It’s a string-matching failure on a field that was already correct.

Why This Happens

The Edit tool works by exact match. It finds old_string in the file and replaces it with new_string. There’s no concept of “pattern” or “any date value here.” Either the exact string exists or the edit fails.

This is fine for targeted, one-off edits. It’s the wrong tool for anything idempotent — fields that need to reflect the current state, not a specific previous state.

The date footer is the most common case. Any field that should say “latest value” will eventually lose the race with itself.

The Fix

Replace the Edit tool call with a sed command. Sed matches a pattern, so it doesn’t matter what the current value is:

Before (in SKILL.md):

Edit the file — append the task to the correct section and update the
"Last updated" date at the bottom.

After:

Edit the file — append the task to the correct section. Then update the
"Last updated" date using a shell command:

sed -i "s/\*Last updated: .*\*/*Last updated: $(TZ=America/Los_Angeles date +%Y-%m-%d)*/" /path/to/TASKS.md

This handles the case where the date is already today.

The sed command matches *Last updated: followed by any value and replaces the whole thing with today’s date. Running it twice on the same day does nothing harmful — the second run replaces the same string with an identical string.

Key Takeaway

The Edit tool is for surgical changes to stable content. The moment a field could have already been updated — a date, a counter, a version string, a status flag — reach for a shell command instead. The pattern is simple: exact match → Edit tool. Pattern match → sed. Two commands that can write the same field on the same day means one of them will lose.

FAQ

Why does my agent's Edit tool fail after the first successful write to the same file?

The Edit tool matches exact strings. If another operation already changed the target text since the last read, old_string no longer exists and the edit fails silently with a warning. Use sed or a shell command for fields that may already have a newer value.

How do I make a skill's file update idempotent?

Replace the Edit tool call with a sed command that matches a pattern instead of an exact string. For example: sed -i "s/*Last updated: .*/*Last updated: $(TZ=America/Los_Angeles date +%Y-%m-%d)*/" /path/to/file.md

My skill shows success then immediately shows a failed edit — did the task actually save?

Probably yes. If the skill confirms the main action (✅ Added to Urgent), that write succeeded. The ⚠️ is almost always a follow-up edit — typically a timestamp or counter — that failed because its old_string was already replaced earlier. Check the file directly.

When should I use the Edit tool vs a shell command in a skill?

Edit for stable, unique content that only one operation will ever change. Shell command (sed, awk, or a small script) for anything a second command could have already updated — dates, counters, version strings, status fields.