DEV Community: Nasrul Hazim Bin Mohamad

Here's How I Build Products Without Losing My Mind.

Nasrul Hazim Bin Mohamad — Tue, 07 Apr 2026 00:58:17 +0000

I've been building software for over a decade.

Laravel trainer. Package author. Solution architect. Juggling multiple products at once — G8Stack, G8ID, Nadi, GatherHub, Warung POS, and more.

And for a long time, I had the same problem every developer has.

I'd jump into code before the thinking was done.

Half-built features. Scope creep. Vague requirements that sounded clear in my head but turned into a mess the moment I opened my editor. I wasn't building products — I was chasing ideas.

Something had to change.

The Shift: Blueprint Before Code

The turning point wasn't a new framework or a new tool. It was a mindset shift.

Build the blueprint first. Code later.

Sounds obvious. But most of us don't actually do it. We treat planning as a formality — something we rush through so we can get to the "real" work.

I stopped doing that. And everything changed.

Here's the workflow I landed on.

Phase 1 — Idea to Clear Direction

Every product starts with a brainstorm. No filters. No structure. Just dumping everything out of my head.

But I don't do this alone.

I bring Claude into the conversation early — not to generate ideas, but to stress-test them. I'll describe what I'm thinking and let Claude push back: Who exactly is this for? What happens if the user does X? Have you considered this edge case?

It's like having a thinking partner available at 2am who never gets tired of your half-formed ideas and isn't afraid to point out the holes.

By the end of this phase I can answer clearly: what exactly am I building, for who, and why does it matter? And more importantly — what are the constraints, the risks, and the things I hadn't thought of yet.

Only then do I move forward.

This phase sounds simple. But skipping it — or rushing through it alone — is the number one reason products stall. You can't build what you haven't clearly thought through.

Phase 2 — Name It. Own the Domain.

Before any file is created, before any command is run — I name the project.

This sounds like a small thing. It isn't.

The name shapes everything: the repo, the folder structure, the domain, the brand, the way you talk about it to clients. Getting it wrong early means renaming things later, and renaming things is painful.

So I take the time. I discuss naming options with Claude — checking for clarity, memorability, and whether it communicates what the product actually does. Then I check domain availability immediately. If the domain isn't available, I keep going until I find a name where both the name and the domain work together.

Only when the name is locked and the domain is secured do I move to the next step.

Phase 3 — Kickoff

With a name in hand, I scaffold the project using kickoff.my — my own tool for getting Laravel projects started with the right foundation.

The project name drives everything here: folder name, repo name, namespace, environment config. It all flows from that one decision made in Phase 2.

Phase 4 — The CLAUDE.md (The Blueprint)

Now I write the CLAUDE.md — inside the project that was just created.

Think of it as a structured brief — not for a client, but for Claude Code (my AI coding assistant). It covers what I'm building, the tech stack, the architecture decisions, naming conventions, and phase-by-phase plan.

Hard cap: 40KB. That constraint keeps me honest. If I can't describe the product in 40KB of structured markdown, I probably don't understand it well enough yet.

Everything that doesn't fit goes into a REFERENCE.md — detailed data models, edge cases, compliance requirements, anything I need visible but not in the main file.

Between the two files, Claude Code has everything it needs to understand the project cold — without me explaining context every single session.

From there, Claude Code reads the blueprint and fills in the docs/ folder — expanding on specs, documenting the data model, breaking down each phase in detail. Full visibility. Nothing hidden.

Phase 5 — GitHub Setup (Before a Single Line of App Code)

This is the part most developers skip entirely.

Before I write any application code, Claude Code creates the GitHub repo and auto-generates Issues based on the phases in my plan. Milestones. Labels. Everything organised.

Now I have a project board that reflects the actual plan — not something I backfilled after the fact.

This alone has saved me hours of context-switching and "wait, what was I building next?"

Phase 6 — Build Phase by Phase

Only now do I start coding.

Each phase has defined deliverables. Each GitHub Issue maps to a real milestone. Claude Code works within the documented context — so there's no guesswork, no AI hallucinations about what I "probably meant", and far fewer errors.

When I finish a phase, I close the issues, review what changed, and update the docs before moving to the next one.

It feels slow at first. It isn't. It's the fastest way I've ever shipped a product that actually works the way I intended.

Bonus: Agent Skills

On top of all this, I maintain a personal library of Claude Code skills — reusable patterns that encode my way of doing things.

Pest testing. Livewire/Flux patterns. API lifecycle. CI/CD pipelines. Package development. Each skill is a structured file that tells Claude Code exactly how I want a thing done.

If you're curious: github.com/nasrulhazim/agent-skills

The Real Lesson

The reason this workflow works isn't Claude. It's not the tools. It's the constraint of having to think clearly before building.

When you write a proper blueprint, you catch the problems that would have killed your project at phase 3. You make architecture decisions consciously instead of by accident. You know — before you write a line of code — what done looks like.

AI just makes the execution faster. The clarity still has to come from you.

Want to Learn This or Work With Me?

If you're a developer or founder who wants to build smarter — not just faster — here's how we can work together:

→ Learn: I run Laravel training sessions covering architecture, clean code patterns, and production-grade development. Reach out to me and ask about upcoming sessions or custom workshops for your team.

→ Hire: Need a solution architect who can take your idea from zero to structured, shippable product? That's exactly what I do. See what I've built at nasrulhazim.com/projects and reach out at nasrulhazim.com.

→ Follow along: I document the journey — products, patterns, and lessons learned — right here on dev.to. Hit follow so you don't miss the next post.

Blueprint first, code later. Build the map before you start the journey.

Laravel Artisan Runner — Run Artisan Commands from the Browser, Safely

Nasrul Hazim Bin Mohamad — Mon, 30 Mar 2026 08:49:32 +0000

The Problem

Every Laravel developer knows the drill. Someone on the team needs to clear the cache, run migrations, or trigger a seeder — but they don't have SSH access. So they ping you on Slack. You SSH in, run the command, confirm the output, and go back to what you were doing.

Multiply that by a dozen teammates and a handful of environments, and it becomes a real productivity drain.

I built Laravel Artisan Runner to solve this. It's a package that lets you expose pre-approved Artisan commands through a clean, Livewire-powered web interface — with full audit logging, queued execution, and notifications baked in.

What It Does

At its core, Artisan Runner gives you three things:

A web UI to browse, configure, and execute Artisan commands
An allowlist system so only approved commands can be run
A complete audit trail of every execution — who ran what, when, with what parameters, and what happened

Every command runs through a queued job. No blocking HTTP requests. No timeouts on long-running migrations.

Installation

composer require cleaniquecoders/laravel-artisan-runner

php artisan artisan-runner:install

php artisan migrate

That's it. Three commands and you're up.

The install command publishes the config, migrations, views, and assets in one shot. Then drop the component into any Blade view:

<livewire:artisan-runner::command-runner />

The default route is /artisan-runner, protected by web and auth middleware.

Configuration: Three Discovery Modes

The package supports three ways to determine which commands are available.

Manual (Default — Safest)

Only commands you explicitly list in allowed_commands are available:

// config/artisan-runner.php

'discovery_mode' => 'manual',

'allowed_commands' => [
    'cache:clear' => [
        'label'       => 'Clear Cache',
        'description' => 'Flush the application cache.',
        'group'       => 'Cache',
        'parameters'  => [],
    ],
    'migrate' => [
        'label'       => 'Run Migrations',
        'description' => 'Run database migrations.',
        'group'       => 'Database',
        'parameters'  => [
            ['name' => '--force', 'type' => 'boolean', 'label' => 'Force (production)', 'default' => false],
            ['name' => '--seed',  'type' => 'boolean', 'label' => 'Run seeders',        'default' => false],
        ],
    ],
],

Auto Discovery

Surfaces all Artisan commands minus your exclusion list:

'discovery_mode' => 'auto',

'excluded_commands'   => ['down', 'up', 'serve', 'tinker', 'db:wipe'],
'excluded_namespaces' => ['make', 'schedule', 'queue', 'stub'],

Good for development. I wouldn't recommend this for production without a tight exclusion list.

Selection

A middle ground — only explicitly included commands are discovered, then merged with your manual entries:

'discovery_mode' => 'selection',
'included_commands' => ['cache:clear', 'migrate', 'config:cache', 'route:cache'],

