Blog
-
Posted on
A runbook so I stop breaking my own blog
Publishing a post here is easy right up until you forget one small thing. The branch is master, not main, so a push to main runs clean and changes nothing. The commit has to land under the right name, and the account I push with keeps resetting to the wrong one. Post-date it by accident and the page just never shows up. Every one of those has bitten me, and not one of them throws an error.
So I wrote the whole thing down as a skill. Blog Publishing is a runbook the agent follows end to end. Clone the repo, write the post, humanize it, commit under the right identity, switch accounts, push to the right branch, wait for the build, then check the post is actually live. No step left to memory.
The point isn’t the steps I already know. It’s the session that doesn’t. Lose the chat that learned all this and the next one starts from zero, guessing at the branch name and the account and wondering why the post returns a 404. The runbook hands that context over cold.
What it pins down:
- The repo, the engine, and the branch. Master, in bold, so nobody pushes main again.
- The front-matter template and the tag format, so the post parses and sorts by date.
- The prose check. It runs the human-writing rules over the draft and fails on em-dashes and filler before anything ships.
- The commit identity, and a hard no on AI attribution.
- The account switch before the push, and back again after.
- The build poll and a live check, because “it pushed” and “it’s live” are not the same sentence.
There’s a checklist at the bottom that has to come back all green. Post named right. Prose clean. One commit, pushed to master under the right account, build finished, URL returns 200, account put back where it was. If a single line fails, the job isn’t done yet.
It won’t run without three other skills. Human-writing handles the voice. Clean-export keeps junk out of git, and the git standards shape the commit message. The runbook names all three up front so a fresh agent loads them before it touches anything.
Installs in one line, works across Claude Code, Cursor, Gemini and 40+ other agents:
npx skills add olakunlevpn/olakunlevpn-blog-publishingNow the process outlives the chat that figured it out. That’s the whole reason it exists.
-
Posted on
Make every docs page sound like one author
Open a docs site written by six people and you feel it before you can name it. One page opens with a chatty rhetorical question. The next drops a wall of abstract nouns on you. Code blocks show up cold, with no sentence telling you what you’re about to read. Half the caveats are yellow boxes, half are red, and they all wear a different little icon. Nothing’s wrong exactly. It just reads like a committee wrote it, and you stop trusting the page.
Docs Writing is an agent skill that fixes that. It holds the agent to one structure and one voice, so every page reads like the same careful person wrote it. It came out of reading a pile of well-run package docs and writing down what they actually do, page after page, with almost no deviation.
Here’s the rule that never breaks. Every code block gets exactly one sentence before it, and that sentence ends in a colon. Never a bare block. Never three paragraphs of setup first. On an intro page that sentence invites you in (“Here’s a quick example:”). On a reference page it states a requirement (“To associate media with a model, the model must implement this interface:”). Same rule, different warmth.
That warmth split is the part most people miss. Tone isn’t uniform across a good docs site, and it doesn’t change by topic. It changes by depth. Intro pages use contractions and the occasional rhetorical question. Reference pages go full forms only and flat imperative instructions. No questions. The reader who’s three pages deep wants the fact, not the small talk.
A few more things it pins down:
- One fixed page skeleton. Name, a one-line capability statement under ten words, an intro, an anchor list, then one concept per section in reading order. Order does the sequencing, so no numbered steps.
- Short sentences that state a fact and then unpack it in the next one. Nothing runs past about 25 words. “This package does X” is the workhorse opener.
- Caveats are sentences, not boxes. Name the edge case, state the consequence, link to the page that covers it in full. No colored admonition block, no warning icon.
- A shared phrase bank for installs, optional steps, and cross-references, so the whole site sounds like one hand wrote it instead of ten.
There’s a list of things it refuses to write, too. No “furthermore” or “moreover”. No “leverage”, no “seamless”. No marketing superlative standing in for a real capability statement. No single sentence hauling four subordinate clauses on its back.
It covers how the docs read, not how the code reads. The language skills handle the code. This one just makes sure a reader moving through your docs never trips over a change in voice.
Installs in one line, works across Claude Code, Cursor, Gemini and 40+ other agents:
npx skills add olakunlevpn/maylancer-docs-writingWrite every page like one person wrote the whole site. That’s the job.
Repo: maylancer-docs-writing
-
Posted on
Write code the framework would've written
You can usually tell when someone brought a habit from their last framework. There’s a hand-rolled router sitting next to the built-in one. Business logic lands in a spot the framework never puts it, so nobody thinks to look there. A library does a job the framework already ships a tool for. None of it is broken on day one. All of it is foreign, and the next person to read it pays for that.
Framework First is an agent skill that keeps code native to whatever it’s built on. Laravel, XenForo, Django, Rails, WordPress, Spring, doesn’t matter. Every framework has a grain. You work with it, not against it.
Six rules:
- Identify the framework and version first. Idioms shift between versions. You can’t follow conventions you haven’t pinned down.
- Follow its conventions and architecture exactly. Put logic where the framework expects it. Use its generators. Conventions are shared memory, and breaking them makes everyone relearn your corner of the codebase.
- Native solutions first. Most frameworks already ship an ORM, a router, validation, queues, auth. Reach for a dependency only when there’s genuinely no native answer.
- Stay consistent with the project. Match the code that’s already there, not the code you’d write from scratch. Consistency beats your personal taste.
- Never mix in patterns from other frameworks. The way Rails does a thing isn’t how Laravel does it. Don’t carry one framework’s habits into another.
- Aim for code a senior of that framework would recognize. Boring and idiomatic beats clever and foreign every time.
There’s one test the skill runs every change through. Would an experienced developer of this exact framework, at this version, read it and think “yeah, that’s how you do it here”? If they’d pause or ask why, it isn’t idiomatic yet. Fix it before it becomes the pattern the next person copies.
The security angle matters too. Use the framework’s own escaping, its CSRF protection, its query builder, its auth guards. Rolling your own around a framework that already solved the problem is how holes get in.
Installs in one line, works across Claude Code, Cursor, Gemini and 40+ other agents:
npx skills add olakunlevpn/olakunlevpn-framework-firstWrite code that looks like the framework wrote it. That’s the whole job.
-
Posted on
Stop fixing bugs straight on the server
Everyone’s done it. Production goes down, you SSH into the box, edit the file, the site comes back, and you move on. It worked. That’s the trap. A fix that lives only on a server is already scheduled for deletion. The next deploy overwrites it, the bug comes back, and nobody remembers why it was ever fine. Or worse, the server drifts so far from the repo that you can’t reproduce anything locally anymore.
Local Source of Truth is a small agent skill that closes that door. One idea, five rules. The local development workspace is the only place permanent code lives. The server runs that code. It doesn’t get to author it.
The short version:
- The local workspace is canonical. If a change isn’t in the repo, it doesn’t exist. It’s a liability waiting for the next deploy to wipe it.
- Servers verify, they don’t author. Read the logs, reproduce the bug. Fine. Editing app code on the box and leaving it there? No.
- Permanent changes go through the pipeline. Ship the way the project ships. Git, a build step, a version bump, a zip upload. No side doors.
- Temporary diagnostics are fine, permanent hacks aren’t. A scratch script to inspect state is fair game while you’re digging. Tear it down when you’re done.
- No permanent server-side hacks. Ever. The running server always traces back to a commit you can name.
There’s an escape hatch for the 2am outage, because sometimes the fix has to land right now. It’s a bridge, not a fix. Patch the server to stop the bleeding, write down exactly what you changed, fix it properly in the local workspace the same day, redeploy, then revert the manual change so the box matches the repo again. A live patch that never makes it back to the repo isn’t a fix. It’s a landmine with your name on it.
One line to install, and it runs across Claude Code, Cursor, Gemini and 40+ other agents:
npx skills add olakunlevpn/olakunlevpn-local-source-of-truthThe server runs your code. It doesn’t write it.
-
Posted on
Ten rules for software that doesn't fall over
Most apps don’t break because of a bug. They break because they grew, and the design never planned for it. The query that was fine with ten rows crawls at ten million. The email that sent inline now makes every user wait. The controller that did one job quietly took on five. I kept hitting the same failures across projects, so I wrote them down and turned them into an agent skill.
Scaling Discipline is ten principles for building systems that stay predictable under load. It’s language-agnostic on purpose. A queue is a queue whether it runs on Redis, SQS or Kafka. An N+1 query is an N+1 query in any ORM. The rules hold in Node, Python, Go, PHP, Ruby, whatever you reach for.
The short version:
- Dependencies aren’t productivity. Master patterns, not packages.
- The data layer is a bottleneck, not a bucket. Index, cache, kill N+1, profile before you guess.
- Queues are oxygen. If it can wait, make it async.
- Events decouple logic. Emit events, isolate side effects.
- Telemetry is your radar. Read the logs on a normal day, not during a fire.
- Scalability isn’t speed. Fast is a snapshot. Scalable is consistency under load you didn’t predict.
- Design systems, not code. Ask where a feature belongs before asking how to build it.
- Mindset beats tools. A bigger server postpones a design problem, it doesn’t fix it.
- Reuse before you build. Check what already exists, follow DRY, and don’t over-engineer the other way.
- Verify. Trust nothing, prove everything, and don’t call it done below 0.9 confidence.
That last one is the whole point. Systems fail less from missing code than from a false belief that they’re finished. So the skill makes the agent trace the real execution path and confirm every piece is wired before it signs off on anything.
It installs in one line and runs across Claude Code, Cursor, Gemini and 40+ other agents:
npx skills add olakunlevpn/olakunlevpn-scaling-disciplineYou can’t optimize your way to scale. You design for it, then you verify it.
-
Posted on
Making AI write like a person
You can feel AI writing before you can name it. The em-dashes. The “delve” and “seamless” and “it’s worth noting.” Lists always in threes. Every sentence the same middling length. Human Writing strips all of it.
The skill is a checklist built from the actual fingerprints of machine text. It kills the banned words, breaks the triads, varies sentence length on purpose, cuts the throat-clearing first line, and puts contractions and a bit of opinion back in. Then it runs a six-point pass before handing the draft over.
Every post on this blog went through it, including this one. That’s the test I care about. If the skill can’t make my own writing sound like me, it isn’t done.
npx skills add olakunlevpn/olakunlevpn-human-writing -
Posted on
One skill that gates done on evidence
I had two skills that belonged together. One enumerates what a build is supposed to do and audits it from seven angles. One proves a claim against real code before anyone touches it. Meta-Verify runs them as a single loop.
Phase one builds the checklist and audits it. Phase two takes each item and proves it. A pass with no trace to code gets downgraded to unverified. A failure becomes a real investigation with an evidence ledger, not a guess. The run ends in a report with a confidence score, and any item still unproven means the verdict is not done.
It’s the shortest honest answer to “is this finished?” Enumerate, prove each item, report. Nothing ships on assumption.
npx skills add olakunlevpn/olakunlevpn-meta-verifyRepo: olakunlevpn-meta-verify
-
Posted on
Prove the bug before you touch the code
Most bad fixes come from the same move. See a symptom, change something nearby, hope. Root-Cause Discipline stops that move cold.
Before any edit, it makes the agent earn the right to edit. Understand what the code is supposed to do. Reproduce the failure. Trace the symptom to the exact line and prove the mechanism, not a hunch about it. Map every caller and consumer the change could touch. Then, and only then, make the smallest change that kills the cause. All of it goes into an evidence ledger, and a confidence gate blocks the edit until the proof holds. Under threshold, it stops and asks instead of guessing.
I built this because a fix aimed at a symptom doesn’t remove a bug. It relocates it. This is the “before the change” half of my workflow, and it hands off to the verification skill once the fix is in.
npx skills add olakunlevpn/olakunlevpn-root-cause-skills -
Posted on
Seven reviewers on your build, none of them optimists
“It’s done” is the most expensive phrase in software. Meta-Cognitive Verification exists to test it.
After a build, the skill runs the whole thing past seven perspectives: QA, Product, Project Manager, Tech Lead, Business Analyst, DevOps, and Stakeholder. Each one wants evidence. It traces data contracts field by field, so the camelCase the frontend reads actually matches the snake_case the backend sends. It hunts for dummy data, debug logs, half-built pages, missing auth. Nothing passes on a vibe.
The output is a report with a confidence score and a verdict, not a thumbs up. Below the bar, it tells you what’s blocking and refuses to call the work done.
This is the “after the change” half of how I work. The partner to it, root-cause, runs before the change. Both go across 40+ agents.
npx skills add olakunlevpn/olakunlevpn-meta-cognitive-verification -
Posted on
No page gets built without a design
Here’s a failure I kept hitting. The agent invents a page from scratch, fills it with dummy data, and now the frontend matches neither the design nor the backend. Design-First Frontend Skills makes that impossible.
The rule is blunt. Every page starts from a pre-built design folder. The agent checks for the design first and never assumes one doesn’t exist. Backend data is the source of truth, so dummy data gets pulled out and real data wired in. What you end up with is one consistent look across the whole app, not a dozen improvised pages that almost match.
It’s the skill I reach for whenever a project has a real design system to honor. Runs on Claude Code, Cursor, Cline, Gemini and 40+ agents.
npx skills add olakunlevpn/olakunlevpn-frontend-first-skills -
Posted on
React standards so components stop fighting each other
React gives you ten ways to do everything, which is fine until a team uses all ten. State handled differently in every component, effects doing too much, types loosened to make an error go quiet. React & Next.js Skills settles those arguments before they start.
It covers components, hooks, state, testing, performance, TypeScript patterns, server components, and project structure. The agent writes to those conventions, so a component I open next month reads like the one sitting next to it. That’s consistency I don’t have to police in review.
It’s aimed at real React and Next work, not toy examples, and it runs across the AI agents I use.
npx skills add olakunlevpn/olakunlevpn-react-skillsRepo: olakunlevpn-react-skills
-
Posted on
Deploys I don't have to think about
The scariest part of a small project is usually the deploy. A manual sequence, a step you forget, a site down while you try to remember it. Deployment Skills turns that into a script.
It generates the deploy scripts for Laravel and Inertia apps: pull, install, migrate, cache, restart, in the right order, with logging and error handling so a failure tells you where it stopped instead of leaving you guessing. It sets up the cron for auto-deploy too. The sequence gets written once and runs the same way every time.
Predictable beats clever here. I want deploys boring, and this makes them boring.
Runs across Claude Code, Cursor, Cline, Gemini and 40+ agents.
npx skills add olakunlevpn/olakunlevpn-deployment-skills -
Posted on
Commit messages that don't make me wince
“fix stuff.” “update files.” “changes.” Open an old repo and the log tells you nothing. Git Workflow Skills is my answer to that.
It holds the agent to a real standard: Conventional Commits, a 50 character subject, the 72 rule for the body, imperative mood, one logical change per commit. No sneaking two changes into a message with an “and.” And no AI attribution, not once. My commits are mine.
Small rules, but they add up. A clean history is the difference between
git loganswering your question andgit logwasting your afternoon.It triggers on any git activity and runs across the same 40+ agents as the rest of the set.
npx skills add olakunlevpn/olakunlevpn-git-skillsRepo: olakunlevpn-git-skills
-
Posted on
Filament v5, built the same way every time
Filament is fast to build with and easy to build inconsistently. Two developers, two ways to wire a form, and the panel starts to feel stitched together. This skill pins down one way.
Filament PHP v5 Skills covers 18 areas: resources, forms, tables, infolists, actions, widgets, panels, relation managers, multi-tenancy, testing, plugins. When the agent builds a resource, it follows the same structure as the last one. CRUD pages line up. Destructive actions get a confirmation step. The admin stops looking like a patchwork of whoever touched it last.
I lean on Filament for the admin side of most projects, so consistency there pays back fast. Less to explain, less to fix, and no nasty surprise when I open a resource I wrote three months ago.
Works with Claude Code, Cursor, Cline, Gemini and 40+ agents.
npx skills add olakunlevpn/olakunlevpn-filament-skills -
Posted on
My Laravel standards, written down so the agent follows them
Every Laravel project drifts. One controller does too much, a model grows a tail of helper methods, validation ends up living in three places. I got tired of correcting the same things, so I put my standards in a skill and let the agent enforce them.
Laravel Coding Standards covers the parts that rot first: models, controllers, services, actions, traits, tests, config, exceptions, providers, package structure. These aren’t opinions for their own sake. They’re the conventions that keep a codebase readable at month six, when the person reading it isn’t you.
The agent applies them while it writes, not after. So the review is shorter, because the code turns up already in the shape I’d have asked for.
It’s built for production apps and packages, and it runs across the AI agents I use day to day.
npx skills add olakunlevpn/olakunlevpn-laravel-skills -
Posted on
The skill that keeps junk out of my commits
I’ve committed a .env by accident. Once is enough. Clean Export Skills is the guardrail I wrote so it doesn’t happen again.
Before any git add or zip, it scans what’s about to go in. Source files pass. Agent configs, plan files, AI rule files, stray markdown, secrets, those get stopped. It keeps a .exclude list so the decision is remembered, not re-argued every time. And it never runs
git add ., which is where most accidents start.When it hits a file it doesn’t recognize, it doesn’t guess. It flags the file and asks. That one habit has caught things I’d have committed on autopilot.
Zips get the same treatment. Real folder structure, project files only, nothing from the agent’s workspace riding along.
It works with Claude Code, Cursor, Cline, Gemini and 40+ other agents.
npx skills add olakunlevpn/olakunlevpn-clean-export-skills -
Posted on
Making AI output read like a real document
Ask an AI for a status report or a plan and you usually get a wall of markdown. Fine to read, ugly to share. I wanted the output to look like something a person laid out, so I built a small CSS library and a set of agent skills around it.
That’s Artifact Skills. A light stylesheet plus skills that tell the agent how to use it: reports, plans, reviews, explainers, diagrams, slide decks. The agent writes one self-contained HTML file with a real color system, real typography, and components that fit together. No framework, no build step, no calls out to a CDN.
The point isn’t decoration. A plan with a proper risk table and a milestone list gets read differently than the same words in a flat bullet dump. Structure carries meaning. When the artifact looks finished, people treat the thinking behind it as finished too.
It runs across Claude Code, Cursor, Cline, Gemini and the other agents that read skills, so I’m not rewriting the same styling notes in every tool.
npx skills add olakunlevpn/olakunlevpn-artifact-skills -
Posted on
Welcome to the blog
New blog, first post. Short one.
I kept telling myself I’d write things down. The auth bug that took a whole evening, the deploy step I always forget, the Laravel trick I rediscover every few months and then lose again. I never did. So here’s the fix: a place to put it, public, where forgetting costs more.
What goes here
Working notes, mostly. Laravel and PHP, some JavaScript and Vue, a bit of React, and whatever AWS throws at me that week. When something breaks and I figure out why, that’s a post. When a pattern finally clicks, that’s a post too.
No filler. If it didn’t save me time, it doesn’t go up.
How it’s built
This site runs on Jekyll with the Libretto theme, hosted free on GitHub Pages. The RSS feed at /feed.xml updates on every build, and a small GitHub Action pulls the latest posts straight onto my profile README. Write once, it shows up in both places. That’s the kind of thing worth writing down.
More soon.
subscribe via RSS