Conciseness

The body is dense and efficient — tables and compact code instead of prose, and explanations are project-specific facts (e.g. "'EventActivity.Execute' returns 'Halt()' by default — the workflow persists and waits") rather than general knowledge Claude already has. Not 5: the Quick Reference section repeats material already in references/activities.md (the GetProperty/SetProperty pattern, outcome helpers, and WorkflowExecutionContext tables all appear in both), which could be trimmed to pointers. Not 3: there is no padding or over-explanation.

Actionability

Concrete, near-executable guidance throughout: full task class, display driver with EditActivity/UpdateActivity mapping, exact shape template filenames ('LogTask_Fields_Thumbnail.cshtml'), and the registration call `services.AddActivity<LogTask, LogTaskDisplayDriver>()`. Not 5: the event example uses `S` and `_expressionEvaluator` without showing its constructor (defined only in the task example), the task's ExecuteAsync contains a '// ... do work ...' placeholder, and the shape-templates step gives filenames but no template content or Razor example.

Workflow Clarity

A clear five-step sequence (activity class → display driver → shape templates → registration → test) with a validation checkpoint in Step 5: 'Build, open Admin → Workflows, create a workflow, drop your activity, wire its outcome, run.' Not 5: there is no error-recovery feedback loop (e.g. what to check when the build fails or the activity doesn't appear in the picker); not 3 because the sequence is complete, correctly ordered, and ends with an explicit test-and-verify step including the event resume path.

Progressive Disclosure

Good structure: the body is a working overview with a clearly signaled one-level-deep reference — 'references/activities.md — base classes, state, outcomes, expression evaluation, full examples' — which exists and matches its advertised scope, plus pointers to repo docs. Not 5: a noticeable share of the body's Quick Reference and Gotchas content duplicates activities.md verbatim in spirit, so the split is not as clean as it could be; not 3 because references are prominent, shallow, and the core file organization is sound.

Specificity

The description lists multiple concrete actions — 'Creates custom OrchardCore workflow activities — tasks and events — with their display drivers and registration', plus 'custom outcomes, activity editor UI, or to read/write workflow input, output, and properties' — giving comprehensive, specific coverage of what the skill produces. Not 4: coverage is broad and each named capability is a distinct concrete deliverable, with no significant gaps.

Completeness

It explicitly answers both: what — 'Creates custom OrchardCore workflow activities … with their display drivers and registration' — and when — 'Use when the user needs a new workflow Task or Event, custom outcomes, activity editor UI, or to read/write workflow input, output, and properties.' Both are concrete and explicit, matching the anchor for a clear what plus a concrete 'Use when' trigger list. Not 4: the when-clause enumerates specific trigger scenarios rather than being merely adequate.

Trigger Term Quality

Good natural-term coverage: 'workflow', 'Task', 'Event', 'workflow activity', 'activity editor UI', 'input, output, and properties' are phrases an OrchardCore user would naturally say. Not 5: a few plausible natural terms (e.g. 'trigger', 'signal', 'resume', 'workflow canvas') are missing; not 3 because the included keywords are the domain's primary vocabulary, not generic.

Distinctiveness Conflict Risk

'OrchardCore workflow activities' carves out a clear niche with domain-specific triggers (display drivers, outcomes, workflow input/output) that no general-purpose skill would claim. Minimal conflict risk — only a hypothetical competing OrchardCore-workflows skill overlaps. Not 4: it is not merely 'mostly distinct'; the domain vocabulary makes accidental triggering very unlikely.