Participant web operator

Skill jasontang-ai/acp/skills/participant-web-operator

ACP is a reusable democratic coordination primitive for discussion under load. Relay is the reference implementation used to validate that primitive in practice.

Install

npx -y skills add jasontang-ai/acp --skill participant-web-operator

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

Use this skill to operate and QA the Relay web app for participant submission, digest reading, baseline thread reading, response flow, and operator review.

SKILL.md

2.8 KB, as published. Nobody here has run it

What this skill is for

Use this skill when ACP must be verified through the rendered Relay web surface rather than only CLI or API outputs.

When to use it

Participant submission workflow QA.
Digest or baseline thread reading workflow QA.
Operator UI inspection of Engine V2 issue maps, critics, and release state.
Browser/server mismatch investigation.

When not to use it

Do not use it for protocol logic that can be checked directly through CLI or schema.
Do not use it to bypass server lifecycle transitions.
Do not use it when no web surface is involved.

Inputs expected

Local app URL
Cycle id when targeting a specific workflow
Participant id when inspecting participant views
Expected server-side state

Preflight / prerequisites

Confirm server readiness.
Run scripts/surface-preflight.mjs --base-url <url> when state is uncertain.
Know whether the task is observation-only or action-authorized.
Keep screenshots or notes tied to the cycle id.

Workflow

Inspect server readiness and participant view payloads.
Open the app in the browser.
Execute the specific participant or operator path.
Compare rendered state against server contract.
Report any mismatch with URL, cycle id, participant id, and expected server state.

Decision rules / judgment criteria

Server contract beats visual assumption.
UI polish is not success if lifecycle state is wrong.
Do not submit participant content unless the user asked for that action.
A browser-only observation is not enough for claim-bearing evidence.

Escalation rules

Escalate when the browser and API disagree, when a participant can see the wrong condition surface, or when a UI path permits lifecycle bypass.

Available scripts

scripts/surface-preflight.mjs --base-url <url> [--cycle-id <id>] [--participant-id <id>]

Outputs

Readiness snapshot
Browser workflow observations
Server/browser mismatch report
Operator QA notes

Failure handling

If the browser surface fails but the server is healthy, preserve both observations. If the server contract fails, stop browser QA and fix the backend surface first.

Trust / safety notes

Participant-facing UI can alter trust in ACP. Treat condition leakage, stale digests, and misleading status labels as serious review findings.

Composition notes

Use in surface-preflight, pilot-cycle-review, and Foresight demo rehearsals.

Examples to inspect next

Read examples/casebook.md for happy path, failure path, ambiguity, and anti-pattern examples.

Evaluation hooks

Run scripts/surface-preflight.mjs and npm run skills:audit.