본문으로 건너뛰기
cccskills
무료GitHub에 공개

polly-e2e-dev

Test polly's coordination of coding agents using a scripted mock language model and live command-line tools. Check startup, task dispatch, safety rules, parallel delegation, and whether real agents make appropriate orchestration decisions.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

End-to-end test the polly multi-agent coding orchestrator's critical user journeys (CUJs). Two halves — a deterministic mock-LLM driver (polly_cuj.py) that boots a throwaway local server + mock LLM and asserts the substrate (boot, bridged sys_* tool dispatch, the blast_radius / spawn_bounds / headless_subagent_purpose_guard guardrails, fan-out delegation), and a live real-CLI recipe (real claude/codex/pi, real worktrees/PRs) for polly's actual judgment. Load when developing, testing, or debugging examples/polly — its config.yaml, the claude_code/codex/pi sub-agents, the investigate/fanout/cross-review skills, or the omnigent.inner.nessie.policies guardrails — or reproducing a polly orchestration bug.

설치 방법 보기

이럴 때 유용합니다

  • Reproducing polly orchestration bugs
  • Checking safety rules with a mock language model
  • Verifying delegation and cross-review with real agents
  • Comparing failing and passing checks before and after a fix

포함된 파일(2)

  • SKILL.md11.4 KB
  • polly_cuj.py26.1 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

polly orchestrator: end-to-end CUJ dev & testing

polly (examples/polly/) is a multi-agent coding orchestrator: a claude-sdk "brain" that writes no code itself and delegates everything to three coding sub-agents — claude_code (claude-native), codex (codex-native), and pi (headless, multi-model). Its critical user journeys are orchestration behaviors, not single-turn answers:

  • roster preflight — first turn runs command -v claude codex pi, routes only to workers whose CLI resolved.
  • investigate — read-only work fanned to explore/search sub-agents; synthesize from their reports.
  • fanout — independent tasks, each in its own git worktree + sub-agent, each opening its own PR.
  • cross-review — an implementer's diff is verified by a different-vendor sub-agent (diff + contract only); blocking issues become fix-tasks.
  • plan gate / inbox — pull the human in at the plan gate; supervise via the inbox + autowake, never busy-poll.
  • guardrails (omnigent.inner.nessie.policies) — blast_radius (deny force-push / rm -rf /), spawn_bounds (cap dispatches per turn), headless_subagent_purpose_guard (every dispatch needs args.purpose).

This skill tests those CUJs two ways. Use both — they cover different things:

HalfWhat it provesNeeds
Mock loop (polly_cuj.py)The substrate/mechanics — the brain is scripted, so this proves bundle load, server-side policy resolution, bridged sys_* tool dispatch, the guardrail DENYs, and fan-out — deterministically, with no credsnothing (mock LLM)
Live recipepolly's judgment — does the real brain preflight, decompose, delegate, cross-review, and pull in the human correctlyreal claude/codex/pi + model creds + network

Like the sibling harness skills, turns run from your current checkout (omni run <bundle> --server <url> = local runner + remote server), so testing exercises exactly the code you're on.

Interpreter

The driver and CLI need the repo's Python ≥3.12 env. If .venv/ is missing, create it once from the checkout:

uv run --frozen python -c "import omnigent; print('ok')"   # builds .venv

Then use .venv/bin/python / .venv/bin/omni below.


Part A — the deterministic mock loop (polly_cuj.py)

