From vnext-ai-toolkit
Use when the user wants to create a new vNext Task component (HTTP, Script, SOAP, Dapr, Notification, GetInstances, etc.). Fetches task.json schema first, drives type and config selection from the schema enum, scaffolds a .csx mapping if needed, suggests a matching MockLab seed.
How this skill is triggered — by the user, by Claude, or both
Slash command
/vnext-ai-toolkit:component-taskThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A Task is the unit of action inside a workflow — invoked from a transition's `onExecutionTasks[]`, a state's `onEntries[]`/`onExits[]`, or composed inside a Function. The `type` field selects the kind of action (HTTP, script, SOAP, Dapr, notification, etc.).
A Task is the unit of action inside a workflow — invoked from a transition's onExecutionTasks[], a state's onEntries[]/onExits[], or composed inside a Function. The type field selects the kind of action (HTTP, script, SOAP, Dapr, notification, etc.).
Before asking about task type or config, fetch
task.jsonfor the workspace'sschemaVersion. The task type enum, the per-typeconfigshapes, and the required-field lists all live in this schema — never hardcode them.
1. Read vnext.config.json → schemaVersion + domain + paths.tasks
2. Fetch https://raw.githubusercontent.com/burgan-tech/vnext-schema/v{schemaVersion}/schemas/task.json
├─ Fail → master branch → references/concepts/component-schemas.md snapshot
└─ No snapshot → halt; never guess.
3. Parse:
- properties.attributes.properties.type.enum (or oneOf branching on type)
- per-type `config` shape (HTTP has url/method/headers/body; SOAP has wsdl/...; Dapr has app-id/...)
- required[] per type
4. Drive AskUserQuestion options + skeleton from this schema.
See references/concepts/component-schemas.md and references/concepts/function-vs-extension-vs-task.md for the mental model.
From vnext.config.json: componentsRoot, paths.tasks, domain.
Target path: {componentsRoot}/{paths.tasks}/{domain-subfolder}/{task-key}.json.
The {domain-subfolder} mirrors the parent workflow's folder name when the task is workflow-specific (e.g. account-opening). For shared/cross-workflow tasks, use a meaningful grouping (e.g. shared, notifications).
Ask:
Render AskUserQuestion with the enum from task.json. Annotate by common use:
HttpTask (type usually 6)ScriptTask (usually 7)NotificationTask (usually 10) — requires INotificationMappingGetInstancesTask (usually 15)SoapTask (usually 16)DaprService (usually 3)DaprPubSub (usually 4)StartFlowTaskTriggerTransitionTask(Verify the exact numbers and full list from the fetched schema — the table above is illustrative.)
config from the schemaOnce the user picks a type, the schema tells you the per-type config shape. For example, an HTTP task's config needs url, method, optional headers, body, timeoutSeconds, validateSsl. Walk the user through each required field.
For URLs that hit external systems during development, default to MockLab: http://localhost:3001/api/{domain}/{resource}/{action}. Production URLs are hardcoded only when explicitly requested.
Read one existing task of the same type in this workspace (or in vnext-example) for envelope reference. Examples:
vnext-example/core/Tasks/account-opening/create-bank-account.jsonvnext-example/core/Tasks/.../flow-types-script-task.jsonvnext-example/core/Tasks/.../notification-task.jsonvnext-example/core/Tasks/.../dapr-service-task.jsonUse it to confirm field order; don't blindly copy.
Standard envelope:
{
"key": "{task-key}",
"version": "1.0.0",
"domain": "{domain}",
"flow": "sys-tasks",
"flowVersion": "1.0.0",
"tags": [],
"attributes": {
"type": "{type-from-schema}",
"config": { /* per-type, populated from schema requirements */ }
}
}
Write to the path from Step 1.
.csx mapping if the caller needs oneMost consumers (transitions, functions) attach a mapping to their reference of this task. The mapping lives in the caller's src/ folder, not the task's:
{paths.workflows}/{workflow-key}/src/{ClassName}Mapping.csx{paths.functions}/{function-key}/src/{ClassName}Mapping.csxFor NotificationTask, the mapping implements INotificationMapping (per-channel). For all other tasks, the mapping usually implements IMapping.
Use references/concepts/csx-contracts.md for the exact interface signature, standard using directives, and class structure.
If the task calls localhost:3001, append a mocks[] entry to the domain's collection file at etc/docker/config/seed/{domain}-collection.json. One collection per domain — don't split.
Mock entry pattern (see references/concepts/mocklab-spec.md for the full reference):
{
"httpMethod": "POST",
"route": "api/{domain}/{resource}/{action}",
"statusCode": 200,
"responseBody": "{ \"id\": \"{{ guid }}\" }",
"contentType": "application/json",
"delayMs": 500,
"rules": [
/* per-input-condition responses, if needed */
]
}
Remind the user: after editing seeds, run docker compose down -v && docker compose up -d mocklab to force re-import.
Run npm run validate. Hand off failures to validate-and-fix.
If the user wants this task wired now, edit the caller (workflow transition's onExecutionTasks[] or function's task / onExecutionTasks[]) and add the reference:
{ "key": "{task-key}", "domain": "{domain}", "flow": "sys-tasks", "version": "1.0.0" }
Re-validate.
type numeric values come from the schema — never hardcode them.NotificationTask without an INotificationMapping is a runtime no-op — always pair them.Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub burgan-tech/vnext-ai-toolkit --plugin vnext-ai-toolkit