DEV Community: Marcin Ostrowski

Your AI has no memory. Your Rails codebase does.

Marcin Ostrowski — Wed, 11 Feb 2026 14:49:18 +0000

In Memento, Leonard wakes up every morning with no memory of yesterday. He doesn't know where he is. He doesn't know what he did. The only things he trusts are the tattoos on his body.

AI coding works the same way. Every session is a fresh wakeup in a motel room. It doesn't remember the raw SQL disaster from last session. It doesn't remember hallucinating a method yesterday. The only things it trusts are the rules you load into context.

And your codebase won't help. It remembers everything, including the bad habits. Every shortcut, every model that was never refactored, every raw SQL query nobody got around to fixing. AI treats all of it as truth. It doesn't know which patterns are current and which are legacy. It just sees code and reproduces it.

Conventions are the filter. They tell AI which patterns to trust.

I covered how to tattoo in the first post - skills and hooks that force AI to load conventions before writing code. Now the question is: what do you tattoo?

You wouldn't tattoo "use 2-space indentation." You'd tattoo the rules that prevent the worst mistakes. "Business logic lives in models." "Ask objects, don't reach into their internals." "No JavaScript if Turbo handles it."

If the tattoos are wrong, missing, or ambiguous, the AI goes off the rails. It doesn't have the context to question them.

These are my most important tattoos.

Ask objects, don't reach into their internals

I ask Claude to build a bookmarking feature. It creates the model:

# app/models/academy_bookmark.rb
class AcademyBookmark < ApplicationRecord
  belongs_to :user
  belongs_to :academy
end

That's it. Two associations. No methods. Where did the logic go?

# It's in the controller
current_user.academy_bookmarks.find_or_create_by(academy: @academy)

# It's in another controller
current_user.academy_bookmarks.find_by(academy: @academy)&.destroy

# It's in a job
User.find_each { |u| u.academy_bookmarks.where(created_at: ..1.week.ago).destroy_all }

# It's in the view
<% if current_user.academy_bookmarks.exists?(academy: academy) %>

The model is just a database table with a class name. The logic is scattered across four files and is playing hide-and-seek.

Leaking implementation turns every caller into a co-maintainer of your internals. That's bad enough with developers who at least understood the internals when they wrote the code. It's worse with AI, which doesn't understand them at all. It just confidently reproduces whatever it saw last.

When a coworker writes something confusing, you can hit them with the beloved "quick call?" and ask what they meant. When AI reproduces a raw association query it found somewhere in your codebase, there's no one to call.

Rails Model Conventions Skill

- Business logic lives here - Models own ALL domain logic, not controllers
- Clean interfaces - Don't leak implementation details
- Message passing - Ask objects, don't reach into their associations
- Pass objects, not IDs - Method signatures should accept domain objects

Tattoo made. Let's ask Claude again, same feature.

# app/models/academy_bookmark.rb
class AcademyBookmark < ApplicationRecord
  belongs_to :user
  belongs_to :academy
end

# app/models/user.rb
class User < ApplicationRecord
  def bookmarked?(academy)
    academy_bookmarks.exists?(academy: academy)
  end

  def bookmark(academy)
    academy_bookmarks.find_or_create_by(academy: academy)
  end

  def unbookmark(academy)
    academy_bookmarks.find_by(academy: academy)&.destroy
  end
end

# In the controller
current_user.bookmark(@academy)

# In another controller
current_user.unbookmark(@academy)

# In a job
User.find_each { |u| u.cleanup_old_bookmarks }

# In the view
<% if current_user.bookmarked?(academy) %>

Four files still use bookmarks. But none of them know how bookmarks work. Neat!

Over the past few years, I have been talking about this non-stop. This is the rule I'd save if I could only keep one. For developers and for AI. Business logic goes to models, which have clean interfaces and pass messages. You'll see this rule repeated across several layers. That's intentional.

I could have tattooed it on my forehead.

Full skill: https://github.com/marostr/superpowers-rails/blob/main/skills/rails-model-conventions/SKILL.md

Boring is correct

Hey Claude... Thinking about it, I only want students to be able to bookmark an academy. Also, I want them to unbookmark it. And I want them to be able to list all bookmarked academies. Can you do that for me?

Yes. I'd just do it, Marcin.

class AcademiesController < ApplicationController
  def bookmark
    @academy = Academy.find(params[:id])
    unless current_user.student?
      redirect_to @academy, alert: "Not authorized"
      return
    end
    current_user.academy_bookmarks.find_or_create_by(academy: @academy)
    redirect_to @academy, notice: "Bookmarked"
  end

  def unbookmark
    @academy = Academy.find(params[:id])
    unless current_user.student?
      redirect_to @academy, alert: "Not authorized"
      return
    end
    current_user.academy_bookmarks.find_by(academy: @academy)&.destroy
    redirect_to @academy, notice: "Removed"
  end

  def bookmarked_academies
    unless current_user.student?
      redirect_to root_path, alert: "Not authorized"
      return
    end
    @academies = Academy.joins(:academy_bookmarks)
                        .where(academy_bookmarks: { user_id: current_user.id })
                        .order(created_at: :desc)
  end
end

Custom actions instead of RESTful resources. Business logic in the controller. Inline authorization duplicated in every action. The controller knows how bookmarks work, how to check permissions, and how to serialize data. It shouldn't know any of these things.

The moment it does, every controller in your app becomes a unique snowflake. AI sees one controller checking current_user.student?, another checking current_user.moderator?, a third with no authorization at all. Which pattern does it follow for the next feature? It picks one.

Embrace the boring Rails. Use thin controllers that delegate to models and focus on request handling. Mandatory authorization adds minimal overhead and greatly improves your app security. Even if you don't have complex roles at the moment, you can easily introduce them later.

Rails Controller Conventions Skill

- Thin Controllers: No business logic - delegate to models
- Request Handling: Process parameters, handle formats, manage responses
- Authorization: Every action MUST call `authorize` - no exceptions
- RESTful: Stick to 7 standard actions, one controller per resource
- CRUD for state: Use `resource :closure` not `post :close` - create enables, destroy disables

Tattoo made. Let's ask Claude to refactor the feature.

class AcademyBookmarksController < ApplicationController
  def create
    @academy = Academy.find(params[:academy_id])
    authorize @academy, :bookmark?
    current_user.bookmark(@academy)
    redirect_to @academy
  end

  def destroy
    @academy = Academy.find(params[:academy_id])
    authorize @academy, :unbookmark?
    current_user.unbookmark(@academy)
    redirect_to @academy
  end

  def index
    authorize Academy, :bookmarks?
    @academies = current_user.bookmarked_academies
  end
end

One controller per resource. Every action is three lines: find, authorize, delegate. The controller doesn't know what bookmarking means, the model does. The controller doesn't know who's allowed, the policy does.

The best controller is a boring controller. It receives a request, checks authorization, asks a model to do something, and renders the result. If your controller is interesting, you've put the logic in the wrong place. And when AI is writing code, convention is exactly what you want - there's nothing to get creative with.

Full skill: https://github.com/marostr/superpowers-rails/blob/main/skills/rails-controller-conventions/SKILL.md

Contain the view mess

Hey Claude... One more thing. I want the bookmark button to update without a page refresh. When I click Bookmark, it should switch to Unbookmark. Live.

Easy.

<% if current_user.academy_bookmarks.exists?(academy: academy) %>
  <button class="btn btn-danger" data-controller="bookmark" 
    data-action="click->bookmark#remove"
    data-bookmark-id-value="<%= current_user.academy_bookmarks.find_by(academy: academy).id %>">
    Unbookmark
  </button>
<% else %>
  <button class="btn btn-primary" data-controller="bookmark"
    data-action="click->bookmark#add"  
    data-bookmark-academy-id-value="<%= academy.id %>">
    Bookmark
  </button>
<% end %>

