Reproducible walkthrough

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.

Evidence boundary: this page is a runnable procedure, not a claim that the example has been completed on your repository. A real model-backed run requires a configured provider and an active minitok entitlement. Review the generated change before applying it.

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

  1. Install the CLI and check the environment:
    npm install -g @flotic/minitok
    minitok doctor
  2. 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 migrate rather 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
  3. For an existing disposable repository, initialize the workflow instead:
    cd your-disposable-repository
    git init
    minitok migrate
  4. 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."
  5. 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.mjs or 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.
  • Verified means 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.