SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsanalyze-github

analyze-github

Coding & development

View repository

Updated 10-15 23:42

About this skill

Analyze GitHub — Project Workflow Analysis and Implementation Blueprint Generation

Input a GitHub repository URL or local directory path, automatically detect the tech stack and architecture patterns, and output end-to-end workflow documentation and an implementation blueprint.

Step -2: Parse the input (must be executed first)

Determine which case the user input belongs to, and handle it according to the corresponding branch:

Branch A: A GitHub URL is already available

The input contains https://github.com/ → directly record it as REPO_URL, and skip to Step -1.

Branch B: A local directory path is already available

The input is a path starting with / or ~/ , or the user explicitly says "local directory" → record it as PROJECT_DIR, and skip to Step -1.

Branch C: Only keywords (no URL, no path)

When the user provides only a project name, description, or keywords, perform the following steps to find the GitHub URL:

  1. Construct a search query: combine the keywords into a site:github.com <keywords> search string.
  2. Execute WebSearch: search and read the first few results.
  3. Extract candidate URLs: filter out links in the https://github.com/<owner>/<repo> format from the search results (excluding issues/pulls/blob subpaths), and compile 1-3 of the most relevant candidates.
  4. Confirm：
    • If there is only 1 high-confidence candidate, use it directly and inform the user: "Found repository <URL>, starting analysis."
    • If there are multiple candidates, list them for the user to choose from, and wait for confirmation before continuing.
    • If no candidates are found, inform the user and request more specific keywords or ask them to paste the URL directly,stop executing subsequent steps。
  5. After confirmation, record the selected URL as REPO_URL, and continue to Step -1.

Step -1: Determine the output filename (must be executed first)

