Skip to main content
Glama

aiworkhub_task_create

MANAGER WRITE: create one new canonical repo-local task card.

Instructions

MANAGER WRITE: create one new canonical repo-local task card.

Creation choices (also exposed as field hints): difficulty: bounded, standard, complex (optional; never inferred). work_kind: generic, bugfix, refactor, performance, security, data_ml. validation_roles: generic, reproduction, regression, parity, baseline, delta, negative_fixture, schema, distribution; one per validation command. Required roles: bugfix=reproduction+regression; refactor=parity; performance=baseline+delta; security=negative_fixture; data_ml=schema+distribution. validation: shell-free executable commands; no environment assignments, pipes, redirects or chaining. Set environment outside validation argv. custom_template_escape: audited_custom_unclassified, explicitly audited unclassified cards only, not an automatic bypass; writable escaped cards require non-empty required_outputs covered by allowed_writes.

Replies with a creation receipt (aiworkhub.task_create_receipt.v1): task_id, created/reconciled/receipt_state, scope_warnings, the server-derived validation_roles, risk_tier/origin/signals, difficulty/origin, validation_exemption, template_provenance, the project_context Source Graph query, and card_sha256/card_bytes -- never the card the caller just typed. echo_card=True returns the full CLI envelope with the persisted card in stdout instead. A refusal names every violation at once (violations) with field, length and limit. The live manager session supplies callback provider/origin identity; callers cannot route a task into another chat, disable the mandatory review callback, or overwrite an existing id. depends_on (optional) names other task_ids in this repo that must finish before this card is Plan-DAG ready; omit it for the pre-DAG behavior. Tasks are uncapped by default. Never infer, estimate, or auto-assign max_live_tokens from task complexity, model, historical usage, or cost. Supply it only when the owner explicitly requests an exact cap or a repository policy pre-registers one. Process efficiency must come from focused context, bounded reads, minimal edits, fewer retries, and useful validation rather than from truncating work. An authorized cap is enforced only when the selected provider exposes structured usage while running; terminal-only usage remains posthoc evidence, never a false live- enforcement claim. A writable task's required_outputs may be empty ONLY when template classification matches a contract that declares that default itself (e.g. implementation_with_tests/cross_boundary_bugfix, whose combined production+test scope keeps a deliberate empty default per NF-2026-00456) or an explicit, in-scope mandatory list resolves that way. Every other writable outcome -- including the audited custom-escape path, which has no template contract of its own to fall back on -- requires a non-empty required_outputs (NF-2026-00772); it contains only repo-relative file paths or glob patterns covered by allowed_writes. Human-readable outcome descriptions belong in acceptance; mixing prose into required_outputs is rejected before a provider run is launched. allow_unchanged_required_outputs explicitly names required files that are evidence inputs/outputs permitted to remain byte-identical to both launch baselines; they are verified and hashed but never promoted. allow_empty_required_outputs is the equivalent explicit exception for deliberately zero-byte outputs. Neither exception is inferred. read_only=True is required for a task that intentionally declares both allowed_writes=[] and required_outputs=[]. Read-only intent is never inferred from missing output authority. runner is the worker execution identity returned by aiworkhub_manager_workforce_rank.launch_contract.runner. The exact value codex is reserved for the verified manager and is rejected for worker cards. work_kind is an explicit behavioral contract, never inferred from the title or worker prose. Specialized values require one validation_roles entry per validation command: bugfix=reproduction+regression, refactor=parity, performance=baseline+delta, security=negative_fixture, and data_ml=schema+distribution. Missing roles are rejected before launch. risk_tier is optional explicit routing/economic evidence. It is never inferred from priority or prose; omitted historical cards remain unknown. It is a FLOOR: the observed write scope may escalate it, never lower it. The skill_* fields are the card's skill selection vocabulary, drawn from closed sets (aiworkhub_manager_skill_mine and skill_registry.SELECTION_VOCABULARIES name them). An unknown token is refused at create rather than silently matching nothing. skill_task_family and skill_path_scope are derivable from the template and the write set and may be omitted; skill_stage, skill_triggers and skill_applicability are not derivable, and a card that omits them selects no skill at all. Default creation is template-first: generic Python production-plus-test cards classify against the frozen registry, and unclassified raw cards fail closed unless custom_template_escape is the audited token. wave_goal_binding (optional) is exactly {roadmap_id, goal_id, predecessor_task_id} and makes this card that active wave goal's current task in place of the predecessor. It is never inferred from a title, topic, version suffix or prose; the receipt names its state.

