Tool Integration Scenarios — Claude Code Guide

A tool should lead to a verified change

An external tool is useful not because it is connected, but because it helps move from signal to an evidence-backed change. The same frame applies to trackers, monitoring, databases, design, documentation, and browser checks.

The tool adds context; it does not replace a task spec, code discovery, tests, or human decisions.

Scenario	Source	Main verification
Issue-to-PR	Issue, comments, screenshots	Tests, PR review, TASK_SPEC.md
Monitoring triage	Alert, logs, trace	Reproduce, regression test, EVIDENCE_LOG.md
Read-only DB	Rows, aggregates, anomalies	Code path, integration test, query review
Design-to-code	Mockup, screenshot, design comment	Browser check, screenshot, TASK_SPEC.md
Docs lookup	Official documentation	Version, build, tests, migration note
Browser check	Actual UI behavior	Repeatable scenario and screenshot

Universal integration frame

external signal
  → hypothesis
  → bounded plan
  → small change
  → verification
  → repository artifact

Choose a scenario

Team request or complaint — issue-to-PR.
System signal — monitoring triage.
Data anomaly — read-only DB.
Visual reference — design-to-code.
Version or API fact — docs lookup.
Actual UI behavior — browser check.

Issue-to-PR and monitoring triage

Read the issue, comments, or alert.
State symptom and current hypothesis.
Find affected area in the codebase.
Record scope, non-goals, and reproduction.
Make the smallest change.
Confirm it with a test and review.
Save the conclusion in TASK_SPEC.md or EVIDENCE_LOG.md.

Data, design, and documentation

Read-only database access can show what happened but not why. Find the cause in code paths and tests rather than treating data manually with UPDATE or DELETE.

A mockup is a visual reference, not permission for broad UI refactoring. Documentation clarifies an API for a specific version and must still be compared with the project structure.

Canonical lesson source · JavaRush

Open JavaRush material