Coder Legion - Recent posts tagged rule

Understanding Chain Rule

Thu, 28 May 2026 13:45:57 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.

What is Chain Rule?

The chain rules nothing but a differntiation of a function with another function.

For example:
Taking displacement, velocity, acceleration as an example

s(t)→v(t)→a(t)

Where:

displacement depends on time
velocity depends on displacement changing over time
acceleration depends on velocity changing over time ### Displacement

Velocity

Acceleration

Each graph is the derivative of the previous one.

Why chain rule is used?

The chain rule is used in Machine Learning during Backpropagation, which is the process of training the network by adjusting its weights and biases to minimize errors.

If you have two functions, f(x) and g(x), and you want to find the derivative of their composition f(g(x)), the chain rule states:

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

cursor-claude-personas: Give Your AI Coding Assistant a Domain Expert Brain in 30 Seconds

Fri, 17 Apr 2026 22:44:50 +0000

cursor-claude-personas: Give Your AI Coding Assistant a Domain Expert Brain in 30 Seconds

TL;DR — cursor-claude-personas is a free, open-source collection of 38 role-based AI persona packs for Claude Code, Cursor, and VS Code. Copy one folder into your project, reopen your editor, and your AI assistant instantly behaves like a seasoned specialist — whether that's a senior Python developer, a DevOps engineer, a security expert, or a UI/UX designer.

The Problem: Generic AI Gives Generic Code

You have Claude Code or Cursor open. You ask it to add an endpoint. It writes something that works — but it doesn't know your preferred framework patterns, it doesn't follow your domain conventions, and it certainly doesn't remember that you care deeply about SQL index hygiene or GraphQL schema design.

The usual fix is a long system prompt you paste in every time. Or a .cursorrules file you spend hours writing. Or endless back-and-forth corrections.

cursor-claude-personas solves this with a dead-simple copy-paste.

What Is cursor-claude-personas?

cursor-claude-personas is a GitHub repository containing 38 ready-made persona packs for AI coding tools. Each persona is a folder with two hidden subdirectories:

senior-python-developer/
├── .claude/
│   ├── rules/       ← always-on instructions Claude Code reads at session start
│   └── skills/      ← auto-triggered skill docs for specific tasks
└── .cursor/
    ├── rules/       ← always-on instructions Cursor reads at session start
    └── skills/      ← auto-triggered skill docs for specific tasks

When you copy .claude/ or .cursor/ (or both) into the root of your project, your editor loads those configs automatically. No slash commands. No system prompts. The persona is live the moment you start a new chat session.

Supported tools

Tool	What to copy
Claude Code	`.claude/` folder
Cursor	`.cursor/` folder
VS Code	`.claude/` folder (when using Claude-based extensions)

How to Use It — Step by Step

Step 1: Clone the repo

git clone https://github.com/ratnesh-maurya/cursor-claude-personas.git

You only need to clone it once. Keep it around as your personal AI persona library.

Step 2: Pick the persona that matches your current work

Browse the table in the next section or visit the GitHub Pages site to filter by technology or tag.

Step 3: Copy the persona into your project

Navigate to your cloned copy and run:

# Claude Code only
cp -R cursor-claude-personas/senior-python-developer/.claude /path/to/your-project/

# Cursor only
cp -R cursor-claude-personas/senior-python-developer/.cursor /path/to/your-project/

# Both tools
cp -R cursor-claude-personas/senior-python-developer/.claude /path/to/your-project/
cp -R cursor-claude-personas/senior-python-developer/.cursor /path/to/your-project/

Replace senior-python-developer with any persona slug from the list below.

Step 4: Reopen your editor or start a new session

Claude Code and Cursor reload configuration at session start. From that point on, the AI follows the persona's rules, applies its skills automatically, and behaves as a domain expert — without you typing a single extra word.

Bonus: Enable the auto-skill router

Each persona includes a special rule file called rules--auto-skill-router.mdc (.mdc is the Cursor/Claude rule file format — it is just Markdown with optional YAML frontmatter). This rule tells the AI to automatically select the right skill doc based on what you're working on — so you never need to type /skill commands manually.

It is already included when you copy the persona folders. No extra steps required.

All 38 Personas

