FeaturesHow It WorksPricingDocsInstallContact Us

Parton CLI is in early alpha (v0.1.0)

Things may break or change between releases. We don't recommend using Parton on production projects yet. If you run into anything unexpected, we'd genuinely appreciate your feedback — it helps us make Parton better for everyone.

How Parton Works

Parton is a local-first AI code execution engine.

It takes an intent, plans the work, executes targeted changes, validates the result, repairs failures if needed, and then gives you a final review URL.

High-level flow

Intent
→ Setup gate
→ Clarification
→ Planning
→ Waves / Lanes
→ Execution
→ Final validation
→ Repair
→ Review

1. Setup gate

Before Parton can do any AI work, it must confirm that model access is configured.

If setup is missing, it blocks the run and launches setup.

2. Clarification

If your request is ambiguous, Parton can ask a small number of clarification questions before planning.

This is especially important for:

  • greenfield tasks
  • vague prompts
  • tasks with multiple valid implementation paths

3. Planning

Parton converts your request into a structured plan.

That plan is broken into:

  • waves
  • lanes

Waves

Waves are higher-level execution stages that must happen in order.

Lanes

Lanes are smaller units of work inside a wave.

A lane should have a focused scope.

4. Greenfield vs existing repo

Existing repo

Parton modifies an existing codebase.

Greenfield

If the repo is empty or does not contain a meaningful project structure, Parton can switch into greenfield mode.

In greenfield mode, it starts with scaffold-first planning.

5. Execution

During execution, Parton:

  • builds context for the lane
  • calls the configured model
  • parses structured output
  • applies edits safely
  • records artifacts and logs

6. Missing-context loop

If the model does not have enough information, it can request more context.

Parton then expands the context and continues the lane.

This keeps execution targeted instead of flooding the model with the whole repo.

7. Final validation

After execution is done, Parton runs full-repo validation.

This typically includes:

  • lint
  • build or typecheck
  • test suite

Parton does not treat final validation as optional.

8. Repair

If final validation fails, Parton enters a bounded repair flow.

Repair tries to fix only the reported issues.

Possible outcomes:

  • Success
  • RepairEscalated
  • Failed

9. Pause and resume

Some failures are external and recoverable, such as:

  • provider outage
  • HTTP 500
  • network loss
  • rate limit
  • temporary quota exhaustion

In these cases, Parton can pause and later resume:

parton resume <run_id>

10. Review

At the end of a run, Parton gives you a local review page.

That page is where you inspect the result and decide what to do next.

What Parton is optimized for

Parton is optimized for:

  • local-first usage
  • guided planning
  • targeted execution
  • validation-backed output
  • repair instead of silent failure

Related