Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

agent-rally-point

Étoiles1

Forks0

Mis à jour9 juin 2026 à 20:22

Use when coordinating build-loop with peer coding agents, checking Rally Point presence/inbox state, posting handoffs or feedback, validating the embedded Rally Point boundary, or changing the future agent-rally-point spin-out surface.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

tyroneross

tyroneross/build-loop

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

Plus depuis ce dépôt

même dépôt

handoff

tyroneross/build-loop

Compose a complete, durable build-loop handoff document from the current run state, and optionally launch a fresh session with it injected. Use when crossing a context boundary (context limit, planned restart, worktree GC). Triggers: 'hand off', 'handoff', 'new session', 'context limit', 'restart', 'fresh session', '/build-loop:compose-handoff'.

2026-07-261

ui-design

tyroneross/build-loop

Use when build-loop needs UI design direction, visual style selection, UI guidance inventory, a .build-loop/app-contract/ui.md design contract, or non-trivial web/mobile/native UI planning. Build-loop-owned design route for design-contract-specialist; selects from project tokens, recent structures, UI Guidance, IBR artifacts, Mockup Gallery, and research based on product/workflow/data/platform fit.

2026-07-251

color-engine

tyroneross/build-loop

Generate accessible color systems and solve contrast, instead of guessing hex values. Use when picking or fixing colors for any UI, chart, diagram, doc, or artifact — "what colors should this use", "is this readable", "this text fails contrast", "make a dark theme", "pick an accent". Also use before shipping any palette, to PROVE contrast rather than assert it. NOT for choosing layout, typography, or component structure.

2026-07-251

build-loop-data-plane-worktrees

tyroneross/build-loop

Use when a Build Loop run or Git worktree touches mutable non-Git state: SQLite or file-backed databases, PostgreSQL databases/schemas and migrations, generated search/vector indexes, Docker volumes or service projects, mutable file trees, caches that cannot be rebuilt safely, or external cloud/account namespaces. Inventories each surface, selects per-worktree, shared-readonly, shared-serialized, or external-namespaced isolation, registers it in the run data manifest, validates collisions before writes, and requires a terminal disposition at closeout.

2026-07-231

model-tiering

tyroneross/build-loop

Use when choosing a model tier or segment for a subagent, deciding a role descriptor (segment + tier) in frontmatter, or escalating mid-flow. Covers the two-axis taxonomy (work-role segment × 7-rung capability ladder) — Opus/Sonnet/Haiku are Anthropic-default mappings; selection is provider-portable and data-driven. NOT for benchmarking models head-to-head on a task — use `model-bakeoff`.

2026-07-231

build-loop

tyroneross/build-loop

Orchestrated build loop for multi-step code work. TRIGGER on verb language ('build', 'implement', 'create', 'add', 'ship', 'wire up', 'integrate', 'refactor', 'migrate', 'rewrite', 'replace') OR symptom language ('fix', 'broken', 'doesn't work', 'isn't loading', 'not displaying', 'missing', 'should show', 'needs to', 'make it', 'show this differently') OR any task touching 2+ files, adding/removing an endpoint, crossing an architectural boundary, or attached screenshots of a bug. SKIP one-line edits, pure Q&A, conversational clarifications, status checks, and trivial typos/renames.

2026-07-211

name	agent-rally-point
description	Use when coordinating build-loop with peer coding agents, checking Rally Point presence/inbox state, posting handoffs or feedback, validating the embedded Rally Point boundary, or changing the future agent-rally-point spin-out surface.
user-invocable	false

Agent Rally Point

Build-loop ships a native embedded agent-rally-point capability while the standalone repo matures. Treat it as a mini-plugin inside build-loop: keep the substrate logic, docs, tests, and thin build-loop adapters grouped so spin-out is mechanical later.

Native Surface

Purpose	Path
Substrate package	`${CLAUDE_PLUGIN_ROOT}/scripts/rally_point/`
Host-neutral CLI	`${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py`
Slash command	`${CLAUDE_PLUGIN_ROOT}/commands/rally-point.md`
Hook adapters	`${CLAUDE_PLUGIN_ROOT}/hooks/session-start-rally-point.sh`, `${CLAUDE_PLUGIN_ROOT}/hooks/pre-edit-rally-point.sh`
Build-loop adapters	`${CLAUDE_PLUGIN_ROOT}/scripts/coordination_status.py`, `${CLAUDE_PLUGIN_ROOT}/scripts/coordination_rally.py`, `${CLAUDE_PLUGIN_ROOT}/scripts/coordination_bootstrap.py`
Boundary manifest	`${CLAUDE_PLUGIN_ROOT}/scripts/rally_point/plugin_boundary.json`

Required Orchestrator Contract

At the Phase 1 preamble, before the first Rally Point write, the orchestrator must generate or resume the durable run identity:

from scripts.rally_point.build_loop_id import generate_or_resume

execution = generate_or_resume(
    workdir=Path.cwd(),
    tool="<tool-id>",
    session_id="<session-id>",
)

