On October 9, in a single evening, I closed four automations that I had left for Monday. I didn't build them alone or in sequence: I split them among agents working in parallel, and the longest task took 458 seconds. What told me what to automate and what to leave alone came from a Wick skill.
Wick is a repository maintained by Ryan, of Agora Dynamics, who is a friend of mine: consider yourself warned and read this with that in mind. It is MIT licensed. Here is the repo: github.com/agoradynamics/wick. I tell it in my own words, with my dates and with what failed me.
What Wick is
Wick is a package you add to Claude Code so it stops starting from zero every morning. The idea underneath is simple: a folder of text files where what the assistant learns about you stays, along with your decisions and why you made them. They are files you can open, edit or delete. There is no account and no service in between.
Around that memory it brings three more things. A collection of thinking frameworks for deciding better, a group of named skills (code review, red team, summarizing a changelog, consolidating memory, among others) and a handful of audit scripts: one that cleans sensitive data before you publish, others that measure how stale what is in the memory is or whether the paths still exist.
I don't use the whole package. I use two pieces and add a method of my own, and all three changed how I work: the wick-automate skill, my version of the observer, which logs which tools I use, and the way of following the repo without losing control of what enters my machine. That last point is the one most worth copying.
Source: Wick repository, Agora Dynamics, MIT license
How I adopt it without looking blind
I don't have write access to Ryan's repo, and I shouldn't. What I do is keep a private fork of my own and bring in new versions when I choose. Every version follows the same path:
- Fetch what is new from the original repo, tags included, and compare against it, not against my copy.
- Audit before merging: hidden Unicode characters, phrases that look like injected instructions, what the new scripts do and whether they reach the internet.
- Create a sync branch and merge there. It should go in clean, with no conflicts, because I have no changes of my own.
- Open a pull request in my own fork, review it and merge.
- Tag the adopted version with a date and check that my copy does not differ from the original.
- Never push anything to the original repo. The remote is configured so that it can't be done.
| Version | Date I adopted it | What it brought or what I checked |
|---|---|---|
| 1.3.0 | Jun 26, 2026 | First adoption |
| 1.4.0 | Jul 20, 2026 | The official wick-automate skill and the observer. Clean merge: 8 files, 162 lines added, 6 removed. |
| 1.6.0 | Aug 5, 2026 | Clean merge, no conflicts |
| 1.8.0 | Sep 30, 2026 | 16 commits, 65 files. Audit: 0 hidden characters, 2 false positives from the injection detector, new scripts that only call a local model and git, 4 scanners with no findings. |
That table is boring on purpose. The value of an audit is that when something goes wrong you already know where to look, and when it goes right you don't have to trust that it went right. In the 1.4.0 merge my secrets scanner flagged 6 matches; I read them one by one and they were documentation text that mentions the words "secret" or "password", with no real value. The discipline is to read the line before approving or ignoring the warning.
wick-automate: program or skill
This is the piece that made me pay attention to Wick. It is a skill that helps you decide whether something is worth automating and, if it is, of what kind. Its central idea: the third time you do something by hand should be the last.
It looks at three kinds of repetition and treats them differently:
| Kind | What it is | My example |
|---|---|---|
| Literal | The same command N times | You get an alias, nothing more |
| Structural | The same shape of task with different data | Closing a work session: summary, devlog, memory, commit |
| Friction | A task that is slow or error-prone even if it is rare | A skill-link fix that kept breaking |
Then it decides with an honest calculation: the benefit (how many times, what each one costs) against the cost of building and maintaining it. And it has a gate I find the smartest part: the stability test. If the steps change each time you do it, wait. Automating something you are still discovering only freezes a mistake.
The last thing it does is pick the type. A program, which is a script that always does the same thing. Or a skill, which is a procedure with judgment. Or both: the skill decides what to do and the program does the mechanical work.
I added a step of my own, number 2.5. Before proposing something new, it asks whether a rule already exists that is being broken. If the rule breaks every time there is a rush, the problem is not discipline but that the right path costs more keystrokes than the wrong one. Then the proposal is not a stronger rule, it is shortening the right path.
What came out of using it
| What it detected | What we built | How sure I am |
|---|---|---|
| Closing a session with the same routine about 6 times in one conversation | A /logs skill (decides what to record) plus a program for the commit | Tested in 2 different repos |
| Skills copied instead of linked: the same error 3 times in one session | A --fix-safe mode: fixes only the 2 no-doubt cases and leaves the rest by hand | Tested on a 3-situation sandbox before touching anything real |
| Two hours for a 30-second film | A repo of our own with automatic checks (motion-forge, the one in the HyperFrames post) | Measured: about 2 hours the first, about 40 minutes the fourth |
| None of my 20 growth skills covered a strategic analysis | A new skill inside the SVDIGINET playbook | Tested on one case, needs more use |
The case that best shows the method is October 9. We had four approved proposals and I dispatched them at once, to different agents. One took 458 seconds, another 227 and another 56; the fourth I built myself. Added in a row, the agents' three are 741 seconds, about 12 minutes. In parallel I waited as long as the longest one took: 458 seconds, about 7 and a half minutes. I saved almost 5 minutes, in theory: I did not time the one-after-another version. That is small, and I say so because the honest number is that one. What did change was that nothing was left pending for Monday.
One more thing that helps you see repetitions without remembering them: my version of the observer, adapted from Wick's. It is a hook that runs after every tool and writes to a local file, which goes nowhere, which tool and on what. When I ask the skill to review that file, it does not depend on my memory but on what I did.
The mistake I made twice
On August 5 I checked whether Ryan had published anything new. I looked at my fork, saw it was the same and said "no changes". He had already pushed 1.5.0 and 1.6.0. My fork only tells me whether I am up to date with myself. On September 30 I repeated it: I looked at my copy first and merged before auditing.
It is now in the rule of my flow: the first thing is to compare against the original repo. These are the commands, and each one is read-only:
git remote -v git fetch upstream --tags git diff upstream/main --stat git log --oneline origin/main..upstream/main | wc -l
A "no changes" report is only worth something if the instrument could have seen the change. If I look at my own copy, it couldn't.
What I don't know
- Whether the observer works inside Codex. I wired it in the same format as a hook that does run, but I haven't seen it fire in a real session.
- How much I really save. My time figures are per task, not a monthly total.
- Whether my reading is neutral. Ryan is a friend of mine and I suggested the wick-automate idea to him. Read this as a happy user, not as a review.
- How many of the package's skills I don't use are worth it. I use two pieces out of many.
Check your fork
If you follow someone else's repo with a fork, paste this into Claude Code. It only reads, it changes nothing:
Tell me whether my fork of someone else's repo is up to date, without changing anything. Run `git remote -v` and tell me which remote is mine (origin) and which is the original (upstream). Then `git fetch upstream --tags` and compare against upstream/main, not origin/main: tell me how many commits I am missing and which files change. If there is no upstream remote, tell me and stop.
If you are curious what my long sessions with agents cost, it is in Claude Code now compacts idle sessions. And the other repo in this series, the one that makes videos from HTML, is in its own post.