The driver boots a throwaway local Omnigent server (which carries omnigent.inner.nessie.policies — the module polly's guardrails resolve) plus the repo's mock-LLM server, rewrites the polly bundle to the openai-agents harness wired to the mock, then runs omnigent run turns where the brain is scripted (text or tool calls). It prints one SUMMARY {json} per scenario and exits non-zero if any check failed.

.venv/bin/python .claude/skills/polly-e2e-dev/polly_cuj.py --list-scenarios
.venv/bin/python .claude/skills/polly-e2e-dev/polly_cuj.py --scenario all
.venv/bin/python .claude/skills/polly-e2e-dev/polly_cuj.py --scenario guardrail_purpose --keep

Read the result with … | grep '^SUMMARY' | python -m json.tool. Each run takes ~45–55s for all five scenarios; no credentials or egress are required.

Scenario catalog

ScenarioScripts the brain to…Hard check
bootreply with textexit 0 + non-trivial reply (bundle load, server-side policy resolve, turn completes)
tool_dispatchcall sys_os_shell to write a sentinelthe file appears on disk (bridged sys_* dispatch works; blast_radius ALLOWs benign shell)
guardrail_purposesys_session_send with no args.purposetool output carries Denied by policy: … must declare what kind of work it is (headless_subagent_purpose_guard)
guardrail_blast_radiussys_os_shell("git push --force …")tool output carries Denied by policy: … blast-radius policy
fanout_dispatchemit 7 sys_session_send in one turn6 dispatch handles created and the seventh is denied by spawn_bounds

The verifiable before→after loop

The driver exists for a loop, not a one-shot. To prove a fix:

  1. On the unfixed code, run the scenario → a check is false (baseline).
  2. Make the change.
  3. Run the same scenario → the check flips to true.

A fix is "verifiable" only if a check flips. If it doesn't flip, you can't prove the change did anything — keep working. To cover a new mechanism, add a scenario_* function + a row in _SCENARIOS (each builds a bundle, scripts the mock, runs a turn, and asserts an observable effect — a session item, a deny sentinel, a file on disk).

What the mock loop can and can't prove

It tests mechanics because the brain is scripted: tool dispatch, the guardrail gate, session persistence, fan-out plumbing. It does not test polly's judgment (whether the real brain preflights, decomposes, picks the right vendor, cross-reviews). That is the live recipe.


Part B — the live recipe (real claude/codex/pi)

Prereqs (check first)

  1. You're on the branch you want to test.
  2. A Claude provider for the brain (omni setup, or ANTHROPIC_API_KEY, or a Databricks default). Verify booleans only — never print keys.
  3. Worker CLIs on PATH — this is the roster preflight:
    command -v claude codex pi || true
    
    A worker is launchable only if its binary resolved. Cross-review needs two different vendors available.
  4. Network egress to the model backends; gh authed if you want real PRs.

Run a live turn

.venv/bin/omni server --background && .venv/bin/omni server status   # prints $SERVER, e.g. http://127.0.0.1:6767
SERVER=http://127.0.0.1:6767
timeout 280 .venv/bin/omni run examples/polly \
  -p "Investigate how the runner enforces tool-call policies and report file:line evidence." \
  --server "$SERVER" 2>&1

Always pass --server "$SERVER"; omitting it routes to the configured remote deploy, which may be stale and reject parts of the bundle.

Observe CUJs (CLI + HTTP API + filesystem)

Grab the session id, then read the transcript and the side effects:

SID=$(curl -s "$SERVER/v1/sessions?kind=default&order=desc&limit=1&visibility=all" | python -c "import sys,json;print(json.load(sys.stdin)['data'][0]['id'])")
curl -s "$SERVER/v1/sessions/$SID/items"          | python -m json.tool | tail -60   # brain transcript + tool calls
curl -s "$SERVER/v1/sessions/$SID/child_sessions" | python -m json.tool             # dispatched sub-agents
git worktree list                                  # fanout: one per task
cat .polly/registry.json 2>/dev/null               # polly's task list
gh pr list --author "@me"                          # each implementer opens its own PR

Per-CUJ live playbook

CUJDrive itLook for
roster preflightfirst live turn on a box missing a CLIpolly tells you which worker is unavailable; routes around it
investigateprompt a read-only question ("explain/audit/why does X…")child_sessions with purpose: explore/search; answer cites their reports, not polly's own deep reads
fanoutprompt 2–3 independent changesone worktree + one sub-agent + one PR per task
cross-reviewlet an implementer finisha different-vendor reviewer child with purpose: review; blocking issues sent back to the same implementer session
plan gate / inboxa multi-step taskpolly pauses for human approval at the plan gate; ends its turn after dispatch and is autowoken by the inbox (no busy-poll)
guardrails (ASK)a task that pushes/mergesthe runner surfaces an approval card; ask_timeout: 86400 keeps it open

For the guardrail DENY set (force-push, rm -rf /, unmarked dispatch, fan-out cap), prefer the mock loop — it's deterministic and creates no real side effects.


CUJ coverage map

CUJMock loopLive recipe
boot / turn completesbootany live turn
bridged sys_* dispatchtool_dispatchtool calls in …/items
headless_subagent_purpose_guardguardrail_purpose ✅(deny — prefer mock)
blast_radiusguardrail_blast_radius ✅ASK card on push/merge
spawn_boundsfanout_dispatch ✅verify cap live
fanout delegationfanout_dispatch (handles)child_sessions + worktrees + PRs
investigate / cross-review / plan gate / inbox— (needs judgment)live playbook above

Known sharp edges (found while building this skill — verify, may change)

  • Two deny formats. Bridged sys_* tools surface a denial as {"error": "Denied by policy: <reason>"}; SDK function tools use [Denied by policy: <name>] {json}. Both share the Denied by policy: marker — match on that plus a policy-specific reason fragment (the driver does).
  • Live fan-out needs the worker CLIs. In the mock loop, sub-agents are rewritten to openai-agents so a dispatch needs no binary. Live, a missing claude/codex/pi makes that worker fail to boot — treat it as UNAVAILABLE.
  • Default server gotcha. config.yaml's server: points at a remote deploy; always pass --server "$SERVER" for local testing.

Code & tests

  • Bundle / prompt / guardrails: examples/polly/config.yaml
  • Sub-agents: examples/polly/agents/{claude_code,codex,pi}/config.yaml
  • Orchestration skills: examples/polly/skills/{investigate,fanout,cross-review}/SKILL.md
  • Guardrail policies: omnigent/inner/nessie/policies.py
  • Runner-side gate: omnigent/runner/policy.py; server-side tool-call enforcement: omnigent/server/routes/sessions.py
  • Mock LLM server: tests/server/integration/mock_llm_server.py
# Existing pytest e2e for polly (mock-LLM) — complementary to this skill:
uv run --frozen --group test python -m pytest \
  tests/e2e/test_polly_e2e.py \
  tests/e2e/test_polly_cost_advisor_e2e.py \
  tests/e2e/test_polly_subagent_model_e2e.py -q

Teardown — non-negotiable

The driver reaps everything it starts, including the per-conversation omnigent.host._daemon_entry / runner._entry / harnesses._runner subprocesses an omni run turn spawns (a plain server SIGTERM leaves these orphaned). The sweep is scoped to this interpreter, so it never touches another worktree. After a live session, sweep manually:

.venv/bin/omni server stop
pgrep -af "$(pwd)/.venv/bin/python -m omnigent" | grep -E "_entry|_runner|_daemon" || echo clean

Honesty

If a worker CLI, credential, or egress isn't available, say the live CUJ was skipped — don't claim it passed. The strongest evidence is a reproduced baseline plus the flipped check (mock loop) or the observed round trip in …/items + …/child_sessions (live). Report the real SUMMARY lines, not a summary of a summary.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Test Omnigent’s native Antigravity integration with a live local server and the real agy CLI. Verify messages traveling between the web interface and terminal, mirrored replies, permission requests, interruption, session resumption, and process cleanup.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Testing message delivery from the web interface to agy
  • Checking terminal output against mirrored session replies
  • Verifying permission requests and interruption
omnigent-ai/omnigent1.1만2026년 10월 18일 업데이트

Test Omnigent’s Antigravity SDK integration against a live local server. Build test agents and run real conversations to check Gemini authentication, model selection, tool connections, and failures across the full execution path.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Test authentication and real Gemini responses
  • Verify tool connections and sub-agent delegation
  • Investigate model selection failures
omnigent-ai/omnigent1.1만2026년 10월 18일 업데이트

api-docs

무료

Create reference documentation directly from source code for public functions, classes, command-line commands, and endpoints. Organize parameters, defaults, return values, errors, and runnable examples, then check that the documentation matches the implementation.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Writing reference docs for a public module
  • Documenting command-line arguments and defaults
  • Adding minimal usage examples for an API
omnigent-ai/omnigent1.1만2026년 10월 18일 업데이트

Create an Omnigent agent directory using validated templates for configuration and instructions. Choose how the agent runs, then add web search, shell access, external tool connections, or subagents only when the task requires them.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Creating a minimal Omnigent agent
  • Configuring an agent with web search
  • Adding shell access or MCP tool connections
omnigent-ai/omnigent1.1만2026년 10월 18일 업데이트

changelog

무료

Turn a selected range of commits or merged pull requests into release notes grouped by change type. Describe user-visible effects, link to supporting changes, and highlight breaking changes so readers can assess an upgrade.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Write release notes covering changes since the last tag
  • Summarize pull requests merged during a selected period
  • Highlight breaking changes before an upgrade
omnigent-ai/omnigent1.1만2026년 10월 18일 업데이트

Test Omnigent’s setup, help, and terminal interactions by driving the real CLI in an isolated environment. Capture rendered screens and compare checks before and after a change to establish whether a reported interface problem was fixed.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Reproducing a first-run setup problem
  • Inspecting menus in a narrow terminal
  • Checking help text and command visibility
omnigent-ai/omnigent1.1만2026년 10월 18일 업데이트

omnigent-ai의 스킬 모두 보기

이 스킬의 문제 신고