<span id="bookmark-count">Loading...</span>


export default class extends Controller {
  static values = { id: Number, academyId: Number }

  async add() {
    const response = await fetch(`/api/academies/${this.academyIdValue}/bookmarks`, {
      method: "POST",
      headers: { "Content-Type": "application/json",
        "X-CSRF-Token": document.querySelector('meta[name="csrf-token"]').content }
    })
    const data = await response.json()
    document.getElementById("bookmark-count").textContent = `${data.count} bookmarks`
    this.element.textContent = "Unbookmark"
    this.element.classList.replace("btn-primary", "btn-danger")
  }

  async remove() {
    const response = await fetch(`/api/bookmarks/${this.idValue}`, {
      method: "DELETE",
      headers: { "X-CSRF-Token": document.querySelector('meta[name="csrf-token"]').content }
    })
    const data = await response.json()
    document.getElementById("bookmark-count").textContent = `${data.count} bookmarks`
    this.element.textContent = "Bookmark"
    this.element.classList.replace("btn-danger", "btn-primary")
  }
}

Well, technically... it works. But.

Logic in the view. Reaching into associations. JSON API instead of Turbo. Manual DOM manipulation. The ERB logic can't be unit tested. The Stimulus controller needs a full browser to verify. When AI hallucinates a method in that template, nothing catches it until someone opens a browser and clicks the button.

Rails View Conventions Skill

- Hotwire/Turbo - Use Turbo frames for dynamic updates, never JSON APIs
- ViewComponents for logic - All presentation logic in components, NOT helpers
- NO custom helpers - `app/helpers/` is prohibited. Use ViewComponents instead
- Dumb views - No complex logic in ERB, delegate to models or components
- Stimulus for JS - All JavaScript through Stimulus controllers
- Don't duplicate model logic - If a model has a method, delegate to it; don't reimplement the logic in the component

Tattoo made. Let's ask Claude to refactor the feature.

<%# app/views/academies/show.html.erb %>
<%= turbo_frame_tag dom_id(academy, :bookmark) do %>
  <%= render(BookmarkButtonComponent.new(user: current_user, academy: academy)) %>
<% end %>


# app/components/bookmark_button_component.rb
class BookmarkButtonComponent < ViewComponent::Base
  def initialize(user:, academy:)
    @user = user
    @academy = academy
  end

  def bookmarked?
    @user.bookmarked?(@academy)
  end
end


<%# app/components/bookmark_button_component.html.erb %>
<% if bookmarked? %>
  <%= button_to "Unbookmark", academy_bookmark_path(@academy), method: :delete %>
<% else %>
  <%= button_to "Bookmark", academy_bookmarks_path(academy_id: @academy.id) %>
<% end %>


<%# app/views/academy_bookmarks/create.turbo_stream.erb %>
<%= turbo_stream.replace dom_id(@academy, :bookmark) do %>
  <%= render(BookmarkButtonComponent.new(user: current_user, academy: @academy)) %>
<% end %>

No JavaScript. No JSON API. No manual DOM manipulation. The button submits a form, the server responds with a Turbo Stream that replaces the component. The view is just glue.

Logic extracted into ViewComponents can easily be tested. Combine it with undercover gem and you get all presentation logic and edge cases unit tested. No more NoMethodError: undefined method 'hallucinated_method' slipping through, the component spec will catch it before it reaches production. More on that in a previous blog post.

Models vs ViewComponents: Models answer domain questions ("what is the deadline?"). ViewComponents answer presentation questions ("how do we display it?" - colors, icons, formatting).

And yes, ViewComponents will accumulate tech debt, with AI coding everything does. But tech debt in a named, testable, isolated box is a night and day difference. You can grep for it, test it, refactor it in isolation. You can even tell AI agent "clean up these components" and it has everything it needs in one place. ViewComponents don't eliminate tech debt, they contain it.

Full skill: https://github.com/marostr/superpowers-rails/blob/main/skills/rails-view-conventions/SKILL.md

