Fortune Checklist

/fortune-checklist — autonomous launch QA

The user types /fortune-checklist (optionally with a plain-language hint) and you do everything else. Never make the user pick flags, options, or paths. Infer scope and target from what they said and from the repository itself. The scripts and reference files below are tools you drive — the user never touches them.

The full catalogue is 518 checks in 30 categories, 222 of them P0 launch blockers. Each check carries its own domain-tailored audit prompt (accessibility, SEO, security, performance, payments, DNS/email, …). Content lives in reference files; load only what a given run needs.

Step 0 — Read the intent (any language)

Look at whatever the user typed alongside the command.

• Nothing extra → run the full audit (all applicable categories, P0 first).
• A topic (e.g. "security", "SEO", "راجع السيكيوريتي", "شوف الأداء") → audit only the

matching categories from the map below.

• "P0" / "blockers" / "المهم" / "الحرج" → audit only the 222 launch blockers.
• A named repo/path/URL → use it as the target instead of the default.

Do not ask the user to confirm the mapping unless it is genuinely ambiguous — infer and proceed, and state what you scoped to in one line.

Intent → categories map (EN + AR keywords)

| If they mention… | Audit these categories | |---|---| | security, secure, أمان, سيكيوريتي, اختراق | Application Security; Authentication & Authorization; Privacy, Cookies & Legal | | auth, login, تسجيل دخول, صلاحيات | Authentication & Authorization; Application Security | | seo, سيو, ظهور جوجل, أرشفة | Technical SEO; Structured Data & Social Sharing | | accessibility, a11y, وصول, إتاحة, ذوي الهمم | Accessibility | | performance, speed, أداء, سرعة, بطء | Performance & Core Web Vitals; Frontend Code Quality | | responsive, mobile, موبايل, الجوال, الشاشات | Responsive Design & Device Layout; Browser & Device Compatibility | | payments, checkout, e-commerce, دفع, متجر, مدفوعات | E-commerce & Payments | | forms, نماذج, فورم, رفع ملفات | Forms & Data Entry | | content, brand, محتوى, علامة, هوية | Content & Brand Quality | | api, backend, باك اند, سيرفر | Backend & API Quality; Database & Data Integrity | | database, بيانات, قاعدة بيانات | Database & Data Integrity | | i18n, rtl, لغات, عربي, ترجمة, اتجاه | Internationalization, Localization & RTL | | pwa, تطبيق ويب, أوفلاين | PWA & Service Worker | | infra, deploy, نشر, استضافة, dns, ssl, دومين | Infrastructure & Deployment; Domain, DNS, SSL & Email DNS | | monitoring, logs, مراقبة, لوجز | Monitoring, Logging & Alerting | | backup, نسخ احتياطي, استعادة | Backups & Disaster Recovery | | email, بريد, إيميل, إشعارات | Email & Notifications | | analytics, تتبع, تحليلات | Analytics & Marketing Integrations | | legal, privacy, خصوصية, قانوني, كوكيز | Privacy, Cookies & Legal | | tests, qa, اختبارات, جودة | Testing & Quality Assurance | | handover, docs, تسليم, توثيق | Handover & Documentation |

The exact category filenames are in references/categories-index.md.

Step 1 — Find the target (default: here)

Default to the repository in the current working directory. If the user named a project, path, or URL, use that. If there is genuinely no repo to audit, that's the one time to ask — otherwise just proceed.

Step 2 — Profile the project (explore, be smart)

Before auditing, learn what the project actually is so you can scope out irrelevant checks. Inspect quickly and cheaply: package.json/lockfiles and dependencies, the framework and router, config files, and the presence of these capabilities. Each present capability turns on its Applies-To group; each absent one lets you mark those checks N/A.

