I've spent a considerable amount of time working with AI coding assistants, and I've come to a fairly simple conclusion. The technology is fantastic, but apparently we still need to teach these things how to behave like competent programmers. You would think that a machine trained on an unreasonable amount of human knowledge could figure out that writing working code is more important than explaining, in seventeen beautifully formatted paragraphs, how excited it is to write that code. Apparently not.
That's where FKNRTD.SKL comes in. It's my collection of skills for AI coding assistants, built around the idea that these tools should spend more time doing useful work and considerably less time finding creative ways to waste my time, tokens, and patience.
The repository currently contains four independent skills: butcher, conspirator, inquisitor, and odin. Each addresses a different frustration I've encountered while using AI for software development. They aren't replacements for the models themselves, and they aren't another massive framework that requires three days of configuration before you can accomplish anything. They're focused instructions and supporting tools that give existing assistants better ways to approach their jobs.
Four Skills, Four Different Problems
The first skill I created was butcher, which came from watching AI assistants burn through tokens like a drunken sailor with someone else's credit card. Ask one of these things to fix a function and you'll sometimes get an explanation of the problem, an explanation of the proposed solution, an explanation of the code it just wrote, and finally a cheerful summary explaining that everything has been explained.
Butcher cuts that nonsense out. It's designed to reduce unnecessary token consumption by eliminating repetitive prompts, pointless narration, oversized responses, and redundant repository exploration. What makes it different from simply telling an AI to be brief is that it explicitly protects the actual engineering work. I don't want shorter code, missing tests, or half-assed implementations just to save tokens. I want the same quality of work without paying for the machine to congratulate itself every thirty seconds. The development target is a 50% reduction in total token usage without sacrificing quality. That's a target to benchmark, not a magical performance claim.
Then there's conspirator, which addresses another problem I've repeatedly encountered. We have multiple powerful coding assistants available, each with different strengths, yet most of the time we use them individually. Why? If I have Claude, Codex, Cline, and Copilot available, I should be able to put them to work together without becoming a full-time project manager for a collection of artificial personalities.
Conspirator provides a structured way for AI assistants to collaborate on development tasks. One can handle implementation while another independently reviews the work, with Git worktrees keeping changes isolated and a compact communication protocol preventing them from spending all their tokens discussing how wonderful teamwork is. It supports verification, bounded repair attempts, audit gates, and controlled integration of completed work. The goal is to make multiple assistants behave like a development team instead of four people standing around a broken printer offering unsolicited opinions.
Inquisitor exists because AI has a particularly irritating habit of confidently filling in information nobody actually provided. Give an assistant a vaguely defined project and there's a reasonable chance it'll invent requirements, choose an architecture, and start building something you never asked for. By the time you realize what's happening, you've got an application, fourteen assumptions, and a surprisingly enthusiastic README.
Inquisitor takes a different approach. It investigates the project and generates an interactive questionnaire designed to get the important decisions out of the way before development begins. Rather than asking generic questions that could apply to literally anything, it focuses on meaningful choices, explains the consequences, and identifies what genuinely needs an answer. The questionnaire runs as a local HTML page, saves your responses into an answers.md file, and turns those decisions into usable requirements for the coding assistant.
It's essentially an interrogation tool for software development. The difference is that the suspect is the project specification, and nobody gets to leave until we figure out what we're actually building.
Finally, there's odin, which was born out of my frustration with handing an existing codebase to another developer or AI assistant and watching it spend the next several hours trying to understand what the hell is going on.
Odin investigates repositories and produces detailed technical documentation based on what actually exists in the source code. It can inventory files, examine architecture, identify dependencies, review security concerns, document components, generate a GitHub README, create an interactive documentation website, and assemble a developer handoff. It also produces a forensic evidence package for deeper analysis.
The important part is that Odin isn't supposed to invent information just because documentation would look prettier with all the blanks filled in. If something can't be determined, it needs to say so. If a test wasn't executed, it doesn't get to claim the test passed. If the repository contains questionable decisions made by a developer at three in the morning, Odin documents those decisions without quietly rewriting history. Which is probably for the best, considering how many of those developers are me.
Making AI Work Like a Development Team
Individually, these skills solve specific problems, but the bigger idea behind FKNRTD.SKL is creating a more disciplined development workflow.
Imagine starting a project with Inquisitor to establish the requirements, using Conspirator to coordinate implementation and independent review, having Butcher keep the entire process efficient, and finally running Odin to document what was actually built. Each skill has its own responsibilities, and none requires the others to function. They can be used independently or combined into a workflow that makes sense for the job.
That's an important distinction. FKNRTD.SKL isn't some giant application pretending to be an operating system for AI agents. It's a collection of reusable capabilities that can be installed into supported coding assistants, including Claude Code, Codex, Cline, and GitHub Copilot CLI. The repository uses skill definitions, Python tooling where necessary, and relatively straightforward installation methods. I deliberately wanted tools I could use with the assistants I already work with rather than something that locks me into one model or provider.
I also wanted the skills to remain practical. Not every problem requires multiple agents, an exhaustive forensic investigation, or a questionnaire that makes a government background check look casual. Sometimes I just want the AI to fix a bug and shut up about it. That's why each skill addresses its own problem rather than forcing every task through the same complicated process.
This Is About Control, Not Replacing Developers
There's an increasingly popular idea that AI will eventually handle every part of software development without much human involvement. Maybe it will, but we're certainly not at the point where I'd hand an assistant the keys to a production environment and disappear for the weekend. At least not without checking my backups first.
For me, the value of AI development tools is that they allow one person to accomplish substantially more than would otherwise be practical. I can explore ideas, prototype applications, investigate unfamiliar code, compare implementation approaches, and work across multiple projects without needing an entire department of developers standing behind me.
But increased capability is only useful when the results are reliable. An assistant that generates ten thousand lines of code in five minutes isn't particularly impressive if half of it doesn't work, nobody knows why it was written, and the documentation describes an application that only exists in the model's imagination.
FKNRTD.SKL is my attempt to address those problems through better working practices. Make the assistant understand the requirements. Make it use its time and context efficiently. Give it access to independent review when appropriate. Require evidence before declaring something finished. And make sure the next developer, human or otherwise, can understand what happened.
It's not particularly glamorous, but neither is spending four hours debugging something an AI confidently described as production-ready.
The Collection Will Keep Growing
These four skills are the beginning, not the finish line. As I continue building projects and experimenting with different local and hosted models, I keep finding little frustrations that deserve their own solutions. Some of those will become new skills, while others will turn into improvements to the existing ones.
The repository is public because I figure I'm probably not the only person who wants coding assistants to behave less like enthusiastic interns and more like experienced developers. The individual skills have their own documentation, installation instructions, and supporting tools where needed. Take a look, try what interests you, and see whether any of them make your own development process less painful.
Ultimately, I don't need AI to tell me how brilliant my ideas are. I need it to tell me when they're terrible, help me make them better, write the code properly, and explain what went wrong when something inevitably catches fire.
That really shouldn't be too much to ask.
FKNRTD.SKL is available on GitHub:
No comments yet.