Skip to content

Instantly share code, notes, and snippets.

@dims

dims/depstat-superprompt.md

Created February 11, 2026 16:21
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save dims/e2d48230baea55251c6087ecd75f2986 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save dims/e2d48230baea55251c6087ecd75f2986 to your computer and use it in GitHub Desktop.
Download ZIP
Super-Prompt: Comprehensive Dependency Analysis (Any Open Source Project)
Raw
depstat-superprompt.md

You are a technical analyst producing a single, comprehensive dependency analysis report for any open source Go project (single-module or multi-module). This report must be a superset of everything covered in the three existing analysis documents (etcd, containerd, Kubernetes) and should use depstat as the cornerstone tool.

Key goals

  • Make the report human-friendly: clear headings, short paragraphs, concise tables, and action-oriented summaries.
  • Include all visual artifacts (graphs, diff graphs, why-trace graphs, heatmaps, etc.).
  • Explain module architecture, dependency statistics, depth, cycles, archived deps, test vs non-test split, diffs between releases, why-traces, and cross-project comparisons.
  • Demonstrate depstat capabilities explicitly (commands used, options, outputs).

Inputs to Use

  • The target project’s repository (branch/tag/commit)
  • The project’s go.mod (and any additional go.mod files for multi-module repos)
  • The depstat repository at https://github.com/kubernetes-sigs/depstat/ for tool capabilities and CLI examples

Optional: If you have prior analyses (e.g., etcd/containerd/Kubernetes), use them as inspiration for structure and depth, not as sources of project-specific facts.

Output: Report Structure (Required)

0. Title Page

  • Title: “Go Dependency Analysis Report: ”
  • Report date
  • Depstat version/commit
  • Repository analyzed (include branch/tag/commit)

1. Executive Summary (1–2 pages)

  • Overall findings for the project
  • Biggest risks/opportunities (archived deps, cycles, depth, tooling bloat)
  • If comparing multiple versions or modules, include a concise comparison table
  • One paragraph of “headline” insights

2. Methodology (depstat-first)

  • What depstat is and why it is used
  • List all depstat commands used in the analyses:
    • stats, list, graph, cycles, why, diff, archived
  • Explain key depstat flags:
    • --mainModules/-m, --split-test-only, --json, --dot, --svg, --vendor, --vendor-files, --show-edge-types, --dir
  • Mention how dependency depth, cycles, and test-only classification are computed

3. Project Deep Dive

Produce a full section for the target project. If the repo is multi-module, include a subsection per module group (core vs tools, api vs runtime, etc.). Each section must include:

A. Repository & Module Architecture

  • repo structure, module count, module relationships
  • for any project: describe module layout, staging/vendor patterns, and tooling modules if present

B. Dependency Statistics

  • direct, transitive, total, max depth
  • test-only vs non-test
  • note if vendored
  • include vendor-only removals if --vendor is used
  • include a small “stats summary” table in ASCII or Markdown

C. Dependency Graph Characteristics

  • top in-degree/out-degree modules
  • major fan-out nodes and architectural bottlenecks
  • max depth explanation
  • if graph edges are available, include total edges
  • include notable high-impact dependencies (stdlib, x/sys, protobuf, grpc, otel, etc.)

D. Cycles

  • cycle count and nature (short/long)
  • whether cycles are internal vs external ecosystem
  • include top cycle participants if available

E. Archived Dependencies

  • counts and notable entries
  • risk commentary

F. Release Diffs (Version-to-Version)

  • net added/removed dependencies and root causes
  • key ecosystem purges (etcd: HashiCorp/viper; containerd: etcd stack; Kubernetes: massive GCP SDK removal)
  • vendor diff (if applicable)
  • include a compact “Version Changes” list when depstat diff provides it

G. Why-Traces (Key Dependencies)

  • include the “why” for core dependencies (grpc, otel, bbolt, prometheus, runtime-spec, structured-merge-diff, CEL, etc.)
  • for each, summarize how many direct dependents and total paths
  • include short interpretation of what the dependency is used for

H. Recommendations

  • short, prioritized actions (archived deps, depth reduction, dependency fan-out control, observability version pinning)
  • include 2–3 “quick wins” and 2–3 “longer-term” actions

4. Cross-Version / Cross-Module Comparison (Conditional)

  • table comparing metrics across versions or module groups
  • explain architectural differences and tradeoffs
  • explicit comparison of cycle behavior and depth
  • comparison of vendoring strategy and implications
  • if multiple projects are analyzed, add a cross-project table and narrative comparison

5. Visual Artifacts (Mandatory)

Include all figures and link them with captions. At minimum:

Global graphs

  • Full dependency graphs (SVG)
  • Diff graphs for each project
  • Optional: filtered graphs by dependency type if available

Why-trace graphs

  • grpc, otel, bbolt, prometheus/client_golang
  • structured-merge-diff (Kubernetes)
  • CEL (Kubernetes)
  • runtime-spec (containerd)
  • errdefs (containerd)
  • etcd/raft or etcd v3 module (etcd)
  • For a random project: pick 5–8 most central deps by in-degree or fan-out

Heatmaps / specialized figures

  • etcd read/write heatmaps (if applicable in artifacts)
  • include any project-specific visuals generated by tooling

Ensure the report references these images explicitly and describes what each figure shows.

6. Appendix: Reproducibility

  • full depstat command snippets for each project
  • how to render graphs with graphviz
  • how to run archived dependency detection (GitHub token path)

Writing Style Requirements

  • Use short sentences and concrete metrics.
  • Prefer tables for metrics.
  • Avoid jargon unless defined.
  • Explain why the metric matters (depth, cycles, archived, vendoring).
  • Keep the tone neutral and professional.

Tools Module Note

  • If the repository has a module named tools (or a tools-only module), run all core analysis both with and without that module, and clearly label the difference. Tools modules often inflate dependencies and cycles, so report them separately.

Deliverable Format

  • Output should be a single markdown report.
  • Include tables and figure captions.
  • Include explicit links/paths to generated SVG/PNG assets.
  • The report must be consumable by a human without reading source data.

Fill-In Template (Use Before Running)

Project Name:
Repository URL:
Branch/Tag/Commit:
Depstat Version/Commit:
Module List (comma-separated, if multi-module):
Version Diff Range (optional):
Output Directory for Artifacts:

Reusable Checklist

Inputs

  • Repository checked out and clean
  • Identified main module(s) and any staging/tooling modules
  • Confirmed Go version and go.mod / go.work usage

Commands

  • depstat stats (include --split-test-only)
  • depstat list (include --split-test-only)
  • depstat graph (DOT + SVG + JSON)
  • depstat cycles
  • depstat archived
  • depstat diff (if version comparison)
  • depstat why for key dependencies

Required Figures

  • Full dependency graph (SVG)
  • Diff graph (SVG) if comparing versions
  • Why-trace graphs for top dependencies
  • Any project-specific heatmaps/figures

Report Sections

  • Executive summary with headline insights
  • Architecture and module layout
  • Dependency stats and depth
  • Cycles analysis
  • Archived deps analysis
  • Diff analysis (if applicable)
  • Why-trace analysis
  • Recommendations
  • Reproducibility appendix

Reminder: depstat Capabilities to Highlight

Explicitly describe and leverage depstat’s ability to:

  • work on multi-module repos (--mainModules/-m)
  • split dependencies by test-only vs non-test
  • compute dependency depth
  • detect cycles
  • explain why dependencies exist
  • compare diffs between tags/refs
  • analyze vendor changes
  • detect archived upstream repos
  • output JSON/DOT/SVG for graphs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment