Scenario Cookbook
Small everyday needs — each with a copy-ready prompt. Covers office work, data cleanup, and daily e-commerce tasks.
Desktop
Turn one Excel into a polished daily report
Manual Excel-to-PPT reporting is slow. Generate an image/PDF instead.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: manual Excel-to-PPT daily reporting is too slow; generate a shareable image/PDF in one click.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript
- Features: import one Excel (columns: metric, value, delta) and auto-render a 1200x1800 PNG daily report plus an A4 PDF — title, 3 KPI cards, one ranking bar chart, footer.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Palette: white background, deep gray text; emphasize typographic hierarchy.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop Excel → preview report → one-click export PNG/PDF; empty data, bad format → friendly message, no crash.
- Package as Windows .exe and macOS .dmg; include a 500-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Web
Build a team file intake website
Teammates send files in chat with messy names; someone still has to chase missing submissions.
You are a senior web app engineer. Build a team file intake website:
- Goal: teammates submit files and notes through a web page; the owner sees submitted/missing people and exports a checklist.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Web app; build/deploy from Windows / macOS / Linux
- Stack: Next.js + React + TypeScript with App Router; browser local storage for submission state; npm run build must pass
- Features: 1. Home dashboard: submitted / missing / needs-fix counts.
2. Submit form: name, department, file type, note, upload; each submission creates a record.
3. Owner view: filterable table with file name, submitted time, status, notes.
4. Missing list: paste or seed an expected-name list; auto-detect who has not submitted.
5. Export: download CSV checklist and copy a missing-submission reminder message.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: open website → submit with sample roster → dashboard updates → export checklist → copy missing reminder; refresh keeps records.
- Deliver a deployable web app; README documents npm run dev / build / start plus Vercel, Cloudflare, or Node deployment.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Initialize the website app project with TypeScript and App Router
2. Install core deps: next, react, react-dom, typescript, @types/react
3. Write a minimal app/page.tsx; confirm npm run dev opens the home page
4. Create sample-data/ or src/data/seed.ts with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with README, deployment notes, and npm run build / start verification
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Turn a pile of PDF invoices into an Excel
Dozens of PDF invoices need to become one Excel ledger.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: manually copying dozens of PDF invoices into Excel is too slow; batch-extract and organize into a ledger.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript with pdfjs parsing
- Features: drop a folder of PDFs; extract invoice id / date / seller / buyer / amount / tax / total; write an Excel ledger.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Highlight uncertain fields in yellow for manual fix.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop PDF folder → auto-extract → generate Excel; uncertain fields yellow; empty folder, non-PDF → friendly message.
- Package as Windows .exe and macOS .dmg; include a 500-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Bulk-rename files by a rule
Messy photo/video names. Rename by date + index.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: messy photo/video names need bulk renaming by date + index rules.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript
- Features: drop a folder; show the file list; rename in bulk by a template (e.g. "YYYYMMDD-{idx3}"). Preview before/after, confirm, then execute.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Undo: save a reversal map locally so users can roll back the last three operations.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop folder → file list → set rule → preview → confirm; undo rolls back last 3 operations.
- Package as Windows .exe and macOS .dmg; include a 300-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Build a tiny lookup table app
Internal handbook in Excel; teammates keep asking in chat.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: internal handbook/product list is in Excel; teammates keep asking in chat. Build a search tool so they can look it up themselves.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript
- Features: on launch, read one Excel (configurable path). Main UI: a big search box + result list. Fuzzy search any column. Cards show all fields.
- One-click copy a specific field (e.g. copy SKU to clipboard).
- Reload when Excel changes on disk, or on restart.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: launch → auto-load Excel → type keyword → results appear → one-click copy; Excel update → restart → auto-reload.
- Package as Windows .exe and macOS .dmg; include a 300-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Web
Build a shared inventory lookup website
Inventory lives on one person’s machine; sales and ops keep asking what is in stock.
You are a senior web app engineer. Build an inventory lookup website:
- Goal: turn an inventory spreadsheet into a team-accessible web lookup where SKU or product name shows stock, warehouse, and risk flags.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Web app; build/deploy from Windows / macOS / Linux
- Stack: Next.js + React + TypeScript with App Router; seed data in src/data/seed.ts; npm run build must pass
- Features: 1. Home has search, filters, and a result table.
2. Fuzzy search by SKU, product name, category, warehouse.
3. Below safety stock = yellow row; out of stock = red row.
4. Upload a new inventory CSV / Excel; preview first 20 rows and validate headers.
5. Export current filtered result as CSV.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: open website → search SKU → see stock result → upload new sheet → risk rows recolor → export filtered CSV.
- Deliver a deployable web app; README documents npm run dev / build / start and deployment.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Initialize the website app project with TypeScript and App Router
2. Install core deps: next, react, react-dom, typescript, @types/react
3. Write a minimal app/page.tsx; confirm npm run dev opens the home page
4. Create sample-data/ or src/data/seed.ts with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with README, deployment notes, and npm run build / start verification
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Track where your day goes
Unsure where your day goes. Want to log it and review weekly.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform time-tracker:
- Goal: unsure where your day goes; want to log time per task and review weekly.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + local SQLite
- Features: 1. "What are you doing" input + Start button; Stop to end.
2. Today's entries with durations.
3. Week view: group totals as a bar or pie.
4. One-click Excel export.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Small window (320x420); always-on-top option.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: enter task → start timer → stop → today's list shows duration; week view shows bar/pie; export Excel.
- Package as Windows .exe and macOS .dmg; include a 300-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
A dead-simple personal Kanban
Todo apps feel heavy. Build one that opens fast.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform personal cross-platform Kanban:
- Goal: todo apps feel heavy; build one that opens fast and just works.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + local SQLite
- Features: Three columns: Todo / Doing / Done. Drag cards. Enter to add. Double-click to rename.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Opens in the last-used view.
- Follows system dark mode.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: launch → three columns → Enter adds card → drag to move → double-click to rename; data persists on restart.
- Package as Windows .exe and macOS .dmg; include a 200-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Merge & split a pile of PDFs
Merge, split, and archive PDFs without manual steps.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: merge, split, and archive PDFs without manual steps.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + pdf-lib
- Features: 1. Merge: drop several PDFs, drag to reorder, type output filename, click merge.
2. Split: drop one PDF, type page ranges (e.g. "1-10, 11-25, 26-end"), export each range as a separate PDF.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Use online website standards; document file-processing boundaries. After completion, show "Download result" and "Open output folder" buttons.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop PDFs → merge or split → output correct; empty file, bad format → friendly message, no crash.
- Package as Windows .exe and macOS .dmg; include a 300-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Watermark and resize a batch of screenshots
Watermark, compress, and resize screenshots in one pass.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: watermark, compress, and resize screenshots in one batch pass.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + sharp
- Features: 1. Drop a folder containing .png .jpg .webp.
2. Settings: watermark image or text (corner choice), longest-edge pixels (e.g. 1600), output format (jpg/png/webp), jpg quality.
3. One-click batch with progress; output to "<originalFolder>_processed".
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop folder → set watermark/size → batch process → output correct; empty folder, non-image → friendly message.
- Package as Windows .exe and macOS .dmg; include a 300-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
One-click clean a messy CSV / Excel
System exports are messy. Clean blanks, duplicates, dates, and spaces.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: system exports are messy; clean blanks, duplicates, dates, and spaces in one click.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + xlsx + papaparse
- Features: 1. Drop a CSV or Excel; preview the first 20 rows.
2. Show a checklist of cleaning actions: remove blank rows, drop exact duplicates, trim whitespace, normalize dates (YYYY-MM-DD), convert full-width to half-width, dedupe by chosen column keeping the first.
3. Live-preview the cleaned result on the right; export to a new file when ready, leaving the original untouched.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop file → pick actions → preview → export new file; empty file, bad format → friendly message.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide, including a short section on "how to describe new cleaning rules to Codex".
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Turn meeting audio into text + key points
Summaries take too long. Keep audio processing local.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: meeting audio summaries take too long; transcribe and extract key points locally.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + local whisper.cpp (small multilingual model, auto-downloaded on first use)
- Features: 1. Drop an mp3/m4a/wav; show audio length.
2. One-click transcribe with timestamps; right pane allows manual edits.
3. After transcription, click "Extract key points" to produce a Markdown summary in three sections: Decisions / Action items / Risks (built-in prompt, editable in settings).
4. Export to .docx and .md.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Document local transcription and online-service boundaries; warn about disk space when downloading the model and provide retry on network failure.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop audio → transcribe → extract points → export .docx/.md; empty file, bad format → friendly message.
- Package as Windows .exe and macOS .dmg; include a 500-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Desktop sticky notes that boot with you
Small notes keep getting buried in chat and note apps.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: small notes keep getting buried; build a desktop sticky that boots with you.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + local SQLite
- Features: 1. A 320×480 window that lives in the top-right corner; toggleable "always on top".
2. Grouped sticky list inside: each note has a title and multi-line body; click title to expand, click again to collapse.
3. One-click copy single line to clipboard; basic Markdown (bold, links, lists).
4. Close minimizes to tray/dock; launch-at-login optional in settings.
5. All data in local SQLite; one-click export to .json backup.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: launch → note list shows → add/edit/copy → data persists on restart; empty data → friendly message.
- Package as Windows .exe and macOS .dmg; include a 300-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Bulk-convert images to the size & format you need
Different channels need different sizes. Photoshop is overkill.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: different channels need different sizes; bulk-convert without opening Photoshop.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + sharp
- Features: 1. Drop several images; list shows thumbnail, original size, file size.
2. Three preset profiles ("WeChat header 900×500 jpg", "Square social 1080×1080 jpg", "Website thumb 600 longest-edge webp"). Custom mode: longest-edge px + format + quality.
3. Two fit modes: crop by ratio, or pad with whitespace.
4. One-click batch export to a sibling "<originalFolder>_resized"; originals untouched.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Use online website standards; document local processing and online-service boundaries; show progress.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop images → pick size → batch export; empty folder, non-image → friendly message.
- Package as Windows .exe and macOS .dmg; include a 300-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Dedupe & merge a contacts / customer list
Customer lists merge into duplicates and messy formats.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: customer lists merge into duplicates and messy formats; automate deduplication.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + xlsx
- Features: 1. Drop multiple Excel/CSV files; auto-detect name / company / phone / email columns (manual override allowed).
2. Normalize: strip +86, spaces, dashes from phone; lowercase email; trim names.
3. Configurable dedupe key: phone / email / phone+name. On collision, keep the most complete row and merge other sources' notes into a "merged_notes" column.
4. Export a merged Excel plus a "removed-as-duplicate" Excel for review; originals untouched.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Use online website standards and document local processing plus online-service boundaries.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop multiple files → auto-detect → dedupe → export merged + suspicious; empty file, bad format → friendly message.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Turn a Markdown outline into a PPTX deck
Markdown drafts still need manual slide building.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform desktop tool:
- Goal: Markdown drafts still need manual slide building; convert to PPTX in one click.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + pptxgenjs
- Features: 1. Markdown editor on the left, live PPT thumbnail preview on the right.
2. Conversion rules: H1 → section cover slide; H2 → content slide title; bullets under H2 → content slide bullets (max 6, auto-paginate beyond); a triple --- inserts a transition slide.
3. Three themes (Minimal White, Dark Tech, Warm Business Orange) with one-click switch in the top bar; system fonts.
4. One-click export to .pptx; auto-save the current .md draft locally.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Use online website standards and document local processing plus online-service boundaries.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: write Markdown → live preview → one-click export .pptx; empty content, bad format → friendly message.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide, including a Markdown cheatsheet.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Merge order exports from multiple marketplaces
Order exports from each marketplace use different columns, making daily consolidation slow.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform e-commerce order merge tool:
- Goal: order exports from each marketplace use different columns, making daily consolidation slow; automate the normalization.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + xlsx + papaparse
- Features: 1. Drop multiple Excel/CSV order exports; auto-detect marketplace source, with manual template override.
2. Normalize columns into: marketplace, store, order ID, order time, SKU, product name, quantity, paid amount, freight, status, province/city.
3. Merge duplicate order IDs and flag them in red; highlight missing fields in yellow.
4. Export "merged-orders.xlsx" and "order-exceptions.xlsx"; originals untouched.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop multi-platform Excel → auto-detect → normalize → export merged + exceptions; duplicates red, missing yellow.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide, explaining how to add a new marketplace mapping.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Package product images by SKU
Product images are scattered across folders and need manual renaming before upload.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform product image packaging tool:
- Goal: product images are scattered; auto-sort and rename by SKU before upload.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + sharp
- Features: 1. Drop an image folder and a SKU mapping Excel.
2. Match images to SKUs by filename, subfolder name, or Excel mapping.
3. Batch rename to patterns like SKU-main-01, SKU-detail-01, SKU-size-01; preview before applying.
4. Check whether each SKU is missing hero, detail, or size images; export missing items to Excel.
5. Output one folder per SKU; originals untouched.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop images+Excel → auto-sort → rename preview → output packages; missing items exported.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Find daily shipment exceptions
Shipment exports hide stalled, returned, failed-delivery, and bad-address orders.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform shipment exception checker:
- Goal: shipment exports hide stalled, returned, failed-delivery orders; CS easily misses them. Auto-filter exceptions.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + xlsx
- Features: 1. Drop shipment Excel/CSV; auto-detect order ID, tracking ID, status, update time, province/city, phone.
2. Built-in rules: no update for 48 hours, failed delivery, returned, bad address, damaged, refused, keyword hit.
3. Let users adjust hour threshold and keywords in settings.
4. Output a severity-ranked exception list with masked phone numbers by default.
5. Export "shipment-exceptions-today.xlsx" with suggested support wording.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Phone masked by default.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: drop shipment Excel → auto-detect → exception list highlighted → export Excel with CS wording; phone masked.
- Package as Windows .exe and macOS .dmg; include a 300-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Generate product labels and barcode stickers
Warehouse label printing for SKUs, price tags, and bin labels is error-prone by hand.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform product label generator:
- Goal: warehouse label printing for SKUs, price tags, and bin labels is error-prone; automate it.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + bwip-js + pdf-lib
- Features: 1. Import SKU Excel with SKU, product name, barcode, spec, price, bin location, print quantity.
2. Choose label size: 40x30, 60x40, 80x50 mm, or custom.
3. Generate barcode/QR code; preview single label and full page.
4. Export PDF for A4 or thermal printer; repeat labels by quantity.
5. Long product names wrap without overflowing the label.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: import Excel → pick size → preview → export PDF; empty data, bad format → friendly message.
- Package as Windows .exe and macOS .dmg; include a 300-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Reconcile marketplace bills with orders
Marketplace bills include commission, refunds, freight, and service fees, often not matching order totals.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform marketplace bill reconciliation tool:
- Goal: marketplace bills include commission, refunds, freight, and service fees, often not matching order totals. Automate reconciliation.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + xlsx
- Features: 1. Import order sheet and marketplace bill sheet.
2. Match by order ID across sales, refunds, commission, service fee, freight, subsidy, actual settlement.
3. Calculate variance amount and likely reason; list unmatched orders separately.
4. Home view shows total orders, settlement, fees, variance, and exception count.
5. Export "bill-reconciliation-result.xlsx" with detail, exception, and summary sheets.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: import orders + bill → auto-match → differences red → home summary → export Excel with 3 sheets.
- Package as Windows .exe and macOS .dmg; include a 500-word user guide, explaining common variance reasons.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Campaign calendar and task reminders
Campaign enrollment, stock, materials, price, live sessions, and recap milestones are hard to track manually.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform e-commerce campaign calendar:
- Goal: campaign milestones are hard to track manually; automate reminders and task templates.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + local SQLite
- Features: 1. Create campaign: name, start/end date, marketplace, owner.
2. Built-in task templates: enrollment, product selection, stock, price confirmation, materials, support wording, live schedule, launch check, recap.
3. Calendar view + board view; drag tasks to change date and status.
4. Overdue tasks turn red; today's tasks export to Excel.
5. Bulk import tasks from Excel.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: create campaign → tasks generated → calendar/board view → overdue alert → export Excel.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Customer support macro library
Support macros are scattered across docs and chats, so agents find or copy the wrong version.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform customer support macro library:
- Goal: support macros are scattered across docs and chats; centralize and version them.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + local SQLite
- Features: 1. Categorize macros by logistics, refund, exchange, quality, campaign rules, invoice, complaint.
2. Large search box supports keyword and tag search; one-click copy.
3. Variable placeholders: {name}, {orderId}, {productName}; prompt for values before copy.
4. Each macro has version, updated date, applicable store, and disabled status.
5. Excel import/export; record copy count per macro.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: search macro → one-click copy → fill variables → import/export Excel; empty data → friendly message.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Creator sample follow-up board
Sample shipment, receipt, publish status, and recap are scattered across records.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform creator sample follow-up board:
- Goal: sample shipment, receipt, publish, and recap status are scattered; centralize tracking.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + local SQLite
- Features: 1. Import creator list and sample sheet: creator, platform, followers, SKU, tracking ID, promised publish date, owner.
2. Board columns: to send, in transit, received, waiting publish, published, waiting recap, paused.
3. Highlight overdue receipt and overdue publish.
4. Creator card stores content link, views/interactions/sales, and notes.
5. Export today's follow-up list and recap sheet.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: import list → board shows → overdue highlights → record data → export list.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Competitor price tracker cleaner
Daily competitor price sheets come back messy, making price drops hard to spot.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform competitor price tracker cleaner:
- Goal: daily competitor price sheets come back messy; automate cleaning and comparison.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + xlsx
- Features: 1. Import today's competitor price sheet and historical price sheet.
2. Clean price fields and detect final price after coupon, gifts, store name, product link, capture time.
3. Compare with history and flag price down, price up, new item, delisted item, gift change.
4. Map competitor products to our SKUs and show price gap and movement.
5. Export "competitor-price-changes.xlsx" and a one-page summary image.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: import price sheets → auto-clean → compare with flags → export Excel + summary image.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Live run-sheet timer
During live sessions, product order, speaking time, and link reminders are hard to manage manually.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform live run-sheet timer:
- Goal: product order, speaking time, and link reminders during live sessions are hard to manage manually.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + local SQLite
- Features: 1. Import live run-sheet Excel: time, SKU, product, price, selling points, link, host wording, control reminder.
2. Big timer view shows current product, next product, remaining time, reminders.
3. Timed reminders for link, coupon, next product, stock check.
4. During live, mark skipped, extended, exception, and actual time.
5. Export recap sheet after the session.
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: import run-sheet → timer view → timed reminders → mark exceptions → export recap.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
SKU listing preflight auditor
Titles, prices, stock, images, and certificates often miss pieces until the last minute.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform SKU listing preflight auditor:
- Goal: titles, prices, stock, images, and certificates often miss pieces until launch day; preflight early.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + xlsx
- Features: 1. Import product sheet, image list, certificate list.
2. Check title, category, spec, price, cost, stock, hero image, detail image, selling points, after-sales note, certificate expiry.
3. Flag missing, conflicting, and high-risk items such as price below cost, zero stock, insufficient images, expired certificate.
4. Generate completeness score per SKU: ready / ready after fixes / pause.
5. Export "listing-fix-list.xlsx".
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: import sheets → auto-audit → flag issues → score SKUs → export fix list.
- Package as Windows .exe and macOS .dmg; include a 400-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along
Desktop
Multi-warehouse transfer planner
One warehouse stocks out while another overstock; manual transfer planning is slow.
You are a senior engineer for Windows and macOS desktop apps. Build an online-usable cross-platform multi-warehouse transfer planner:
- Goal: one warehouse stocks out while another overstock; automate transfer planning.
- User: serve the business role implied by the goal; if unclear, infer from context and state the assumption in the opening brief.
- Input: identify what users fill, upload, drop, or import; if real files are missing, create anonymized sample-data first.
- Output: define the page result, downloaded file, copied content, or saved artifact; the user must be able to take it away.
- Main flow: open app → fill/upload → preview → generate/download/save.
- Platform: Windows 10/11 and macOS
- Stack: Electron + React + TypeScript + xlsx + ECharts
- Features: 1. Import warehouse stock, last-30-day sales, and incoming stock sheets.
2. Calculate daily average sales, days of supply, stockout risk, and overstock risk per SKU per warehouse.
3. Recommend transfers from overstocked warehouses to low-stock warehouses, with quantity and reason.
4. Configurable safety stock days, minimum transfer quantity, campaign reserve.
5. Export "transfer-suggestions.xlsx" and "stockout-risk.xlsx".
- Verification commands: after install, run lint / typecheck / test / build; for web also smoke-test npm run start, for desktop smoke-test launch or packaging.
- Execution loop: package Goal / Context / Constraints / Done when; inspect→plan→implement→verify→review; parallelize only independent read-heavy work; do not edit the same files in parallel; report after verification.
- Constraints: use online-app data boundaries, HTTPS for network requests, and only necessary fields; never overwrite originals; no fake packages; make anonymized sample-data first.
- Warm UX: first launch auto-runs sample-data demo; keep a "Try with sample data" button up top; buttons/errors in business language; never overwrite originals; finish with a ≤30-word summary + system notification + "Open output folder / Run again" buttons.
- Acceptance: import stock → auto-calculate → transfer suggestions → risk flags red → export Excel.
- Package as Windows .exe and macOS .dmg; include a 500-word user guide.
- Final report in four sections: ✅ Delivered / ▶ How to open / ✔ What I verified / ⚠ Known limits & v2 ideas.
- Error recovery: retry the same fix ≤3 times; beyond that, downgrade the feature, log the issue, restore the main flow. Install fail → bump major or --legacy-peer-deps; too many TS errors → any-type through main flow first; Electron blank → check preload/CSP; build fail → return to a clean dev mode first.
[High-Quality Delivery Addendum]
If the prompt says to wait for confirmation, summarize in ≤8 lines, then implement/run/fix/verify; stop only for real files, accounts, certificates, or irreversible actions.
[Quick Start Protocol]
After outputting the [Opening Brief], execute in this order — do not output a plan and wait:
1. Create project directory, init config files
2. Install core deps: electron, react, react-dom, typescript, @types/react
3. Write minimal main.ts (create window) + index.html + renderer entry; confirm the window launches
4. Create sample-data/ with realistic anonymized business data
5. Implement features one by one; verify each immediately after writing
6. Finish with docs, packaging scripts, and user guide
[Codex Execution Loop]
- First package Goal / Context / Constraints / Done when: outcome, relevant files or data, constraints, and completion criteria must be explicit. If information is missing, state assumptions and continue.
- Use this work loop: inspect → plan → implement → verify → review. For complex or fuzzy tasks, make a short plan with verifiable small steps before coding.
- Every step needs observable evidence: visible UI, generated file, passing test, vanished error, or useful log. If there is no evidence, keep fixing.
- Use parallel sub-tasks only when they are independent, read-heavy, parallelizable work: code exploration, test-log analysis, document synthesis, or risk review. Do not let two parallel tasks edit the same files.
- Control context pollution: summarize large logs and files, preserve key paths, errors, decisions, and verification results, and keep noise out of the final report.
- Report only after verification passes; if verification fails, fix or downgrade edge behavior while keeping the main flow runnable.
[Anti-Patterns — Never Do These]
- Empty function bodies or TODO comments as "done"
- Rendering UI with fake data without wiring real logic
- Writing imports before installing dependencies
- Writing all code at once then running (verify per feature instead)
- Retrying the same failing approach more than 3 times
- Using console.log instead of real error-handling UI
- Ignoring empty states and loading states
- First screen on launch is blank / welcome / settings (should be workspace + demo data)
- Error messages leaking jargon ("Cannot read property", "Column not found")
- Bulk operations with no progress bar / ETA
- Overwriting original files on write (always Save as; timestamp conflicts)
- Finishing with zero feedback (no summary, no buttons, no system notification)
[DoD / Stop-Vibe-Coding]
Done criteria (check each — all must pass before reporting):
☐ Launches; sample data creates the artifact
☐ Edge cases are friendly (empty data, bad format, cancel, name conflict → no crash)
☐ UI meets minimum standards (clear type hierarchy, comfortable spacing, empty states have guidance)
☐ lint/typecheck/test/build pass
☐ Smoke test: launch → main flow → export/save with sample-data; note result
☐ setup/dev/package scripts, README, guide, limits, and samples exist
Stop; new ideas go to v2.
[Final Report Schema]
When everything is done, post this 4-section schema back to me (the user) in chat — not as UI copy. Each section opens with an emoji; body in business language.
✅ Delivered: ≤5 core capabilities, business framing, no jargon.
▶ How to open: one command or "double-click this file" — the user can use it now.
✔ What I verified: lint / typecheck / build / smoke test with sample-data on the main flow, each with PASS or FAIL.
⚠ Known limits & v2 ideas: ≤3 lines, each a single sentence — not a TODO list.Paste into Codex and follow along