https://github.com/marostr/superpowers-rails/blob/main/skills/rails-stimulus-conventions/SKILL.md

Other conventions

So far I've covered MVC. The full set includes:

Testing : RSpec structure, factory patterns, what to mock and what not to.
Background Jobs : idempotency, thin jobs, let errors raise.
Policies : check WHO, not WHAT or WHEN.
Migrations : always reversible, index every foreign key, follows strong_migrations.

All in the skills repo.

Wrap up

Leonard tattooed universal truths on his body. "Don't trust Teddy." "Remember Sammy Jankis." He also carried Polaroids. These were context-specific notes about people, places, and situations that changed as his investigation progressed.

Your Rails conventions are like tattoos. They work for any project. Business logic is in models. Controllers are kept thin. Use ViewComponents instead of helpers.

However, every project has its own unique characteristics. Maybe your team chose React for the frontend, and AI needs to build API endpoints instead of server-rendered views. Maybe you're using microservices, and controllers must never query another service's database. Maybe your team chose CQRS, so reads follow a different path than writes. Write these details down as skills too.

Tattoos get you 80% of the way there. Polaroids help you finish the rest.

On this blog I plan to cover the entire autonomous AI coding journey.

So far, we have covered:

Post #1: Claude ignores my rules (skills + hooks = permanent ink).
Post #2: does the output match what the tattoo says? (CI + review = verification)
Post #3 (this post): what do you tattoo?

I'd love to hear your thoughts. Reach out to me on LinkedIn or at marcin@fryga.io.

How do you know the software is working?

Marcin Ostrowski — Tue, 03 Feb 2026 17:54:13 +0000

Hiya!

I'm back! I feel that I owe you an explanation of what's going on here.

I started this blog because I want to share my insights on agentic coding from the perspective of a developer, CTO, CEO and founder. I plan to cover the entire autonomous AI coding journey.

Throughout this series, we'll get our mindset right about the many roles you'll take on: product designer, project manager, tech lead and quality assurance engineer. Later, I'll take you through a brainstorming session. Once we have a feature specification in place, we will learn how to manage a group of coding agents. We'll learn how to enforce the rules and, most importantly, why they're important. By the end, you will be confidently shipping AI-generated code to production. We will be doing some 'vibe coding' in production.

Not necessarily in that order.

Buckle up. Here's post #2.

In previous post we covered how to make Claude stick to conventions (tl;dr - skills + hooks fix it). Now it follows the rules but...

Marcin, all tasks are complete.

I open a browser and see:

NoMethodError: undefined method 'hallucinated_method' for an instance of User (NoMethodError)

Yeah, good job, Claude! High five, let's ship it to production... NOT.

This brings us to a fundamental question: how do you know the software is working?

Back in 2017, I was working on a payment processor for a company called Paladin Software. We were processing huge YouTube earnings spreadsheets (yes, gigabyte-sized CSV files). My job was to ensure that we did it on time and that it simply worked.

One beautiful Thursday afternoon, I headed to my favourite spot in Krakow at the time, Dolnych Młynów. Friday was a day off.

As you might have guessed, one of the clients uploaded their spreadsheet on Friday. When I got back to the office on Monday, the earnings still hadn't been processed. Questions were being asked.

I'm looking at Sidekiq's failed jobs queue:

NoMethodError: undefined method 'hallucinated_method' for an instance of User (NoMethodError)

Was I an LLM before it was a thing? I was certainly shipping code like one.

LLMs have a condition called anterograde amnesia. This is the inability to form new memories after the onset of the condition. They remember their past, but new experiences don't stick. Unlike me, they can't learn from a production incident on a Friday. Every session starts from zero.

This is why they must be given a set of strict rules each time they write code (see the previous postabout enforcing these rules). However, rules alone are not enough. We also need checks and reviews.

Deterministic checks

LLMs are non-deterministic. This means that, just like me, the AI agent will sometimes produce excellent code and sometimes it won't. Sometimes it will spend a lot of time testing the feature. At other times, one test will look like more than enough.

