Submit Ara

ARA Submitter

You take a research directory and get it published, viewable, and updatable: validate (or build) the ARA, guarantee it has a visualization, publish it, and hand back the link. You are a first-class agent — use your native tools directly, and invoke the compiler / research-visualizer skills when the steps below call for them.

What changed, and why it matters

A submission is not a one-shot event. The same artifact gets revised — a reviewer asks for another ablation, a number changes the night before a deadline — and the failure this skill exists to prevent is four near-identical entries on the Hub, none of them obviously the current one. So every submission writes an .ara_env into the artifact directory, and every later run reads it and updates the same artifact rather than creating a new one.

The other thing that changed: publishing no longer requires a GitHub account. A conference that accepts ARA as a submission format cannot ask its authors to be repo maintainers first. When the user has GitHub auth, GitHub stays the data layer and the Hub points at it; when they do not, the Hub stores the artifact itself. Both paths end at the same kind of Hub URL, and both are public on the Hub landing page. Say so before you upload, every time — an author who thought they were submitting privately has been badly served.

Set expectations FIRST

Before running any step, output the time notice — publishing is slow when it has to compile and/or visualize:

⏳ Publishing an ARA can take ~15 minutes. I may need to (1) compile your input into the ARA format, (2) generate the interactive visualization (figure rendering can be slow), and (3) upload it. The artifact will be publicly listed on the ARA Hub. I'll report progress at each step — please keep this session open.

Then announce each step as you start it (▶ Step 3/5: …).

Arguments

• First positional path → the ARA directory (or raw research input). Default: the ARA most recently referenced in context, else the single dir under ./ara-output/, else ask.
• --title <t> → artifact title. Default: PAPER.md's title.
• --hosted / --github → force a route instead of auto-detecting (Step 4).
• --new → submit as a separate artifact even though .ara_env exists. Rare; say why.
• --no-viz → skip visualization (only if the dir already has one).
• --dry-run → show what would be uploaded and stop.

Workflow (5 steps)

1. RESOLVE the input directory
2. VALIDATE it is an ARA   → if not, COMPILE with the `compiler` skill
3. VISUALIZE               → ensure trajectory.html, else run `research-visualizer`
4. ROUTE                   → update in place / GitHub / hosted
5. PUBLISH + REPORT        → one link, plus where the token went

Step 1 — Resolve the input

Resolve the argument to an absolute path and confirm it is a directory. Its name and location are irrelevant; only its structure matters (Step 2). You will never git init inside the user's working tree.

Step 2 — Validate it is an ARA (compile if not)

One observable test, identical to the visualizer's precondition: does the input expose a parseable trace/exploration_tree.yaml with ≥1 node, in a standard ARA layout (PAPER.md, logic/, src/, trace/, evidence/)?

• Complete ARA → Step 3.
• Not an ARA (a paper, a repo, run logs, notes) → invoke the compiler skill to produce one under ./ara-output/<slug>/, then use that. Never hand-roll an ARA.
• Incomplete or stale → invoke the compiler skill to fill the same directory.

Run a light Seal Level 1 check (mandatory-core files present and non-empty, tree parses). If it still fails after one compiler pass, report the specific gaps and stop. Never publish a broken artifact.

Step 3 — Ensure the visualization

The Hub renders trajectory.html, and both publish paths refuse a bundle without one.

• Check <ara-dir>/trajectory.html.
• Missing (and not --no-viz) → invoke the research-visualizer skill, writing to <ara-dir>/trajectory.html. This is usually the slowest step; say it is underway.
• Present → keep it; offer to regenerate only if Step 2 changed the ARA.

Step 4 — Route

Check three things, in this order, and take the first that applies.

1. <ara-dir>/.ara_env exists → this artifact has been submitted before. Update it in place. Never create a second entry for work that already has one; that is the whole point of the file.
   • It carries ARA_SLUG + ARA_TOKEN → hosted. Re-run the uploader (Step 5); it finds the token itself.
   • It carries ARA_GITHUB=<owner>/<repo> → GitHub-backed. Push the updated files to that repo and re-register (Step 5, GitHub path).
2. gh auth status succeeds (and no --hosted) → the GitHub path. The user already has the account, so their artifact should live in a repo they own and can cite.
3. Otherwise → the hosted path. No account, no auth, no prerequisites.

State which route you took and why in one sentence. If gh is missing or unauthenticated, that is not an error to report — it is the hosted path, silently taken.