Build an original, cinematic, anime-inspired personal portfolio with me as its protagonist. This is a professional portfolio for real visitors, with a coherent illustrated story and interactions that reveal my personality. Use this brief in Codex, Claude Code, Cursor, or another coding agent with access to my project files.

MY BRIEF — replace these fields before starting
Name: [YOUR NAME]
Brand / world name: [YOUR BRAND]
Domain: [YOUR DOMAIN]
Primary audience: [PRODUCT CLIENTS / EMPLOYERS / STARTUP COLLABORATORS]
What I do: [YOUR ACTUAL ROLE AND SPECIALTIES]
Personality: [THREE TRAITS AND A SHORT PERSONAL STORY]
Anime / visual inspirations: [FAVORITES AND WHAT EACH ONE MEANS TO YOU]
Portrait references: [LOCAL FILE PATHS OR ATTACHED PHOTOS]
Projects: [NAME, PROBLEM, YOUR CONTRIBUTION, VERIFIED RESULT, LIVE LINK, SOURCE LINK, SCREENSHOT FOR EACH]
Resume: [FILE PATH]
Contact and social links: [VERIFIED PUBLIC CONTACT DETAILS]
Existing repository / stack / hosting: [PATH AND CURRENT SETUP]
AI assistant: [OPTIONAL; PROVIDER AND SERVER-SIDE SECRET NAME, NEVER THE SECRET VALUE]
Budget and constraints: [TIME, ASSET BUDGET, SUPPORTED DEVICES, OPTIONAL SERVICES]

WORKING RULES
Read the repository instructions and applicable installed framework documentation first. Inspect the existing site, routes, content, assets, build scripts and deployment setup. Preserve unrelated work and user edits. Do not invent credentials, projects, job titles, testimonials, impact metrics, links, or contact details. Mark missing facts and ask only the questions that block useful progress. Do not install a large stack just because this brief mentions cinematic animation.

Before changing the visual design, present a concrete art-direction proposal and wait for my approval. Include a scene-by-scene storyboard, desktop and phone compositions, typography, palette, transitions, asset list, animation technique, performance compromises, and a rough prototype plan. If I have already approved a direction, continue within that direction. Do not publish, push, merge or configure external accounts unless I have authorized those actions.

PHASE 1 — CONTENT AND STORY
Map real aspects of my work to a short narrative: curiosity, invention, discipline, strategy, training, shipped work, and an invitation to collaborate. Choose only the chapters that fit my background. Each scene must tell a visitor something specific about me and have a visible next step. Define recurring visual motifs and a beginning, development and payoff.

Use anime as inspiration for staging, expressive poses, anticipation, speed, atmosphere and transformation. Keep my likeness and build an original world. Give me a different outfit where the story calls for one. My symbolic enemies should be relevant engineering obstacles such as brittle systems, repetitive work, confusing interfaces or fear of shipping. Explain the metaphor in the copy without pretending fictional powers are real professional achievements.

Avoid generic gradient cards, floating technology logos, decorative empty panels, filler copy, repetitive fade-ins, and unrelated spectacle. The work and contact information must remain easy to find.

PHASE 2 — STRUCTURE BEFORE EFFECTS
Build semantic pages with readable DOM text, real links, headings, project details, a blog, contact information and an accessible assistant if requested. Keep existing URLs where possible and map necessary redirects. Separate content data, visual scene configuration, renderers, playback state and optional audio. Make the site useful when animation or an asset fails.

Use the smallest rendering approach that achieves the design. CSS and SVG are good for simple effects. A layered Canvas 2D scene can animate illustrated assets with aura, particles, wind and parallax. Use a timeline library when it simplifies synchronization. Use WebGL or a rigged character only if the chosen interactions require it. Do not describe moving a single cutout as full character animation.

PHASE 3 — ASSETS AND IDENTITY
Create an asset manifest listing each scene, reference portrait, outfit, pose, background, foreground, effect layers, intended dimensions, alpha bounds, focal point and fallback. Preserve recognizable facial features, complexion, hairline and proportions across versions. Prepare separate backgrounds and transparent character cutouts when needed. Keep all hair, hands, feet, weapons and energy effects inside safe image bounds.

If image generation is available, show identity and style proofs before producing a large batch. If unavailable, list the exact assets and generation prompts I need to supply. Never claim an image or video was generated when it was not. Inspect outputs visually; remove halos, unintended transparency, hard crop edges and baked-in labels. Optimize web formats without making high-density displays visibly blurry. Do not hotlink images or assume third-party assets are licensed for my use.

PHASE 4 — ONE COMPLETE SCENE PAIR
First implement the opening scene and its transition into the next chapter. Build one persistent visual handoff: for example a loose sheet becomes a notebook page. Match its position, size, rotation, color and content at both ends. The object should mean something before and after the transition. Test slow scrolling, reverse scrolling, fast scrolling, direct anchor navigation, resizing and page restoration.

