أوامر Claude Fable 5

Here is a screenshot of [PRODUCT NAME]'s interface: [ATTACH SCREENSHOT].

Recreate this UI as a working [FRAMEWORK / SINGLE HTML FILE] app with REAL functionality, not a static mockup.
- Match the layout, spacing, and visual hierarchy in the screenshot as closely as you can.
- Implement the core interactions I would actually use: [LIST KEY FEATURES, e.g. navigation, search, create/edit items].
- Wire up local state so buttons, forms, and lists genuinely respond.
Work autonomously until it runs, then tell me what you approximated and what still needs real backend wiring.

You are a principal-level software engineer and technical auditor. Deeply analyze this repository and deliver an honest audit plus a prioritized, actionable improvement plan.

Ground every claim in actual files: cite file paths and line numbers. If you cannot verify something, say so.
Work through these phases in order, do not skip ahead:
1. Map the architecture, key modules, and how data flows through [PROJECT NAME].
2. Find correctness bugs, security issues, and [SPECIFIC CONCERN, e.g. performance hot paths].
3. Flag dead code, duplication, and risky patterns worth refactoring.
4. Produce a ranked improvement plan (impact vs effort) with concrete next steps.

This repository has roughly [LINE COUNT] lines. There is a bug: [DESCRIBE THE SYMPTOM, e.g. cache never invalidates after an update].

Do a full investigation before proposing anything:
- Trace the relevant call chains end to end, including hidden or indirect calls.
- Identify the true root cause, not just the surface symptom, and cite the files and lines involved.
- Propose a complete fix that a reviewer could merge, covering edge cases and any affected callers.
Explain your reasoning and list anything you were unsure about so I can verify before merging.

Something is broken in [ENVIRONMENT, e.g. my self-hosted k8s cluster] and I cannot describe it precisely. Investigate and fix it.

You have access to [AVAILABLE TOOLS, e.g. kubectl, database query access, container registry]. Work autonomously:
- Read pod/service logs and error logs from [DATA SOURCES] to find what actually changed.
- Compare deployed versions, image digests, config, and migrations to spot mismatches.
- Form a hypothesis, verify it against evidence, then open a PR with the fix and a clear write-up.
Do not ask me to hand-hold each step; report your findings and the PR when done.

Build [PROJECT NAME] to completion by running an autonomous loop, hands-free, until every item in the spec is met.

The spec / definition of done is: [SPEC OR CHECKLIST].
On each iteration:
- Implement the next unfinished piece.
- Build it, run the tests, and smoke-test the actual behavior (launch it, exercise it, [e.g. play the level]).
- If something fails, diagnose and fix it, then re-verify before moving on.
Keep a running log of what is done, what changed, and what remains. Continue on autopilot until the checklist is fully satisfied.

Set a goal to fully implement this spec, then keep working until it is genuinely complete: [SPEC].

Context you should know: [BACKGROUND AND CONSTRAINTS, e.g. this is experimental and may be removed in a month, so keep it easy to delete].
Then run a workflow that verifies each part of the plan independently:
- For every requirement, check the real behavior against what was asked.
- Note anything that differs from the spec or that you had to interpret.
Prepare a short report of what was implemented, how you verified it, and where reality diverged from the plan.

Build a browser-based endless-runner game controlled by [INPUT, e.g. finger/hand tracking via the webcam].

Requirements:
- Use [LIBRARY OR APPROACH, e.g. a hand-tracking library] to map [GESTURE, e.g. raising a finger] to the jump action.
- Add obstacles, increasing speed, a score counter, and a game-over/restart flow.
- Keep it self-contained and runnable as a single [HTML file / small project] with no build step.
Handle camera permission gracefully and keep it at a smooth frame rate.

Build a complete arcade kart-racing game in the style of [REFERENCE, e.g. Mario Kart 64].

Include, generated by you, no external assets:
- At least [N] tracks with distinct themes and decoration.
- Driveable characters/karts with simple models and handling.
- [GAME MODES, e.g. grand prix, time trial, versus], plus background music and sound.
- A full UI: menus, HUD, lap and position tracking, and results screen.
Keep controls responsive and ship it as a runnable project I can start immediately.

Build a playable voxel sandbox game in the style of [REFERENCE, e.g. Minecraft].

Include:
- Procedurally generated terrain with [FEATURES, e.g. biomes, caves, ores].
- Block placing and mining with a simple inventory.
- A day/night cycle and basic [MOBS/ENTITIES] with simple AI.
- First-person movement, collision, and mouse-look controls.
Target [TECH, e.g. a single HTML file with WebGL / a Rust project] and keep a steady frame rate. Build it end to end, testing as you go.

Build a full [STYLE, e.g. macOS-style] desktop operating system as a single self-contained HTML file with embedded CSS and JS.

Include:
- A menu bar and dock, plus draggable and resizable app windows.
- Working built-in apps: [APPS, e.g. file explorer, terminal, settings, browser mockup].
- Desktop icons, notifications, themes, and a boot screen.
- [BONUS, e.g. a small working sound player using real synthesis, or a mini game inside the desktop].
Make it feel real and responsive, generated in one pass with no external files.

Create a full-length, tall vertical ecommerce email mockup for [BRAND], a [CATEGORY] brand for [AUDIENCE].

Design a highly realistic premium DTC email that feels sleek, polished, and editorial, like a real designer-made email screenshot, not a poster, landing page, or generic template.
Brand vibe: [ADJECTIVES, e.g. modern, confident, clean, aspirational].
Feature these products prominently: [PRODUCT LIST].
Include a hero, product sections with real-feeling copy, and a clear call to action. Use realistic typography, spacing, and imagery placement.

In Three.js, create a first-person, navigable 3D scene of [PLACE, e.g. the iconic apartment from a TV show] based on this floor plan: [ATTACH FLOOR PLAN].

- Stay true to the original look and feel: layout, furniture placement, colors, and materials.
- Use [LIGHTING STYLE, e.g. warm interior lighting] and sensible shadows.
- Let me walk around with WASD and mouse-look, with collision so I cannot pass through walls.
Deliver it as a single HTML file. Verify your result visually against the floor plan and iterate until the geometry matches.

Do a full, careful read-through of this [DOCUMENT TYPE, e.g. policy memo]: [PASTE OR ATTACH DOCUMENT].

Return your review in three layers:
- Fluency edits: tighten wording and flow, shown as clearly marked track changes.
- Comments: flag shaky or unsupported claims and ask the questions a sharp reviewer would.
- Sources: suggest specific references or data that would strengthen or verify the weak points.
Preserve my voice and argument; do not rewrite it into your own style. Keep the changes suggestion-style so I can accept or reject each one.

Research and answer this question in depth: [QUESTION].

Frame it around a specific premise: [PREMISE OR ANGLE, e.g. treat the timeline as starting from a particular year rather than the conventional one].
Structure the answer as:
- What actually happened: the concrete events, decisions, and turning points.
- Why it happened: the underlying causes and how they compounded.
- What it means going forward: implications for [TIME HORIZON / DOMAIN].
Go deep on substance but keep the surface clean and readable. Cite specific figures, dates, and facts, and flag where the evidence is contested.

Draft an S-1 registration statement for [COMPANY], a [DESCRIPTION] company.

Follow the standard S-1 structure and produce genuinely long-form content, not an outline:
- Prospectus summary, risk factors, use of proceeds, and MD&A.
- Business description, competition, and market opportunity.
- Selected financial data and management/ownership sections.
Match the tone, formatting, and structure of a real filing. Where you would need actual numbers, use clearly labeled placeholders such as [FY2025 REVENUE] rather than inventing figures.