1. Extract the project name: take the last segment from the URL or path as PROJECT_NAME(e.g., https://github.com/Foo/hermes-agent → hermes-agent）。

2. Use Bash to get the current timestamp (accurate to the minute):

date +"%Y-%m-%d-%H%M"

3. Determine the output path:

OUTPUT_FILE={当前工作目录}/{PROJECT_NAME}-workflow-analysis-{yyyy-mm-dd-HHmm}.md

Example:hermes-agent-workflow-analysis-2026-04-16-1430.md

The timestamp is accurate to the minute, naturally avoiding conflicts, with no need for a version number suffix.

Record the determined path as OUTPUT_FILE, and use it directly in subsequent Steps.

⚠️ Prohibited:

  • Do not skip the analysis on the grounds that "the existing analysis is sufficient"
  • Before writing, use Glob to confirm once more that the OUTPUT_FILE path does not exist, and only call Write after confirmation

Step 0: Obtain the project source code

If the input is a GitHub URL (starting with https://github.com/ ):

REPO_URL="<用户输入的URL>"
REPO_NAME=$(basename "$REPO_URL" .git)
TARGET_DIR="$HOME/temp/$REPO_NAME"

if [ -d "$TARGET_DIR" ]; then
  echo "Already cloned: $TARGET_DIR"
else
  mkdir -p "$HOME/temp"
  gh repo clone "$REPO_URL" "$TARGET_DIR" -- --depth=1 2>/dev/null || \
  git clone --depth=1 "$REPO_URL" "$TARGET_DIR"
fi
echo "Project dir: $TARGET_DIR"

If the input is a local directory path: directly use that path as PROJECT_DIR, and skip the clone step.

Step 1: Automatic detection phase

Scan the project structure, identify the following information, and record it in the analysis context:

Tech stack detection

  • Look for .csproj/.sln → .NET
  • Look for pom.xml/build.gradle + @SpringBootApplication → Java/Spring
  • Look for package.json + React/Next.js → Node.js/React
  • Look for go.mod → Go
  • Look for requirements.txt/pyproject.toml → Python
  • Look for Cargo.toml → Rust

Architecture pattern detection

  • Directory contains controllers/+services/+repositories/ → Layered
  • Directory contains Commands/+Queries/+Handlers/ → CQRS
  • Directory contains domain/+application/+infrastructure/ → Clean Architecture
  • docker-compose.yml contains multiple services → Microservices
  • Directory contains resolvers/+schema/ → GraphQL

Entry point detection

  • API Controller / Router files
  • GraphQL Resolver file
  • Where frontend components initiate network requests
  • Message Handler / Event Subscriber
  • Scheduled Job definition

Persistence layer detection

  • ORM configuration files (DbContext, JPA Entity, GORM Model, etc.)
  • Repository implementation
  • Database connection configuration
  • External API client

Community signal scan (quick)

Scan the following information sources to supplement context not visible at the code layer:

  • Issues (Top 10 by upvotes): Reflects users' core pain points and unmet needs
  • Discussions: Community controversies or questions about the design direction
  • Release Notes (last 3 versions): What practical problems were solved
  • README's "Compared to" / "Why not X": The author's self-stated positioning

If GitHub Issues/Discussions are inaccessible, skip this section.

Step 1.5: Architecture layer diagram (must output)

Before proceeding to workflow documentation, based on the detection results from Step 1, use an ASCII block diagram to drawthe call relationships and data flow between architecture layers。

Format requirements:

  • Enclose each layer with ┌─┐ │ └─┘ , labeling the layer name and the layer's core classes/modules
  • Between layers use │ and ▼ to indicate call direction
  • Label the data type or object name passed beside the arrow (e.g., MemorizeRequest、SearchRequest）

Example format:

┌─────────────────────────────────────────────┐
│         HTTP API Layer                      │
│  XxxController                              │
└──────────────────┬──────────────────────────┘
                   │ RequestDTO
┌──────────────────▼──────────────────────────┐
│         Service Layer                       │
│  XxxService                                 │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│         Repository / Data Access Layer      │
│  XxxRepository                              │
└─────────────────────────────────────────────┘

Adjust the number of layers and layer names according to the actual architecture (e.g., Agentic/Business/Memory/Infrastructure, etc.).

Step 1.7: Key design decision analysis

For the project's 3-5 most important architecture/technology choices, output the motivation behind each decision one by one.

Identification method(prioritize the following types):

  • Non-mainstream choices: using SQLite instead of PostgreSQL, using Markdown files instead of a database to store configuration
  • In-house vs. mature libraries: why implement X yourself instead of using library Y
  • Architecture pattern choices: strategy pattern vs. hardcoded if/else, plugin system vs. static registration
  • Storage format: JSON vs. YAML vs. database
  • Concurrency model: event loop vs. multithreading vs. goroutine

Output format for each decision:

Field Content
Question Why use X instead of Y?
Conclusion A short chosen answer (1 sentence)
Reason 2-3 sentences: performance, cost, maintainability, compatibility, migration path, etc.
Trade-off What was sacrificed for this (flexibility? ecosystem? maintainability? migration cost?)

Step 2: Workflow documentation

Select 1-3 most representative end-to-end workflows(CRUD operations, core business processes), and output the following for each workflow:

2.1 Workflow overview

  • Name and business purpose description
  • Triggering action or event
  • List of all files/classes involved

2.2 Entry point implementation

Output according to the detected entry type:

API entry:

  • Controller classes and methods that receive requests (including full signatures, annotations/attributes)
  • Request DTO/Model class definitions
  • Validation attributes and custom validators
  • Authentication/authorization attributes and checks

GraphQL entry points:

  • Resolver classes and methods
  • Schema definitions (Query/Mutation)
  • Input type definitions

Frontend entry points:

  • Components and event handlers that initiate API calls
  • API client Service methods
  • State management-related code

Message consumer entry points:

  • Message Handler classes and methods
  • Message subscription configuration
  • Message model definitions and deserialization logic

2.3 Service layer implementation

  • Each Service class and its dependencies
  • Complete method signatures (including parameters and return types)
  • Actual implementation of key business logic
  • Interface definitions (if any)
  • Dependency injection registration approach

For CQRS pattern, include: complete Command/Query Handler implementation For Clean architecture, include: Use Case/Interactor implementation

2.4 Data mapping

  • DTO → Domain Model mapping code
  • Object Mapper configuration or manual mapping methods
  • Validation logic during the mapping process
  • Domain Events triggered during mapping (if any)

2.5 Data access implementation

  • Repository interfaces and their implementations
  • Complete query implementations (including ORM statements or native SQL)
  • Entity/Model class definitions (including all properties)
  • Transaction handling approach

For SQL databases, include: ORM configuration, Fluent API, actual SQL For NoSQL, include: document structure definitions, query/update operations

2.6 Response construction

  • Response DTO/Model class definitions
  • Domain/Entity → Response mapping
  • HTTP status code selection logic
  • Error response structure and generation approach

2.7 Error handling

  • Exception types used in the workflow
  • try/catch patterns at each layer
  • Global exception handler configuration
  • Error logging implementation
  • Retry strategy or circuit breaker pattern
  • Failure compensation operations

2.8 Asynchronous processing (if any)

  • Background task scheduling code
  • Event publishing implementation
  • Message queue sending patterns
  • Asynchronous operation tracking and monitoring

Step 3: Technology Stack-Specific Patterns

Output the corresponding specific patterns based on the detection results:

.NET： Controller attributes and filters, Startup/Program.cs registration, EF Core DbContext configuration, AutoMapper Profile, middleware implementation, Options pattern, ILogger logging

Spring： Controller annotations and dependency injection, Service transaction boundaries, JPA Entity and relationship mapping, DTO implementation, Bean configuration, ExceptionHandler, custom validators

React/Node.js： Component structure (Props/State), Hook implementation patterns, API Service implementation, state management (Context/Redux), form handling, routing configuration

Go： Handler functions and middleware, Repository interfaces, GORM/sqlx queries, error wrapping conventions, goroutine usage patterns

Step 4: Implementation Blueprint Output

4.1 Implementation Templates

Provide reusable code templates:

  • Complete skeleton for creating a new API Endpoint
  • Structure for creating a new Service method
  • Structure for creating a new Repository method
  • Creating a new Domain Model class
  • Correct error handling implementation

4.2 Naming Convention Documentation

Document consistent naming conventions:

  • Controller naming (e.g. EntityNameController）
  • Service naming (e.g. EntityNameService）
  • Repository naming (e.g. IEntityNameRepository）
  • DTO naming (e.g. EntityNameRequest/EntityNameResponse）
  • CRUD method naming patterns
  • Variable naming conventions
  • File organization patterns

4.3 Implementation Guidelines

  • Where to start: the starting point for adding similar functionality
  • Implementation order: model → repository → service → controller (adjust according to the actual stack)
  • Integrating cross-cutting concerns: how to hook in logging, authentication, caching, etc.
  • Common pitfalls: error-prone areas, performance considerations, common bugs

4.4 Extension Mechanisms

  • How to hook into existing extension points
  • How to add new behavior without modifying existing code
  • Configuration-driven feature patterns

Step 4.5: Application Scenario Assessment

From the perspective of "after learning this project, what can I do", output three tiers of application scenarios:

Tier A — Direct Use

2-3 real problems that this project can solveout of the box, each including:

  • Scenario: who encounters what problem under what circumstances
  • Usage: which API / CLI / module to call directly

Tier B — Combined Use

1-2non-obvious combinations: combining this project with other tools to produce capabilities that are not available when used alone:

  • Combined with: which tool/framework to combine with
  • New capability produced: what can be done after combining that could not be done before

Tier C — Borrowed Patterns

1-2 design ideas that can beported across projects(without depending on this library, only borrowing the idea):

  • Pattern name: a short name for this design idea
  • How to migrate: how to reproduce this idea in other languages/scenarios

Step 5: Market Positioning and Competitive Perspective (specific to tool/product-type projects)

Determine whether to execute this step:

  • ✅ Execute: the project is a user-facing CLI tool, Agent framework, development platform, or SaaS SDK
  • ❌ Skip: the project is a pure library (utility library), language binding, dataset, or Demo

Output content:

5.1 Core Value Proposition

Describe in one sentence: what unique problem does this project solve? After users adopt it, what previously impossible thing can now be done?

5.2 Before vs. After

Without this project With this project
Pain point 1 Solution
Pain point 2 Solution
Pain Point 3 Solution

5.3 Comparison with Similar Projects

List 2-4 of the closest competitors/alternatives:

Project Similarities Core Differences Applicable Scenarios
Competitor A ... ... ...
Competitor B ... ... ...

Methods for identifying competitors: The "compared to" section in the README, projects with the same tags in GitHub Topics, migration sources mentioned in the documentation ("migrating from X")

5.4 Core Differentiation Factors

The 1-2 most unique core capabilities of this project compared with competitors (not a feature list, but what it truly achieves that competitors do not).

Output Format

Save the analysis results as a Markdown file:

  • File name:{项目名}-workflow-analysis-{yyyy-mm-dd-HHmm}.md(time accurate to the minute, determined by the OUTPUT_FILE from Step -1)
  • Save location: current working directory (or a user-specified path)

Document structure:

  1. Project overview (tech stack, architecture pattern, entry point type, directory structure tree)
  2. Architecture hierarchy diagram (ASCII block diagram from Step 1.5)
  3. Key design decisions (Step 1.7, "why X instead of Y", including cost analysis)
  4. Detailed documentation for each workflow (all subsections of Step 2)
  5. Tech stack specialized patterns (Step 3)
  6. Implementation blueprint (Step 4)
  7. Three-layer framework for application scenarios (Step 4.5: direct use / combined use / pattern borrowing)
  8. Common pitfalls
  9. Transferable mental models: after reading this project, which 3-5 design principles usable across projects can you take away (not a summary of conventions internal to the project, but transferable insights)
  10. Market positioning and competitor perspective (Step 5, only for tool/product-type projects)

For the output path, use the OUTPUT_FILEdetermined in Step -1, Glob again before writing to confirm the path is empty, then call the Write tool.

Each output must be a complete standalone document (writing only increments is prohibited): Even if an old file with the same name exists, the new file must cover all sections, and existing sections must not be omitted on the grounds of "incremental supplementation based on vN". If version differences need to be compared, a "Main Changes from the Previous Version" subsection may be added at the end of the document, but all preceding sections must be complete.