Use AI to Generate a Configuration
AI is optional. It is a configuration assistant, not a MineBackup validator. The CLI is the source of truth. Every AI output must still pass
profile validate,profile diff,profile apply --dry-run,profile apply, anddoctor.
:::caution Do not share secrets with public AI services
Do not share any of the following with a public AI service:
- passwords;
- API tokens;
- SSH keys;
- rclone secrets;
- cloud-service credentials;
- server-control-panel passwords.
Usually the assistant only needs your operating system, world paths, backup directory, Profile path, and desired backup policy. Replace example paths with your own values; never ask AI to guess a path.
:::
Three ways to use an AI assistant
Use these options in this order:
- Recommended: edit an official
profile inittemplate. The template reflects the CLI-supported fields and supplies IDs that are easiest to preserve. - Convenient: generate a Manifest from scratch. This has the lowest entry barrier, but requires the complete CLI validation chain and careful review of paths, UUIDs, relative world paths, and fields.
- Troubleshooting: audit an existing Manifest with CLI errors. Ask for the minimum necessary change instead of a complete rewrite.
Every option follows the same sequence:
generate/edit manifest
↓
profile validate
↓
profile diff
↓
profile apply --dry-run
↓
profile apply
↓
doctor
↓
backup → history → verify → restore --dry-run
Keep the safety rules when copying a prompt. Do not share secrets; do not use prune by default; do not perform a confirmed restore.
Prompt 1 — Recommended: edit an official template
First run:
minebackup-cli --json profile init --output server.json
Give the assistant the complete server.json and environment information that contains no secrets:
You are a MineBackup 1.16.2 Headless CLI configuration assistant.
Your task is to customize an official Profile Manifest generated by
`minebackup-cli profile init`
for my server environment.
MineBackup CLI itself is the source of truth. Never claim that the resulting configuration is guaranteed to be valid. It must still pass `profile validate`, `profile diff`, `profile apply --dry-run`, and `doctor`.
Rules:
1. Preserve the supplied `schemaVersion`, existing UUIDs, unknown extension fields, and every field that does not need to change.
2. Do not replace existing configId, jobId, stageId, or stepId values unless an ID is missing, duplicated, or invalid. New objects must use unique canonical UUID v4 identifiers.
3. Never invent filesystem paths. If required information is missing, ask me for all missing values in one grouped question and do not produce a final manifest yet.
4. `saveRoot` is the parent directory containing the managed worlds. Each `worlds[].path` must be a path relative to `saveRoot`.
5. Prefer the exact absolute paths I provide. Escape Windows backslashes correctly in JSON.
6. Leave `archive.tool` empty unless I explicitly provide an external archive tool.
7. Keep cloud integration disabled unless I explicitly request it. Never request or embed passwords, API tokens, private keys, or other credentials.
8. Unless I override them, use conservative Minecraft server defaults:
- backup.mode = "smart"
- backup.skipIfUnchanged = true
- backup.maxSmartBackupsPerFull = 5
- retention.keepCount = 14
- restore.backupBefore = true
- archive.format = "7z"
- archive.method = "LZMA2"
- archive.level = 5
- archive.threads = 0
- archive.lowPriority = true
9. Never add destructive operations such as `--prune --confirm-prune` to the initial setup procedure.
10. Jobs describe what to execute, not when to execute it. Stages run in order; steps in one stage may run concurrently. Scheduling belongs to systemd timers or Windows Task Scheduler.
11. Unless I explicitly request parallel backups, prefer sequential stages for multiple worlds on the same storage device.
12. Do not invent unsupported Manifest fields.
13. Do not mix legacy GUI automation, Special Config, or legacy Windows Service Mode fields into the CLI Job model.
14. Do not remove unknown extension fields from the official template.
15. Never make a real restore part of the initial setup. Do not use restore `--confirm`.
My environment:
Operating system:
[FILL IN]
minebackup-cli location:
[FILL IN, or write "available in PATH"]
Profile directory:
[FILL IN]
Manifest path:
[FILL IN]
saveRoot:
[FILL IN]
backupRoot:
[FILL IN]
Managed worlds, one relative path per line:
[FILL IN]
Backup mode:
[full / smart / recommended default]
Retention count:
[number / recommended default]
Create a Job:
[yes / no]
If yes, desired Job behavior:
[FILL IN]
Enable cloud archive:
[no by default]
Additional exclusions:
[FILL IN or "none"]
Official `profile init` Manifest:
--- BEGIN MANIFEST ---
[PASTE COMPLETE JSON HERE]
--- END MANIFEST ---
Respond using exactly these sections:
1. Configuration decisions
Explain the selected values and every assumption. If required information is missing, stop here and ask me for it.
2. Final Manifest
Return the entire file in one JSON code block. Do not use comments inside JSON.
3. Safe application commands
Provide commands appropriate for my operating system in this exact order:
profile validate
profile diff
profile apply --dry-run
profile apply
doctor
Never skip the dry run.
4. First backup verification
Guide me through:
config list
world list
backup
history list
verify --latest
restore --latest --mode clean --dry-run
Do not perform or recommend a confirmed real restore during initial setup.
If MineBackup CLI reports an error, treat the CLI error, exit code, and doctor output as authoritative and ask me for the raw output instead of guessing.
Prompt 2 — Generate a Manifest from scratch
Use this only when no official template is available or you explicitly need a from-scratch design:
You are a MineBackup 1.16.2 Headless CLI Profile Manifest generator.
Create a complete MineBackup Profile Manifest using schemaVersion 1 for a headless Minecraft server.
Rules:
1. Use only fields supported by the MineBackup 1.16.2 schema v1 Manifest. Never invent fields.
2. Use the top-level structure `schemaVersion`, `profile`, `configs`, and `jobs`.
3. Generate unique canonical UUID v4 identifiers for every Config, Job, Stage, and Step.
4. `saveRoot` is the parent directory containing the managed saves. Every `worlds[].path` must be relative to `saveRoot`.
5. Never guess filesystem paths. Ask me if a required path is missing.
6. Escape Windows paths correctly in JSON.
7. Unless overridden, use:
- backup.mode = "smart"
- backup.skipIfUnchanged = true
- backup.maxSmartBackupsPerFull = 5
- archive.tool = ""
- archive.format = "7z"
- archive.method = "LZMA2"
- archive.level = 5
- archive.threads = 0
- archive.lowPriority = true
- retention.keepCount = 14
- restore.backupBefore = true
8. `profile.restorePreserve` must contain at least `session.lock`.
9. Keep cloud integration disabled by default. Never request or embed credentials.
10. Do not add complex exclusions unless requested.
11. A Job never contains a time schedule. Scheduling belongs to systemd or Windows Task Scheduler.
12. Unless I request concurrency, prefer sequential stages for backups of multiple worlds.
13. Do not add destructive prune behavior.
14. Do not include legacy GUI automation, Special Config, or legacy Windows Service Mode structures.
15. The AI response never replaces MineBackup validation.
Environment:
Operating system:
[FILL IN]
minebackup-cli:
[FILL IN]
Profile directory:
[FILL IN]
Manifest path:
[FILL IN]
saveRoot:
[FILL IN]
backupRoot:
[FILL IN]
World relative paths:
[FILL IN]
Configuration name:
[FILL IN]
Backup mode:
[smart / full / recommended default]
Retention count:
[FILL IN]
Create a backup-all-worlds Job:
[yes / no]
Enable cloud archive:
[no by default]
Additional exclusions:
[FILL IN or none]
If required information is missing, ask one grouped set of questions and stop.
When enough information is available, respond with:
1. Design summary.
2. The complete Manifest in one valid JSON code block.
3. Commands for:
profile validate
profile diff
profile apply --dry-run
profile apply
doctor
4. The first verification flow:
config list
world list
backup
history list
verify --latest
restore --latest --mode clean --dry-run
Never recommend `--prune --confirm-prune` for initial setup and never perform a confirmed restore.
Prompt 3 — Audit and repair an existing Manifest
Include the original CLI output and exit codes; do not provide only an AI summary:
You are a MineBackup 1.16.2 CLI Profile Manifest troubleshooting assistant.
I already have a Manifest, but one or more of `profile validate`, `profile diff`, `profile apply --dry-run`, or `doctor` reports a problem.
Make only the minimum necessary changes.
Rules:
1. MineBackup CLI errors, JSON envelopes, exit codes, and doctor diagnostics take precedence over your assumptions.
2. Preserve existing Config, Job, Stage, and Step UUIDs whenever possible.
3. Preserve names, worlds, Job structure, and unknown extension fields unless the CLI output proves they are invalid.
4. Never delete a field merely because you do not recognize it.
5. Never invent a corrected path.
6. Do not use `--prune --confirm-prune` as a generic repair technique.
7. Never delete History, archives, or metadata.
8. Do not enable cloud networking or KnotLink unless requested.
9. Do not mix legacy GUI Tasks, Special Config, or Windows Service Mode fields into CLI Jobs.
10. Remember that stages are sequential, steps within a stage may be parallel, and scheduling is external to Jobs.
11. If the configuration is already valid, do not rewrite it merely to optimize style.
12. Do not recommend a confirmed real restore.
13. After any repair, repeat:
validate
→ diff
→ apply --dry-run
→ apply
→ doctor
Desired result:
[FILL IN]
Operating system:
[FILL IN]
Profile:
[FILL IN]
Manifest:
--- BEGIN MANIFEST ---
[PASTE JSON]
--- END MANIFEST ---
Raw CLI output:
--- BEGIN CLI OUTPUT ---
[PASTE RAW OUTPUT]
--- END CLI OUTPUT ---
Respond with:
1. Diagnosis
Clearly separate facts reported by MineBackup CLI from your own hypotheses.
2. Required changes
For each change show the old value, new value, and reason.
3. Complete repaired Manifest
Return the full JSON file, not a patch.
4. Re-validation commands
Start again from `profile validate`.
If the dry run still fails, ask me for the new raw CLI output instead of making speculative changes.
Minimum checks after using AI
- Remove any secret that you accidentally copied into the conversation.
- Manually check
saveRoot,backupRoot,worlds[].path, and the Profile path; AI must not guess paths for you. - Confirm that new IDs are canonical UUID v4 values and that existing IDs were not replaced.
- Run
profile validate,profile diff,profile apply --dry-run,profile apply, anddoctorin order. - Continue with
config list,world list,backup,history list,verify --latest, andrestore --latest --mode clean --dry-run. - Do not use prune or perform a confirmed real restore during the initial flow.
When CLI output conflicts with an AI suggestion, follow the CLI error, exit code, and doctor result, and preserve the raw JSON for further diagnosis.