Persona	Best for
`3d-frontend-developer`	Three.js, WebGL, 3D UI
`ai-agent-developer`	LLM agents, tool use, orchestration
`ai-ml-engineer`	Model training, pipelines, MLOps
`azure-developer`	Azure services, ARM/Bicep, AKS
`blockchain-web3-developer`	Smart contracts, DeFi, Web3 tooling
`blog-website-developer`	Content sites, CMS, static generators
`data-engineer`	Pipelines, dbt, Spark, warehouses
`devops-cloud-engineer`	CI/CD, Kubernetes, IaC, observability
`ecommerce-specialist`	Shopify, WooCommerce, checkout flows
`fullstack-saas-mvp`	Rapid SaaS prototyping, full-stack
`functional-programming`	Haskell, Clojure, FP patterns
`game-developer`	Unity, Godot, game loops
`health-tech-developer`	FHIR, HL7, medical data systems
`legal-finance-analyst`	Contracts, compliance, financial models
`marketing-automation`	Email, CRM integrations, analytics
`mobile-developer`	React Native, Flutter, iOS/Android
`n8n-automation-specialist`	n8n workflows, low-code automation
`odoo-erp-specialist`	Odoo modules, ERP customization
`open-source-maintainer`	OSS governance, reviews, releases
`platform-integrations`	APIs, webhooks, third-party services
`product-manager`	Roadmaps, specs, user stories
`qa-testing-engineer`	Test strategy, automation, coverage
`saas-startup-founder`	GTM, metrics, early-stage decisions
`security-engineer`	Threat modeling, hardening, audits
`senior-dotnet-developer`	C#, ASP.NET Core, Azure
`senior-elixir-developer`	Elixir, Phoenix, OTP
`senior-frontend-developer`	React, TypeScript, frontend architecture
`senior-golang-developer`	Go, microservices, concurrency
`senior-java-developer`	Java, Spring Boot, enterprise patterns
`senior-python-developer`	Python, APIs, automation, data
`senior-rust-developer`	Rust, systems programming, WASM
`seo-specialist`	Technical SEO, Core Web Vitals, schema
`system-architect`	Service boundaries, scalability, design
`system-designer`	Low-level system design, algorithms
`technical-writer`	Docs, onboarding, API clarity
`ui-ux-designer`	Design systems, accessibility, UX
`voice-ai-developer`	Voice interfaces, TTS, STT, ASR
`wordpress-specialist`	WordPress, WooCommerce, theme dev

Not sure where to start? Try senior-python-developer or senior-frontend-developer — both are polished starting points that work for a wide range of projects.

What Makes This Different From a `.cursorrules` File?

A .cursorrules file (a single plain-text file at the project root) you write yourself usually contains two or three paragraphs of general instructions. Cursor also supports a .cursor/rules/ directory of individual rule files for more granular control. Both are fine for broad guidance, but neither gives your AI assistant real domain depth out of the box.

cursor-claude-personas packs in:

Multiple focused rule files — each covering a specific concern (schema design, security, pagination, query patterns, etc.) rather than one sprawling blob of text.
Skill documents — structured reference files that are automatically surfaced when the AI detects it needs them, without you prompting it.
Both tool formats simultaneously — the same expertise loads whether you are using Claude Code, Cursor, or VS Code Copilot.
Zero prompt engineering on your part — you copy two folders and you are done.

The key design principle is depth over breadth: one sharp specialist beats five vague generalists.

Real-World Example

Imagine you are building a Python REST API with PostgreSQL. You copy in the senior-python-developer persona. From that point on, when you write a query, the AI:

Warns you against WHERE id IN (SELECT ...) and rewrites it as WHERE id = ANY(ARRAY[...]) with a note about the 10× speedup.
Adds WHERE deleted_at IS NULL partial indexes automatically when it sees soft-delete columns.
Flags missing foreign key indexes before you even run EXPLAIN ANALYZE.
Enforces proper connection pool limits and prepared statement patterns.

None of that required you to type a single instruction. It was all encoded in the rules and skills you copied in.

How the Folder Structure Works Under the Hood

Each persona ships with two kinds of config files:

Rules (`rules/`)

Rules are always-on markdown files the editor reads at the start of every session. They define the persona's defaults, code style, anti-patterns to avoid, and domain-specific best practices. They are named with a rules-- prefix so they sort together and are easy to identify.

Skills (`skills/`)

Skill documents are structured markdown files with YAML frontmatter. The auto-skill router rule tells the AI to load the relevant skill when it detects you are working on a related task. For example, if you start writing an index migration, the SQL indexing skill is surfaced automatically. If you start wiring up an authentication flow, the auth skill fires.

This means the AI pulls in deep, specific guidance exactly when it is relevant — not all at once, cluttering its context.

Switching Personas Mid-Project

You can swap personas at any time. Just delete the existing .claude/ and .cursor/ folders in your project and copy in a different persona. Reopen your session and the new persona is live.

You can even mix rules from multiple personas manually if you know what you are doing, but most of the time a single focused persona is all you need.

Contributing a New Persona

The project is open source under the MIT license and welcomes contributions. If you want to add a new persona:

Fork the repository.
Create a new folder named after the role (e.g., data-science-researcher).
Add matching .claude/ and .cursor/ subdirectories with rules and skills.
Make sure the two directories are in sync — the parity check in CONTRIBUTING.md validates this.
Open a pull request.

See CONTRIBUTING.md for branch naming conventions, commit message format, and the full persona checklist.