Derive scene position from normalized scroll progress, with clamped values and deliberate easing. Keep copy readable throughout. Preload the next necessary scene before it enters, release unnecessary resources, and stop animation loops when the scene is off-screen or the tab is hidden. Commit this milestone only when authorized, after reviewing the diff and verifying it in a browser.

PHASE 5 — TRANSFORMATION AND ACTION
Create a transformation chapter with [NUMBER] forms that represent learning or growth. Describe each form's visual identity, posture, aura behavior, palette, wind, sparks, pressure and sound character before implementing it. If I choose a Dragon Ball fan-art sequence, use the requested order: Super Saiyan, Super Saiyan 2, Super Saiyan 3, Super Saiyan God, Super Saiyan Blue, Ultra Instinct. These are fan-art references; my face and the professional story remain mine.

Do not only swap hair color. Give each form a distinct silhouette or pose, atmosphere, intensity and movement. Use bounded shake on decorative layers; never shake readable text or the entire page continuously. Offer direct form selection and a clear return to following scroll.

Keep scroll-driven playback separate from time-driven actions. An attack needs anticipation, charge, release, impact and recovery. The projectile must leave the character, reach a visible target, affect that target and finish in a stable state. A collected energy sphere needs a clear gather and throw. A beam needs a clear launch and hit. Repeated clicks, switching form, toggling sound, leaving the scene or scrolling must follow an explicit interruption policy and never freeze the character in a halfway frame.

PHASE 6 — SOUND AND ASSISTANT
Sound is opt-in. Unlock Web Audio from a real user gesture, resume a suspended context, confirm that audio is running before displaying "Sound on", and provide retry feedback when it fails. Use original or appropriately licensed effects. Synchronize cues with action stages, crossfade aura sound between forms, cap volume, and stop audio when the scene or tab is inactive. Do not add TTS unless I explicitly request it.

If an AI assistant is requested, give it an original mascot with idle, listening, thinking, answering and error states. Place the panel so it does not hide navigation or story controls. Support keyboard focus, closing, readable messages, phone keyboards, streaming failures and reduced motion. Ground answers in verified portfolio content. Keep provider credentials server-side. Limit body size, conversation size, response duration and output. Use a shared production rate limiter, return 429 with a meaningful Retry-After, and fail closed if the shared limiter cannot be checked. Never treat a per-instance memory map as a reliable production quota.

PHASE 7 — REAL WORK, PHONES AND ACCESSIBILITY
Show complete project screenshots at their natural aspect ratio or provide a clearly labeled detailed view. Do not crop away the UI that explains the project. Pair each project with its problem, my contribution and verified outcome. Make primary project and contact links obvious.

Design a separate phone composition instead of shrinking the desktop canvas. Reserve space for the character, place copy where it remains readable, simplify particles, preserve important poses and keep controls reachable. Check at least 320, 375, 412, 768, 1440 and 1920 CSS-pixel widths, recording the actual viewport used. Test high-density displays, landscape, browser zoom and a physical phone if available. Do not claim a device was tested unless it was.

Honor prefers-reduced-motion and provide a reading mode. The full story, forms and projects must remain accessible without continuous movement. Include keyboard controls, visible focus, sensible heading order, sufficient contrast, alt text for meaningful images and decorative-layer hiding. Optimize measured bottlenecks, load assets in stages and cap canvas pixel ratio based on visual quality and device cost. Do not promise an unmeasured frame rate or Lighthouse score.

PHASE 8 — REVIEW AND DELIVERY
Review every route, not only the home page. Verify project readability, image bounds, links, resume download, contact flows, missing assets, direct navigation, metadata, canonical URLs, sitemap, robots, article schema and honest visible content. SEO and answer-engine readability should come from semantic, specific content, not hidden keyword stuffing.

Run the project's required type checks, build and meaningful tests. Use actual browser screenshots to inspect desktop and phone layouts. Test transition boundaries in both directions and action interruptions. Test the chatbot quota with an isolated mock provider so tests do not spend real API credit; verify production behavior separately with a bounded check if authorized. Redact credentials from logs and artifacts.

Deliver the working preview, a concise change summary, real test results, remaining limitations and any manual configuration needed. Do not declare completion based only on a successful build. Work in small reviewable milestones: content, scene pair, assets, remaining chapters, transformations, assistant, mobile/accessibility, final polish. When authorized, commit each completed milestone and use the requested PR/review/deployment workflow.

START NOW
Inspect my materials and repository. Summarize what is known and missing. Then propose the storyboard and implementation plan for approval. Make the result specific to my identity and work, rather than copying the reference portfolio.