jordan violet

Software as a Skill

Published .

Most software (I’m talking about the millions of applications not in your top 100) is mostly logic. Parse the input, branch on the cases, format the output. Some of it doesn’t need to be software, though. If you can pretty easily describe what goes in, what comes out, and how the system should behave in between…Claude can play the part of the system. I started calling that a different kind of SaaS. Software as a Skill.

Sure, it doesn’t work for everything. But it does work very well for one thing we use every day at Netwrix, a prose linter called Dale.

What Vale can’t do

Our documentation is linted with Vale, an open-source prose linter. Vale is fast and exact. A simple system where a rule is a pattern, and Vale finds every match. That’s the right tool for “write to, not in order to” or “it’s dropdown, not drop-down”.

Plenty of writing problems aren’t patterns, though. “X is not Y, X is Z” has endless wordings. A misplaced modifier depends on which noun the phrase attaches to. Whether a passive sentence can become active depends on whether the sentence says who did the thing. You can’t just write a regular expression for those situations, but you can explain each one to a person in a sentence!

Dale

Dale is what I call Vale’s sibling from the future. Dale lives in our docs repo, in .claude/skills/dale, and its structure intentionally works similar to Vale.

There is of course SKILL.md or “the app”. It tells Claude that it is not an assistant but a piece of software, a linter named Dale. Its only job is to apply each rule in the rules folder to the markdown file it’s given, then print a table of the rules that failed: line, rule, message, offending text. It is told not to talk to the user at all. LLMs aren’t perfect rule-followers, but they’re pretty good.

Then there are the rules, which are one small YAML file closely resembling Vale’s rule schema. Like Vale, a rule has a message, a level, and a reason, which is a sentence about when the rule should fire. This is a whole rule:

message: "Don't make negative assumptions about what users can or cannot do."
level: warning
reason: "This rule should trigger when the user or agent writes something that assumes a user cannot do something without the product."

That’s it. There’s no parser, no rules engine, no formatter for the output. We started in March with a skill file and two rules. There are 22 rules now, about 60 lines of YAML in all. This is significantly easier to manage than software, there is no release pipeline to break, and any non-developer can maintain it.

Dale is just one way that we’re innovating incrementally, and saves our technical writer what would have been 20-30 hours/week of work to only managing rules once every so often. He can now handle doc changes about as fast as they come in!

Where it runs

Dale is most useful when it runs without anyone remembering to run it, so it’s activated in a few ways:

  1. When Claude edits a docs page, a hook reminds it to run Dale on that page.
  2. When Claude finishes a turn, a hook runs Vale and Dale. Findings go back to Claude to fix, for up to three rounds.
  3. The pre-commit hook blocks a commit if the new or changed lines get flagged.
  4. CI checks the pull request.

What I’ve learned

While some software is complex, most of it is not. We’ve heard the phrase, “this meeting could have been an email” but what about, “this app could have been a skill”? I believe this is just a small but clean example of just how useful skills can be, and it seems that sometimes the coolest and most elegant solutions are the simple and benign ones.

I think this idea was silently inspired by DHH’s blog post, Merchants of complexity. In enterprise software we can become wired that something needs to be complex, but it doesn’t always have to (in fact, it seldom does).

The same file can get slightly different findings on two runs, and every run costs tokens and time. So anything a pattern can catch should be code. I wouldn’t build anything this way where the answer has to be exact and repeatable, like money, permissions, etc. For a linter though, where a person reads the findings and an occasional miss is cheap, the trade is a great one.

The skill is in the netwrix/docs repo, feel free to use it.

all content