https://preview.redd.it/me8kgh3oii2h1.png?width=1585&format=png&auto=webp&s=c9d365912049b61dbef266c06a0de2c1572e899d

https://preview.redd.it/8by3uibqii2h1.png?width=1620&format=png&auto=webp&s=29188383eca9eabcb27eecf3ff4a19edee012a4f

So, after 3 days of launching I got 10 installs and two 5-star ratings on my extension PromptForge ( ChatGpt prompt Enhancer).
I'm so excited!!!

https://chromewebstore.google.com/detail/promptforge-%E2%80%94-ai-prompt-e/mhjailanhenjkhjgkjakoobkmgjpkgjp?authuser=0&hl=en-GB

I built it after rejecting three time by chrome web store.

ExtGuard(https://www.extguard.online/): Validate your chrome extension before submitting it to chrome web store and save your weeks.

On chrome web store, it take 4-5 days for publishing the extension if you don't have any error. But It might take weeks because of some small errors. So validate your extension, know your chances of approval.

ExtGuard(https://www.extguard.online/): Validate your chrome extension before submitting it to chrome web store and save your weeks.
On chrome web store, it take 4-5 days for publishing the extension if you don't have any error. But It might take weeks because of some small errors. So validate your exetsnion, know your chances of approval.

Chrome Web Store rejections are weirdly demoralizing — not because they're hard to fix, but because you find out 5–17 days after submitting, for something a script could've flagged in 30 seconds.

After going through it myself and talking to a lot of developers who did too, the same five patterns come up over and over.

1. Overly broad host permissions

Requesting `<all_urls>` or `*://*/*` when your extension only ever talks to one API endpoint. Google reviewers are specifically trained to check permission-to-functionality match. If the scope is wider than what your code actually does, expect a flag.

Fix: lock `host_permissions` to exactly the domains your extension contacts. If you genuinely need broad access, your store listing description needs to explicitly justify why.

2. `eval()` or `new Function()` buried in your build output

You didn't write it. A dependency did. Doesn't matter — it violates MV3's Content Security Policy and your submission gets rejected. The brutal part: the rejection often doesn't tell you where it is.

Before you zip: `grep -r "eval(\|new Function(" ./dist")

One command. Do it every time.

3. Description compliance — and there are two separate fields

The Web Store enforces limits on:

- Short description (132 char max)

- Detailed listing description

- The description field *inside the developer dashboard* (separate field, separate rules)

These are checked independently. You can pass two and fail the third. Know which field you're editing.

4. Icons declared in manifest.json but missing from the zip

You have `icons/icon128.png` in your local project. You reference it in the manifest. You forget to include it in the production build. Rejection.

Fix takes 10 seconds: open your zip, manually verify every icon path listed in the manifest exists at that exact path. It's case-sensitive.

5. Privacy policy URL that doesn't resolve

If your extension touches user data in any way — even just `chrome.storage.sync` for preferences — you need a publicly accessible privacy policy URL in your listing. Not a Notion page behind a login. Not a URL that 404s. Something that loads, publicly, before you hit submit.

Every single one of these is catchable before submission. None of them require a human reviewer.

After getting burned by three of these across 17 days of waiting, I built ExtGuard — a browser-based validator that runs 25 of these checks on your zip locally before you submit. Nothing leaves your machine.

But even if you skip the tool — bookmark these five. They're responsible for a huge chunk of first-submission rejections.

What rejection reasons have you run into that aren't on this list?

Is anyone of you know how much time it will take to get credentials from Swiggy builders club?

I have submitted the form for my SaaS Nutriguard (health tracker built on top of Swiggy MCP) a week ago. But didn't get any response from Swiggy team.

What to do?

One thing I’ve noticed while using ChatGPT heavily for technical learning is that most disappointing answers come from vague inputs rather than weak models.

A lot of prompts look like:

• “Teach me React”
• “Explain APIs”
• “Help me debug this”

The model responds correctly, but the output becomes generic because the request itself lacks:

• context
• constraints
• desired depth
• target outcome

Small changes in phrasing drastically improve results.

For example:

Instead of:

>

Something like:

>

…usually produces much more useful responses.

Same model, completely different outcome.

It feels like interacting with AI is becoming less about “searching” and more about communicating requirements clearly.

Curious whether others have noticed the same thing.

Hey all!
I have built my first chrome extension ( PromptForge- AI prompt enhancer), i tested it and submitted it on the chrome web dashboard, after three days i got a rejection email because of a very small thing in my privacy policy. On the same day I re-submitted it and it's not still got approval. It's now 5 days.
I don't know what to do?
Does web store usually takes this much of time or web is treating me specially?
Have anyone of you faced the same?

I spent weeks testing why ChatGPT ignores instructions.

The biggest anti-patterns I found:

• Huge walls of text
• Conflicting instructions
• “Write professionally”
• No output format
• Generic prompts like “don’t hallucinate”

The weird discovery:
Prompting works better when you treat it like writing an API contract instead of chatting casually.

I built these rules into a Chrome extension I’ve been working on called PromptForge.

Looking for a few heavy ChatGPT users who enjoy breaking products.

I spent weeks testing why ChatGPT ignores instructions.

The biggest anti-patterns I found:

• Huge walls of text
• Conflicting instructions
• “Write professionally”
• No output format
• Generic prompts like “don’t hallucinate”

The weird discovery:
Prompting works better when you treat it like writing an API contract instead of chatting casually.

I built these rules into a Chrome extension I’ve been working on called PromptForge.

Looking for a few heavy ChatGPT users who enjoy breaking products.

I realized most bad ChatGPT outputs are caused by bad instruction structure, not the model itself.

The framework that improved my prompts the most:

• Context → who the AI is
• Rules → hard constraints
• Examples → tone anchors
• Format → exact output structure

The biggest mistake:
People keep adding more instructions when the output gets worse.

Usually shorter + clearer prompts work better.

I got tired of rewriting prompts manually every day, so I built a small Chrome extension that restructures them automatically while using ChatGPT.

Still waiting on Chrome approval, but curious if anyone else noticed prompt quality dropping with longer prompts.