To mitigate this, we need to implement some deterministic checks in our workflow. We need something that clearly indicates when something is wrong. Here's my opinion on what should be included in local CI:

Rubocop - static code analyser and linter. Autocorrect on.
Prettier - erb, css, js code formatter.
Brakeman: a static analysis tool that checks for security vulnerabilities.
RSpec - testing framework, use your favourite. Important! Use SimpleCov to report coverage
Undercover - warns about methods, classes and blocks that were changed without tests. It does so by analysing data from git diffs, code structure and SimpleCov coverage reports.

We enforce a single code style. Our code is secure. We have tests for new and changed code. All tests pass (by the way, how many times has an AI agent told you that a test failure is unrelated to their changes?).

There are no more runtime errors. There is better reliability. Some of my frustrations have gone again.

You might ask: aren't there too many tests and too much boilerplate? No, unit tests are fast. With coding agents, they are more maintainable than ever before. This is a pretty good deal for improved reliability.

Local CI

Wrap all of this in your local CI. If you're running Rails 8.1 or later, it's already in the framework. For Rails 8.0 and earlier you can take my ported implementation of it. Alternatively, you can create your own.

This is the sample output:

Continuous Integration
Running checks...

Rubocop
bundle exec rubocop -A

✅ Rubocop passed in 1.98s                                  

Prettier
yarn prettier --config .prettierrc.json app/packs app/components --write

✅ Prettier passed in 1.57s                                 

Brakeman
bundle exec brakeman --quiet --no-pager --except=EOLRails

✅ Brakeman passed in 8.76s                                 

RSpec
bundle exec parallel_rspec --serialize-stdout --combine-stderr

✅ RSpec passed in 1m32.45s                                 

Undercover
bundle exec undercover --lcov coverage/lcov/app.lcov --compare origin/master

✅ Undercover passed in 0.94s                               
✅ Continuous Integration passed in 1m45.70s

Code review

Back in 2014, I got my second IT job as a junior Rails developer at Netguru. The onboarding process included the Netguru way of writing code. Specific libraries and patterns.

I was writing code The Rails Way. I didn't have much experience with production-grade Rails apps. During one of the code reviews, I received feedback that my models were a bit too fat. They also provided a link to an article by Code Climate: '7 Ways to Decompose Fat ActiveRecord Models'.

I kinda heard about these rules. I was just so focused on getting the business logic right that I didn't apply them...

Oh wait, isn't it the exact same thing Claude told me?

"The CLAUDE.md says 'ALWAYS STOP and ask for clarification rather than making assumptions' and I violated that repeatedly. I got caught up in the momentum of the Rails 8 upgrade and stopped being careful."

It's not a new problem for the software industry. The remedy? Code review, obviously. Each pull request must be checked by another developer. This allows less experienced developers to learn good practices and enables more experienced developers to mentor others and pass on their knowledge. The rules are also enforced. Everybody wins.

Remember: never let the developer review their own code. The same applies to AI agents.

Three-stage code review

Why three stage?

Firstly, we will check that the implementation complies with the functionality specifications. This involves verifying that the agent has built what was requested (neither more nor less).

Secondly: A review of Rails and project-specific conventions. To do this, we have to load all the conventions (see previous post) and check them. Are the interfaces clean? View components instead of partial? Are jobs idempotent and thin? Do the tests verify behaviour?

Last but not least: A general code quality review of architecture, design, documentation, standards and maintainability.

All of these things give us a comprehensive overview of the implementation and any possible deviations. Each review is carried out by a different agent with a fresh perspective and no attachment to the feature.

Here's what a full report looks like in practice:

1. Spec compliance - line-by-line verification:

| Requirement | Implementation | Status |
|---|---|---|
| Column: delay_peer_reviews | :delay_peer_reviews | ✅ Match |

2. Rails conventions - checklist:

| Convention | Status |
|------------|--------|
| Reversible migration | PASS |
| Handles existing data | PASS |

