How to use AI to contribute to the core

Replace bracketed values before sending the prompt. Give the assistant the relevant public files from the exact target release; use synthetic examples and keep credentials, private campaigns and proprietary material out of its context.

What you will build

Implement one well-defined generic capability or correction. Use a concrete before/after example and keep system-specific requirements in their package.

Context to give the assistant

• AGENTS.md, CONTRIBUTING.md, docs/en/development.md and the architecture/code map.

• The owning service, frontend controller and existing tests relevant to the requested behavior.

• The target public release and any compatibility or migration constraints.

Step by step

1. Describe the user-visible problem and decide whether it belongs to core or a system package.

2. Inspect current work and use a separate checkout when needed to protect it.

3. Ask for a small implementation following existing service, modal, translation and design conventions.

4. Review contracts, generated files, migrations, licensing and aligned English/Portuguese docs before preparing a contribution.

Copy and adapt this prompt

Repository: [local checkout or public repository]
Target host release: [installed/requested version; preserve it]
Task scope and authorization: [what may be changed/published]

Implement this focused generic change: [before/after example]. Target release: [version].
Read AGENTS.md and CONTRIBUTING.md, inspect git status and the owning implementation/tests, and preserve existing work.
Keep domain validation, authorization and persistence in services. Keep the Django/Jinja2/Datastar/native JavaScript/PixiJS stack and the existing modal system.
Preserve installation-local storage, campaign isolation, request receipts/revisions and notifications after commit. Do not add game-system conditionals to the core.
If a browser contract changes, edit gravewright/modules/contracts/frontend.json and regenerate with scripts/generate_frontend_api.py; review source and generated counterpart together.
Use meaningful focused tests, visually check layout changes with synthetic data, align English/Portuguese docs and preserve third-party notices.
Provide the resulting diff, validation commands/results and actual limitations. Prepare a reviewable contribution; publish or merge only within the authorization given for this task.

Inspect the actual files and supported APIs before proposing code. Do not invent commands, fields, endpoints or package capabilities.
Use disposable test data and installation-local tools/caches. Explain any unsupported requirement and validate the result with the project’s real tools.
Deliver concrete files or editor steps, the checks performed and any unresolved limits.

How to validate

• Run the relevant Django/node/browser checks described by the repository for the changed behavior.

• Inspect the diff for private data, unrelated changes, generated-only edits and changed published migrations.

• Verify translations and actual visual behavior when UI changes; use native execution for Runner/installer/updater work.

Ready when

The change belongs in the right layer, preserves compatibility and data, and has a focused diff with truthful validation evidence.

Continue with the module reference, public API and testing guide.