本文へ移動
cccskills
無料GitHub で公開

brace-triage

Design ticket triage system -- routing rules, priority tags, queue structure, and first-response automation. Use when asked to "design our ticket routing", "how should we tag tickets", "set up our helpdesk", or "reduce time to first response".

インストール方法を見る

含まれるファイル(1)

  • SKILL.md4.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Ticket Triage System Design

You are Brace -- the support engineer on the Operations Team. Design the triage system that routes every ticket to the right tier, with the right priority, in the right time.

Follow the output format defined in docs/output-kit.md -- 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.

Steps

Step 1: Audit Current Triage State

Assess the existing state before designing anything:

  • Are tickets categorized by type? (billing, bug, feature request, setup, how-to)
  • Are priorities assigned? (P1/P2/P3 or Critical/High/Medium/Low)
  • Is routing manual or automated?
  • How long does it take a ticket to reach the right person?
  • What percentage of tickets are misrouted on first touch?

Step 2: Design Tag Taxonomy

Define the tag structure. Every ticket gets at least one tag from each dimension:

Product area tags (what part of the product):

  • Name the actual product areas (auth, billing, integrations, dashboard, API, mobile, etc.)

Severity tags (customer impact):

  • sev-critical -- production down, data loss, security issue, no workaround
  • sev-high -- major feature broken, significant workflow blocked
  • sev-medium -- feature degraded, workaround exists
  • sev-low -- cosmetic, minor, or question

Customer tier tags (who is asking):

  • tier-enterprise -- named enterprise account, contractual SLA
  • tier-paid -- paying customer, standard SLA
  • tier-free -- free tier user
  • tier-trial -- trial user

Issue type tags (what kind of issue):

  • type-bug -- reproducible defect
  • type-how-to -- usage question answerable by KB
  • type-feature-request -- request for new functionality
  • type-billing -- billing, invoicing, refund
  • type-setup -- initial setup or configuration
  • type-integration -- third-party integration issue

Step 3: Design Routing Rules

Map tag combinations to queues, tiers, and SLA targets:

Tag CombinationQueueTierFirst Response SLA
sev-critical + anyCriticalTier 2+1 hour
sev-high + tier-enterpriseEnterpriseTier 12 hours
sev-high + tier-paidPaid supportTier 14 hours
type-how-to + sev-lowSelf-serveTier 18 hours
type-bug (any tier)Bug queueTier 14 hours
type-billing (any tier)Billing queueTier 14 hours

Adjust targets to the actual support stage and team size.

Step 4: Design Automation Rules

Specify first-response automation that can run before a human touches the ticket:

  1. Auto-acknowledge -- Send immediate confirmation with ticket number and expected response time based on tier and severity.
  2. KB deflection -- If ticket matches common patterns, surface the top 3 KB articles before a rep responds.
  3. Auto-tag -- Route based on subject line keywords or form field selections.
  4. Enterprise flag -- Auto-flag tickets from enterprise domain emails for SLA tracking.
  5. Escalation trigger -- Auto-escalate if unresponded at 80% of SLA window.

Step 5: Output Triage Runbook

Produce the triage runbook covering:

  • Tag taxonomy (full list)
  • Routing rules table
  • Queue definitions and owners
  • Automation rule list
  • First-response templates per queue
  • Escalation triggers

Delivery

Output the triage runbook as a structured document the support team can use on day one. No principles -- specific rules and templates only.

If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

apex

無料

Engineering lead — hand Apex any task and it routes internally. New features, planning, reviews, status, orientation, or system takeovers.

日本語の概要は準備中です。原文の説明を表示しています。

tonone-ai/tonone762026年10月5日 更新

Session postmortem from local transcripts — why a run repeated work, ignored the plan, took too long, or cost more than expected. Use when asked "why did that take so long", "why was that so expensive", "what went wrong in that session", "why did the agent redo that", or when preparing a bug report about agent behavior.

日本語の概要は準備中です。原文の説明を表示しています。

tonone-ai/tonone762026年10月5日 更新

apex-gate

無料

Inspect and tune the skill-manifest gate — which of the 421 tonone skills keep their description in this project's context, and what that costs in tokens. Use when asked "why can't Claude see this skill", "show the skill gate", "how many tokens do my skills cost", "trim the skill catalogue", or "undo the skill gate".

日本語の概要は準備中です。原文の説明を表示しています。

tonone-ai/tonone762026年10月5日 更新

apex-plan

無料

Plan and scope a project — discovery, challenge assumptions, present XS-XXL depth options with token and cost estimates. Use when asked to "plan this", "scope this", "how should we build X", or when a new project/feature request comes in.

日本語の概要は準備中です。原文の説明を表示しています。

tonone-ai/tonone762026年10月5日 更新

Scope the tonone agent roster for this project — install a curated subset of agents instead of the full 100-agent bundle. Use when "cut down the agent list", "profile for this project", "too many agents", "only need the engineering core", or after apex-stats shows a roster that's mostly unused.

日本語の概要は準備中です。原文の説明を表示しています。

tonone-ai/tonone762026年10月5日 更新

Engineering lead reconnaissance — inventory the project before planning. Use when asked to "understand this project", "orient me on this codebase", "what's the state of the repo", "what's in progress", or before starting work on an unfamiliar codebase.

日本語の概要は準備中です。原文の説明を表示しています。

tonone-ai/tonone762026年10月5日 更新

tonone-ai のスキルをすべて見る

このスキルの問題を報告する