agentsclimarketplace

Roboports

Skill dylanmccavitt/loom/skills/roboports

Loom — a cross-harness, self-improving agent pack (OMP, Codex, Claude Code)

Install
npx -y skills add dylanmccavitt/loom --skill roboports

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

The implement coordinator. Runs one tracked issue end-to-end as code — one issue to one branch/worktree to one PR — with localized subagent fanout and a minimal diff, and covers behavior-preserving refactors and measured performance work through lenses. Use when the user asks to start, continue, or ship one tracked issue, refactor without changing behavior, or optimize a proven bottleneck.

SKILL.md

5.0 KB, as published. Nobody here has run it

Roboports

Blueprint's issue-decomposition lens stamps the planned work; roboports coordinates the bounded build network that turns one ready tracked issue into landed code: one issue → one branch/worktree → one PR, no more. The main agent is the roboport hub — it owns intake, integration, and handing the PR to rocket-launch; subagents do bounded, disjoint, localized work.

Lenses

The input packet's lens field selects which variant guidance loads: a named lens loads references/lens-<name>.md; when lens is absent, load the default references/lens-issue-delivery.md. Unnamed lens references stay unloaded. Lenses select guidance only; they never widen packet scope, change the implement-mode boundary, or grant extra delegation authority.

  • issue-delivery (default) — one ready issue through branch, implementation, proof, review, and PR readiness.
  • refactor — behavior-preserving refactor: upgrade in place or delete/salvage dead and duplicated code while tests stay green.
  • performance — optimize a proven bottleneck with measured before/after results, stopping at diminishing returns.

Side-effect boundary: resolve the packet's context (validation | live) per the shared contract before any tracker, PR, or live-HOME action; under validation, report intended side effects instead of performing them.

The bridge

Planning lives in the tracker; code lands as a PR; the tracker's PR integration stitches the two. Preserve one issue to one branch/worktree to one PR unless the repo envelope says otherwise. The branch name carries the tracked issue id — the PR auto-links and, on merge, auto-closes the issue. Never craft a branch that drops the id.

Required reading

Before editing, read the repo envelope assembler generated (tracker team/project/label map, domain glossary, branch/PR conventions, build/test commands — never hardcode commands or a tracker), the active tracked issue (description, comments, acceptance criteria), and any architecture/ADR/domain docs the issue names.

Localized roboport discipline

Do not wire every subagent into one giant global network. Fan out in localized small batches: each subagent gets a bounded, disjoint write scope and a single lens. Default to the main agent implementing the first pass; spawn bots only when they cut risk or context load; give reviewers distinct lenses. Do not spawn separate "read issue", "implement", "review findings", and "fix findings" bots — that makes coordination the work. Localized small-batch fanout, never a universal backbone.

Doctrine and specialist routing

  • Apply the minimal-diff doctrine (the biters minimal-diff lens reviews against it): reuse before you write, ship the minimum that works, never cut validation/security/error-handling/accessibility.
  • Use tdd for test-first / red-green-refactor work.
  • For a bug, failing check, or regression: route to the operator-local debug-tools diagnose loop when installed (docs/skills/operator-local-manifest.md); otherwise run reproduce→minimise→hypothesise→instrument→fix→regression-test inline.
  • Route triage of incoming work to blueprint's triage lens; roboports only builds an already-tracked, ready issue.
  • Use the biters drift lens when repo/tracker/proof drift could change the route; it checks only.
  • Use lab for targeted proof of the implemented behavior (the lab ui-proof lens for user-visible flows) before launch gates rely on it.
  • Hand the finished PR to rocket-launch; roboports does not own closeout.

Flow

  1. Confirm scope, blockers, and the proof plan from the issue's acceptance criteria; create the one branch/worktree (id in the name) if absent.
  2. Implement only the acceptance criteria — nothing the issue did not ask for.
  3. Run the envelope's targeted checks that prove the changed behavior.
  4. Fan out localized reviewer bots when the change is non-trivial; fix real findings; rerun the relevant checks once across the union of changes.
  5. Prepare a review packet (the tracked issue id and acceptance criteria, changed files/diff, checks run and any unrun with reasons, exact questions per reviewer lens, blockers) and open or update the PR.

Invariants

  • The branch name carries the tracked issue id for the bridge.
  • Implements only the acceptance criteria; reads commands from the repo envelope.
  • Prepares the PR review-ready but does not own closeout (that is rocket-launch), and never silently closes the issue.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.