There's also a CLI tool to help you build your command list:

php artisan artisan-runner:discover
php artisan artisan-runner:discover --output=json
php artisan artisan-runner:discover --dry-run

How It Works Under the Hood

The architecture follows a clean action-based pattern:

User clicks "Run"
  → Livewire CommandRunner component
    → RunCommandAction (validates against allowlist)
      → Dispatches RunArtisanCommandJob to queue
        → Job calls Artisan::call()
          → Output + exit code saved to CommandLog
            → Notification dispatched (if enabled)

The Audit Log

Every execution creates a CommandLog record:

CommandLog::create([
    'uuid'       => Str::uuid(),
    'command'     => 'migrate',
    'parameters'  => ['--force' => true],
    'status'      => 'pending',  // pending → running → completed/failed
    'ran_by_type' => 'App\Models\User',
    'ran_by_id'   => 42,
]);

The status lifecycle is simple:

pending → running → completed
                  → failed

Each log tracks start time, finish time, full output, and exit code. The Livewire component polls every 5 seconds, so you see status updates in real time.

Query your logs programmatically:

use CleaniqueCoders\ArtisanRunner\Models\CommandLog;
use CleaniqueCoders\ArtisanRunner\Enums\CommandStatus;

// Recent failures
CommandLog::where('status', CommandStatus::Failed)->recent(7)->get();

// Who's been running commands
CommandLog::with('ranBy')->latest()->take(20)->get();

Smart Parameter Rendering

The UI automatically renders the right input type based on parameter definitions:

Arguments (positional) → text inputs
Boolean flags (--force, --seed) → checkboxes
Numeric options (--step=5) → number inputs
String options → text inputs

One gotcha I hit early: Livewire doesn't play well with wire:model bindings that have -- prefixes (like parameterValues.--force). The fix was to use index-based keys internally and map them back to parameter names when dispatching. Small detail, but it would've bitten anyone building this.

Notifications

When a command completes or fails, the package can notify a configurable user via any Laravel notification channel:

'notification' => [
    'enabled'  => true,
    'channels' => ['database', 'mail'],
    'notifiable' => [
        'model'      => \App\Models\User::class,
        'identifier' => 'email',
        'value'      => env('ARTISAN_RUNNER_NOTIFY_EMAIL', 'ops@yourdomain.com'),
    ],
],

The notification includes the command name, status, exit code, and execution duration. Wire it up to Slack, Discord, or whatever your team uses.

Security: Built Paranoid by Default

This is a package that runs shell commands from a web interface. Security isn't optional.

Allowlist-first. The default mode is manual. Nothing runs unless you explicitly approve it.

Auth-protected routes. Default middleware is ['web', 'auth']. Tighten it further:

'route' => [
    'middleware' => ['web', 'auth', 'role:admin'],
],

Dangerous commands pre-excluded. Even in auto-discovery mode, commands like down, db:wipe, migrate:fresh, tinker, and serve are excluded out of the box.

Full audit trail. Every execution is logged with who triggered it (polymorphic relation — works with any model, not just User).

No retries. Failed jobs stay failed. You investigate, you don't auto-retry migrate --force in production.

Timeout protection. Commands are killed after 300 seconds. No runaway processes.

Livewire 3 + 4 Compatibility

The package supports both Livewire 3 and 4. The service provider handles registration automatically:

if (method_exists(Livewire::class, 'addNamespace')) {
    // Livewire 4
    Livewire::addNamespace('artisan-runner', __DIR__ . '/Livewire');
} else {
    // Livewire 3
    Livewire::component('artisan-runner::command-runner', CommandRunner::class);
}

No feature flags. No config toggles. It just works.

When Should You Use This?

Great fit:

Admin dashboards where non-technical staff need to trigger maintenance tasks
Deployment pipelines where you want a "run post-deploy tasks" button
Multi-tenant apps with per-tenant cache clearing or migrations
Teams where not everyone has SSH access but everyone needs to clear caches

Not ideal for:

Interactive commands (tinker, make:model)
Long-running batch jobs that exceed 5 minutes
Anything that needs real-time streaming output (it captures output after completion)

Stack Compatibility

	Supported
PHP	8.3+
Laravel	11, 12, 13
Livewire	3, 4
Tailwind	4 (via CDN)

Try It Out

composer require cleaniquecoders/laravel-artisan-runner
php artisan artisan-runner:install
php artisan migrate
php artisan queue:work

Then visit /artisan-runner in your browser.

Source code: github.com/cleaniquecoders/laravel-artisan-runner

I'm Nasrul Hazim, a software engineer from Malaysia building Laravel packages and tools. Find more of my work at nasrulhazim.com.

I Built a Claude Code Skill to Sync CLAUDE.md Across 12+ Laravel Projects

Nasrul Hazim Bin Mohamad — Sat, 14 Mar 2026 00:06:27 +0000

You know that feeling when you update something important in one place, then you realise — oh no, I need to propagate this to like 10 other projects?

Yeah. That was me last week.

A Bit of Background

I maintain a Laravel kickstart project called Kickoff. Every Laravel project I start — personal, client, internal — starts from this base. It contains my opinionated project structure, conventions, Docker setup, and one particularly important file:

stubs/CLAUDE.md

If you're using Claude Code, this file matters a lot. It's the instruction manual Claude reads before it touches your codebase. Stack, conventions, patterns, boundaries — it's all there. Without it, Claude guesses. With it, Claude codes like it already knows your project.

Problem: I have multiple projects built on top of Kickoff. Every time I update stubs/CLAUDE.md in Kickoff, those changes need to flow downstream. Into every project. One by one.

I did it manually twice. Third time, I refused.

The Boring Fix vs The Right Fix

The boring fix: write a bash script that loops through directories and overwrites CLAUDE.md. Quick. Fragile. Dumb.

The problem with dumb scripts? They don't understand context. My projects aren't identical. Each one has project-specific sections in CLAUDE.md — custom domain notes, environment variables, Docker services, known issues, client-specific conventions. A dumb overwrite nukes all of that.

What I actually need is something that can:

Scan a parent directory for projects
Figure out which ones are based on Kickoff
Diff their CLAUDE.md against the latest from Kickoff
Merge the changes without destroying project-specific content

That's not a bash script. That's judgment. And Claude Code is actually good at that — if you give it the right structure upfront.

So I built a Claude Code skill.

What's a Claude Code Skill?

A skill in Claude Code is a SKILL.md file that provides Claude with structured context, instructions, and a defined workflow for a specific repeatable task.

Think of it like this — instead of you typing a long prompt every single time, you encode the decision tree once into a skill file. Claude reads it, understands what it's supposed to do, and executes consistently every time.

I've been building these skills in my own repo: nasrulhazim/agent-skills. I already have skills for testing, Livewire components, API lifecycle, CI/CD pipelines, and more. This new one — project-sync — joins the collection.

A skill is just a directory:

skills/project-sync/
├── SKILL.md                              # The instructions
└── references/
    ├── merge-algorithm.md                # How to merge sections
    ├── section-classification.md         # What's shared vs project-specific
    ├── detection-markers.md              # How to identify Kickoff projects
    └── registry-schema.md               # Registry file format

No runtime. No API. No build step. Just markdown that Claude reads and follows.

What the Skill Actually Does

Here's the workflow, broken into commands:

Scan: Find All Kickoff Projects

/project-sync scan ~/Projects --since=2025

Claude scans the directory tree, finds Laravel projects (checks for artisan + composer.json), then verifies Kickoff-specific markers:

app/Models/Base.php exists
composer.json requires cleaniquecoders/traitify
support/helpers.php in autoload
CLAUDE.md mentions "Kickoff"

At least one marker must match. This avoids false positives from vanilla Laravel projects.

Output:

Scanned: ~/Projects
Found: 12 Kickoff Laravel projects (filtered: --since=2025)

~/Projects/2025/ — 8 projects
  ✓ project-alpha          CLAUDE.md: 18.2 KB
  ✓ project-beta           CLAUDE.md: 22.1 KB
  ✗ project-gamma          No CLAUDE.md

~/Projects/2026/ — 4 projects
  ✓ project-delta          CLAUDE.md: 19.8 KB
  ...

It can also scan a GitHub account without cloning anything:

/project-sync scan gh:cleaniquecoders --since=2025

Everything gets saved to a registry at ~/.claude/projects/.project-sync.json — persistent across Claude Code sessions.

