AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

To Tickets

skill-saikaaco-saika-hermes-skills-to-tickets · by SaikaAco

Use when the user explicitly asks to turn an approved specification, plan, or settled contract into agent-sized implementation tickets with requirement coverage and blocking edges. Drafts first; publishes only with separate authority.

No reviews yet
0 installs
18 views
0.0% view→install

Install

$ agentstack add skill-saikaaco-saika-hermes-skills-to-tickets

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-saikaaco-saika-hermes-skills-to-tickets)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
1mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of To Tickets? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Traceable To-Tickets

Lineage

This is an MIT-licensed Hermes adaptation of Matt Pocock's public to-tickets. The complete upstream notice is preserved in [references/third-party-notices.md](references/third-party-notices.md).

Compile one exact, user-accepted source snapshot into an agent-sized delivery graph. Initial invocation authorizes a chat draft only.

DRAFT_READY means an honest reviewable draft exists; it does not mean grounding is complete or authorize publication or implementation. Pending pre-publication grounding, graph rechecks, or fresh approval may coexist with DRAFT_READY when accepted facts already determine the safe draft shape. Use BLOCKED when missing facts prevent an honest draft or materially change its graph, sizing, sequencing, or safety. For decision-only decomposition, do not block merely because later implementation details remain unknown.

Source and grounding

Accept one exact source snapshot with identifiable scope, owner, requirements, decision/evidence handles, constraints, negatives/exceptions, out-of-scope boundaries, observable acceptance, and required evidence. Do not infer acceptance or current truth from an old conversation, a similarly named file, or mere draft existence. Keep source_snapshot exactly equal to the accepted version, revision, fingerprint, or message handle. Put drift history or missing-revision explanations in lineage, blockers, or a separate drift field; never append those explanations to the snapshot value.

Before slicing, inspect only current repository and record evidence needed to validate implementation-facing claims: active project/tracker policy, governing decisions and vocabulary, relevant interfaces, seams, behavior and tests, plus source negatives, exceptions, and acceptance methods. Prior exploration does not validate a specific claim. A direction to reuse an unnamed “existing seam” does not itself verify that seam.

Verify every claim that determines ticket size, blocker edges, blast radius, or acceptance. For an actual ticket bundle, do not claim DRAFT_READY or grounding passed when unavailable evidence would require route-changing guesswork. Never invent a seam, cohort, owner, dependency, acceptance boundary, or implementation fact. Exact files belong to later Plan work, but uncertainty that changes graph, sizing, sequencing, coverage, or safety blocks drafting. Name the missing evidence and required regeneration checks rather than emitting placeholder tickets.

Compile the graph

Ordinary work

Prefer narrow vertical slices. Each ticket must:

  • deliver one observable end-to-end behavior across every required layer;
  • fit one fresh implementation context and leave the repository green;
  • own source-derived positive and negative acceptance plus evidence across every

applicable behavior class: validation/failure, authorization, retry and idempotency, atomicity and rollback, audit, confidentiality/metadata, and temporal or compatibility transitions;

  • preserve source semantics exactly: never strengthen, relax, or redefine an

exception, grace period, compatibility window, security boundary, or non-goal;

  • be independently demonstrable, with no hidden half-feature or follow-up needed

to satisfy the behavior it claims;

  • preserve atomic requirements together: do not split required audit, security,

idempotency, rollback, or failure behavior from the operation whose safe completion depends on it.

For each applicable behavior, make cross-effects explicit:

  • authorization failure, expiry, revocation, or a nonexistent handle causes no

protected mutation, no success audit, and no protected metadata or secret disclosure unless the source explicitly permits an effect;

  • same-key retry duplicates none of the source-required persisted effects,

including primary records, audit records, events, or handles;

  • temporal and grace behavior is verified before, during, at the boundary, and

after transition without redefining the source contract.

Split large work by independently usable behavior, not schema/API/UI or other horizontal layers. A separate infrastructure or preparation ticket is allowed only when independently verifiable and a genuine blocker. Preserve unrelated parallelism; never add edges for review order or convenience.

Wide migrations

