Replace write-a-skill with custom write-a-7f-skill

[dumptruckman]

This PR introduces a new skill to help us write skills for this repo. The new skill focuses on the new guidelines for using docker as a fallback when your skills include scripts. Rather than copy/pasting skill building advice from Matt Pocock's skills, this skill instead expects the user to use such a skill in combination with this new skill.

This PR also removes the checked in, but outdated, Matt Pocock write-a-skill skill from .agents/skills, and replaces it with a symlink to the new skill.

[mariobrubio]

the skill itself says user-invoked skills cannot be reached by other skills. Since write-a-7f-skill is expected to use this as its authoring discipline, shouldn’t this remain model-invoked?

[dumptruckman]

The idea is that you invoke it specifically though?

[goneflyin]

I do like the intent of this, but in reality, at least the way I tend to want to reference skills like this, it makes it awkward.

To intentionally invoke it you have to start your prompt with /write-a-7f-skill. That's not bad, but when you're just thinking out loud and typing it, and say "I want you to create a skill that ... And make sure to use the /write-a-7f-skill to ensure it's robust", then it refuses.

This flag would also prevent you from having it be used to analyze your skill if you were updating it -- even if it knew from the frontmatter that it would be helpful, it can't use it to recommend things without asking you about it first.

It's fine if you do want to keep it -- I've just found it's personally more limiting than beneficial. Totally your call though.

[dumptruckman]

This is interesting @goneflyin because from my experience, it seems like Codex doesn't care whether disable-model-invocation is set to true. When I was working on building this, it just kept invoking it even though I never asked it to.

[goneflyin]

I cheated. I'm not the best judge of what makes a skill great myself, so I asked claude a few different ways and especially within the context of the /writing-great-skills skill, a few recurring themes arose.

(a few of these I adopted and rewrote myself, a couple ... I didn't have time, so forgive the raw copy/paste!)

1. The various failure modes that can come up with depending on Matt Pocock's skill. Details in my comment below.
2. Sprawl — the standards in the skill should be moved externally from the SKILL.md file. ~90 lines of dispatch / native-pair / simple / complex / container-contract are only relevant on the branch where the authored skill bundles scripts. The base skill's branch test is explicit: inline what every branch needs, push behind a pointer what only some reach. Most skills bundle no scripts, so most runs pay this context load for nothing. Move it to a REFERENCE.md.
3. Duplication — portability stated three times (the "Portability invariant" section, the frontmatter bullet, the dispatch section). The base skill: duplication "inflates a meaning's prominence past its real rank." And the skill's own step 2 demands "one authoritative home" — so it breaks its own single source of truth.
4. Some "leading words" are invented jargon. immutable-host works — the model has priors for both words. native pair and portable dispatch don't recruit pretraining; they're locally-defined terms the agent must decode, so they cost load without the anchoring a leading word is supposed to buy.

[goneflyin]

I do like the intent of this, but in reality, at least the way I tend to want to reference skills like this, it makes it awkward.

To intentionally invoke it you have to start your prompt with /write-a-7f-skill. That's not bad, but when you're just thinking out loud and typing it, and say "I want you to create a skill that ... And make sure to use the /write-a-7f-skill to ensure it's robust", then it refuses.

This flag would also prevent you from having it be used to analyze your skill if you were updating it -- even if it knew from the frontmatter that it would be helpful, it can't use it to recommend things without asking you about it first.

It's fine if you do want to keep it -- I've just found it's personally more limiting than beneficial. Totally your call though.

[goneflyin]

I thought about this a lot more, and even grilled my clanker about it, and think I've changed my mind....

Don't make Matt's skill a silent external dependency.

If /writing-great-skills is absent or renamed (as it was once already), the gate falls through and the agent proceeds anyway even though the skill may not exist -- it only has the overlay.

I still prefer that we reference the skill, but I think we should fall back on a vendored copy if necessary. So:

1. Try the live /writing-great-skills (then legacy /write-a-skill).
2. If neither is exists/active, fall back to a vendored copy included here -- don't proceed.
3. Have the skill announce which skill it actually loaded — e.g. "loaded live writing-great-skills" vs "loaded vendored copy @ <commit/version>" — so the user is never misled about what's driving the authoring.
4. Pin a version/commit in the vendored copy's header and add a short "how to re-sync" note, so drift is visible and intentional rather than invisible.