Status: What Needs Updating?

/project-sync status

Source: kickoff/stubs/CLAUDE.md (fetched from GitHub)

Project                 Status      Size     Last Synced
─────────────────────────────────────────────────────────
project-alpha           ✓ current   18.2 KB  2026-03-10
project-beta            ✗ outdated  22.1 KB  2026-02-15
project-gamma           ⚠ missing   —        never
project-delta           ✗ outdated  19.8 KB  2026-03-01

Summary: 1 current, 2 outdated, 1 missing CLAUDE.md

Instantly see which projects have drifted.

Diff: Preview Before You Touch Anything

/project-sync diff project-beta

Dry-run merge. No files changed. Just shows what would happen:

## Sections to UPDATE (from source):
  - Architecture & Key Concepts > Models - CRITICAL  [changed]
  - Architecture & Key Concepts > Enums  [changed]
  - Livewire Patterns > Toast Notifications  [changed]

## Sections to MERGE (combine items):
  - DO list: +2 new items from source, 3 project-only preserved
  - DON'T list: +1 new item from source, 1 project-only preserved

## Sections PRESERVED (project-specific):
  - Project Overview
  - Common Commands
  - Packages
  - Docker Services
  - Environment Variables

No surprises. You see exactly what gets replaced, what gets merged, and what stays untouched.

Update: Do the Thing

/project-sync update all

Sync complete:
  ✓ Updated: 8 projects
  — Skipped: 2 projects (already current)
  ✗ Failed: 1 project (git working tree dirty)

Report saved: ~/.claude/projects/reports/20260314.0600/

Each updated project gets a clean commit: docs: sync CLAUDE.md with kickoff conventions.

The Secret Sauce: Section-Level Merging

This is the part that makes it actually work. Not line-level diffing — section-level merging.

A CLAUDE.md built from Kickoff has a predictable structure. Every H2/H3 section falls into one of four categories:

Type	Action	Examples
SHARED	Replace from source	Model conventions, testing rules, Livewire patterns
PROJECT-SPECIFIC	Never touch	Project overview, packages, env vars, Docker config
MERGE	Combine both lists	DO/DON'T — keep source items + project-only items
CONDITIONAL	Check each subsection	Important Conventions (mixed shared + project-specific)

How a DO List Merge Works

Source (from Kickoff):

- ✅ DO extend App\Models\Base for all models
- ✅ DO use dual-key pattern
- ✅ DO use Pest syntax for tests
- ✅ DO use Form Requests for validation     ← NEW

Target (project-beta has custom items):

- ✅ DO extend App\Models\Base for all models
- ✅ DO use Pest syntax for tests
- ✅ DO use PostgreSQL for all new tables     ← PROJECT-ONLY
- ✅ DO prefix admin routes with /admin       ← PROJECT-ONLY

Merged result:

- ✅ DO extend App\Models\Base for all models
- ✅ DO use dual-key pattern                   ← RESTORED FROM SOURCE
- ✅ DO use Pest syntax for tests
- ✅ DO use Form Requests for validation       ← NEW FROM SOURCE
- ✅ DO use PostgreSQL for all new tables       ← PRESERVED
- ✅ DO prefix admin routes with /admin         ← PRESERVED

Source items are updated and new ones added. Project-only items are preserved. Nobody loses anything.

The Section Classification Map

Here's the actual map encoded in the skill:

Section	Classification
`## Project Overview`	PROJECT-SPECIFIC
`## Common Commands`	PROJECT-SPECIFIC
`## Architecture & Key Concepts`	SHARED
`## File Organization`	SHARED
`## Testing with Pest`	SHARED
`## Livewire Patterns`	SHARED
`## Important Conventions`	CONDITIONAL
`## Code Quality Checklist`	SHARED
`## Packages`	PROJECT-SPECIFIC
`## Docker Services`	PROJECT-SPECIFIC
`## Environment Variables`	PROJECT-SPECIFIC
`## Gotchas`	CONDITIONAL
Any unlisted H2 section	PROJECT-SPECIFIC

That last row is important — if a project adds a custom section like ## Deployment Notes or ## Client Requirements, the skill automatically preserves it because it's not in the source.

Edge Cases

Because real-world projects are messy:

Scenario	What Happens
Project has no `CLAUDE.md`	Creates one from source + `composer.json` metadata
Dirty git working tree	Skips the project, reports as failed
Source URL unreachable	Falls back to cache, or asks for `--source` override
Custom H2 sections in project	Always preserved — if it's not in source, it's yours
Merged file exceeds 40 KB	Auto-refines (trims whitespace, condenses examples), then asks if still over
Sections in different order	Preserves project's order — merge is content-based, not position-based

Why This Matters Beyond CLAUDE.md

The real point here isn't about CLAUDE.md specifically. It's about a pattern shift.

Every time I find myself doing something tedious and repetitive — especially something that involves judgment, not just mechanics — I now ask one question:

Can I encode this into a skill?

Same instinct that makes me write packages instead of copy-pasting code. Same instinct that makes me extract traits and contracts instead of duplicating logic. Except now, instead of PHP abstractions, I'm building AI workflow abstractions.

The mental model:

Tedious thing detected
  → Solve it once manually, understand the decision tree
    → Encode the decision tree into a skill
      → Never think about it again

Practical Steps If You Want to Do This

Start with the boring problem. What do you keep doing manually that involves some judgment?
Map out the decision tree before writing anything. What are the conditions? What are the outputs? What needs human review vs what's automatable?
Write the SKILL.md. Phases, inputs, workflow, edge cases. Be explicit. Claude follows structure well.
Keep it in version control. I keep mine in nasrulhazim/agent-skills. Commit it, tag it, evolve it.
Test it on a safe project first. Dry run. Verify the output before letting it touch 10 projects.

Try It Yourself

Install all my skills:

curl -fsSL https://raw.githubusercontent.com/nasrulhazim/agent-skills/main/install.sh | bash

Or just this one:

git clone https://github.com/nasrulhazim/agent-skills.git
cp -r agent-skills/skills/project-sync ~/.claude/skills/

Then in Claude Code:

/project-sync scan ~/Projects
/project-sync status
/project-sync diff project-name
/project-sync update all

Final Thought

AI tools aren't magic. But when you invest time designing how you use them — giving them structure, context, repeatable workflows — they become serious force multipliers.

The leverage isn't in using AI. The leverage is in designing how you use AI.

Working smart isn't about working faster. It's about doing the tedious thing once, then letting the system carry it forward.

That's the whole game.

My agent skills collection (26 skills, MIT licensed) → github.com/nasrulhazim/agent-skills

Kickoff (Laravel kickstart) → kickoff.my

Teaching Claude Code to Think Like a Laravel Developer: Introducing agent-skills

Nasrul Hazim Bin Mohamad — Sat, 28 Feb 2026 00:23:32 +0000

I've been building with Claude Code for a while now, and one thing kept bothering me: every new project started from zero context. Claude doesn't know I use Pest over PHPUnit, that I'm opinionated about Action classes, or that my baseline stack is Livewire 4 + Flux UI. I had to re-explain the same things across sessions, every time.

The fix wasn't to write longer prompts. It was to build skills.

What Are Claude Code Skills?

Claude Code supports a SKILL.md convention — a structured Markdown file that tells Claude how to behave in a specific domain before it starts generating code. Think of it like a system prompt scoped to a task, packaged as a reusable module.

A skill lives at either:

~/.claude/skills/ — globally available across all your projects
.claude/skills/ — scoped to a specific project

When Claude Code encounters a relevant request, it reads the matching skill and follows its instructions. The skill can include frontmatter metadata, trigger phrases, step-by-step workflows, and even reference files like templates and pattern libraries.

Why I Built agent-skills

I maintain 20+ open-source Laravel packages and have been training Laravel developers since 2015. After years of writing the same architecture — contracts, traits, action classes, service providers — I realized I wasn't just repeating code. I was repeating decisions.

agent-skills is my way of encoding those decisions into Claude Code. Instead of prompting Claude from scratch, I give it the same mental model I use when I sit down to build something.

What's Inside

The repo currently covers four areas:

Development & Quality

