---
name: carbon-more
description: Continue a prior broad CARBON run with the next highest-value deferred candidates without repeating the initial pass. Use when the user says more, carbon more, run the rest, add coverage, continue testing, execute remaining tests, or asks for a deeper follow-up after the bounded first /carbon run.
user-invocable: false
---

# CARBON More

Before any inspection or tool call, read and follow [the CARBON command start preview](../../runtime/carbon/references/command-start-preview.md). Explain that this command continues the durable candidate pool; it does not regenerate or repeat the initial pass by default.

Read [progress and resume](../../runtime/carbon/references/execution/progress-and-resume.md) before execution. Preserve the same evidence, safety, adapter-negotiation, and authority boundaries as the main CARBON skill.

## Continue coverage

1. Resolve the current project root explicitly. Never fall back to the plugin installation directory.
2. Call `carbon_set_preferences` with no arguments and apply the saved local execution context without exposing secrets.
3. Inspect the newest CARBON run, its terminal statuses, candidate pool, original cut line, failures, blockers, and stale evidence.
4. Build the next plan from deferred candidates:

```bash
<plugin-root>/bin/carbon-runtime framework more --root <project> --limit 40 --budget-minutes 60
```

Accept a user-stated smaller, larger, time-boxed, domain-specific, or "all remaining" scope. Otherwise use the next 40 candidates or a 60-minute plan, whichever cut line arrives first. Keep planned candidates distinct from executed results.

5. Call `carbon_open_execution_plan` with `root=<project>` and `planPath=<project>/.carbon/framework/more-plan.json`. Open the returned HTML inside the coding agent before execution: use `codexBrowserUrl` in Codex or the embedded project-local HTML artifact in Claude. If the host does not confirm the internal pane opened, keep the exact project-local link visible and state that host limitation; never launch an operating-system browser automatically.
6. Initialize and execute a durable run from `more-plan.json`. Reuse passed evidence only when its definition, build, target, and dependencies are still fresh. Reproduce important failures before expanding adjacent coverage.
7. Update the live command page and test-level execution page after every major step. Persist partial results, screenshots, blocked channels, and the remaining cut line.
8. Finish with generated, previously selected, newly executed, passed, failed, blocked, skipped, and still-deferred counts. Explain what the added evidence changed about shipping confidence.

## Boundaries

- Never repeat the prior selected set merely to inflate executed-test counts.
- Never call a deferred candidate passed until direct evidence supports its oracle.
- Preserve destructive, paid, notification, production, privacy-sensitive, privilege, and hostile-security gates.
- Stop on a severe failure, authorization boundary, shared blocker, exhausted budget, or evidence that no longer changes the risk decision.
- If no candidate pool exists, explain that `/carbon` must create the initial broad pool first.
- If no candidates remain, recommend context-specific generation with `/carbon-generate` rather than inventing more work.

Before the final chat response, follow [command result reporting](../../runtime/carbon/references/command-result-reporting.md). Publish the required branded CARBON HTML report, end with the current host's **Open the CARBON report** link, and recommend the next useful command based on remaining risk, not a generic upsell.
