Run a repository change you can inspect
Use a disposable repository to add a health-check endpoint and tests while preserving the existing API. The workflow makes the plan, checks, recovery boundaries, and result visible.
Scenario
Task: Add a health-check endpoint, tests, and documentation while preserving existing APIs.
Why this example: it is small enough to reproduce, has a deterministic check, and produces an easy-to-review file and test summary.
Run it
- Install the CLI and check the environment:
npm install -g @flotic/minitok minitok doctor - For a disposable no-credential fixture, use the built-in promotion helper. It creates a local Git repository and writes a plan; it does not call a model or apply a change. The command prints the absolute fixture path; pass that path to
minitok migraterather than assuming a current-directory name:# POSIX shell output="$(minitok promote demo)" printf '%s\n' "$output" fixture="$(printf '%s\n' "$output" | sed -n 's/^Demo fixture created: //p')" minitok migrate "$fixture" # PowerShell $output = minitok promote demo $output $fixture = (($output | Where-Object { $_ -match '^Demo fixture created: ' }) -replace '^Demo fixture created: ', '').Trim() minitok migrate $fixture - For an existing disposable repository, initialize the workflow instead:
cd your-disposable-repository git init minitok migrate - Preview the task without applying the generated change. A configured provider and entitlement are still required for the model-backed preview:
minitok run --dry-run "Add a health-check endpoint, tests, and documentation. Preserve existing APIs." - Inspect the result and local run records:
minitok status minitok run list minitok run show <run-id>
The first successful local milestone is a configured repository with a passing verification gate and an inspectable dry-run/evidence record. A fixture created by minitok promote demo is onboarding evidence only, not model output or deployment proof.
What to inspect
- The plan matches the repository structure and the requested compatibility constraint.
- The repository's
VERIFY_CMD.mjsor configured check is the project check, not a bundled minitok check. - Changed files, test output, retries, and stop reasons are visible in the run result.
- A failed check stops or guides bounded repair according to configured limits; it is not silently treated as success.
Verifiedmeans the configured checks passed. It does not guarantee correctness, security, deployment, or production readiness.
After the preview
If the plan and safety boundaries look right, run the same task without --dry-run only after confirming your provider, entitlement, approval policy, backups, and repository checks. Keep the resulting evidence with the repository's change record.
minitok does not replace Anthropic, OpenAI, Google, or another model provider. Provider credentials and model usage costs are separate.
Sources and limits
This walkthrough follows the CLI's documented command shape. For integration details, see the documentation, source repository, and npm package. For data handling, see the privacy policy.