Where to Get It

GitHub repository: https://github.com/ratnesh-maurya/cursor-claude-personas
GitHub Pages site (browse and filter personas): https://ratnesh-maurya.github.io/cursor-claude-personas/
License: MIT — free for personal and commercial use.

If it saves you time, star the repo. It helps other developers discover it.

Summary


What it is	38 role-based AI persona packs for Claude Code, Cursor, and VS Code
What it does	Shapes your AI coding assistant into a domain specialist — instantly
How to install	Clone the repo, copy one persona folder, reopen your editor
Time to set up	Under 30 seconds
Cost	Free and open source (MIT)
Requires	Claude Code, Cursor, or VS Code with Copilot

Clone it, copy a persona, and ship better code.

# The Rule Pattern in C#, and Why It Works So Well with the Result Pattern

Tue, 07 Apr 2026 10:01:22 +0000

The Rule Pattern in C#, and Why It Works So Well with the Result Pattern

Business rules rarely stay in one place.

A small validation starts in a command handler. Another check appears in a service. A third gets added somewhere in the domain. A few weeks later, the real business policy is scattered across the application, and nobody can see it clearly anymore.

That is exactly where the Rule pattern becomes useful.

At its core, the idea is simple. Instead of expressing business decisions as anonymous conditionals spread throughout the system, you give each rule a name and wrap it in its own object. Martin Fowler describes this style through the Specification pattern, where the statement of what satisfies a candidate is separated from the candidate itself, and those specifications can be combined into richer logic. (martinfowler.com)

In practical C# applications, especially the ones using CQRS or domain-driven design, that gives you something powerful: business rules that are explicit, reusable, and easy to reason about. (martinfowler.com)

What the Rule pattern really solves

The biggest problem is not that business checks exist. The problem is that they often exist in the wrong shape.

When rules are buried inside handlers, services, or controller actions, they are hard to spot, hard to test in isolation, and very easy to duplicate. The code still works, but the business language disappears.

The Rule pattern fixes that by turning each business condition into a named concept. Instead of asking developers to interpret a chain of low-level checks, the code starts speaking in terms the business would actually recognize. That is very much in line with DDD’s emphasis on modeling around the real language of the domain. (Microsoft Learn)

In other words, the pattern is not just about validation. It is about clarity.

Why it is often called the Specification pattern

If the shape feels familiar, that is because it usually is. What many teams call a Rule pattern is very close to what Fowler documented as Specification. The core idea is to represent business criteria as composable objects rather than raw conditionals, and then combine them with logical operations like AND, OR, and NOT. (martinfowler.com)

That is why this pattern tends to feel so natural in real systems. Business rules are rarely isolated. More often, they are layered:

A customer must be verified.
An order must reach a minimum amount.
A credit limit must not be exceeded.

On their own, each rule is simple. The real value appears when they can be combined into a meaningful policy.

Why this pattern becomes more valuable as the system grows

At first, a few inline checks seem harmless. But as the application grows, the cost of hidden business logic grows with it.

Rules get copied into multiple workflows.
One endpoint enforces them, another forgets.
A handler applies three checks, a background job applies only two.
Tests start focusing on branches instead of policies.

When rules become standalone concepts, those problems start to shrink. You can test a rule directly. You can reuse it in multiple flows. You can combine it with other rules. Most importantly, you can read the application flow and understand what it is trying to protect.

That is one of the reasons this pattern fits so well in systems that care about maintainability.

Where the Result pattern fits

The Rule pattern answers one question:

Is this action allowed according to the business?

The Result pattern answers another:

What happened when we tried to perform it?

That separation is the reason the two patterns fit together so well.

The rule evaluates business truth.
The result communicates application outcome.

Vladimir Khorikov’s writing on Result-based error handling makes this distinction especially useful for expected failures. Instead of throwing exceptions for normal business rejections, you can return an explicit failure outcome and keep the flow predictable. (Enterprise Craftsmanship)

That gives you a very clean mental model:

The domain decides.
The application reports.

Why this pairing feels so clean in practice

A good rule object should not care about HTTP, API responses, logging, UI wording, or transport concerns. Its responsibility is much smaller. It answers whether a business condition holds.

The application layer then takes that answer and decides what to do next. If the rule fails, the application can return a failure result. If it passes, the use case continues.

This separation lines up well with Microsoft’s DDD guidance, which treats validations as invariants and emphasizes that aggregates are responsible for enforcing consistency across state changes. (Microsoft Learn)

That is why the combination works so well. The rule keeps business logic clean. The result keeps flow control clean.

A simple order example, without the code

Imagine an order placement use case with three policies:

The order must meet a minimum amount.
The customer must be verified.
The order must stay within the customer’s credit limit.

Without a rule-based approach, those checks often end up inline inside the command handler. That works, but the handler slowly becomes the place where business policy lives.