When the source establishes a wide mechanical change, use expand → independently green migration batches → contract:

  1. add a backward-compatible expansion and mixed-version contract evidence;
  2. migrate explicitly bounded, owned, independently testable cohorts in

parallel where safe;

  1. remove the old contract only after every cohort is verified migrated.

If intermediate batches cannot be independently green, name the integration boundary and add final integration verification instead of claiming each batch is releasable. Missing cohort membership, ownership, transition semantics, conflict behavior, or contraction evidence that changes sizing or safety is BLOCKED, not a placeholder ticket.

Coverage and graph checks

Use stable draft IDs and only real blockers. Reject missing, self, or cyclic edges and compute the true frontier. frontier is stage-specific: a DRAFT_READY bundle may show structural start nodes for review but creates no implementation authority; BLOCKED and RECONCILE_REQUIRED bundles always use frontier: []. Never expose a blocked, unknown-body, or reconciliation-pending ticket as actionable.

Cycle-check completeness concerns the intended ticket-ID/blocker-edge set, not ticket bodies, acceptance, or source mappings. If all intended IDs and edges are known, run the check even when grounding or coverage remains blocked. If that ID/edge set is unavailable or incomplete, set cycle_check: not_run; never claim passed for an unaudited graph. Prove both directions: every current requirement/constraint maps to tickets or an explicit owner-accepted disposition, and every ticket maps to source requirements, decisions/evidence, and acceptance. Omission, orphan scope, silent expansion, or self-accepted disposition is BLOCKED.

Canonical schemas

Every ticket uses this contract:

id: 
status: DRAFT | READY | BLOCKED | PUBLISHED
parent: 
source_snapshot: 
owner: 
source_requirements: []
source_decisions_evidence: []
blocked_by: []
delivers: 
acceptance_criteria: []
verification_evidence: []
constraints: []
exclusions: []
authorization: 

The bundle uses this contract:

schema: to-tickets-bundle-v1
state: DRAFT_READY | PUBLISHED | BLOCKED | RECONCILE_REQUIRED
source: 
source_snapshot: 
source_owner: 
lineage:  ticket graph>
tickets: []
frontier: []
coverage:
  requirement_to_tickets: 
  ticket_to_source: 
  dispositions: 
  uncovered_requirements: []
  orphan_tickets: []
cycle_check: passed | failed | not_run
grounding_status: passed | blocked
publication:
  backend: none | local | tracker
  approval_binding: none | 
  persistence: none | partial | confirmed
  published_handles: []
  readback_verified: false

Additional presentation fields are allowed, but these meanings and types must not be silently replaced by an ad-hoc schema.

Authority, drift, and recovery

  • Publication requires later approval bound to the exact reviewed graph and one

named backend. A configured tracker, old access, source approval, draft request, or generic “go ahead” is not publication authority.

  • Graph approval and backend authorization are separate. Naming or approving a

backend does not invalidate approval of an unchanged graph; source or graph changes do.

  • RECONCILE_REQUIRED preserves the exact approval binding for an unchanged

graph. Uncertain, partial, or unverified persistence alone never clears that graph approval.

  • An approved ticket ID whose source mapping is temporarily unavailable remains

approved-but-unresolved, not an orphan. Keep orphan_tickets: [] unless evidence proves a ticket lacks source authority; represent unknown mappings as blocked or unknown coverage instead.

  • Source drift invalidates coverage and approval. Graph mutation requires

affected grounding, bidirectional coverage, cycle/frontier checks, and new exact publication approval.

  • Create blockers first where handles are needed, then bodies and real edges;

read back bodies, edges, labels, and handles before claiming PUBLISHED or applying ready-for-agent to verified approved child tickets.

  • On uncertain or partial writes, preserve known handles, search stable

idempotency keys before retry, never recreate blindly, and return RECONCILE_REQUIRED until reconciled.

  • Never plan implementation, dispatch agents, create Kanban, implement, commit,

deploy, complete tickets, or modify/close/label the parent specification. A ticket graph never creates implementation authority.

  • A request for exact files, code, tests, or commands for one existing ticket

routes to Plan, not To-Tickets.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.