ANALYSIS, MADE CLEAR.AnalyzeAPI.com
Documentation ↗

GIT REPO ANALYZE API

Meet the codebase.
Find your bearings.

Make a repository easier to understand with a read-only review of its structure, documentation, entry points, and test organization.

Explore this sampleRead the guide

WHAT GOES IN

The right input.
The right question.

An authorized repository snapshot or file manifest pinned to a known revision.

KEEP THE SCOPE CLEARA file inventory is not a security audit. The presence of tests does not establish test coverage or passing status.

WHAT COMES OUT

A report you can use.

  • File-role and component inventories
  • Documentation and onboarding findings
  • Traceable paths, revisions, and open questions

Keep the evidence, interpretation, and next action separate. Document missing inputs instead of filling them with guessed values.

A PRACTICAL WORKFLOW

Make the first contribution easier

Map the setup instructions to the actual files, identify application entry points, and record missing explanations. Distinguish observed test files from tests that were actually run.

Explore integration patterns

LOOK INSIDE THE OUTPUT

Evidence, not a mystery score.

An illustrative report for this workflow. Download the JSON to inspect the complete structure.

THE ANALYSIS PLAYGROUND
Interactive sample

Illustrative file manifest

Sample project snapshot

An inventory for orientation, not a code-quality verdict.

✓
An entry point is documented

README.md identifies src/main.js as the entry point.

!
Setup instructions are incomplete

The sample README omits the configuration step.

·
Test files are visible

The sample manifest contains tests/main.test.js.

report.json
{
  "schema_version": "1.0",
  "report_id": "sample-git-repo-analysis",
  "sample": true,
  "analysis_type": "git-repo-analysis",
  "status": "complete",
  "target": {
    "label": "Sample project snapshot",
    "input_kind": "Illustrative file manifest"
  },
  "summary": "An inventory for orientation, not a code-quality verdict.",
  "findings": [
    {
      "id": "f01",
      "outcome": "pass",
      "title": "An entry point is documented",
      "evidence": "README.md identifies src/main.js as the entry point.",
      "action": "Verify the path at the reviewed revision."
    },
    {
      "id": "f02",
      "outcome": "review",
      "title": "Setup instructions are incomplete",
      "evidence": "The sample README omits the configuration step.",
      "action": "Document the required configuration."
    },
    {
      "id": "f03",
      "outcome": "note",
      "title": "Test files are visible",
      "evidence": "The sample manifest contains tests/main.test.js.",
      "action": "Run tests separately in an approved environment."
    }
  ],
  "not_measured": [
    "Executed test results",
    "Coverage percentage",
    "Security assessment"
  ]
}
Illustrative data. No live analysis or uploads.Download JSON Explore workflow

TAKE IT FURTHER

A little context goes a long way.

Review repository structure, setup instructions, and test organization with clear scope and revision-level evidence.

Read the full guide

Before you connect a real source

Confirm that you are authorized to use the input. Preserve its collection context and version, agree on an acceptance rule, and decide how incomplete results should be reviewed.

  • Validate the report before consuming it.
  • Keep secrets out of public browser code.
  • Show what was—and was not—measured.

Make your next move
a clearer one.

Explore the workflows. Inspect the evidence. Build something useful.

Explore the toolkitRead the docs