With a rule-based approach, those policies become named rules. The handler simply coordinates the workflow: load data, build the order, evaluate the rule set, return a success or failure result, and persist when everything is valid.

That is a much healthier separation of concerns.

The handler stops being the place where business logic is invented, and becomes the place where business logic is orchestrated.

The biggest benefit is not flexibility, it is readability

People often talk about this pattern in terms of reuse or composability, and those are real benefits.

But the biggest benefit is readability.

When rules are named well, the code starts reading like a business conversation instead of a technical negotiation. That matters more than people think. Clear code reduces mistakes, speeds up maintenance, and makes onboarding easier for everyone who touches the system later.

A long chain of conditionals tells you how the system behaves.

A well-named rule tells you why.

One important design note

There is one trap worth mentioning.

Just because a rule is expressed cleanly does not automatically mean it belongs in the application layer.

Some rules are just use-case checks. Those can live comfortably near the workflow.

But some rules are true invariants of the domain. Those should usually be protected by the aggregate itself. Microsoft’s guidance is very clear on this point: aggregates are responsible for enforcing invariants across state changes. (Microsoft Learn)

So the right question is not only, “Can I model this as a rule?”

The better question is, “Who is responsible for protecting this rule?”

If the answer is “the domain itself,” then the aggregate should not rely on the handler to remember it.

Where this pattern can go wrong

Like most good patterns, this one becomes dangerous when overused.

Not every if statement needs to become a rule object.
Not every workflow needs an entire rules engine.
Not every tiny validation deserves its own abstraction.

If the business logic is trivial and local, introducing rule classes may create more ceremony than value.

The pattern shines when the rules are meaningful, reusable, and important enough to deserve a name. If the condition is just a one-off technical check, a plain conditional may still be the better choice.

The goal is not abstraction for its own sake. The goal is to make business intent easier to see.

Why the Result pattern keeps the design honest

The Result pattern adds a second layer of clarity.

A failure is no longer hidden behind a thrown exception for something the system fully expected. Instead, the caller gets an explicit outcome. That makes business rejections feel normal rather than exceptional, which is often the right model for application workflows. (Enterprise Craftsmanship)

When paired with rules, the flow becomes very natural:

Evaluate the business policy.
If it fails, return a failure result.
If it passes, continue the operation.

That is simple, predictable, and easy to test.

Final thought

The Rule pattern is one of those ideas that looks modest at first, but pays off more and more as the codebase grows.

It helps you name business policies.
It helps you reuse them.
It helps you combine them.
And when paired with the Result pattern, it gives your application a very clean way to both enforce rules and communicate outcomes. (martinfowler.com)

If your handlers are starting to fill up with business conditionals, this pattern is often a strong sign that the code wants a better language.

And that, more than anything else, is what good domain design is really about.

Source code :

https://github.com/stevsharp/RulePatternApplication

References

Martin Fowler, Specifications. (martinfowler.com)

Microsoft Learn, Designing validations in the domain model layer. (Microsoft Learn)

Microsoft Learn, Designing a DDD-oriented microservice. (Microsoft Learn)

Vladimir Khorikov, Error handling: Exception or Result? (Enterprise Craftsmanship)

Vladimir Khorikov, Advanced error handling techniques. (Enterprise Craftsmanship)

Coder Legion - Recent posts tagged rule

Understanding Chain Rule

What is Chain Rule?

Velocity

Acceleration

Why chain rule is used?

cursor-claude-personas: Give Your AI Coding Assistant a Domain Expert Brain in 30 Seconds

cursor-claude-personas: Give Your AI Coding Assistant a Domain Expert Brain in 30 Seconds

The Problem: Generic AI Gives Generic Code

What Is cursor-claude-personas?

Supported tools

How to Use It — Step by Step

Step 1: Clone the repo

Step 2: Pick the persona that matches your current work

Step 3: Copy the persona into your project

Step 4: Reopen your editor or start a new session

Bonus: Enable the auto-skill router

All 38 Personas

What Makes This Different From a .cursorrules File?

Real-World Example

How the Folder Structure Works Under the Hood

Rules (rules/)

Skills (skills/)

Switching Personas Mid-Project

Contributing a New Persona

Where to Get It

Summary

# The Rule Pattern in C#, and Why It Works So Well with the Result Pattern

The Rule Pattern in C#, and Why It Works So Well with the Result Pattern

What the Rule pattern really solves

Why it is often called the Specification pattern

Why this pattern becomes more valuable as the system grows

Where the Result pattern fits

Why this pairing feels so clean in practice

A simple order example, without the code

The biggest benefit is not flexibility, it is readability

One important design note

Where this pattern can go wrong

Why the Result pattern keeps the design honest

Final thought

References

What Makes This Different From a `.cursorrules` File?

Rules (`rules/`)

Skills (`skills/`)