Test a skill by hand

On the bus, your skill executor is a consumer of story.context and a producer of skill.warning.raised. You can test it end to end on the Sandbox today. You need:

• a consumer connection for your executor, subscribed to story.context and its other triggers;
• your executor's app connected as a producer granted skill.warning.raised (Credentials);
• a second app of yours that publishes story.context, to trigger it.

The run

1. With your producer app, publish a snapshot that should trigger your skill: a headline with a term your style skill flags, for example.
2. Check that your executor publishes one skill.warning.raised within your expected time (5 seconds is RND's target, P-15), and that it's accepted with 202.
3. On the portal's Story timeline, the warning appears on the right story, after the snapshot that caused it.
4. Publish a snapshot that shouldn't trigger it. Check there's no warning.
5. Publish the next snapshot of the triggering story, unchanged in the watched field. RND's executors stay silent while nothing changes (P-08). Whatever yours does, it must never raise the same warning_id twice.

Test	Expect
A trigger snapshot	Exactly one warning, 202, causation_id = the snapshot's message_id
A non-trigger snapshot	No warning
The same snapshot redelivered, by a replay	No second warning. The bus de-duplicates on message_id, so a re-raised warning with a new message_id would reach every consumer again
A snapshot of a KILLED story	No warning (P-12)
A snapshot with an unknown extension	Your skill runs normally

Check each warning against A warning that validates and How an executor behaves.

The skill harness in Test runs does this for you with the suite's fixtures, and grades every case. The skill dev kit, to do the same from your command line and CI, is coming.

Checkpoint

• [ ] My warnings pass the Playground and are accepted on publish.
• [ ] Every warning carries the trigger's correlation_id, and its message_id as causation_id.
• [ ] Trigger, no-trigger, redelivery and killed-story tests behave as above.
• [ ] Anything that depends on a message type without a 1.0 schema is listed as provisional.