Tse

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