MuseMVP
Docs MuseMVP
Development

AI Collaboration

Use the repository rules and skills while preserving authorization, ledgers, idempotency, and evidence.

Start from existing repository guidance

Flare includes AGENTS.md and .agents/skills. Read the actual files at the current commit rather than inventing .cursor, .claude, or tooling directories from memory.

flare-public-surface covers public/auth/content work, and flare-build-behavior covers build and behavior verification. Follow their current SKILL.md boundaries. The marketing website's Next.js instructions do not describe a TanStack Worker application.

Write an executable request

Specify the trigger, URL, expected behavior, server constraints, edit scope, and acceptance. For example:

Add filename filtering at /app/files.
Filter only the currently loaded user's files; do not claim database-wide search.
Preserve upload/download/delete, API keys, and server ownership checks.
Provide English/Chinese empty states without mobile overflow.
Run relevant type/browser checks and list unverified behavior.

A concrete request makes completion reviewable. Asking only for a prettier page does not constrain authorization, real data, or request states.

Trace before editing

Follow routes, modules, server APIs, and packages through the complete call chain. For a field change, inspect UI, input schemas, queries, persistence, and responses together. Do not invent payload mappings. For billing, credits, and tasks, read the state machine and database constraints first.

Preserve URLs, API contracts, server authorization, query invalidation, ledgers, and idempotency. A UI refactor must not substitute mock data or remove checks merely to make an action appear successful.

Keep credentials out of prompts

Share variable names from .env.example, redacted errors, and target types rather than real .env/.dev.vars, sessions, webhook secrets, or deployment tokens. Review public excerpts and screenshots for codes and personal information too.

Deployment is an explicit operational action. Generate a reviewable plan before authorized execution. Ordinary UI/documentation work does not imply production registration, payment attempts, or publishing.

Review the result

Inspect unrelated dependency, lockfile, schema, authorization, resource-name, and test-expectation changes. Require separate statements for implemented source, executed checks, and outstanding real-service acceptance rather than an unsupported all-clear.

Use relevant test layers and browser checks for languages, themes, keyboard access, and mobile layouts. Update documentation and changelog with behavior changes so the next developer follows current instructions.

Sur cette page