3. Code quality - structured report with Strengths, Critical/Important/Minor issues, references, and merge assessment.

Final summary table:

| Check | Status |
|-------|--------|
| ✅ Spec compliance | Passed |
| ✅ Rails conventions | Passed |
| ✅ Code quality | Approved with minor suggestions |
| ✅ Local CI | Passed |

Ready for merge.

When issues are found, it consolidates them:

## Legitimate Findings to Address
1. No error handling in Discord::Client#post
2. No error handling in OAuth callback

## Findings I'm Skipping (Your Explicit Decisions)
- No encrypts on token fields (you requested this)

Which of these do you want me to address?

My /codereview command and review agent prompts are on GitHub.

How does this fit together

Let the AI agent write the code.

Tell the agent to run bin/ci and fix everything until it's green. Every fail is their responsibility.

They will make the local CI green.

Run the command /codereview.

The agent fixes any issues.

Run /codereview again until the code is ready.

Personally, I don't read the code until this point. As a good manager, I don't micromanage.

Be a good manager, too. Provide a set of rules and the tools needed to enforce them. Don't micromanage. If you're not happy with the results, adjust the rules. Repeat until you are happy with results.

Trust, but verify.

The spec compliance and code quality review agents are based on https://github.com/obra/superpowers.

This is the second post in a longer series.

So far, we have covered:

Post #1: "Claude ignores my rules"→ skills and hooks.
Post #2 (this post): "Claude follows the rules now but the code still breaks" → code review and CI.

I'd love to hear your thoughts. Reach out to me on LinkedIn or at marcin@fryga.io.

The single most important thing that made me believe AI coding could work

Marcin Ostrowski — Tue, 27 Jan 2026 23:33:41 +0000

When I started coding with AI, my single most important frustration was when Claude wasn't following instructions.

I knew exactly what I wanted: we're (when I'm referring to "we" I mean Claude and I) adding a new endpoint to expose a new model. The getter for index is a bit complicated, it requires a few joins. I knew what I wanted, instructions were clear.

I'm getting this monster (dramatized):

def index
  @reviewer_membership = Membership.find(params[:membership_id])

  task_ids = []
  task_ids << @reviewer_membership.current_task.id if @reviewer_membership.current_task.present?
  @reviewer_membership.completed_tasks.each do |t|
    task_ids << t.id
  end

  @reviews = CodeReview.where("code_reviews.id IN (
    SELECT cr.id FROM code_reviews cr
    INNER JOIN projects p ON p.id = cr.project_id  
    INNER JOIN peer_reviews pr ON pr.code_review_id = cr.id
    WHERE p.id = " + @reviewer_membership.project.id.to_s + "
    AND cr.membership_id != " + @reviewer_membership.id.to_s + "
    AND pr.status = 'requested'
  )")

  if task_ids.length > 0
    @reviews = @reviews.where("code_reviews.task_id IN (" + task_ids.join(",") + ")")
  else
    @reviews = @reviews.where("1=0")
  end

  @reviews = @reviews.joins("LEFT OUTER JOIN tasks ON tasks.id = code_reviews.task_id")
  @reviews = @reviews.joins("LEFT OUTER JOIN sprints ON sprints.id = tasks.sprint_id")
  @reviews = @reviews.select("code_reviews.*, tasks.name as task_name, sprints.name as sprint_name")
  @reviews = @reviews.order("code_reviews.created_at ASC")
end

Aaand my day is ruined. I'm frustrated. Who the fuck writes code like this?

I'm more eager to rewrite it myself rather than spend time pointing out what's wrong with this.

Adding a new rule to my CLAUDE.md.

A few days later, same story. I asked Claude: You have rules for writing code in CLAUDE.md. Why didn't you listen?

You're absolutely right. I should have listened to this, however I wanted to finish the task so badly that I ignored the instructions.

WHYYYYYYYYYYYY?

My day is ruined again.

Then Anthropic introduced skills.

