1. Record the environment
Write down the Minecraft version, server software, plugin names and exact plugin versions. Include the dependency versions when a feature relies on another plugin. Say whether the issue affects startup, one command, one world or one player group.
Do not choose runtime versions from an old generic checklist. Paper’s current requirements differ by server release; check the official documentation for the release you actually run. Its getting-started guide links the relevant setup and configuration documentation.
2. Describe a player journey
Describe the starting state, action and result. For example: a player with the default rank opens the starter menu, chooses the starter option and receives the intended kit. Then specify what should happen when they repeat the action or lack permission.
State what currently happens using the same steps. Screenshots can explain a menu layout, but a text reproduction makes a failure testable. Include exact error wording with credentials, addresses and personal information removed.
3. Separate requirements from references
List required behavior separately from visual inspiration. “Use this color palette” is more specific than “make it like this server.” Identify the settings that must remain unchanged and features that are deliberately outside this task.
Confirm ownership of any paid plugin and who supplies it. Do not send licence keys or control-panel passwords as part of a public brief. Agree the smallest necessary access privately once scope is clear.
4. Agree a reversible test
Back up the affected files and agree a test environment before replacing a live setup. Paper’s administration guidance treats backups and permissions as distinct operational concerns; a feature looking correct does not establish that access control or recovery works.
Your acceptance checklist should include both an allowed action and a denied action. Test as a normal player as well as any relevant staff rank, and record the expected result. Ask which files will be delivered and whether installation notes are included.
5. Turn the brief into a quote
Send the environment, reproduction, requirements, references and acceptance checklist together. Include a desired deadline without assuming it is already accepted. If new behavior emerges later, ask whether it belongs to the original scope or needs a separate quote.
Use CraftLabs’ current pricing page to compare service families, then confirm the scope with the team. This guide is a preparation checklist, not a universal server configuration or a promise that every plugin combination can be supported.
Official references
The practical brief checklist is CraftLabs guidance. The technical references below are maintained by their respective publishers; check their current documentation for your platform and version.