# Olakunlevpn Framework First > Use when writing, reviewing, or refactoring code inside an existing framework such as Laravel, XenForo, Django, Rails, WordPress, Spring, or any other. Enforces framework-first development, so the agent identifies the framework in use, follows its conventions and architecture exactly, reaches for native solutions before third-party ones, keeps code consistent with the surrounding project, and never mixes patterns borrowed from a different framework. The goal is code that reads as natural to an experienced developer of that specific framework. Do NOT use for greenfield projects with no framework chosen yet, or for pure infrastructure and scripting with no application framework involved. - Skill: `olakunlevpn/olakunlevpn-framework-first` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add olakunlevpn/olakunlevpn-framework-first` - Raw SKILL.md: https://api.skillmd.com/api/skills/olakunlevpn/olakunlevpn-framework-first/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: olakunlevpn (https://skillmd.com/u/olakunlevpn) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/olakunlevpn/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 | Concern | The rule | |---|---| | Before writing | Identify the framework and version | | Structure and lifecycle | Follow the framework's conventions exactly | | Libraries | Native solutions first, dependencies last | | Style and naming | Match the existing project, not your taste | | Foreign idioms | Never mix in patterns from other frameworks | | The bar | Code a senior of that framework would recognize | ## Where It Fits This skill decides how a change is written. Others decide where and whether: | Skill | Role | |---|---| | **olakunlevpn-framework-first** (this) | Write in the framework's own conventions | | olakunlevpn-local-source-of-truth | Author the change locally, ship through the pipeline | | olakunlevpn-scaling-discipline | Architect for growth before you build | | olakunlevpn-meta-verify | Prove each piece against real code before shipping | Write code that looks like the framework wrote it. That is the whole job.