Optimizer for your resonators and weapons and echoes

See the project for more information on where things are at, and where things are going: https://github.com/users/ryanbenson/projects/2

• Daisy UI
• Tailwind
• Vue
• Vercel

• You need NodeJS installed.
• Then clone the repo
• Install the depdencies: npm i
• Start the local server: npm run dev
• It should kick up and be available at http://localhost:5173/

Project maintenance commands live under cli/. Run them with Make or directly via npm run cli -- <command>.

Prerequisites: Node.js and npm install (or make install).

Scaffold a new character folder under src/characters/ from live game data. The generator writes attack files, buffs, resonance chains, tune break attacks, stats, and patches characters.ts.

make generate-character

Aliases: make character, make cli

Equivalent without Make:

npm run cli -- generate character

Regenerate an existing character while keeping buff/resonance entry properties:

make generate-character ARGS="--merge-modifiers"

The command will:

1. Fetch the character list and let you search/select a character
2. Prompt to confirm overwrite if the character already exists
3. Generate files in src/characters/<CharacterKey>/
4. Print a review checklist for anything that needs manual follow-up (e.g. unmatched DamageList entries, missing attributes on healing/shields)

Generated files still need manual work for modifiers, presets, and some edge cases — use the checklist at the end of the run.

Scaffold a new weapon file and register it in src/weapons/weapons.ts.

make generate-weapon

Alias: make weapon

npm run cli -- generate weapon

Generate an echo preset and append it to a character's presets.ts. The CLI walks through build options (set combination, cost layout, ER target, main stats, attack type) and produces a preset matching the project's standard build patterns.

make generate-echo-preset

Alias: make echo-preset

npm run cli -- generate echo-preset

The command will:

1. Let you search/select a character (shows how many echo presets already exist)
2. Prompt for set bonus combination (5-piece, 2+5, 2+3, or 2+2+1)
3. Prompt for echo cost layout (43311 or 44111), target ER%, 4-cost mains, 3-cost mains, attack type, and main stat focus
4. Auto-generate a description and pick random valid echoes (unique within the preset)
5. Preview the result and append it to src/characters/<CharacterKey>/presets.ts

Primary echoes use fixed rolls (8.1% CR, 16.2% CD, 8.6% main stat, 8.6% attack type, flat main stat). Filler substats are randomized from HP/DEF pools, excluding any stats already declared for the build. ER rolls are placed explicitly to hit the target ER%.

Import echoes from the Encore API into src/echoes/index.ts.

make import-echoes

npm run cli -- import echoes

• Run npm run test to run the Vitests
• Use npm run cypress:open to open Cypress for the UI for e2e tests
• You can also just run the e2e tests with npm run cypress:run and it will run them in your terminal

This app will not support unreleased content (characters, echoes, weapons, echo sets, etc.) We will only release content to production if Kuro has released the content officially (in-game, news article on the official website)

We can prep ahead of a release using leaked data, but it cannot be accessible in the app at all.

Also, do not reference websites or sources that include links (e.g. do not link or reference encore.moe).

Every commit and branch gets auto-deployed to https://vercel.com. So to deploy to production, any new update to master will auto-deploy.

The e2e tests don't currently block any release. I don't have teams setup for Vercel right now, so contributors won't be able to see the staging environments in Vercel.

• CLAUDE.md — concise briefing for coding agents (and humans)
• docs/context.md — priorities (accuracy first) and mental model
• docs/adr/ — architecture decision records
• docs/ — area guides (calculator, stores, workers, …)

• Use pull requests (PRs). All changes should go through a PR. Do not push directly to the master/protected branch.
• Feature branches are fine. You can also setup a feature flag if you want as well.
• Keep PRs small. Prefer several focused PRs over one large one. Smaller PRs are easier to review and reduce the risk of regressions.
• Tests must pass. CI (if configured) must be green before merge. Run tests locally before opening or updating a PR.
• Add tests where possible. When you add or change behavior, add or update tests (unit tests for logic, E2E for critical flows). See docs/architecture.md for testing expectations.
• One logical change per PR. Mixing unrelated fixes or features in a single PR makes review and history harder. Split them when it makes sense.

• Don’t force-push to shared branches (e.g. master). Rewriting history after others may have pulled causes confusion and broken clones.
• Respond to review. Address comments, ask for clarification if needed, and keep the conversation constructive.
• Update docs if behavior or setup changes. The docs/ folder is the reference for new contributors; keep it in sync with how the app and contribution flow work.
• Follow project conventions. See docs/architecture.md for technical conventions (Vue, types, performance, no classes, workers, DaisyUI, etc.).

• Tests pass locally (and in CI if applicable).
• New or changed behavior is covered by tests where practical.
• Docs are updated if you changed setup, architecture, or contribution process.
• PR is focused and reasonably sized for review.