| Signal in the repo | Turns on | |---|---| | public marketing pages / SSR site | Public Websites, Tracking Sites | | cart, products, checkout, Stripe/Paymob/PayPal | E-commerce, Payments, Transactional Apps | | auth (next-auth, sessions, JWT, Supabase auth) | Authenticated Apps, OAuth/SSO, Token Apps | | DB / ORM (Prisma, Drizzle, Supabase, SQL) | Data-backed Apps, Critical Writes | | API routes / webhooks | APIs, Public APIs, Webhook Integrations | | forms / file uploads | Public Forms, File Uploads, Lead Generation | | i18n / locale routing / dir="rtl" / Arabic | Multilingual Sites, RTL Sites | | manifest.json + service worker | PWA, Push Notifications | | email sending (Resend, nodemailer, edge fns) | Email-enabled Apps, Marketing Emails | | admin / CMS routes | CMS / Admin | | Dockerfile / compose / cron / queues | Containerized Apps, Background/Scheduled Jobs |

Applies To: All (261 checks) always applies. When unsure whether a group applies, keep it in rather than dropping it — a false N/A hides real risk.

Step 3 — Scope

Load assets/checklist.json. Keep every All check plus the checks whose Applies-To is in your enabled set (and, if the user named a slice in Step 0, only those categories). Mark the rest N/A — not applicable to this project type so the report is honest.

Step 4 — Audit with each check's own prompt

For each in-scope category, run its checks using their exact tailored prompts — pull them from the category file or with python scripts/get_prompt.py (also --category "" or --p0). Run each prompt verbatim against the target; don't paraphrase. Every prompt already demands the six-section contract in references/audit-protocol.md: Status / Evidence / Gaps / Fix / Verification / Changed files.

Order: P0 first, then the rest. For a full audit this is large, so fan categories out across subagents and consolidate — give each subagent one category, the repo path, and its checks' prompts, and have it return structured per-check results. Keep it moving; you don't need the user in the loop while it runs.

The rule that gives this its value: never mark PASS without direct evidence. Anything provable only outside the code (DNS, SSL, live payments, real email, analytics, a physical device, client sign-off) stays PARTIAL with the exact manual step written out.

Step 5 — Report (and offer fixes)

Consolidate into a GO/NO-GO report and save it as fortune-checklist-report.md in the project. Also scaffold a tracking sheet with python scripts/new_run.py .csv if a spreadsheet is wanted.

#  — Launch QA ()
Scope:  · applicable checks /518 · P0 in scope 

Status: PASS  · FAIL  · PARTIAL  · N/A 

## Launch blockers still open (P0 not PASS)
- FC-XXX-000 —  — FAIL/PARTIAL — 

## By category
 — PASS/FAIL/PARTIAL/N/A

## External verifications outstanding
- 

## Verdict: GO / NO-GO

Auditing is safe and autonomous. Applying fixes is not — the tailored prompts include a fix step, but do not mass-edit a whole codebase unattended. Finish the audit, then offer: "want me to fix the P0 FAILs?" and apply fixes in reviewed batches (P0 first), running the strongest available checks after each.

Autonomy rules

• Infer scope and target; don't ask the user for flags, paths, or options.
• State in one line what you scoped to, then run.
• The only reasons to pause: no repo found, or a fix step that is genuinely destructive

with unclear intent.

Reference map (tools you drive)

• references/audit-protocol.md — output contract + status/safe-change rules. Read first.
• references/categories/NN-*.md — per-category checks, each with its exact prompt embedded.
• scripts/get_prompt.py — print any check's prompt (`, --category, --p0, --all`).
• scripts/new_run.py — scaffold a tracking CSV (--p0-only, --applies, --category).
• references/launch-blockers.md — the 222 P0 checks.
• references/categories-index.md — the 30 categories with counts + filenames.
• references/official-references.md — Google, WCAG 2.2, OWASP, Core Web Vitals, PCI, DMARC.
• assets/checklist.json — full machine-readable data including every check's prompt.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Fortune-Code-Digital-Sloutions
• Source: Fortune-Code-Digital-Sloutions/fortune-checklist
• License: MIT
• Homepage: https://www.fortunecode.org/

Install and usage instructions live in the source repository linked above.