session_id is the ephemeral host session. run_id is caller-chosen legacy provenance. build_loop_id is the durable human-visible run identity and is surfaced on Rally Point records as top-level build_loop_id and build_loop_run_label.

Operating Rules

Resolve the channel through scripts/rally_point/discovery_bridge.py or scripts/agent_rally.py where; do not hardcode legacy channel roots.
Write cross-session events through scripts/rally_point/post.py::post(); do not append directly to changes.jsonl.
Keep build_loop_id separate from producer_metadata.
Keep substrate files independent from build-loop memory/orchestration internals. If a build-loop-specific integration is needed, put it in a thin adapter named in plugin_boundary.json.
Use stable tool ids: claude_code, codex, cursor, gemini, or another lowercase id agreed by the adapter.

Commands

python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py status --workdir "$PWD" --session-id "$SESSION_ID" --json
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py heartbeat --workdir "$PWD" --session-id "$SESSION_ID" --task-ref "$TASK_REF" --progress "still working" --json
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py ack-inbox --workdir "$PWD" --session-id "$SESSION_ID" --tool "$TOOL_ID" --json
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py boundary --repo "${CLAUDE_PLUGIN_ROOT}" --check --json
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/rally_point/boundary.py --repo "${CLAUDE_PLUGIN_ROOT}" --check --json

Use /agent-rally-point status for the same sensor from Claude Code. Status/watch envelopes include inbox_latest_messages, a compact doorbell preview for the newest unread direct/broadcast inbox records. Counts are session-ack aware; read inbox/<tool>.jsonl or inbox/all.jsonl before acting on a full message, then run ack-inbox after handling it. Ack cursors live under inbox/.acks/ and never rewrite the append-only inbox payloads.

Task Heartbeat — still on the claimed task

Presence is process liveness: it tells peers this session can still write to the channel. Task heartbeat is work liveness: it tells peers whether the session is still on the claimed task, what changed since the last check-in, what evidence exists, and when the next check-in is due.

For long-running tasks, write a heartbeat at task start and then at least every 10 minutes:

python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py heartbeat \
  --workdir "$PWD" \
  --session-id "$SESSION_ID" \
  --tool "$TOOL_ID" \
  --model "$MODEL" \
  --run-id "$RUN_ID" \
  --task-ref "$TASK_REF" \
  --status running \
  --progress "short update since last check-in" \
  --evidence "files/tests/commit-or-handoff-ids" \
  --json

Then pass the same --task-ref to status or watch. Health can be current, stale_check_in, wrong_task, missing, drift_risk, blocked, or needs_attention. blocked and needs_attention make status report blocked; stale, missing, wrong-task, and drift-risk states report warn.

Roster — who is running, where, doing what, with how many subagents

roster answers the cross-channel "who's live right now" question in one command. It walks every <apps_root>/*/sessions/*.json (all repos at once), keeps sessions whose last_seen is within the stale window, and builds a parent/child tree from each record's parent link plus the self-reported spawned fan-out.

python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py roster              # live tree, all channels
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py roster --app ptyd   # one channel
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py roster --json       # structured (array of agent objects w/ children + spawned)
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py roster --stale-secs 300 --all   # widen window, keep stale
python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py roster --watch 5    # re-render every 5s

Each row: session_id · app · host:cwd · tool/model · task · last-seen(age) · subagents (Σtotal by-type + live nested count). Children that posted their own presence nest under the parent; subagents that did not post presence are reflected by the parent's spawned totals.

Convention — populate the roster on every presence write

So the roster is useful, agents must enrich their presence calls. These fields are additive and backward-compatible (existing callers keep working):

python3 ${CLAUDE_PLUGIN_ROOT}/scripts/agent_rally.py presence \
  --session-id "$SESSION_ID" --tool claude_code --model opus \
  --cwd "$PWD" \
  --task "what this agent is actually doing right now" \
  --parent "$SPAWNING_SESSION_ID" \
  --spawned "coder:2,workflow:21,independent-auditor:1"

--cwd / --pid / --host — where it runs (default cwd / this pid / this host).
--task — fuller free text (falls back to --phase for display).
--parent <session_id> — links a subagent to its spawning agent; omit for top-level.
--spawned <type:count,…> — the fan-out an agent self-reports.
Every presence call rewrites last_seen; re-post periodically so the agent stays in the live window (default 120s). Presence is not task heartbeat; use agent_rally.py heartbeat for long-running task check-ins.

Top-level orchestrators should post --spawned reflecting their dispatched subagents; each dispatched subagent that can post should set --parent to the orchestrator's session_id.

Validation

uv run pytest scripts/test_build_loop_id.py scripts/rally_point/test_boundary.py scripts/rally_point/test_orchestrator_contract.py scripts/test_agent_rally_roster.py scripts/test_agent_rally_status.py
python3 scripts/agent_rally.py boundary --repo "$PWD" --check --json

Spin-Out Rule

When extracting to the standalone plugin, copy the namespaced substrate, skill, command, hooks, tests, and docs named in plugin_boundary.json. Build-loop should then keep only the thin adapters that call the standalone package.