skillify-meta-loop
Skill50 starsChanged 7 months agoMITView on GitHub
Use when a recurring bug, support question, client incident, or manual task surfaces 2+ times, when a codified rule keeps getting violated despite being written down, when a teammate or client hits an issue anyone could hit, or when delivery/setup friction repeats. Triggers: "skillify this", "this keeps happening", "we hit this last week too", "make a skill for X", "automate this", "every client hits this", "I keep doing X manually", "turn this into a skill".
In this repository39 other files it gives its agents.
- docs/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- setup-brainSkill
- backfill-journal-body-contextSkill
- cierre-de-llamadaSkill
- coachingSkill
- coachSkill
- daily-journalSkill
- deconstructSkill
- diagnoseSkill
- doubt-driven-developmentSkill
- evolveSkill
- for-my-teamSkill
- graphifySkill
- health-contextSkill
- health-doctorSkill
- health-setupSkill
- ingest-githubSkill
- ingest-healthSkill
- ingest-youtubeSkill
- insightsSkill
- instinct-exportSkill
- instinct-importSkill
- interview-meSkill
- longitudinalSkill
- meeting-todosSkill
- nano-bananaSkill
- note-todosSkill
- optimize-brainSkill
- patternsSkill
- repurpose-talkSkill
- resolver-querySkill
- riseSkill
- second-brain-mappingSkill
- secret-warnSkill
- security-snapshotSkill
- setup-vault-typesSkill
- sunday-reviewSkill
- vault-systemSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
If the trigger is a one-off accident with no pattern signal, skip skillify.
- Very specific: line 47
Every behavior-changing skill ships a check that proves it works.
- Distinctive: line 53
Commit with explicit paths.
- Distinctive: line 56
Document the skill in your memory index.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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.
Files
Bug → durable skill in 10 steps. The loop runs same-session, no queueing.
When to invoke
| Signal | Example |
| Same issue 2+ times | Two clients hit the same install error |
| Manual repeat | Wrote the same onboarding email 3× |
| Codified rule violated | A typo slipped past a lint rule despite it being codified |
| Support question pattern | 3 teams asked "how do we wire X" |
| Delivery friction | Bespoke setup hour you shouldn't be spending each time |
If the trigger is a one-off accident with no pattern signal, skip skillify. The loop is for repeats.
The 10 steps
1. Scaffold
Pick the skill's home:
- Private skills repo →
~/dev/<your>-skills/<name>/ - Public substrate →
<repo>/skills/<name>/(if generic + no personal data) - Team repo →
~/dev/<team>-skills/<name>/
mkdir <path> && touch <path>/SKILL.md. Don't symlink yet.
2. State the trigger
In SKILL.md frontmatter trigger: field: every phrase a user might type that should fire this skill. Cover bilingual surfaces if relevant. Cover the explicit invocation (/skill-name) AND natural-language patterns. Be over-inclusive; pruning false-positives is cheaper than missing the signal.
3. Define the failure mode
What does the world look like WITHOUT this skill? One paragraph. Be specific: name the file, the rule, the client, the hour cost. Without this, the skill ages into a "feels useful but no one runs it" file.
4. Write the steps in caveman form
Terse, IF/THEN, bullets, no preamble. Drop articles. Drop multi-paragraph rationale. The skill must be USABLE on read, not appreciable.
5. Provide one real example
Concrete, with real file paths, real flags, real outputs. Not <your-key-here>. Not # do the thing. The first real example is the most-cited part of the skill.
6. Add the discoverability path
Pick ONE: top-level SKILL.md (auto-loads metadata); plugin marketplace registration; hookify trigger reminder; CLI tool with explicit invocation. Document which path is wired. A skill nobody can find = a skill that doesn't exist.
7. Wire the verification harness (if behavior-changing)
Every behavior-changing skill ships a check that proves it works. Forms: pytest in tests/ if Python; a "good vs bad" example pair; a scheduled verification script (cron/launchd) if the skill prevents drift. If documentation-only, skip.
8. Audit for personal-data leakage (if public)
For skills landing in any public repo: run a personal-data scrub — word-boundary regex on real names, company names, private paths. Example patterns: \bYourName\b, \bYourCompany\b, /Users/youruser/. Any match → scrub or move to private repo.
9. Commit + push
Commit with explicit paths. Public: scrub → commit → push → auto-merge own PR when CI green. Private: commit + push.
10. Add to skill-usage tracking + cross-link
Document the skill in your memory index. Add a one-line entry if it's a CLI tool. Link from related rule files. The first invocation logs to a skill-usage log automatically; that's how you know the discoverability wiring works.
Common failure modes
| Failure | Diagnosis | Fix |
| Skill exists but never fires | Discoverability not wired (step 6 skipped) | Add hookify reminder OR plugin marketplace OR top-level SKILL.md |
| Skill fires but wrong context | Trigger too narrow (step 2 underspecified) | Add more natural-language phrases, common typos, bilingual variants |
| Skill ages into stale advice | No verification harness (step 7 skipped) | Add a scheduled check OR a pytest assert that flags drift |
| Skill duplicates existing one | Skipped grep before scaffold | grep -r <pattern> across your skills dirs first |
| Skill leaks personal data publicly | Skipped step 8 | Scrub via word-boundary regex; revoke public commit if pushed |
Source
Adapted from garrytan/gbrain Skillify Meta-Loop pattern. Generalizes across vault rules, public skills, and team playbooks.
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
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.