Install any skill in seconds. Free to start, no credit card required.
Get Started Free →/observe — natural-language entry to the Policy Interaction Layer: compile an NL request into a structured observation/subscription policy, confirm via effect-card (or standing approval), then subscribe on the events plane.
.claude/skills/sonichi-observe/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 310% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 211% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 177% | 0% |
| case-05 | ✗→✓ | ▲ Improved | 207% | 0% |
| case-06 | ✗→✓ | ▲ Improved | 140% | 0% |
The owner (or a scoped user) says what they want watched, in natural language:
/observe watch doc changes in this room and ping me daily
The core agent COMPILES that into a structured draft; everything deterministic around the compilation lives in observe_policy.py. Design + resolved decisions: workspace notes/observe-mvp-slice-design.md.
/observe <text> owner task){room_id, event_types[], mode, cost_cap?, created_by, source_text}
room_id: the task's channel_id unless the text names another room.event_types: map the intent to plane types (message.created,reaction.added, artifact.updated, member.joined, …). Unknown intent → ask, don't guess.
mode: observe (context only) | record (journal) | notify (ping theowner) | taskify (promote batches to ambient tasks — never standing-approved).
observe_policy.validate_draft(draft) — errors go back to theuser verbatim; do not "fix" a draft silently.
owner_rooms=…). owner_rooms = rooms the owner OWNS — created by the owner or where the owner holds PL≥50 (checked via the room state the core already has; when ownership is unknown, the room is NOT in scope). Familiarity — "the owner sent a task from here" — is NOT ownership: a shared room must never enter standing-approval scope (001 review; the server's four-way authz still gates the subscribe, but the standing-approval semantic is stricter by design). True → save + transition(id, "active") + subscribe + post the AUTO-ACTIVATED card (visibility is mandatory — never activate silently). False → save draft + post the CONFIRM card and wait for the decision.
policy <id> activate | edit <new text> | cancel — typed reply, reaction on the card, or (when custom-event fan-out lands) an A2UI button. edit recompiles with the new text into the SAME policy id.
subscribe(room_id, event_types) —the events plane's four-way authz is the permission evaluator; a subscribe rejection (e.g. PL too low) goes back to the user as the card's failure line, not swallowed.
notify/record/taskify policies are consumed bythe sparrow drain handlers (taskify today; notify/record handlers are the next slice). cost_cap shows the CAP on cards; metering is a later slice.
observe_policy.py — validation, standing-approval evaluator,SubscriptionStore (<workspace>/state/observe/), effect-card renderer (plain text always; A2UI choice-group in the real renderer contract behind include_a2ui).
obs_*.json, states draft → active → cancelled/expired,terminal states immutable, every transition audited.
Test: python3 tests/observe-policy.test.py (99% module coverage).
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→pass | 4,500 | 14,463 | +221% | 1 | 1 | 0% | 635 | 2,601 | +310% | 0 | 0 | — |
case-07 | fail→fail | 6,495 | 6,360 | -2% | 1 | 1 | 0% | 973 | 1,268 | +30% | 0 | 0 | — |
case-02 | fail→pass | 6,092 | 14,733 | +142% | 1 | 1 | 0% | 893 | 2,773 | +211% | 0 | 0 | — |
case-03 | fail→pass | 6,830 | 10,439 | +53% | 1 | 1 | 0% | 972 | 2,691 | +177% | 0 | 0 | — |
case-04 | fail→fail | 5,755 | 6,691 | +16% | 1 | 1 | 0% | 774 | 1,146 | +48% | 0 | 0 | — |
case-05 | fail→pass | 4,439 | 10,395 | +134% | 1 | 1 | 0% | 643 | 1,971 | +207% | 0 | 0 | — |
case-06 | fail→pass | 7,911 | 14,134 | +79% | 1 | 1 | 0% | 1,030 | 2,474 | +140% | 0 | 0 | — |
case-08 | fail→pass | 6,633 | 10,697 | +61% | 1 | 1 | 0% | 906 | 2,518 | +178% | 0 | 0 | — |
case-09 | pass→pass | 3,272 | 6,724 | +106% | 1 | 1 | 0% | 442 | 1,831 | +314% | 0 | 0 | — |
case-10 | fail→pass | 7,908 | 8,329 | +5% | 1 | 1 | 0% | 1,133 | 2,150 | +90% | 0 | 0 | — |
case-11 | fail→pass | 6,606 | 13,161 | +99% | 1 | 1 | 0% | 879 | 2,891 | +229% | 0 | 0 | — |
case-12 | fail→pass | 6,448 | 15,079 | +134% | 1 | 1 | 0% | 901 | 2,771 | +208% | 0 | 0 | — |
case-13 | fail→pass | 6,276 | 8,691 | +38% | 1 | 1 | 0% | 841 | 2,238 | +166% | 0 | 0 | — |
case-14 | fail→pass | 5,248 | 9,854 | +88% | 1 | 1 | 0% | 640 | 2,320 | +263% | 0 | 0 | — |
case-15 | fail→pass | 8,257 | 8,777 | +6% | 1 | 1 | 0% | 1,436 | 2,278 | +59% | 0 | 0 | — |
case-16 | pass→fail | 5,192 | 5,552 | +7% | 1 | 1 | 0% | 711 | 1,029 | +45% | 0 | 0 | — |
case-17 | fail→fail | 6,345 | 6,899 | +9% | 1 | 1 | 0% | 830 | 1,171 | +41% | 0 | 0 | — |
case-18 | fail→pass | 2,707 | 12,022 | +344% | 1 | 1 | 0% | 421 | 2,361 | +461% | 0 | 0 | — |
case-19 | fail→pass | 4,037 | 12,302 | +205% | 1 | 1 | 0% | 575 | 2,237 | +289% | 0 | 0 | — |
case-20 | pass→pass | 9,171 | 4,377 | -52% | 1 | 1 | 0% | 1,197 | 1,528 | +28% | 0 | 0 | — |
case-21 | fail→pass | 12,468 | 3,777 | -70% | 1 | 1 | 0% | 1,705 | 1,418 | -17% | 0 | 0 | — |
case-22 | pass→pass | 9,742 | 3,193 | -67% | 1 | 1 | 0% | 1,395 | 1,294 | -7% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted, and 18 counted toward the lift figure. The other 4 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +64 percentage points is the difference between those two pass rates over the 18 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.