Write tickets

Invocation, authority and companions

Use for ordinary matching requests or bounded authorized handoffs. Own cohesive decomposition, ticket publication/reconciliation and verified native relationship/role outcomes. Stop before scheduling, implementation, closure, merge or release. Loading this skill grants no remote mutations, delegation, installation, model calls or additional disclosure.

Accept an approved brief/spec with current technical readiness, or a bounded bug investigation. Inspect target instructions, agreement/acceptance references, deciding source revisions or dirty-content digests, exclusions, confirmed decisions, evidence/gaps, exact authority and approval source, protected work/current graph, and expected result. Conversation input is sufficient; no mandatory form or delivery run. Keep multi-session state only at an authorized retained location.

A bug-ready input includes expected/actual behavior and impact, reproduction/environment and observed results/intermittency, established cause and affected sources, bounded fix/exclusions/dependencies/risks, acceptance/regression checks, method recommendation and temporary-probe disposition. Reuse complete current evidence without automatically invoking Analyze or investigation. Compare deciding inputs on receipt/resume; invalidate only dependent findings when scope is clear, otherwise mark relevant evidence stale. Missing cause or unconfirmed symptom returns an investigation-only draft/gap, not a ready fix ticket. With exact publication approval, that draft may be persisted as explicitly investigation-only work: retain attempted observations, missing cause/confirmation, the blocker and bounded diagnostic acceptance/next action; do not invent fix scope or assign implementation readiness. A standalone bug needs no artificial spec parent or implementation-step role: use the target's approved standalone classification. Match existing tickets before proposing a new one.

Discover companions by runtime/project catalog or explicit approved location, not sibling paths. Read complete entries and relevant references, record resolved source/revision or digest, and compare semantic capabilities. Ambiguous candidates block the affected route; recheck changed source, authority or task. Required GitHub persistence uses the discovered Setup Project tracker library with native hierarchy/blockers, actual IDs, pagination, conflict checks, additive writes and both-direction read-back. Reading it does not invoke setup. Other trackers need a project-approved native procedure. Missing capability permits labeled drafting, not verified persistence or silent prose substitutes.

For material technical gaps, use discovered compatible Analyze for bounded prerequisite inspection within existing task authority; do not ask again merely to read sources or use the skill. Execute directly unless delegation is separately authorized. Supply the missing questions, current agreement/evidence, permitted effects and expected return. On return, inspect its findings and support, retain current evidence, resolve routine technical choices, and resume ticket preparation under the original request. A specialist return is an intermediate result, not work for the user to coordinate. Missing authority, unavailable capability or consequential product uncertainty blocks only the affected work; return the specific gap and recommended next action to its owner. Optional delegation needs separate authorization and the discovered Work On read-only execution contract: the root owns shared capacity, bounds and repair lineage; workers do not recursively delegate. Missing contract blocks delegation, not direct ticket drafting. No model assessment is needed.

Read validation when changing or testing this package.

1. Establish the agreement and tracker capability

Pin the approved brief/spec and technical-plan revisions, or the bounded bug investigation and its deciding inputs, acceptance references, exclusions, settled decisions, authority and protected work. Distinguish complete ready evidence from an explicitly unresolved investigation draft; the latter can authorize diagnostic work only, with its missing facts and bounded diagnostic acceptance preserved. For a standalone bug, checkable regression criteria can supply acceptance references without an owning spec. The ticketing caller owns routine design, dependency, method and verification choices from inspected evidence unless the user requests technical collaboration. These choices must preserve agreed behavior; they cannot silently add product commitments. Missing consequential product decisions return to their agreement owner as concise outcome/scope/risk questions with a recommendation; ticketing does not settle them by creating tasks. For a small cohesive change, recommend direct build instead of manufacturing a hierarchy. Reuse suitable existing tickets rather than decomposing again.