pest-testing — Generates Pest tests with Livewire support, architecture testing, and factory patterns. It knows I want arch()->preset()->laravel() checks, not just feature tests.
code-quality — Automates the PHPStan + Pint + Rector workflow. Run it before a PR, not after.
php-best-practices — PHP 8.2+ modernization and code review, flagging things like missing readonly properties, untyped parameters, and constructor promotion opportunities.
design-patterns — Laravel-specific pattern guidance with a decision matrix. Should this be a Job, an Action, or a Pipeline? The skill helps Claude answer that in context.
livewire-flux — Component patterns for Livewire 4 with Flux UI. No more explaining my component structure from scratch.

Project Lifecycle

project-docs — Full SDLC documentation toolchain, from product spec to post-mortem.
project-requirements — SRS, user stories, proposals, and wireframes. Useful when a client brief arrives and you need structured output fast.
roadmap-generator — Phase-based roadmaps in Markdown and styled HTML. I use this when pitching to clients or planning sprints.
api-lifecycle — API design through governance. Covers versioning, deprecation policies, and OpenAPI documentation patterns.

Deployment & Ops

ci-cd-pipeline — GitHub Actions + Docker workflow automation. Includes Laravel-specific steps like php artisan optimize and migration safety checks.
package-dev — Laravel package scaffolding, testing, and release automation. This one's personal — it encodes the same structure I use across all my Cleanique Coders packages.

Business & Design

sales-planner — Pricing, quotation generation, marketing copy, and financial planning. Especially handy for solopreneurs who need to go from client brief to proposal quickly.
svg-logo-system — SVG logo design with multi-platform export. Useful when you're the dev and the designer.

The Skill Structure

Every skill follows a consistent format:

skills/[skill-name]/
├── SKILL.md              # Skill definition with YAML frontmatter + instructions
└── references/           # Templates, patterns, examples
    ├── template-a.md
    └── patterns-b.md

The SKILL.md frontmatter looks like this:

---
name: pest-testing
metadata:
  compatible_agents: [claude-code]
  tags: [testing, pest, laravel, livewire]
description: ">"
  Generates Pest PHP tests for Laravel applications.
  Trigger phrases: "write tests", "generate test", "tulis test"...
---

Notice the description includes trigger phrases in both English and Bahasa Malaysia. That's intentional — I code-switch constantly, and I want my skills to respond to either.

Installing in 30 Seconds

# Install all skills globally
curl -fsSL https://raw.githubusercontent.com/nasrulhazim/agent-skills/main/install.sh | bash

This drops everything into ~/.claude/skills/, making all skills available across every project on your machine. If you only need one:

cp -r skills/pest-testing /path/to/your-project/.claude/skills/

The Kickoff.my Baseline

Many skills assume the Kickoff.my bootstrap stack as a starting point:

Livewire 4 + Flux UI
Pest with arch testing
PHPStan / Larastan
Rector + Laravel Pint
GitHub Actions CI
Spatie Permission, Activity Log, Media Library

Rather than re-scaffolding what Kickoff already provides, skills build on top of it. If you're not using Kickoff, the skills still work — you'll just want to adjust a few assumptions in the reference files.

Seeing It in Action

Here are three skills I ran this morning — no extra prompting, just invoking the slash command and letting the skill do its job.

project-docs: Documentation Health Report

This is the project-docs skill running a health check on the agent-skills repo itself. It scored 18/100 — which sounds brutal, but that's exactly the point. It audited the folder structure, badge compliance, SDLC coverage, and surfaced specific HIGH priority gaps: missing docs/ directory, no product spec, no API docs, no support workflow. And then it handed me a prioritized action list.

No vague "your docs could be better." Just a score, a breakdown, and five concrete next steps. That's a skill doing real work.

/svg-logo-system: Brand Brief Intake

I ran /svg-logo-system inside the Kickoff project. The skill immediately launched into brand brief intake — asking about name, audience, personality keywords, color direction, and style preference. I answered casually in a paragraph (mixing English and Bahasa Malaysia, as usual), and it extracted everything it needed.

Brand Brief Extraction → 25 SVG Concepts

From my casual paragraph, the skill structured a complete brand brief: Kickoff, Laravel developers, minimal + developer-focused personality, Emerald #059669 primary, #0B1120 dark background, clean sans-serif inspired by Figtree. Then it went straight to generating 25 SVG logo concepts in parallel.

That's the workflow: one slash command, one casual brief, 25 concepts ready to review. No back-and-forth, no re-explaining the stack.

The Output: 25 Concepts in an Interactive Gallery

This is what the skill generated — a fully interactive HTML gallery with 25 distinct concepts, all respecting the emerald + dark navy palette. Rocket Wordmark, Bracket Code, Terminal Prompt, Abstract K Paths, Terminal Window showing actual composer commands — every concept is on-brand and developer-native. You can toggle between dark and light mode right in the preview.

Click a concept and the skill tells you exactly what to say next: "Selected: #21 — Speed Lines. Tell Claude 'go with #21' to proceed to refinement." The entire workflow — brief intake, concept generation, selection, refinement — is guided by the skill with zero ambiguity about the next step.

The Bigger Picture

Skills are how I'm thinking about AI-assisted development going forward. Not give Claude a long prompt, but give Claude a reusable module of expertise.

The same way we don't write raw SQL when we have Eloquent, we shouldn't re-explain our conventions every time we open a new session.

This also feeds directly into my 2026 training program on Claude Code for solopreneurs. The goal is to show that AI isn't just a code autocomplete — it's a system you can configure to reflect your own architectural judgment.

If you're a Laravel developer who's tired of re-explaining your stack, give agent-skills a try. And if you have skills of your own worth sharing, PRs are open.

Repository: github.com/nasrulhazim/agent-skills

I Built a Claude Code Slash Command That Designs Complete SVG Logo Systems

Nasrul Hazim Bin Mohamad — Thu, 26 Feb 2026 16:40:51 +0000

Ever spent hours going back and forth with design tools trying to nail down a logo? I built a Claude Code slash command that turns logo design into a structured, repeatable process — from initial brainstorming to production-ready SVG files.

The Problem

Logo design is messy. You start with a vague idea, sketch a few concepts, pick one, then spend forever tweaking it for dark mode, light mode, favicons, mobile, and every other context your logo needs to live in.

What if you could condense that entire workflow into a single command?

What `/design-logo` Does

The command walks through a proven three-phase methodology:

Phase 1: Discovery & Mass Exploration

Instead of starting with one idea and hoping it works, the command generates 25 diverse SVG concepts — mixing icon-only marks, wordmarks, and combination marks across different shapes (circles, shields, hexagons) and styles (lettermarks, abstract, symbolic, typographic).

All 25 concepts get dropped into a tinker/ directory with an interactive preview gallery featuring a dark/light mode toggle. You browse them like a mood board.

Phase 2: Selection & Refinement

Pick your favorite direction. The command then creates four production variants:

Wordmark — dark and light background versions
Icon mark — dark and light background versions

Then it builds a comprehensive preview page with real-world mockups: navigation bars, browser frames, mobile splash screens, favicon sizes (64/32/16px), footer placements, and your brand color palette with hex codes.

This is where you see if the logo actually works in context, not just in isolation.

Phase 3: Iteration

Feedback loop. Need the icon simplified for small sizes? The command generates 3-4 icon alternatives and shows them at every relevant size (80px down to 16px) in both dark and light mode, side by side. Pick the winner, and the final preview updates automatically.

Design Principles Baked In

The command enforces good practices:

Dark mode first — designs start on navy (#0B1120), then adapt for light
Size-aware rendering — wordmarks at 140px+, icons at 80px and below
Contrast checking — text must be legible in both modes
Simplicity that scales — fewer elements survive better at small sizes

Installation

One line:

curl -fsSL https://raw.githubusercontent.com/nasrulhazim/claude-design-logo/main/install.sh | bash

Or clone it:

git clone https://github.com/nasrulhazim/claude-design-logo.git
cd claude-design-logo
bash install.sh

The installer copies the slash command to ~/.claude/commands/design-logo.md. That's it.

Usage

Open any project in Claude Code and run:

/design-logo

Claude walks you through brand discovery, asks your style preference, then starts generating. You can also jump to specific phases:

/design-logo refine — skip discovery, work with existing concepts
/design-logo icons — generate icon alternatives for an existing logo

How It's Built

The entire thing is a single Markdown file (design-logo.md) that serves as a Claude Code slash command. No dependencies, no build step, no runtime. Just a well-structured prompt that Claude follows step by step.

The file structure it produces:

tinker/
├── logo-{01..25}-{name}.svg           # 25 concepts
├── preview.html                        # Gallery preview
├── logo-dark.svg                       # Final wordmark (dark bg)
├── logo-light.svg                      # Final wordmark (light bg)
├── logo-icon-dark.svg                  # Final icon (dark bg)
├── logo-icon-light.svg                 # Final icon (light bg)
├── logo-preview.html                   # Comprehensive preview
├── icon-{a..d}-{name}-{dark|light}.svg # Icon alternatives
└── icon-compare.html                   # Icon comparison

Why This Approach Works

The key insight is volume first, then narrow. Starting with 25 concepts instead of 1 removes the pressure of getting it right on the first try. You explore the design space broadly, then focus.

The structured phases also mean you never skip important steps like testing at small sizes or checking dark/light contrast — things that are easy to forget when designing ad hoc.

Try It

The repo is public: github.com/nasrulhazim/claude-design-logo

If you use Claude Code, give /design-logo a spin on your next project. The whole process — from brand discovery to production SVGs — happens in your terminal.

Results

One of my latest works, as following:

Tips

Give a good information about your products
Keep it as SVG, because you always can ask for Claude to render in different sizes and for different purposes.

From Guidelines to Toolchain: Rebuilding claude-docs in One Day

Nasrul Hazim Bin Mohamad — Tue, 03 Feb 2026 08:45:26 +0000

I maintain 20+ open-source packages. Every one of them needs documentation. And every time I start a new project, I solve the same problems — folder structure, linting rules, release notes, badge standards.

claude-docs was supposed to fix that. But until today, it was just a set of guidelines and a slash command. Helpful, not enough.

So I blocked out a day to turn it into a proper toolchain. 8 commits, 20 files changed, +2,083 / -449 lines. Here's the before and after.

Documentation Guidelines

Before: Abstract rules about how docs should look. You read them, nodded, then did your own thing anyway.

After: Rewritten from scratch with concrete examples for 5 project types — Laravel packages, APIs, full-stack apps, CLI tools, and SDKs. Numbered folder conventions, progressive detail structure, ADR support, MermaidJS diagrams. Over 700 lines changed in the first commit alone.

The goal: if you can't figure out how to structure your docs after reading the guidelines, that's a bug.

Markdown Linting

Before: markdownlint was configured, but you had to run it file by file. Most of the time, people just skipped it.

After: One script, one command. lint.sh finds all markdown files, auto-detects your config, and lints everything in one pass. Add --fix to auto-correct.

~/.claude/lint.sh           # lint everything
~/.claude/lint.sh --fix     # lint & auto-fix

If linting takes effort, nobody lints. Now it doesn't.

Release Notes

Before: Manual. Copy commits from git log, reformat into markdown, paste into CHANGELOG. Every. Single. Time.

After: release-note.sh — a 300+ line script that parses your git log, categorizes commits by conventional prefixes, and generates structured markdown with summary tables and contributor lists.

~/.claude/release-note.sh                        # today's release note
~/.claude/release-note.sh --tldr                 # summary version
~/.claude/release-note.sh --since "1 week ago"   # custom date range
~/.claude/release-note.sh --output CHANGELOG.md  # write to file

This one went through three iterations in a single session — build, refactor, extend. The first version showed me what the second version needed. That's the natural rhythm for tooling work.

Badge Standards

Before: Some projects had badges, some didn't. No consistency.

After: Mandatory version and license badges for every project README. Copy-paste templates for 10 package registries (Packagist, npm, PyPI, crates.io, and more). Badge compliance tracked in the /docs health report.

Badges are the first thing people see on your repo. They signal you care. Making the standard easy to follow is what makes people actually follow it.

Project Auto-Detection

Before: PHP and Node only.

After: Supports Python, Ruby, Rust, Go, .NET, Java, Dart/Flutter, and Elixir. Run /docs scaffold <type> and get the right structure for your stack.

What `/docs` Can Do Now

After today's update, here's everything available under the /docs slash command in Claude Code:

Command	What It Does
`/docs`	Create new documentation structure (auto-detects your project type)
`/docs reorganize`	Reorganize existing docs into the numbered standard
`/docs validate`	Validate against standards and report issues
`/docs update-toc`	Update all README.md table of contents
`/docs health`	Generate documentation health report with badge compliance
`/docs scaffold <type>`	Scaffold from template: `laravel`, `api`, `cli`, `sdk`, `fullstack`
`/docs release-note`	Generate full release note from today's git log
`/docs release-note --tldr`	Generate summary release note

One command to rule them all. Pick what you need.

The Full Picture

One install command gets you everything:

curl -fsSL https://raw.githubusercontent.com/nasrulhazim/claude-docs/main/install.sh | bash

What You Get	What It Does
Guidelines	Concrete examples for 5 project types
`lint.sh`	Batch markdown linting with auto-fix
`release-note.sh`	Git log → structured release notes
`/docs` command	Scaffold, validate, health report, auto-detect
Badge templates	10 registries, 13 project types

Why This Matters

I'm a solo founder running Cleanique Coders. No docs team, no technical writer. What I have is tooling that enforces standards so I don't have to remember them.

Every hour spent on this saves ten hours of "how did we do docs in that project?" across the next year. If you maintain multiple repos — especially alone — standardize the boring stuff first.

The repo is open source. Take it, use it, tell me what's missing.

👉 github.com/nasrulhazim/claude-docs

Stop Guessing Your Product's Worth: A Claude Code Skill for Pricing, Sales & Financial Planning

Nasrul Hazim Bin Mohamad — Tue, 03 Feb 2026 02:02:39 +0000

I've been building software for over a decade. Laravel packages, enterprise systems, SaaS tools — you name it.

But here's the thing nobody talks about: most developers are terrible at pricing their own work.

I know because I was one of them.

The Problem: We Build Great Software, Then Guess the Price

You spend weeks — sometimes months — building a product. You know every line of code, every edge case, every architectural decision.

Then someone asks, "How much?"

And suddenly, you're stuck.

You look at competitors. You check some blog posts. You ask in a Telegram group. Someone says "just charge RM 500/month" and someone else says "bro, that's too cheap."

So you pick a number that feels right. No structure. No breakdown. No financial plan.

I've done this myself more times than I'd like to admit. And I've watched other developers do the same — talented people undercharging because they've never sat down to properly think through their pricing.

Why I Built claude-sales

I was working on the pricing strategy for one of my products — G8Stack, an API management platform built on Kong Gateway. I needed to figure out:

What should the base license cost?
What about add-ons like monitoring, SSO, training?
How do I structure partner channels? Reseller vs referrer vs affiliate?
What's a realistic government project quotation?
What marketing copy works for different audiences?

I ended up having long conversations with Claude about all of this. And the output was genuinely useful — proper pricing breakdowns, partner margin calculations, quotation templates, even social media copy.

Then I thought: why am I keeping this in a single conversation?

What if I could package this into a reusable Claude Code skill — something I could use across any product, anytime?

That's how claude-sales was born.

What claude-sales Does

It's a set of Claude Code slash commands that give you instant access to your product's sales and pricing information:

/get-pricing license
/get-pricing via reseller
/get-pricing government full project

/get-marketing taglines
/get-marketing social casual

/get-quotation enterprise

But the real value isn't the commands — it's the thinking framework behind them.

The Framework: Think Like a Business, Not Just a Developer

When you install claude-sales, you get a product-config-template.md file. Filling it in forces you to answer questions most developers skip:

1. What's Your Base Price?

Not "what feels right" — but what's the actual value?

base_price: 25000
unit: "one-time"
includes:
  - "Unlimited nodes"
  - "Unlimited users"
  - "Remote deployment"
  - "1 year updates & support"

When you write this down, you start thinking about what's included, what's extra, and what your minimum viable offering looks like.

2. What Are Your Add-ons?

Most products have a core and optional extras. Defining them separately helps you create flexible packages:

addons:
  - name: "Monitoring Integration"
    price_min: 20000
    price_max: 30000
  - name: "SSO Integration"
    price_min: 10000
    price_max: 25000
  - name: "Training"
    price: 5000
    unit: "per day"

This isn't just for quotations. This is your product strategy. Each add-on is a revenue stream.

3. How Will You Sell Through Partners?

If you're a solo founder or small team, you can't be everywhere. Partners extend your reach — but you need clear margins:

channels:
  referrer:
    margin: 10    # Just introduces a lead
  affiliate:
    margin: 20    # Markets and qualifies leads
  reseller:
    margin: 30    # Handles full sales cycle
  fronting:
    margin: 15    # PM & finance only

I learned this the hard way. Without defined margins, every partner conversation becomes an awkward negotiation. With a clear framework, it becomes a professional discussion.

4. What Does a Typical Project Cost?

Government and enterprise clients don't buy "a license." They buy projects. You need to break down what a full implementation looks like:

packages:
  - name: "Government Full"
    components:
      - item: "Requirement Study"     → RM 15,000
      - item: "Product License"       → RM 40,000
      - item: "Integration"           → RM 30,000
      - item: "Customization"         → RM 20,000
      - item: "Training"              → RM 15,000
    total: 135,000

When a prospect asks "how much for the whole thing?", you have an answer ready. Not a guess — a structured breakdown.

The Financial Planning Side

Here's where it gets interesting for solo founders and small teams.

Once you have your pricing defined, you can start asking real business questions:

"How many direct sales do I need this year to hit RM 300,000?"

RM 300,000 ÷ RM 25,000 = 12 direct sales
That's 1 sale per month.

"What if half come through resellers?"

6 direct × RM 25,000 = RM 150,000
6 reseller × RM 17,500 = RM 105,000
Total: RM 255,000

Need 2 more reseller sales to hit target.

"What's my revenue if I land 2 government projects?"

2 × RM 135,000 = RM 270,000
Plus maintenance Year 2: 2 × RM 5,000 = RM 10,000

These aren't complex calculations. But most developers never do them because they never structured their pricing in the first place.

How to Use It

Quick Install

curl -fsSL https://raw.githubusercontent.com/nasrulhazim/claude-sales/main/install.sh | bash

Configure Your Product

cp ~/.claude/product-config-template.md ./product-config.md
# Edit with your product details

Use the Commands

/get-pricing license              # Base pricing
/get-pricing via reseller         # Partner calculations
/get-quotation government         # Quotation template
/get-marketing elevator pitch     # 30-second pitch

The template is generic — it works for any product, SaaS, on-premise software, or service. Fill in your numbers, and Claude Code becomes your sales assistant.

What's Inside the Repo

claude-sales/
├── install.sh                     # One-line installer
├── get-pricing.md                 # /get-pricing command
├── get-marketing.md               # /get-marketing command
├── get-quotation.md               # /get-quotation command
├── sales-reference.md             # Pricing logic & patterns
├── product-config-template.md     # Your product config
└── examples/
    └── g8stack-config.md          # Real-world example

The G8Stack example is a real configuration I use for my own product. It includes actual pricing, partner margins, social media copy (yes, even the Malay casual posts), and quotation templates.

Who This Is For

This isn't just for people selling software. If you're:

A developer with a side project that you want to monetise
A freelancer who packages services into products
A small agency that needs consistent quotations
A solo founder trying to figure out pricing strategy
An open-source maintainer exploring commercial offerings

...then having a structured pricing framework saves you from the "I'll figure it out later" trap that never actually gets figured out.

The Bigger Picture

I've been building Claude Code skills like claude-docs for documentation and claude-analyze-repo for repository analysis. Each one tackles a specific pain point developers face.

claude-sales tackles the business side — because building a great product is only half the battle. Knowing how to price it, sell it, and plan around it is the other half.

And honestly? That other half is what separates a side project from a business.

Final Thoughts

If you've ever caught yourself saying "I don't know how much to charge" or "I'll figure out the pricing later", this is for you.

The template forces you to think about your product as a business:

What's the core offering worth?
What can be sold separately?
Who are your partners and what do they earn?
What does a full project look like?
How do you talk about your product?

It takes maybe 30 minutes to fill in. But the clarity it gives you lasts much longer than that.

Check it out: github.com/nasrulhazim/claude-sales

If you find this useful, give it a ⭐ on GitHub. And if you end up defining your product pricing with it, I'd love to hear how it went.

Dokufy: Generate PDFs your way — Gotenberg, LibreOffice, or native PHP.

Nasrul Hazim Bin Mohamad — Thu, 15 Jan 2026 10:08:03 +0000

I'm excited to share my latest Laravel package - a driver-based document generation and PDF conversion tool.

The problem it solves: You shouldn't have to rewrite your document generation code just because you switched from local development to production, or moved from shared hosting to Kubernetes.

Key features:

Unified API across 5 drivers (Gotenberg, LibreOffice, Chromium, PhpWord)
DOCX & HTML template support with placeholder processing
First-class testing support with FakeDriver
Integrates with cleaniquecoders/placeholdify

composer require cleaniquecoders/dokufy

More details documentation can be found here.

Feedback and contributions welcome!

Introducing Claude Code Documentation Standards: Automated Documentation with Built-in Linting

Nasrul Hazim Bin Mohamad — Wed, 10 Dec 2025 01:23:18 +0000

Keeping documentation tidy, readable, and easy to navigate shouldn’t feel like a chore. But in most projects, it eventually becomes one. Different people write differently, folders get messy, and soon no one knows where anything lives.

So I built something to fix that.

Introducing Claude Code Documentation Standards — a framework that helps you write better documentation with less effort, using a consistent structure, automated checks, and a simple one-line install.

Why Documentation Usually Feels Hard

If you’ve ever joined or handed over a project, you’ve probably faced one (or all) of these:

Every project stores documentation differently
It's difficult to figure out “where to start” reading
Markdown formatting isn’t consistent
No quality control — mistakes slip through
Setting up documentation tools takes time

None of this should be your problem. You just want your documentation to look good, stay organised, and help people find what they need quickly.

What This Framework Does For You

Claude Code Documentation Standards gives you:

✅ A clean, numbered folder structure so you always know where things belong
✅ Automatic markdown linting so everything stays consistent
✅ A simple /docs command that generates and organises your documentation
✅ One-line installation — truly plug-and-play
✅ CI/CD examples for teams
✅ Pre-commit hooks so docs stay clean before they’re even committed

It’s designed to save you time, reduce confusion, and make your project look polished — with almost no setup.

What You’ll Love About It

1. A Structure That Actually Makes Sense

Your documentation is grouped by context, not by random categories.

docs/
├── 01-architecture/
├── 02-development/
├── 03-deployment/
└── 04-api/

The numbering tells you the order things should be read — so new contributors always start in the right place.

2. Your Documentation Cleans Itself

With built-in markdown linting, you don’t have to worry about:

Odd formatting
Incorrect heading levels
Missing code block labels
Extra whitespace
Long, unreadable lines

Write normally — the tools help keep it clean.

3. A Single Command That Builds Everything For You

Just type:

/docs

Claude Code will:

Scan your project
Create the correct folder structure
Generate READMEs with tables of contents
Lint everything
Fix formatting issues

Documentation setup becomes a 5-second task instead of a weekend chore.

4. Easy-to-Understand Flow

Your docs now guide readers naturally:

Overview — What this project is
Getting Started — How to use it immediately
Deep Dives — How it works behind the scenes
Reference — APIs, endpoints, commands, etc.

This keeps your project beginner-friendly and expert-friendly.

Installation (Takes Only One Line)

curl -fsSL https://raw.githubusercontent.com/nasrulhazim/claude-docs/main/install.sh | bash

That’s all. The installer sets up:

Documentation templates
Markdown linting
Slash commands
Default linting rules

If you prefer manual install:

git clone https://github.com/nasrulhazim/claude-docs.git
cd claude-docs
./install.sh

Using It

In any Claude Code project, run:

/docs

It will:

Analyse your project
Generate all documentation folders
Create READMEs
Lint your files
Automatically fix issues

Additional commands:

/docs reorganize
/docs validate
/docs update-toc

Need to lint manually?

markdownlint docs/**/*.md
markdownlint --fix docs/**/*.md

A Documentation Layout That Stays Consistent

Example structure:

docs/
├── README.md
├── 01-getting-started/
│   ├── README.md
│   ├── 01-installation.md
│   ├── 02-authentication.md
│   └── 03-first-request.md
├── 02-endpoints/
│   ├── README.md
│   ├── 01-users.md
│   ├── 02-posts.md
│   └── 03-comments.md
└── 03-guides/
    ├── README.md
    ├── 01-pagination.md
    ├── 02-filtering.md
    └── 03-rate-limiting.md

Your readers will never wonder where to look again.

Works Beautifully in CI/CD

Add automatic documentation linting to your workflows with a few lines. This keeps your project polished even as more contributors join in.

Why This Matters (Even If You’re a Solo Developer)

For Developers

Faster onboarding
Cleaner, more readable docs
Less manual formatting
A consistent experience across projects

For Teams

Everyone follows the same structure
Automated checks mean fewer review headaches
Clearer documentation means fewer repeated questions

For Open Source

Your project looks more mature
Contributors instantly understand where to add docs
Easier discovery = more engagement

Customise It Your Way

Want shorter line lengths?
Want different contexts?
Working on mobile apps, microservices, or data science?

You can adjust everything:

Add new contexts
Update linting rules
Modify folder structure
Create your own templates

The framework is opinionated — but flexible.

Final Thoughts

Writing documentation shouldn’t drain your energy or slow down your project. With Claude Code Documentation Standards, you get:

A clean structure
Automatic quality control
One-command generation
Consistent formatting
A beginner-friendly experience

Let your tools handle the boring parts — so you can focus on building great software.

Laravel Running Number v3.0 — A Practical, Powerful Upgrade for Real-World Systems

Nasrul Hazim Bin Mohamad — Thu, 13 Nov 2025 11:33:21 +0000

Laravel Running Number v3.0 is finally here, and this release introduces the kind of improvements that make a difference in real systems—where concurrency matters, audit trails need to be trustworthy, and developers just want a clean, predictable API to generate running numbers.

If you haven't seen the release notes yet, you can check them out here:

Before we dive in, one quick reminder:
Make sure your types are declared in config/running-number.php or exposed via your enum.

Native PHP Enums — Cleaner, Safer, Less Guesswork

I’ve wanted proper enum support for a long time, and v3.0 finally brings it in.
Enums help reduce typos, give you IDE autocompletion, and make your code more expressive.

With Traitify behind the scenes, you also get helpers like values(), labels(), and options() automatically.

use CleaniqueCoders\RunningNumber\Enums\Organization;

// config/running-number.php
'types' => Organization::values();

$number = running_number()
    ->type(Organization::PROFILE->value)
    ->generate(); // PROFILE001

UUID Identifiers — Because Debugging Shouldn’t Be a Guessing Game

Every generated sequence now comes with a UUID.
This is incredibly helpful when:

You’re syncing with external services
You want stronger audit trails
You need to debug inconsistencies

$rn = RunningNumber::where('type', 'PROFILE')->first();
echo $rn->uuid;

It’s small, but it’s the kind of practical addition you appreciate once you need it.

Reset Periods — Daily, Monthly, Yearly, or Fully Manual

Reset periods make your identifiers predictable.
Think invoices that restart monthly or reports that refresh every year.

'reset_period' => [
    'default' => ResetPeriod::MONTHLY->value,
    'types' => [
        'invoice' => ResetPeriod::YEARLY->value,
    ],
];

And if you ever need to reset manually:

php artisan running-number:reset INVOICE --scope=retail

This gives you full control without cluttering your code.

Date-Based Presenters — Human-Readable, Business-Friendly Numbers

Sometimes the business team wants to see the date inside the number.
Presenters let you customise formatting cleanly:

use CleaniqueCoders\RunningNumber\Presenters\YearMonthPresenter;

$number = running_number()
    ->type('invoice')
    ->formatter(new YearMonthPresenter('-'))
    ->generate();
// INVOICE-2025-11-001

Readable, structured, and consistent.

Scopes — Multiple Independent Sequences for the Same Type

One of my favourite additions.
Scopes let you maintain separate sequences for different "segments"—branches, stores, departments, etc.

running_number()->type('invoice')->scope('retail')->generate();    // INVOICE001
running_number()->type('invoice')->scope('wholesale')->generate(); // INVOICE001

No more juggling prefixes or custom logic just to keep numbers separated.

Custom Starting Numbers — Perfect for Migrations

For teams migrating from legacy systems, this is a lifesaver.

$number = running_number()
    ->type('ticket')
    ->startFrom(1000)
    ->generate(); // TICKET1001

CLI option is also available:

php artisan running-number:create ticket --start=1000

Max Number Limits — Fail Fast, Fail Safe

If a sequence should never go beyond a certain range, you can enforce it:

try {
    running_number()->type('voucher')->maxNumber(5)->generate();
} catch (MaxNumberReachedException $e) {
    // graceful handling
}

Especially useful for voucher books, serial allocations, and compliance-driven systems.

Preview Mode — Know the Next Number Without Updating Anything

Great for UI previews and displaying "Upcoming Order Number".

$next = running_number()->type('order')->preview();

No DB writes. No side effects.

Batch Generation — Atomic, Fast, and Fully Safe

Sometimes you need to generate multiple numbers in one go—shipping labels, voucher sheets, batch allocations.

$numbers = running_number()
    ->type('shipment')
    ->generateBatch(5);

This happens inside a single transaction with locking, so everything remains safe.

Model Trait — Zero Boilerplate Number Generation

If you want a field to auto-populate when a model is created, this trait does all the heavy lifting.

class Invoice extends Model
{
    use InteractsWithRunningNumber;

    protected string $runningNumberField = 'invoice_number';
    protected string $runningNumberType = 'invoice';
    protected ?string $runningNumberScope = '$store_id';
}

Clean. Minimal. Reliable.

Artisan Commands — Handy Tools for Ops and Developers

You can create, list, and reset sequences directly from the CLI.

php artisan running-number:create invoice --scope=retail --start=100 --reset=yearly
php artisan running-number:list
php artisan running-number:reset INVOICE --scope=retail --force

Ops teams will appreciate this.

Optional REST API — Use It Across Services

If you’re running microservices or integrating with external apps, the optional API is a straightforward solution.

curl -X POST http://localhost/api/running-numbers/generate \
  -d '{"type":"invoice","scope":"retail"}'

Full API docs

Events — Integrate with Logging, Notifications, or External Systems

Hook into RunningNumberGenerated to push updates where you need them.

Event::listen(RunningNumberGenerated::class, function ($event) {
    logger()->info('Number generated', $event->toArray());
});

Simple and effective.

Documentation

See full documentation here.

Upgrade Guide

Refer to upgrade guide for upgrading from version 2.3 to 3.0.

Final Thoughts

v3.0 is a solid upgrade. It’s the kind of release that doesn’t just add features—it improves the fundamentals of how running numbers should behave in a production-grade system.

Whether you're building a billing engine, logistics workflow, multi-tenant SaaS, or internal ERP module, this version gives you the flexibility and reliability you need.

Photo by Francesco Ungaro: https://www.pexels.com/photo/blue-sky-281260/

Eligify v1.4.0: We Made Your Rules Organized (And Auditable)

Nasrul Hazim Bin Mohamad — Fri, 07 Nov 2025 17:17:30 +0000

You know that moment when you're building eligibility rules and realize you've got 15 different checks all mixed together? Identity stuff, financial stuff, contact verification... it's a mess.

We felt that pain too. So we built two features to fix it.

Rule Groups: Stop the Rule Chaos

Here's the thing about eligibility decisions—they're rarely "check everything the same way."

A loan approval needs:

Identity checks: All must pass (you can't approve someone without proper ID)
Financial checks: All must pass (they need sufficient income and good credit)
Contact verification: At least 2 out of 3 methods need to work (we just need to reach them somehow)

Before v1.4.0, you'd list all 15 rules in one giant pile. Good luck explaining to someone why their loan got rejected when 8 different checks got mixed together.

With Rule Groups, you organize related rules into logical buckets with clear logic:

Identity group? All must pass
Financial group? All must pass
Verification group? At least 2 must pass

That's it. Your code now reads like your actual business logic. When someone asks "why was this rejected?" you can point to the group that failed instead of wading through spaghetti.

Plus, you can weight groups differently. Maybe identity is critical, financial is important, but nice-to-haves are just bonus points.

Rule Versioning: Never Lose Track Again

Here's another common headache: "Did we change the credit score requirement last month?"

Rule Versioning solves this by creating snapshots of your rules at key moments. Think of it like Git for your eligibility rules.

When you update your rules, you create a version: "Q4 2025 - Stricter credit requirements"

Now you can:

Look back: "What rules were we using in October?"

Prove it: Auditors ask if a decision was fair? Show them exactly which rules were applied.

Test it: Want to see how people would have qualified under the old rules? Evaluate against version 2 instead of the current version.

Compare changes: See exactly what rules were added, removed, or modified between versions.

This is huge for regulated industries—loan companies, insurance, benefits programs. You're not just making decisions, you're making defensible decisions.

What This Means For You

If you build eligibility systems:
Your code gets cleaner, your decisions get clearer, your audits get easier.

If you work with compliance:
You now have a built-in audit trail. Who changed what? When? What were the rules at decision time? It's all tracked.

If you're managing stakeholders:
Rule Groups make it easy to explain your logic. No more "well, we check 15 things"—you can say "we verify identity, check finances, and confirm contact" and people understand immediately.

Real Talk: A Day in the Life

Let's say you're building a scholarship program.

You need:

Academic performance (GPA + test scores)
Financial need
Citizenship requirements

Instead of one rule list, you set it up like:

Academic group (must pass) → GPA above 3.5 AND test score above 1400
Financial group (weighted importance) → Family income below $150k
Citizenship group (must pass) → Must be citizen or permanent resident

Three groups. Clear intent. Easy to test. Easy to explain. Easy to audit.

Then next year when requirements tighten? Create a new version. Your 2025 rules stay on record.

The Bottom Line

v1.4.0 gives you two superpowers:

Organization: Rules that make sense to humans, not just computers
Auditability: A complete history of how decisions were made

Both feel like they should have been there from day one. We're glad they're here now.

Try It Out

composer update cleaniquecoders/eligify
php artisan migrate

That's it. Your existing code still works. Rule Groups are there when you're ready to use them.

Questions? Check the full documentation or read the detailed guides.

Eligify v1.4.0 – Define criteria. Enforce rules. Decide eligibility.

Eligify — The Criteria and Rule Engine for Explainable Decisions

Nasrul Hazim Bin Mohamad — Tue, 28 Oct 2025 02:12:01 +0000

Business eligibility logic has a habit of hiding in plain sight.

It starts with a few if statements in a controller, a couple more in a form request — and before long, the logic has spread across jobs, listeners, and policies.

And then the inevitable happens:

Different parts of the system disagree on what “eligible” means.
Making changes becomes risky because rules are scattered.
When someone asks, “Why was this rejected?” there’s no single, auditable answer.

Eligibility determines who qualifies — for a loan, a scholarship, a feature upgrade, or access to a service.
It’s too important to be buried inside conditional statements.

That’s where Eligify comes in.

Introducing Eligify — A Criteria and Rule Engine for Explainable Decisions

Eligify turns eligibility from hidden code into a first-class decision engine.

It gives you a declarative, data-driven, and auditable way to define and evaluate business rules — making decisions predictable and explainable.

Instead of scattering logic across your application, you define criteria (the decision context) and rules (the conditions). Each evaluation produces a clear outcome — with the “why” built in.

$criteria = Eligify::criteria('loan_approval')
    ->addRule('income', '>=', 3000)
    ->addRule('credit_score', '>=', 650)
    ->passThreshold(75)
    ->save();

$result = Eligify::evaluate('loan_approval', [
    'income' => 5000,
    'credit_score' => 720,
]);

Example result

[
  'passed' => true,
  'score' => 90,
  'failed_rules' => [],
  'decision' => 'Approved',
]

Whether you run it in a controller, background job, or policy — Eligify ensures every decision follows the same consistent logic.

How Eligify Works — The Core Architecture

Eligify separates definition, data extraction, evaluation, and audit — so every layer is clear, testable, and reusable.

Component	Purpose
🧠 Criteria & Rules	Define logical conditions with a fluent DSL. Supports AND/OR/XOR/MAJORITY groups, weights, and thresholds.
🔍 Model Data Extractor	Normalises attributes and relationships into a flat structure. Keeps business logic decoupled from model internals.
⚙️ Evaluator Engine	Runs rules, computes scores, and triggers callbacks (`onPass`, `onFail`, `onExcellent`).
📜 Audit Trail	Stores every evaluation: what ran, what passed, what failed, and why — critical for transparency and compliance.

Architecture Flow (Text Diagram)

You can see more details architecture design from here.

Practical Usage — From Definition to Decision

Eligify makes complex logic readable and repeatable. Here’s how it fits naturally into any application flow.

Step 1: Define Your Criteria

Eligify::criteria('membership_upgrade')
    ->addRule('account_age_days', '>=', 30)
    ->addRule('total_purchases', '>=', 5)
    ->addRule('support_tickets', '<=', 2)
    ->save();

Step 2: Extract Model Data

$data = ModelDataExtractor::forModel(User::class)->extract($user);

Step 3: Evaluate and Act

$result = Eligify::evaluate('membership_upgrade', $data);

if ($result['passed']) {
    // Upgrade membership
} else {
    Log::info('User not eligible', $result['failed_rules']);
}

Each evaluation is audited, giving you a full history of what happened, when, and why — no more guesswork.

Why Eligify Matters

Eligify isn’t just a rules engine — it’s a mindset shift.

Instead of burying decisions inside conditionals, it makes them transparent, explainable, and reusable.

✅ Centralised rule definitions — one source of truth
✅ Consistent outcomes across systems
✅ Auditable results for compliance and debugging
✅ Extensible design for any domain — finance, education, HR, SaaS, government

When decisions impact real people, clarity and fairness matter.
Eligify helps you build both into your software.

🌟 Get Started

composer require cleaniquecoders/eligify
php artisan vendor:publish --tag="eligify-config"
php artisan migrate

🔗 View on GitHub → cleaniquecoders/eligify

Stop scattering your eligibility logic. Centralise it. Audit it. Trust it.

Eligify — make decisions explainable.

DEV Community: Nasrul Hazim Bin Mohamad

Here's How I Build Products Without Losing My Mind.

The Shift: Blueprint Before Code

Phase 1 — Idea to Clear Direction

Phase 2 — Name It. Own the Domain.

Phase 3 — Kickoff

Phase 4 — The CLAUDE.md (The Blueprint)

Phase 5 — GitHub Setup (Before a Single Line of App Code)

Phase 6 — Build Phase by Phase

Bonus: Agent Skills

The Real Lesson

Want to Learn This or Work With Me?

Laravel Artisan Runner — Run Artisan Commands from the Browser, Safely

The Problem

What It Does

Installation

Configuration: Three Discovery Modes

Manual (Default — Safest)

Auto Discovery

Selection

How It Works Under the Hood

The Audit Log

Smart Parameter Rendering

Notifications

Security: Built Paranoid by Default

Livewire 3 + 4 Compatibility

When Should You Use This?

Stack Compatibility

Try It Out

I Built a Claude Code Skill to Sync CLAUDE.md Across 12+ Laravel Projects

A Bit of Background

The Boring Fix vs The Right Fix

What's a Claude Code Skill?

What the Skill Actually Does

Scan: Find All Kickoff Projects

Status: What Needs Updating?

Diff: Preview Before You Touch Anything

Update: Do the Thing

The Secret Sauce: Section-Level Merging

How a DO List Merge Works

The Section Classification Map

Edge Cases

Why This Matters Beyond CLAUDE.md

Practical Steps If You Want to Do This

Try It Yourself

Final Thought

Teaching Claude Code to Think Like a Laravel Developer: Introducing agent-skills

What Are Claude Code Skills?

Why I Built agent-skills

What's Inside

Development & Quality

Project Lifecycle

Deployment & Ops

Business & Design

Meta

The Skill Structure

Installing in 30 Seconds

The Kickoff.my Baseline

Seeing It in Action

project-docs: Documentation Health Report

/svg-logo-system: Brand Brief Intake

Brand Brief Extraction → 25 SVG Concepts

The Output: 25 Concepts in an Interactive Gallery

The Bigger Picture

I Built a Claude Code Slash Command That Designs Complete SVG Logo Systems

The Problem

What /design-logo Does

Phase 1: Discovery & Mass Exploration

Phase 2: Selection & Refinement

Phase 3: Iteration

Design Principles Baked In

Installation

Usage

How It's Built

Why This Approach Works

Try It

Results

Tips

From Guidelines to Toolchain: Rebuilding claude-docs in One Day

Documentation Guidelines

What `/design-logo` Does

What `/docs` Can Do Now