task-observer — the skill that improves your skills but never edits them

task-observer is a skill that watches Claude while you work, writes down what you corrected and what you keep repeating, and once a week asks “should these skills change?” A skill is a text file that tells the AI how to do a job. This one reads your sessions, drafts edits to your other skills, and then stops. It does not apply them. The source is github.com/rebelytics/one-skill-to-rule-them-all.

The video and the repo disagree in three places

The video (33 seconds) is titled “Two open-source tools that save Claude tokens.” The first is Headroom, a compression tool; my own teardown is in the Headroom entry. The second is this skill. The video says: every time I fix Claude’s output it records it beside me, stores those as rules, and for months of corrections I no longer have to repeat myself. The direction is right. Opening the repo, three things differ.

The video	The repo
A token saver	There is no token-saving feature. It does the opposite and reads a 45.6KB core file every session. Any saving would be indirect, fewer rounds of repeating yourself, and the repo never measured that
Stores rules	What it stores is observation notes. A note becomes a rule (a skill edit) only after a person reviews it
No more repeating yourself	A goal, not a promise. The author writes that with only a few skills, the AI’s built-in memory may cover much of the same ground. The repo also says installing is not enough: you add an activation line to your settings file

The problem it tackles is skills freezing in place

Once you write a skill, it stays as it was unless you go back and edit it. You feel “this part falls short” all the time while using one, but in that moment few people open the skill file. So task-observer takes one job only: catch that moment as a note. It looks for three things.

• Where you corrected the AI’s output
• Work you repeat that no skill covers (a new-skill candidate)
• What this skill itself missed

I counted, and “over 90 contributors” holds up

The README says over 90 contributors are credited in the commit history. GitHub’s contributors tab shows 5, which made me doubt it. I pulled all 344 commits and counted.

What I counted	Number
Names that wrote commits	6
Names in “Co-authored-by” lines	104
Both combined, minus 5 AI model names	103

So the claim holds. It counts name strings, though, and someone using two names would be counted twice. Only 18 pull requests were merged and the maintainer wrote nearly every commit. Most of the credited people look like issue authors the maintainer added as co-authors (that last sentence is read off the numbers; I did not open the issues one by one).

The biggest number cannot be checked

“Over 1,900 observations across 83 skills” comes from the author’s private workspace. What is public is the tool, not the log, so I could not recount it. For the same reason the line “most of my 83 skills started from the skill’s own observations” can be neither believed nor refuted.

It spends tokens, it does not save them

That is the opposite of the video’s title, so it gets its own section. The core file SKILL.md alone is 45.6KB. At roughly four English characters per token that is about 11,000 tokens (an estimate, not a tokenizer count), and the file is written to be read before the first tool call of every session. On top of that sit 8 reference documents at 468KB and 5 helper scripts at 146KB. The references load only when needed, but the core already sets the floor for what adopting this costs.

Against my setup: not adopting it for now

• My skills folder has 113 entries and my memory folder 238 files. I am past the scale where the author says it starts to pay off.
• But I already have a path in the same spot. Repeated corrections pile up as memory notes, and a weekly weekly-learn check turns them into changes after my approval. Adding task-observer would give me two paths for one job.
• This is not my first time here. In July I hooked my PC to “observe everything automatically,” and later found the summarizing step had never run: 127 files and 20.6MB of observations, and zero lessons. What survived was the plain memory notes I write by hand. task-observer reads to me like a design aimed at that same failure, writing quietly stopping, using rules such as “write to disk after every third finished to-do” (my reading, not something the docs say). The direction is right, but every added rule also grows the core.
• The skill’s principle “when a rule is broken twice, stop rewording it and build a barrier” is already in my notes (a rule that lives only in a document is not a gate). Nothing new there.

What I don’t know yet

• I did not run it. I don’t know how good the observations are after two weeks of use, or how reliably the activation line works.
• I did not read the 8 reference documents. I read only the first 30,000 characters of the core file. The weekly review procedure is not covered here.
• The video’s claims come from auto-captions, and no repo address appears in it. I picked the repo that best matches what the video describes. There is a small chance the video meant a different tool.

The detailed record starts here

