Olakunlevpn Framework First

Framework First -- Write Code That Belongs

You are a developer joining a codebase that already made its architectural choices. It runs on a framework, and that framework has opinions. Your job is not to impose your favorite patterns on it. Your job is to write code that an experienced developer of that framework would nod at and move past, because it looks like it was always there.

Every framework has a grain. You work with the grain, not against it. The moment you paste a pattern from a different framework, the code reads as foreign, fights the tooling, and confuses the next person.

SECURITY: Use the framework's own security primitives, not your own. Its escaping, its CSRF protection, its query builder, its auth guards, its validation. Rolling your own around a framework that already solved it is how injection and auth holes get in.

When to Use (Auto-Trigger)

Load this skill automatically. Do not wait to be asked. Run it when ANY of these happen:

• Writing or reviewing code inside an existing framework.
• Adding a feature to a project built on Laravel, XenForo, Django, Rails, WordPress, Spring, or similar.
• Choosing between a native framework solution and a third-party library.
• About to copy a pattern you learned in a different framework.
• Refactoring code that feels foreign or inconsistent with the rest of the project.
• Anyone asks "is this the right way to do it in [framework]?".

The Rules

1. Identify the framework before you write a line

Rule: Know exactly what you are building on, and which version.

• Find the framework and its major version before touching anything. The idioms change between versions.
• Read a few existing files in the area you are about to work in. The project already shows you how it does things.
• Frameworks named as examples here (Laravel, XenForo, Django, Rails, WordPress, Spring) all differ. What is idiomatic in one is wrong in another.

Why: You cannot follow conventions you have not identified. Guessing the framework is how foreign code gets in.

2. Follow the framework's conventions and architecture exactly

Rule: Do it the framework's way, not your way.

• Directory layout, naming, lifecycle hooks, service registration, routing, the request flow. Match what the framework prescribes.
• Put logic where the framework expects it to live. Controllers thin where the framework wants them thin. Models, services, listeners, add-ons, plugins, wherever the framework's architecture says.
• Use the framework's generators and scaffolding when it provides them. They encode the conventions for you.

Why: Conventions are shared memory. When you follow them, every other developer already knows where your code is and how it behaves. When you break them, everyone has to relearn your corner of the codebase.

3. Native solutions first

Rule: Reach for what the framework already gives you before adding a dependency.

• Most frameworks ship an ORM, a router, validation, queues, events, auth, caching, and templating. Use them.
• Only add a third-party library when the framework has no native answer, or the native answer genuinely does not fit.
• A native solution stays compatible across upgrades. A bolted-on library is one more thing that can break when the framework moves.

Why: The framework's own tools are tested against the framework, documented for it, and understood by everyone who knows it. A dependency you did not need is surface area you did not need.

4. Stay consistent with the existing project

Rule: Match the code that is already there, not the code you would write from scratch.

• Follow the project's existing style, structure, and naming even where you would personally choose differently. Consistency beats personal preference.
• If the project has a way of solving a class of problem, solve your problem the same way.
• When you spot a genuinely better pattern, raise it as a deliberate, project-wide change, not a one-off you sneak into a single file.

Why: A codebase with one voice is easy to read. A codebase where every file reflects a different developer's taste is exhausting and error-prone.

5. Never mix patterns from other frameworks

Rule: Do not import idioms from a framework this project does not use.

• The way Rails does a thing is not the way Laravel does it, and neither is the way Django does it. Do not carry one framework's habits into another.
• No parallel structures that shadow the framework's own. No custom router next to the built-in one. No hand-rolled ORM layer over the native one.
• If you catch yourself recreating a feature the framework already provides because it is how your last framework did it, stop and use the native feature.

Why: Mixed patterns are the worst of both worlds. The code does not match this framework's docs, does not match the other framework either, and fights the tooling of both.

6. Aim for code an expert of that framework would recognize

Rule: The target is code that feels native to a senior developer of that specific framework.

• Ask yourself the test. Would an experienced developer of this framework read this and see nothing surprising?
• Idiomatic code is faster to review, easier to onboard onto, and cheaper to maintain, because it uses the shared vocabulary of the framework's whole community.
• Cleverness that departs from the framework's norms is a cost, not a feature. Boring and idiomatic wins.

Why: Code is read far more than it is written. The highest compliment your code can earn is that no one noticed it, because it looked exactly like it belonged.

The Test

Before you finish, run every change through one question:

Would an experienced developer of this exact framework, at this exact version, read this and think "yes, that is how you do it here"?

If yes, ship it. If it would make them pause, squint, or ask "why did they do it that way", it is not idiomatic yet. Fix it before it becomes the pattern the next person copies.

Recap

Where It Fits

This skill decides how a change is written. Others decide where and whether:

Write code that looks like the framework wrote it. That is the whole job.