ticket-knowledge

name	ticket-knowledge
description	Use when Codex is handling ticket work and must load or inspect the CTOX ticket knowledge plane before any operational action.
metadata	{"short-description":"Load and inspect ticket knowledge before ticket handling"}
cluster	ticket_integration

Ticket Knowledge

CTOX Runtime Contract

• Task spawning is allowed only for real bounded work steps that add mission progress, external waiting, recovery, or explicit decomposition. Do not spawn work merely because review feedback exists.
• The Review Gate is a quality checkpoint, not a control loop. After review feedback, continue the same main work item whenever possible and incorporate the feedback there.
• Do not create review-driven internal work cascades. If more work is needed, reuse or requeue the existing parent work item; create a new task only when it is a distinct bounded work step with a stable parent pointer.
• Every durable follow-up, queue item, plan emission, or internal work item must have a clear parent/anchor: message key, work id, thread key, ticket/case id, or plan step. Missing ancestry is a harness bug, not acceptable ambiguity.
• Rewording-only feedback means revise wording on the same artifact. Substantive feedback means add new evidence or implementation progress. Stale feedback means refresh or consolidate current runtime state before drafting again.
• Before adding follow-up work, check for existing matching internal work, queue, plan, or ticket state and consolidate rather than duplicating.

Use this skill before ticket classification, dry run, execution, or writeback whenever ticket understanding depends on the CTOX knowledge plane.

Core Rule

No ticket should be handled operationally without loading the relevant ticket knowledge first.

The ticket system is only the communication surface. CTOX runtime knowledge is the source of truth.

Only CTOX runtime records count as durable ticket context. ticket_knowledge_entries are fact/context records used for ticket handling; they are not a substitute for source skills, skillbooks, runbooks, or runbook items when reusable operational knowledge is claimed. Workspace markdown files, copied ticket notes, or ad hoc analysis documents do not count unless the same facts are present in the runtime store.

Commands

Refresh observed knowledge from mirrored ticket data

ctox ticket knowledge-bootstrap --system "<system>"

Inspect ticket knowledge references

ctox ticket knowledge-list [--system "<system>"] [--domain "<domain>"] [--status "<status>"] [--limit "<n>"]
ctox ticket knowledge-show --system "<system>" --domain "<domain>" --key "<key>"

Load the reference context for a concrete ticket

ctox ticket knowledge-load --ticket-key "<ticket_key>" [--domains "source_profile,label_catalog,glossary,service_catalog,infrastructure_assets,team_model,access_model,monitoring_landscape"]

Inspect CTOX internal work around source understanding

ctox ticket internal-work-list [--system "<system>"] [--state "<state>"] [--limit "<n>"]

Operating Pattern

1. Refresh or inspect the source-specific knowledge plane.
2. Load the ticket-specific knowledge context.
3. If access or secret context is missing, stop operational handling and inspect the secret store or create an explicit access request through the onboarding or access skill.
4. If monitoring context is missing for infra/process questions, ingest or request monitoring evidence instead of guessing.
5. If domains are missing, stop operational handling, inspect existing internal work, and if needed create or continue a justified onboarding or maintenance work item instead of proceeding blindly.
6. If you continue an existing internal work item, assign it to CTOX if needed and leave a plain internal note about what knowledge gap you are resolving.
7. Only continue into dry run or execution once the knowledge load is ready.
8. Verify that the source is actually operationalized when that matters:
   • ctox ticket sources
   • ctox ticket source-skills
   • ctox ticket list --system "<system>"
   • ctox ticket knowledge-list --system "<system>" --limit 20 If the source is only running in local fallback or partial monitoring mode, say so explicitly and handle the work as knowledge/onboarding correction, not mature ticket execution.

When a concrete ticket cannot proceed because the requester or owner must supply a missing value, create a durable clarification request instead of leaving only a prose blocker:

ctox ticket clarification-request --case-id "<case_id>" --question "<exact question>" --target-type requester --target-channel ticket --missing-inputs "<csv>"

If the clarification is asked through the ticket system, publish only after the exact question has passed the relevant communication/review check:

ctox ticket clarification-request --case-id "<case_id>" --question "<exact question>" --target-type requester --target-channel ticket --missing-inputs "<csv>" --publish-reviewed --review-summary "<why this is safe and sufficient>"

Inbound ticket comments after a published clarification are linked back to the open clarification by ticket sync. Once resolved, the case returns to executable state so CTOX can continue from durable runtime state.

Important Boundaries

• Do not treat remote ticket fields as durable truth when CTOX knowledge already contradicts them.
• Do not hide knowledge gaps in prose; surface them explicitly through the ticket knowledge commands or internal work items.
• Do not skip knowledge load just because the ticket looks familiar.
• Do not leak raw secrets into ticket knowledge or ticket internal work metadata.
• Do not write internal storage or tool mechanics into remote ticket notes.
• Do not call a markdown file or workspace artifact "knowledge". If it is not in CTOX runtime state, it is not durable ticket context; if it is not in the Skillbook/Runbook hierarchy, it is not reusable operational knowledge.