Input Schema

NameRequiredDescriptionDefault
titleYes
topicYes
runnerYes
task_idYes
priorityNonormal
echo_cardNo
forbiddenNo
objectiveYes
read_onlyNo
risk_tierNo
task_typeNocode
work_kindNoAccepted work_kind values: generic, bugfix, refactor, performance, security, data_ml. Case and surrounding space are normalized by core; never infer from prose.generic
acceptanceYes
depends_onNo
difficultyNoAccepted difficulty values: bounded, standard, complex. Optional; omitted remains undeclared, never inferred. Case and surrounding space are normalized by core.
read_firstNo
validationNoshell-free executable commands, one per entry; no environment assignments, pipes, redirects, or command chaining. Set environment outside validation argv.
skill_stageNo
allowed_writesYes
skill_triggersNo
max_live_tokensNo
immutable_inputsNo
required_outputsNo
skill_path_scopeNo
validation_rolesNoAccepted validation_roles: generic, reproduction, regression, parity, baseline, delta, negative_fixture, schema, distribution. Supply one role per validation command. Required: bugfix=reproduction+regression; refactor=parity; performance=baseline+delta; security=negative_fixture; data_ml=schema+distribution. Case and surrounding space are normalized by core.
skill_task_familyNo
wave_goal_bindingNo
skill_applicabilityNo
apply_contract_patchNo
custom_template_escapeNoExplicit audited escape token: audited_custom_unclassified. Only for deliberately audited unclassified cards, not an automatic bypass. Writable escaped cards require non-empty required_outputs covered by allowed_writes.
allow_empty_required_outputsNo
allow_unchanged_required_outputsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the entire behavioral burden and does so: it states that callers cannot overwrite an existing id, cannot disable the mandatory review callback, cannot route into another chat, that "codex" is rejected for workers, that refusals enumerate all violations at once, and that live token enforcement only holds when the provider exposes structured usage. It also spells out the receipt contract and that the card itself is never echoed unless echo_card=True.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence is correctly front-loaded and the density is justified by a 32-parameter contract with heavy policy. However, the work_kind/validation_roles role requirements are stated verbatim twice, and the wall-of-prose format makes scanning for a specific rule costly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create tool with a declared output schema, the description covers validation-failure modes, identity constraints, receipt shape and the most dangerous options (escape token, read_only inference, max_live_tokens). The remaining hole is the handful of undocumented optional parameters that could break creation, notably apply_contract_patch and immutable_inputs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 16% across 32 parameters, so the description must compensate and largely does: difficulty, work_kind, validation_roles, validation argv constraints, custom_template_escape, required_outputs, the two allow_* exceptions, read_only, runner, risk_tier, the skill_* family and wave_goal_binding all get real semantic explanation. Gaps remain for immutable_inputs, apply_contract_patch, forbidden, read_first, priority and task_type, which are never explained anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"MANAGER WRITE: create one new canonical repo-local task card" gives a specific verb, resource and scope, and the MANAGER WRITE prefix separates it from the many read-only siblings. It never names aiworkhub_task_create_from_template, so an agent must infer whether the template path or this raw path is the right entry point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage rules are extensive but almost entirely field-level (when to supply depends_on, when to set max_live_tokens, when custom_template_escape applies) rather than tool-selection-level. There is no explicit statement of when to call this instead of aiworkhub_task_create_from_template or aiworkhub_manager_task_decomposition_preview; the template-first paragraph implies the boundary but does not name the alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools