LLMs changed the way I do software development. Depending on who you ask, admitting that I haven’t hand-coded a feature since the beginning of the year may or may not be a good thing. Regardless of where you fall on the “AI morality” spectrum, one thing is hard to deny: software development has evolved significantly over the past year. With it came agentic skills frameworks like Superpowers that enable agents to code software end-to-end. As a developer myself, why not try to reinvent the wheel and make your own framework? Enter Kantan Dev.

Kidding aside, I enjoyed working with skill-based frameworks like Superpowers. It consistently produced higher-quality results than simply prompting an LLM to generate code. Alas, no tool is all upside, and I noticed a few drawbacks:

  • The framework sometimes just takes too long to generate the code.
  • I think the “spec” document step is unnecessary and just adds token cost without much benefit. A detailed coding plan is sufficient enough for a capable model to understand and execute.
  • It is too “black box” for me (I know, ironic coming from a Rails developer!)

From my experience, nearly every project I work on uses some variation of Rails with or without React. That got me wondering: why not create a more focused framework? Whatever I build will not be the greatest solution out there. It certainly won’t be optimal for every tech stack. But there’s something incredibly satisfying about scratching your own itch.

My AI Coding Journey

Before we go into the details on what Kantan Dev does, I think it is important to look back in my professional journey as it relates with agentic software development.

Now spanning almost exactly a year, I started from copying and pasting code snippets to letting Claude Code hammer through features semi-independently. The way I use LLMs for coding has evolved through several distinct stages:

  1. Asking for code snippets in ChatGPT and pasting it in the codebase
  2. Asking ChatGPT to generate entire classes through their Canvas feature
  3. Using an AI-powered IDE like Copilot to auto-complete code and entire methods
  4. Moving over to Cursor and using LLMs to generate test files
  5. After finding that the tests consistently are becoming more acceptable as-is, asking LLMs to generate classes and services in the IDE
  6. Prompting Claude Code to create plans first and then create entire new features in a session
  7. Using an agentic skills framework like Superpowers to further enhance the code quality
  8. Adding an agentic standards feedback loop
  9. Creating a custom agentic skills framework that focuses on the tech stack you are using for a higher quality, more streamlined development workflow

Feedback Loop

Perhaps the most significant milestone I experienced was Step 8, where I let the agent encode any identified common standards that can be included in CLAUDE.md. This makes Claude Code incrementally better the more I start new features, plan, and let the agent do the coding.

This isn’t something magical, as it is just a few lines in my CLAUDE.md file. Here is an example for the backend repository:

Review the changes for anything generic and reusable (not feature-specific): new service/controller/model patterns, testing helpers, component/API/state patterns, library integrations, migration conventions.

For each reusable pattern, update the relevant repo's conventions file — write to AGENTS.md if it exists, otherwise CLAUDE.md. Backend patterns go in the backend's file; frontend patterns go in that frontend's file. Keep entries concise and prescriptive (tell future agents what to do, not what was done).

This makes your CLAUDE.md or AGENTS.md better as more updates are made. Once a development plan is thoroughly defined, the agent can almost always implement the feature in a single pass with this simple addition.

Kantan Dev

After months of doing AI-assisted development, I found that I just do the same thing every time I do a feature: write an idea, enter plan mode, go to development mode, review, code quality checks, and so on. Why not turn this into a skill-based framework so everything is standardized?

There are already lots of similar skill based frameworks like Superpowers, but they were built as a generic “one size fits all” approach. This makes the framework versatile, but at a cost of adding more context to the LLM in order to do its job. Since I am primarily a Rails developer, and most of of my projects use React, I decided to create a more focused, leaner framework: Kantan Dev.

In general, this plugin basically encodes and standardizes the development approach I have been doing for AI-assisted development. Each step is its own skill, which the LLM invokes as it moves through feature development.

  • kantan-start-feature — name the feature, confirm the working branch, capture your requirements as an idea document.
  • kantan-plan-feature — read the idea + prior docs + repo conventions, ask clarifying questions, write a plan, and wait for approval.
  • kantan-backend-tdd — implement Rails code with TDD; keep RSpec (or the detected suite) and RuboCop (if present) green.
  • kantan-frontend — implement React changes following the frontend repo’s stack; run its formatter then linter.
  • kantan-review-feature — expert Rails + React review of the changes against the plan, conventions, and best practices; Critical/Major findings block the process.
  • kantan-finish-feature — write a “how it was built” doc and fold new reusable patterns into each repo’s conventions file.

The process is mostly sequential, except for the following steps:

  • kantan-plan-feature loops until the developer is satisfied with the current development plan
  • kantan-review-feature can loop back to either kantan-backend-tdd or kantan-frontend if there are major review findings

Apart from clarifying the plan, the coding agent can accomplish the entire feature without any user input. The only input it needs from you is the most important part of software development: the plan. The plan is where the code architecture, workflow, and limitations are defined. If you thoroughly review the development plan, the agent can almost always implement the feature in a single pass!

Artifacts

The Kantan Dev framework creates several markdown files once the development process has completed:

  • Idea – saved to .kantan-dev/ideas
  • Plan – saved to .kantan-dev/plans
  • Review – saved to .kantan-dev/reviews
  • Documentation – saved to .kantan-dev/docs

In my use case, these artifacts are also pushed in the repository, and that is also my recommendation when using the plugin. But why the need for so many files?

What powers coding harnesses are LLMs. And LLMs natively consume text. If you watch a coding agent work, you will often notice that it uses grep to navigate the codebase. These Markdown files are the perfect place for the agent to gather additional context about a feature. First, the filenames act as concise feature summaries. Second, most of the terminology associated with each feature appears in these documents. This makes it easier for the agent to determine how the previous feature was built, the architecture, and specific pitfalls that may not be present in the app-level AGENTS.md or CLAUDE.md files.

However, there are drawbacks to using text files for information retrieval. This tends to bloat the context window due to the amount of information contained in the artifacts. As more features are built, the number of files grows as well. You can manage this by using a separate repository for indexed context. From the plugin’s perspective, however, text files are an easy and readily available way to store information. They may not be the most optimal solution, but they are more than sufficient for providing application context.

1.0.0

As mentioned, the current limitation of the Kantan Dev framework is the heavy usage of markdown files to record the application’s behavior. This can be further improved by incorporating a Git-based memory backend (such as DiffMem), or even using a more standardized approach like the Open Knowledge Format (OKF).

That said, I have been using the plugin for my professional work for some months now, and have proven to deliver results. For this reason, I am happy to release this plugin to the public as the first stable release! See the installation instructions on how to install it in Claude Code, Codex, or Cursor.

Photo by BoliviaInteligente on Unsplash

Leave a Reply

Your email address will not be published.