A prompt engineer built a system prompt that turns Claude (or any model) into a full Chrome extension dev team, not a code vending machine. Thirteen steps, each one needs your approval before the next one starts. No skipping. No dumping 400 lines of JavaScript before you’ve even agreed on what the extension does.
Most “vibe coding” prompts do the opposite of this. You type an idea, you get code, and you find out about the missing permissions or the broken content script three debugging sessions later. Sometimes it’s worse: you ship the thing, a user installs it, and only then do you find out about the missing permissions, either from a Chrome Web Store rejection email or a one-star review about a popup that never loads. This one, posted to r/PromptEngineering under the name ChromeExtensionCoder (CEC), forces the model to slow down on purpose. It treats every stage like a real gate you have to walk through, not a suggestion the model can skim past on its way to writing code.
How it’s structured
The prompt walks through discovery, requirements, solution modeling, architecture, tech stack, file structure, technical design, implementation, testing, code review, security review, documentation, and final delivery. Thirteen stops, in that order, every single time. You can’t jump from “I want a tab manager extension” straight to a manifest.json file. The model has to ask what problem you’re solving, what the user actually does with the extension day to day, and what “done” looks like before it writes a single line of code.
A few things worth stealing for your own prompts:
- It assigns roles. The model isn’t just “an assistant,” it’s told to act as requirements analyst, architect, developer, code reviewer, and QA engineer in sequence. That role-switching keeps each phase focused instead of blending planning and coding into one mushy output. When the model is wearing the “architect” hat, it’s not also trying to write test cases in the same breath, so each stage’s output stays sharp enough to review on its own.
- It has a checkpoint rule. When the context gets too big, the model is told to stop and say “checkpoint reached, we can continue implementation” instead of quietly truncating or hallucinating the rest. Anyone who has watched a model confidently invent a function it never actually wrote three messages ago knows why this matters. A checkpoint is an admission of limits, and that’s rarer than it should be in most coding prompts.
- It bakes in a real security review. Excessive permissions, Content Security Policy, XSS, injection, message validation, OAuth, cookie handling. Most extension prompts skip this entirely, and it’s exactly the part that gets extensions pulled from the Chrome Web Store. A permission like “read and change all your data on all websites” sounds harmless in a manifest file until a reviewer, or a user, asks why a note-taking extension needs it. Baking the review into the process instead of hoping you remember it at the end catches that stuff before it becomes a rejection notice.
- It sequences implementation file by file, in dependency order. That sounds small, but it means the model isn’t guessing what a background script needs from a content script that doesn’t exist yet. Each file gets written against real code instead of an imagined API, which is exactly where a lot of AI-generated extensions fall apart once you actually try to load them.
Use cases
- 🧩 Building any Chrome extension where you actually want to ship it, not just prototype it. If you’re planning to submit to the Chrome Web Store, the security and documentation stages alone will save you a rejection cycle or two.
- 🔒 Teaching a model to treat security review as a mandatory gate, not an afterthought. This holds up well outside of extensions too. Any time you’re generating code that touches user data, permissions, or third-party APIs, forcing a dedicated security stage catches things a single “write me the code” prompt never will.
- 🛠 Adapting the 13-step skeleton for other coding domains: VS Code extensions, CLI tools, browser add-ons, anything where “just write the code” tends to produce something half-finished. Swap “Chrome extension” for “CLI tool” and the stages barely need to change. Discovery, requirements, and architecture matter just as much for a command line tool as they do for a popup UI.
Prompt of the day
You are [ROLE], a specialist engineer for [PROJECT TYPE]. Your job is to turn an idea into a complete, secure, production-ready [DELIVERABLE]. Act as requirements analyst, architect, developer, code reviewer, and QA engineer, one role at a time. Work in defined stages: idea discovery, requirements, solution modeling, architecture, tech stack, project structure, technical design, implementation (one file at a time, in dependency order), testing, code review, security review, documentation, final delivery. Never skip a stage. Always explain your key technical decisions. Always ask for approval before moving to the next stage. If context gets too large, stop and say so explicitly rather than compressing or guessing.
Swap the brackets for your project and you’ve got a system prompt that won’t let the model cut corners. Drop in “solo developer” or “startup engineering team” as the role, whatever fits, and the structure holds up without much extra tweaking.
If you’ve been getting burned by AI-generated code that looks done but isn’t, this staged-approval structure is worth copying into your own prompts. Try it on your next side project and see how much further you get before something breaks.
Prompt vibe coding: Desenvolvimento de Extensões
by u/Ornery-Dark-5844 in PromptEngineering