MuseMVP Docs
Development

AI Collaboration

MuseMVP's AI collaboration system: built-in rules, AI-friendly structure, and docs/community update division.

MuseMVP treats AI collaboration as engineering infrastructure. Beyond built-in rule and skill entrypoints like AGENTS.md and .agents, the repository layout itself is designed for AI readability. This page focuses on the stable collaboration framework; high-frequency tactics and tool frontiers are maintained through docs updates and private community discussions.

Start with the split: Stable docs vs fast updates

Documentation (/docs)

Stable knowledge: architecture boundaries, directory conventions, layering responsibilities, and pre-commit checks. Use this as the team baseline and onboarding reference.

Community + Ongoing Updates

Fast-moving content: latest AI IDE usage patterns, prompt strategy updates, model capability changes, and real-world troubleshooting.

Read together

This page covers the long-lived collaboration framework. For rapidly changing tactical practices, follow the latest docs updates and private community discussions.


Built-in AI Collaboration Infrastructure in MuseMVP

AGENTS.md - Project-wide source of truth (architecture, conventions, commands)
claude.md - Claude compatibility entry (references AGENTS.md)
  • AGENTS.md: defines mandatory engineering constraints and reduces off-spec AI output.
  • .agents/skills: modularizes frequent workflows for on-demand reuse.
  • src/modules + backend layering: makes it easier for AI to place orchestration vs data access logic correctly.

Do not turn rules into an encyclopedia

Rules should be short, executable, and verifiable. Overlong rule files lower the hit rate of critical constraints.


Why this structure is AI-friendly

Business-domain colocation

`src/modules/*` colocates components, hooks, and lib logic, so AI can implement and refactor within one coherent context.

Strict backend layering

`routes -> modules/lib(orchestrator) -> queries` keeps responsibilities explicit and reduces cross-layer mistakes.

Type-safe request chain

Hono RPC + TypeScript surfaces frontend/backend mismatches at compile time.

Fixed i18n destination

User-facing copy is centralized in `src/i18n/translations/*/mvp.json`, making bilingual sync predictable.


Provide context first, do not ask AI to code immediately
Specify target files, affected modules, and whether auth/billing/i18n is involved.

Ask AI for a change plan first
The plan should include file paths, layer-specific changes, and verification commands.

Implement by layer
Recommended order: queries -> modules/lib -> routes -> api-client -> UI.

Require AI self-verification
At minimum, run type-check and build, then report failures.

Do final human review
Focus on permission boundaries, billing flows, i18n sync, and error branches.

Context:
- Feature: src/modules/muse-billing
- Route: src/backend/api/routes/upgrade
- Query: src/backend/database/queries/billing-contracts.ts
- i18n: src/i18n/translations/{en,zh}/mvp.json

Task:
Add a "downgrade to free" endpoint and a frontend action button.
Requirements:
1) Strictly follow modules/lib orchestration + queries data-access layering
2) Sync user-facing copy in both en/zh mvp.json files
3) Run pnpm type-check && pnpm build after implementation

Pre-PR Verification (Mandatory)

CheckRequirement
Type correctnesspnpm type-check passes
Build integritypnpm build passes
Code qualitypnpm check returns no errors
Layer boundariesFollows queries -> modules/lib -> routes -> api-client -> UI
i18n synchronizationUser-facing text is updated in both en and zh
pnpm type-check
pnpm build
pnpm check

Put verification commands in your prompt

Having AI run verification before handoff is one of the most effective ways to reduce rework.


For real-time tactics and tool frontiers

This site's /docs covers stable template reference. When you need "what works this week" for MVP shipping rhythm, AI coding tactics, and field-tested fixes, use the private encrypted Notion playbook unlocked after purchase, plus the private paid community.