Asteria: The useful part is that it treats every recurring “please fix that” as missing product infrastructure.
Draco: Yeah. Anthropic’s actual argument isn’t that Claude Code needs more looping. It’s that the manual checks people perform after an agent finishes are often the only place their real engineering standard exists. Put that standard into a skill, and the agent can inspect, repair, then inspect again without waiting for a human to remember the ritual.
Asteria: And that’s immediately practical, Draco. A team doesn’t buy “agentic loops.” They buy fewer tiny review comments about the same log field, accessibility detail, or migration footgun. This is very much our old judgment-layer argument, except it’s sitting in a repo as a little contract.
Draco: Right.
Asteria: Also, my week has had a weird amount of reading specs that pretend edge cases are optional. So this article hit a little close to the keyboard. A markdown file is not a requirement until something can notice when it got ignored.
Draco: The article gives a clean example: a log-hygiene skill reads changed error paths and checks every error log for a request I D, while rejecting request bodies, headers, and user payloads. It reports file and line, then fixes the violation. That’s a useful shape because the condition is local enough to inspect, and the repair is bounded.
Asteria: Oh, that matters.
Draco: It also scopes the skill with a description and allowed tools like Read, Edit, and Grep. That sounds mundane, but it’s the difference between a focused verifier and a vague instruction that wanders through the repository. The article’s migration rule is even better: reject a dropped column unless there is a backfill step. A generic linter will never know that policy.
Asteria: That’s where the product story gets real. The stuff a team repeats is usually invisible in a benchmark and painfully visible in production. Someone has already paid to learn that a request body in an error log is a bad day, so preserving that lesson in a skill is much better than hoping the next model run has the same instinct.
Draco: Exactly.
Asteria: There is a tiny bureaucratic comedy here. You begin by saying, “I’ll just check it myself.” Then you write a skill. Then it runs on every pull request. Suddenly your two-minute habit has acquired governance.
Draco: And a name, a directory, frontmatter, and eventually a queue of complaints. Nature heals.
Asteria: Okay, that’s genuinely funny. But yes, it’s the good kind of bureaucracy when it prevents the same avoidable mistake.
Draco: Mm-hm.
Draco: The placement taxonomy is sensible. Standalone is for checks you want available but not constantly firing, like a pre-commit security scan. Embedded means the producing skill runs its own check, such as a component scaffolder running eslint before it declares success. Chained means one skill invokes the next, like /code-review, then /simplify, then /verify, with a design check if the diff touches U I.
Asteria: I like that they don’t sell chaining as automatically better. It trades flexibility for automation. If I sometimes want /simplify without the whole sequence, forcing the chain is annoying. But if every refactor has the exact same safety step afterward, making it a contract is cleaner than relying on developer memory.
Draco: The technical caveat is important, though. A skill that asks a model whether code “looks accessible” or “matches the spirit of the spec” is still an imperfect judge, even if a separate grader agent does it. We have been over this with agent-written tests. Fluent self-approval is not verification.
Asteria: Yep.
Draco: So use type checks, tests, linters, parsers, and explicit repository rules whenever they fit. Let the agent handle the awkward work around those tools: locating the relevant files, interpreting a failure, attempting a bounded fix, and escalating when the evidence is ambiguous. That’s the loop earning its keep, not a model awarding itself a gold sticker.
Asteria: Yeah, no, you’re completely right. I changed my mind on the green-test-run thing after that Slack testing discussion. The strongest version here is not “Claude can validate anything.” It’s “Claude can keep working against evidence we already trust,” plus project rules explicit enough to inspect.
Draco: And Anthropic does flag the operational cost. Chained loops can burn more tokens, and a pull-request gate turns every adjustment into a team-visible event. Their advice to stabilize the chain locally before applying it to every P R is boring, which is why I believe it.
Asteria: Oh, come on. You only trust it because it’s boring.
Draco: Correct. Boring systems have receipts.
Asteria: If I were setting this up, I’d start with the exact command they show: /skill-creator, then ask it to interview me about an end-to-end frontend verification workflow. That at least forces the manual process out of somebody’s head before it gets turned into automation.
Draco: Or hand-write .claude/skills/verify-log-hygiene/SKILL.md for one narrow rule. The article’s wrapper pattern is handy too: a safe-refactor skill can run /simplify, then invoke /verify-no-public-api-changes. But test it on fresh tasks. A chain that exists in markdown but never gets invoked is just documentation wearing a tool belt.
Asteria: That’s painfully accurate.
Draco: One more thing: watch the trigger descriptions. The article notes that an embedded step may fail to run if the skill description or earlier instructions do not pull it in. So the first acceptance test is not whether the skill reads nicely. It’s whether a new task actually causes the check to execute.
Asteria: All right, Asteria’s product-optimist verdict is that this is worth doing exactly where the repeated correction already hurts. No grand agent architecture required. Just capture one annoying truth, give it a judge, and see whether the loop behaves.
Draco: That tracks.
Asteria: Fine, we can spend another Wednesday making small contracts for robots. I’ll take that over rediscovering request I Ds in code review, Draco.