Skip to content

THEONE CODING / POWERED BY ONECLAW

Not just a suggestion.
A change you can inspect.

Bring your repository and a clear objective. TheOne coordinates the work; OneClaw runs the coding engine, tools and checks in an authorized workspace.

Start a coding task ↗Get Desktop ↓

Local repositories require a connected desktop/runtime and workspace authorization.

TheOne coding workspace: repository setup and task interface with example content
Product screenshot with example content. Not a live run or benchmark result.

WATCH A TASK

From the request to a verified change.

Six phases you can follow live: understand, plan, implement, verify, review, deliver.

Coding task · price-repo
ObjectiveFix src/price.js: round discounts to the cent and always show prices with two decimals; run npm test when done.
  1. Understand
  2. Plan
  3. Implement
  4. Verify
  5. Review
  6. Deliver

Plan

  • Find where discounts and prices are formatted
  • Round discounts to the cent
  • Always show two decimals
  • Run the tests

src/price.js +2 −2

  export function applyDiscount(cents, percent) {
-   return Math.floor(cents * (100 - percent) / 100);
+   return Math.round(cents * (100 - percent) / 100);
  }
  export function formatPrice(cents) {
-   return `¥${cents / 100}`;
+   return `¥${(cents / 100).toFixed(2)}`;

Verification

  • Types & lint0.8s
  • Targeted tests6 / 6
  • Full suite48 / 48
  • Build2.1s
Done and verified

What changedDiscounts round to the cent; prices always show two decimals.

How it was verifiedLint, targeted tests 6/6, full suite 48/48 and the build all pass.

What is still riskyFormats for other currencies are not covered.

Open pull request →

Illustration that follows the real phases and screens of a TheOne coding task; not a live run.

THE ENGINEERING WORKFLOW

Explore. Change. Check. Review.

01

Work in context.

Authorize a workspace and ask for a focused change. Start with a read-only review when the scope is still unclear.

02

Follow the execution.

Inspect the plan, tool activity, changes and checks as the runtime reports them. See what needs attention instead of guessing.

03

Review before delivery.

Use diffs, test results and execution records to judge the change. Pull-request delivery requires the appropriate runtime and authorization.

EXAMPLES

Hand it work like this.

Fix a bug without touching the tests

“A test is failing. Find the cause and fix the implementation — do not change the test.”

  1. Read the failing test and the code it covers
  2. Change the implementation only
  3. Run the targeted and full test suites

You getA verified change and a one-line cause.

Understand an unfamiliar codebase

“Analyse this codebase’s structure and main risks, and give the 3 improvements most worth doing first.”

  1. Read-only: nothing is changed
  2. Map the modules, dependencies and risks
  3. Every recommended step can be run with one click

You getA report you can act on directly.

Upgrade a dependency

“Upgrade next to the latest patch release and run the tests and the build.”

  1. Read the release notes for breaking changes
  2. Upgrade and fix what breaks
  3. Full suite and build must pass

You getAn opened pull request with the risks spelled out.

Add a feature, with tests

“Add CSV to the export feature, with tests.”

  1. Plan first, then implement step by step
  2. Write tests for the new behaviour
  3. Before-and-after screenshots for any UI change

You getThe feature, its tests and screenshots, together.

WHAT IT CAN DO

14 engineering skills, six layers of checks.

TheOne picks the skill from what you ask; the checks run until the change is proven or the gap is named.

Engineering skills

Code reviewBug fixingFeature workReleaseIncident handlingSecurity reviewRefactoringWriting testsAPI designDatabase changesPerformanceDependency upgradesTechnical docsArchitecture design

Verification ladder

  1. 1Types & lint
  2. 2Targeted tests
  3. 3Full suite
  4. 4Build
  5. 5End-to-end
  6. 6Visual

Where it works

  • Folders and repositories on your computer, through TheOne Desktop
  • GitHub repositories, with pull requests opened for you
  • Triggered by GitHub events through automations

How it delivers

  • Pull requests: what changed, why, how it was verified, what is still risky
  • Before-and-after screenshots for UI changes
  • “Continue” resumes the same task and workspace

MULTIPLE ENGINES. ONE WORKFLOW.

Choose the intelligence.

Whichever engine runs the task, you get the same plan, live progress, checks and result card.

TheOne Native

The native agent loop for repository exploration, edits, tool calls and checks.

Codex

A configured Codex execution path, with results surfaced in the same task workspace.

Claude-based engine

A configured Claude-based coding engine, subject to its runtime and provider requirements.

Which engines you can use depends on your plan and the credentials configured for your workspace.

A MORE HONEST DEFINITION OF DONE

The evidence matters.

A plausible answer is not a passing test. A passing test is not a guarantee that every requirement is met.

01

Inspect what changed

Review the diff and the workspace affected by it.

02

Inspect what was checked

Read the actual checks and their outcomes. Independent verification is a separate workflow state.

03

Keep release authority separate

Review the candidate and use your repository's approval and release process.

START WITH A SMALL, REAL TASK

Your repository. Your boundaries.

Open TheOne ↗Explore governance →