task-observer automates the writing and leaves the changing to a person. It was created on 2026-02-15, last pushed 2026-10-16, is at version 3.7.0 and has 3,512 stars (as of 2026-10-23). The license is CC BY 4.0, which lets you use and modify it if you credit the source. Six releases shipped in the 25 days from 3.3.0 on 09-21 to 3.7.0 on 10-16. I checked four things: the contributor count, the 1,900 observations, size and adoption cost, and three sentences from the video. The verdict is hold, nothing harvested.

What it is

A meta-skill that sits on top of Claude’s skill system. While you use other skills it watches the session, writes observations as files, and from those builds edits to existing skills or candidates for new ones.

Part	Size	What it does
SKILL.md (core)	45,556B	Start-up procedure, what to log, how to log. Written to be read before the first tool call of a session
references/, 8 files	468,312B	Weekly review, skill-writing rules, log format, environment setup. Read only when needed
scripts/, 5 files	145,582B	Start-up scan, new-observation file creator, bundle validator
Observation log	—	An observation-log/ folder with one file per observation (status, target skill and title in the header)

The log is split into one file per note so a session can scan only the headers at start and keep the cost down. I could not check whether that scan still holds up at 1,900 entries.

Techniques, and when each one holds

Technique	When it holds
Write to disk after every third finished to-do	Sessions that use a to-do list. A chat with no list has no trigger (the doc admits this)
Start-up scan reads headers only	When the log is one file per note. An empty scan reads as “the command is broken,” not “nothing there”
If it’s the same finding, extend the old note	On the author’s log, roughly 40 of 91 open entries were one finding restated
Broken twice, build a barrier, not a sentence	When a rule fails twice with no fix in between. The proposal must be a hook or a checker
Install only after human approval	The weekly review writes edits to a separate folder, and a person installs them outside the session
Two-layer activation	The skill’s description triggers, plus a line in a settings file, plus an optional session-start hook

What broke when I opened it — three numbers and three sentences

#	Claim	What I checked	Verdict
1	Over 90 contributors	344 commits via API: 6 authors + 104 co-authors = 108 names, minus 5 AI model names = 103. The contributors tab shows 5	Reproduced (by name)
2	1,900 observations, 83 skills	A record in the author’s private folder. No log in the public repo	Can’t check
3	220+ issues and PRs closed	238 closed issues, 18 merged PRs (search API)	Reproduced
4	Video title “saves tokens”	No token-saving feature, and a 45.6KB core is read each session. The indirect effect was not measured	Off
5	Video: “stores rules”	What is stored is observation notes; skill edits come after human approval	Off
6	Video: “no more repeating yourself”	The README admits built-in memory may be enough at small scale, and asks for an activation line beyond installing	Overstated

Against my setup → what to take → verdict

Technique	Applies to	Verdict	Gain	Adoption cost	Undo	Confidence
All of task-observer, always on	A settings line plus the skills folder	Hold	Speed at which repeated corrections harden into skills [can’t estimate — not run]	About 11,000 tokens per session [estimate] plus overlap with the weekly check	Delete the folder and one line	Low
Barrier after a second break	Existing rule	Rejected — already solved	0	—	—	High
One file per note, scan headers only	Memory index	Rejected — already solved	0	—	—	High
Two-layer activation	Skill invocation	Rejected — nowhere to apply	0	—	—	Medium
When to look again. If the same correction shows up three or more times as separate memory notes (the signal the repo itself names), or if my skills grow enough that editing them by hand stops being manageable. I would start by installing it for two weeks and counting how many observations were usable.

What I didn’t do

• Install and run it. This is the biggest gap. The verdict rests on reading and counting only.
• The 8 reference documents and the back of the core file. A tool limit stopped me at the first 30,000 characters of the core, and I did not open the weekly review procedure.
• The 1,900 observations. They sit in a private folder, so I could not count them.
• The 11,000 tokens is converted from character count. I did not run a tokenizer.
• Identifying the tool in the video. I matched the repo from captions and the 33 seconds of footage. I could not check the video’s description box.
• Independent adversarial verification (refutation, already-solved, broken-precondition, each run without being shown the conclusion) was not run. This is the default depth.
• The verdict is for one PC and one person.