Skip to content
Back to skills

Tracing Across Services

ASecurity

Use when you need to understand how a request, endpoint, or feature flows across multiple Spring Boot service repos and shared libraries - produces an ordered call chain with file:line citations, following inter-service proxy-lib calls.

  • 2 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added September 7, 2026
developmentgospring

Works with

  • cli

Security analysis

A100/100

Scanned September 29, 2026

npx -y skills add talayash/spring-fleet --skill tracing-across-services --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Tracing Across Services?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Tracing Across Services
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/talayash-tracing-across-services/badge)](https://www.skillsdirectory.com/skills/talayash-tracing-across-services)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: tracing-across-services
description: Use when you need to understand how a request, endpoint, or feature flows across multiple Spring Boot service repos and shared libraries - produces an ordered call chain with file:line citations, following inter-service proxy-lib calls.
---

# Tracing a Flow Across a Service Fleet

A single feature often crosses several repos: an entry controller calls
downstream services (usually through a generated proxy/client library), each of
which leans on shared libraries. This skill reconstructs that chain.

## Prerequisites

- A `spring-fleet.config.json` exists (else run `/fleet-init`). It provides the
  `reposRoot`, services, `sharedLibs`, `proxyLib`, and `topology`.

## Procedure

1. **Identify the target.** An endpoint (`POST /order-v1/reserve`), a controller,
   or a feature name. If ambiguous, locate candidate entry points first and
   confirm with the user.

2. **Dispatch the `fleet-explorer` agent** with the config path and the target.
   It knows the flow spans many repos, follows `proxyLib` client calls across
   service boundaries using `topology.edges`, and returns an ordered call chain
   with `file:line` citations and the shared-lib code each hop touches.

3. **Read the chain critically.** Confirm each hop's downstream target matches
   the topology. Where a hop is dynamic (reflection, event bus, conditional
   routing), the explorer marks it; resolve it by reading the dispatch site
   rather than guessing.

4. **Present the result.** Give the ordered chain entry → … → leaf, each step
   cited, plus a short summary of which services and shared-lib modules
   participate. Highlight the hops most relevant to the user's goal (e.g. where a
   change must be made, or where a failure could originate).

## Tips

- The `proxyLib` is the seam between services; grep it for the client class to
  find who calls whom when the topology is unclear.
- Contract changes ripple through the `proxyLib`: if a hop's request/response
  shape changes, the generated client (and every caller) is affected.
- For "what breaks if I change this shared-lib code?", trace consumers outward
  from the shared module instead of inward from an endpoint.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.