The marketplace for AI prompts, skills & packs. Ready-made packs for your trade, built for ChatGPT, Claude & Gemini, each with a start file your AI reads first.
🚀 $50 VALUE GIVEAWAY 🚀
We’re giving away $50 worth of Prompt Packs from @PromptCorrectly !
That’s 8–10 ready-to-use packs with 100+ expert prompts + installable AI skills tailored to real trades. Drop them straight into ChatGPT, Claude or Gemini and instantly get professional-level outputs.
What you actually get:
- Hours of work saved every week
- Specific, high-quality prompts (not generic “act as a…” stuff)
- Yours forever — pay once, keep forever (no subscription)
- Real productivity upgrade most people pay for
How to enter (takes 10 seconds):
1. Like this post
2. Repost
3. Follow @PromptCorrectly
Deadline: Sunday, November 21, 2026 (11:59 PM EET)
Winner picked randomly and announced right after. One lucky person gets the full $50 pack credit.
This is one of the highest-value AI giveaways you’ll see this month. Don’t sleep on it.
#AIPrompts #Giveaway #ChatGPT #PromptEngineering #ClaudeAI #Web3Community #Prompting #Prompt
"Help me with this email" is not a task.
The model guesses who is rejected, how warm to stay, and how long it is.
Try: "Two-paragraph rejection. Keep the relationship warm. No new promises."
If you cannot name the deliverable, you are not ready to prompt.
When a draft is wrong, do not rewrite the whole prompt.
Change one block.
Tone off? Change only the role.
It rambled? Change only the format.
It invented facts? Change only the constraints.
Two changes at once, and you will not know which one saved you.
Most bad AI output is not a bad model.
It is the gap between what you meant and what you typed.
The model spent its capacity guessing the audience, the length, and the point. You had already decided those. You just did not say them.
What did you leave out last time?
The prompt that gets saved is rarely the clever one. It’s the one that removes the next 3 decisions the user has to make. That’s the filter we now use for every pack we list. If your current prompts still require you to rewrite half the output, they’re not finished. What’s the last prompt you used that actually saved you time instead of creating more work?
FREE: Test Plan for an App You Built With AI
ROLE: You are a QA lead who works with small teams and solo builders. You know you can't test everything, so you test what would hurt most if it broke, and you make testing a habit rather than an event.
CONTEXT: The app: [APP_DESCRIPTION]. Stack and test tools available: [STACK_AND_TOOLS]. Main user flows: [FLOWS] (sign up, onboarding, the core action, payments, settings). Past bugs that reached users: [PAST_BUGS]. How often I release: [RELEASE_RHYTHM]. Who can help test: [TESTERS].
TASK:
1. Rank the flows by damage if broken (money, data loss, lock-out, embarrassment).
2. For the top five flows, write test cases: steps, expected result, test data.
3. Add edge cases people forget: empty states, long text, slow network, expired session, double-clicking pay, mobile screens.
4. Choose three to five automated tests worth writing first and describe each simply.
5. Write the instruction for my AI coding tool to create those tests without changing app code.
6. Write a manual pre-release checklist that takes 15 minutes.
7. Plan a small beta group and how they report bugs (what to include).
8. Write a bug report template.
9. Set rules: when a release must be stopped, and how to roll back.
10. Plan monitoring after release: error tracking, key actions per day, payment failures.
11. Suggest how the plan grows as the app grows.
CONSTRAINTS:
- Focus on user-visible behaviour, not internals.
- Test data never uses real customer information.
- Keep the manual checklist to one page.
- Plain language throughout.
OUTPUT FORMAT:
1. Flow ranking · 2. Test cases (Flow | Steps | Expected | Data) · 3. Edge cases · 4. First automated tests
5. AI instruction · 6. Pre-release checklist · 7. Beta plan · 8. Bug report template
9. Stop and rollback rules · 10. Monitoring · 11. Growing the plan
FREE :
ROLE: You are a test engineer who prefers a few honest integration tests over hundreds of mocks that lie. You make tests isolated, deterministic and fast, so the team actually runs them before every push.
CONTEXT: The API and its main flows: [API_FLOWS]. Database and ORM or query builder: [DATABASE]. Test runner and current tests: [TEST_STACK]. Auth mechanism the tests must pass: [AUTH]. External services the API calls (payments, email, storage): [EXTERNALS]. CI environment: [CI].
TASK:
1. Choose which flows deserve integration tests (critical paths, money, permissions) and which stay as unit tests.
2. Set up the test database: how it starts (container, local instance, per-run schema), migrations, and teardown.
3. Isolate tests: transactions rolled back per test, unique data per test, or truncation — with the trade-offs and your choice.
4. Write fixture factories for the main entities with sensible defaults and overrides.
5. Write auth helpers to create a user and authenticated requests in one line.
6. Fake [EXTERNALS] at the boundary (fake servers or adapters), never in the middle of business logic.
7. Write example tests for one happy path, one validation failure, one permission failure and one external-service failure.
8. Configure [CI] to run them in parallel within a time budget, and report flaky tests.
CONSTRAINTS:
- Tests must not depend on order or on data from other tests.
- Never point tests at a production or shared database.
- No sleeps; wait on conditions.
- Keep the whole suite under a target time you state, with a plan if it grows.
- Check runner and ORM APIs against [TEST_STACK] and [DATABASE].
OUTPUT FORMAT: Test scope (table: Flow | Integration | Unit) · Database setup (config + code) · Isolation strategy · Factories (code) · Auth helpers (code) · External fakes · Example tests (code) · CI configuration · Flake policy.
Role: Chief of staff or BD lead who has written 40+ strategy memos and watched which ones drive decisions vs which die in review.
Context: Decision needed: [the specific call]. Audience: [exec team / board / founders]. Time-pressure: [why this needs to be decided by when]. Options on the table: [list, briefly]. The implicit option being ignored: [if any].
Task: Write the memo.
1. TL;DR (3 sentences max): the decision needed + your recommendation + the strongest counter-argument.
2. Context (1 paragraph): why this decision is on the table now. What changed.
3. Options: each one with: description, what we'd do first 30 days, expected outcome, biggest risk.
4. Recommendation (1 paragraph): which option + why. Be willing to be wrong.
5. Risks: 3 specific risks of your recommendation, ranked by likelihood + impact. For each: the mitigation.
6. Open questions: 2-3 things the decision-makers should weigh in on before signing off.
Constraints:
- ≤2 pages (≈800 words)
- TL;DR must include the counter-argument
- Every option has a 30-day first move
- No hedge in the recommendation paragraph — say what you think
- Risks are specific, not generic ("market conditions")
Output format: Markdown memo · 6 sections · ≤800 words · ready for a 30-min review meeting.
You can read every title.
A free account opens 274 prompts in full, a starter skill in each field, the foundation courses, and 30 tailoring runs a month.
The rest is a plan. The samples are not a locked door with a fake handle.
There are two businesses pretending to be one:
A) they improve today's output, and you rent that forever
B) they improve how you think, and you can leave
Cancel A: the magic leaves with the login.
Cancel B: you still know how to write the prompt.
We built B. On purpose.