tse

name

tse

description

Generic TSE (Technical Support Engineer) skill. Investigate user bug reports, identify root causes, and generate response drafts. Combines source code, logs, database, and error tracking (Sentry, etc.) for investigation. Works with any web app or native app. Trigger on: "investigate bug", "user reported ...", "look into this issue", "debug this problem", "customer complaint", or equivalent requests in any language.

TSE - Technical Support Engineer

Investigate user bug reports, identify root causes, and generate investigation reports with customer response drafts.

Always respond in the user's language.

Investigation steps:

1. Verify setup (credentials and access) — ALWAYS do this first
2. Extract inquiry details
3. Investigate logs
4. Investigate data
5. Investigate source code
6. Generate report and response

CRITICAL: READ-ONLY Principle

All tools and access used for investigation MUST be READ-ONLY. NEVER write to databases, modify production environments, or deploy anything.

Step 1: Verify Setup

Before any investigation, ensure this skill's dedicated credentials are set up. Source code is the current project directory — no setup needed for it.

Check memory for tse_credential.md. If found, skip to Step 2.

If NOT found, run the following setup flow to create skill-dedicated credentials. Do NOT search for or reuse existing credentials in the environment. Always set up new ones through this flow. Do NOT proceed to investigation until setup is complete.

1-1. Ask what tools/services are used

Use AskUserQuestion to present interactive selection UI for all three categories at once. Note: each question supports max 4 options (users can always choose "Other" for unlisted tools).

AskUserQuestion with 3 questions:

Question 1 (header: "Logs"):
  "Which service do you use for log access?"
  Options:
    - label: "Google Cloud Logging", description: "gcloud logging read"
    - label: "AWS CloudWatch", description: "aws logs"
    - label: "Datadog Logs", description: "Datadog Log Management"
    - label: "Not available", description: "No log access available"

Question 2 (header: "Database"):
  "Which tool do you use for database access?"
  Options:
    - label: "PostgreSQL", description: "psql CLI"
    - label: "MySQL", description: "mysql CLI"
    - label: "BigQuery", description: "bq CLI"
    - label: "Not available", description: "No database access available"

Question 3 (header: "Error Tracking"):
  "Which error tracking service do you use?"
  Options:
    - label: "Sentry", description: "Sentry CLI or MCP server"
    - label: "Datadog", description: "Datadog Error Tracking"
    - label: "Not available", description: "No error tracking in use"

If the user selects "Other" for any category, ask for details (tool name, access method).

1-2. Set up dedicated READ-ONLY access — ONE tool at a time

IMPORTANT: Do NOT present all tools at once. Set up one tool, confirm it works, then move to the next.

For each tool the user selected (in order: Logs → Database → Error Tracking):

1. Explain what credentials/setup is needed for this specific tool
2. Ask the user to set up READ-ONLY permissions — NEVER accept or request WRITE permissions
3. Wait for the user to confirm setup is done
4. Test access with a simple read command
5. Confirm success to the user, then move to the next tool

When asking for the first credential, inform the user:

• Credentials are stored only in local memory on this machine (~/.claude/ directory)
• They are never sent to external servers or shared with third parties

After all tools are set up, save all credential details to memory as tse_credential.md.

Knowledge Accumulation

Accumulate project-specific knowledge in memory as investigations progress:

• Common bug patterns
• Architectural notes and gotchas
• Frequently used operations (e.g., how to fetch user info, how to search data by status)
• Useful log filter conditions and DB queries
• Helpful commands and API calls discovered during investigations

Step 2: Extract Inquiry Details

Extract from the inquiry text:

• User identifier: email / user ID / account name
• Timestamp: clarify timezone (ask if unknown)
• Symptom: what was done, what happened (expected vs actual behavior)
• Reproducibility: always occurs, or under specific conditions
• Environment: browser / OS / app version (if mentioned)

If critical information is missing, ask the user. However, start investigating without waiting for all details — some information becomes clear during investigation.

Step 3: Investigate Logs

1. Retrieve logs within 30 minutes before and after the incident time
2. Prioritize error logs (severity=ERROR, CRITICAL)
3. Trace request/processing logs corresponding to the user's action
4. Record stack traces if found

Tips:

• Filter by user identifier when possible
• Trace the full request chain using request ID / trace ID if available
• Check error tracking tools (Sentry, etc.) in parallel

Step 4: Investigate Data

1. Check the user's account/profile data
2. Check data related to the issue (orders, bookings, settings, etc.)
3. If data state deviates from expected, trace when and which process caused the inconsistency

Tips:

• Check created_at/updated_at timestamps and correlate with log timeline
• Verify consistency between related data (foreign keys, status transitions, etc.)

Step 5: Investigate Source Code

Review source code at the locations identified from logs and data.

1. Read the code of the function/endpoint where the error occurred
2. Look for unhandled edge cases, race conditions, type conversion errors, etc.
3. Check recent code changes (git log / git blame) for regressions

Step 6: Generate Report and Response

After investigation, output the following two items. Write both in the user's language.

Internal Investigation Report

## Bug Investigation Report

### Inquiry Summary
- User: <identifier>
- Timestamp: <datetime with timezone>
- Symptom: <description>

### Investigation Results
- Findings from logs: <details>
- Data state: <details>
- Root cause: <explanation>
- Impact scope: <this user only / potentially affects other users>

### Action Plan
- Immediate fix: <details>
- Permanent fix: <details or "requires development">

### Evidence
- <summary of logs, data, and links found during investigation>

Customer Response Draft

• Use polite, professional language
• Explain technical causes in terms the user can understand
• If resolved, confirm completion
• If in progress, communicate expected timeline
• Include an apology at the beginning if appropriate
• Do not include the user's personal information (name, contact details, etc.) in the response

Investigation Tips

• If root cause cannot be identified, report as "under investigation" and specify what additional information or investigation is needed
• If multiple hypotheses exist, list each with its likelihood and how to verify
• Consider whether the behavior might be by design, not a bug
• If clear reproduction steps exist, consider reproducing locally