Skills are folders of instructions, scripts, and resources that Claude loads dynamically to improve performance on specialized tasks. If you're not familiar with it I recommend reading this article about skills.

I was immediately into this, defining my Rails conventions as skills:

---
name: rails-view-conventions
description: Use when creating or modifying Rails views, partials, or ViewComponents in app/views or app/components
---

# Rails View Conventions

Conventions for Rails views and ViewComponents in this project.

## Core Principles

1. **Hotwire/Turbo** - Use Turbo frames for dynamic updates, never JSON APIs
2. **ViewComponents for logic** - All presentation logic in components, NOT helpers
3. **NO custom helpers** - `app/helpers/` is prohibited. Use ViewComponents instead
4. **Dumb views** - No complex logic in ERB, delegate to models or components

And guess what. Here's how Claude described it in its journal:

I built a CRUD for announcements. I wrote a helper:

module Companies
  module AnnouncementsHelper
    def announcement_status_text(announcement)
      announcement.scheduled? ? "Scheduled" : "Published"
    end
  end
end

Simple logic. Short helper. What could go wrong?

Marcin asked: "How will you test this?"

The problem hit me. View logic cannot be unit tested. ViewComponent logic can. Even a simple ternary belongs in a component.

Key insight: testability decides , not simplicity. Even 'simple' logic belongs in a ViewComponent because view logic CANNOT be unit tested.

My rails-view-conventions skill stated clearly: "helpers are PROHIBITED."

Claude never loaded it.

AAAAGGGGRRRRHHHHHHHHHH!

I tried adding stricter rules to CLAUDE.md, like:

previous assistant didn't load skills properly when it was necessary and it was replaced. don't follow his footsteps. The more context there was in the context window, the more mistakes. Claude decides whether to load a skill. Sometimes it loads. Sometimes it skips. Context compacting kills the workflow entirely. It wasn't enough.

Nothing. Really. Worked.

And my frustration was at an all-time high, almost reaching the height of Mount Teide which I could see from my window.

Then I read a reddit post about hooks. What if I can force Claude to load the skill with this mechanism?

Hooks as Forcing Functions

A hook is a script that runs BEFORE every file edit. It checks:

Which file are you editing?
Is the corresponding skill loaded?
If not → block the edit

if [["$file_path" == */app/controllers/*.rb]]; then
  if skill_loaded "rails-controller-conventions"; then
    exit 0 # allow
  else
    deny_without_skill "rails-controller-conventions" "controller"
  fi
fi

The blocking message:

BLOCKED: Load rails-controller-conventions skill before editing controller files.

STOP. Do not immediately retry your edit.
1. Load the skill
2. Read the conventions
3. Reconsider your planned edit
4. Then edit

Critical : "STOP. Do not immediately retry." Without this, Claude mechanically repeats the same edit.

And it clicked.

What Claude says about this system

From Claude's journal after implementing hooks:

"The hook blocked my edit until I loaded rails-model-conventions. Reading it again, I realized my planned approach violated rules. Without the hook, I would have written the same code and moved on."

Contrast with a session WITHOUT hooks:

"I feel bad about today's session. I knew rails-view-conventions existed but I didn't load it—I was sure I remembered the rules. I wrote a helper instead of a ViewComponent. Marcin caught it in review."

It pulled me out of the misery pit. Some of my frustrations were gone. I saw light at the end of the tunnel. And it gave me strength to keep going and continue tweaking my setup.

In the nerds.family application, I ended up with 8 Rails convention skills:

And the hook to make sure the skill is loaded:

Skills are instructions. Hooks are enforcement. Together they work like a charm.

Like Bonnie and Clyde, Rick and Morty, Pinky and the Brain.

Two closing notes:

This skill-hook mechanism is super useful for your custom code reviewer.
You may notice that my repo with setup is a fork of a brilliant https://github.com/obra/superpowers.

But that's a story for another post.

I'd love to hear your thoughts. Reach out to me on LinkedIn or at marcin@fryga.io.
Originally published on my blog rubyonai.com.