Agent skill

Repository Analysis

by JocysCom in JocysCom/FocusLogger

Generate or refresh .ai/repository-analysis.instructions.md whenever the user needs a repository-wide map of architecture, projects, technology stack, developer workflows, CI/testing, documentation…

GPL-3.0Auto-check passedDevelopment

Install Repository Analysis

skills CLI
$ npx skills add JocysCom/FocusLogger --skill repository-analysis -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install JocysCom/FocusLogger repository-analysis --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/JocysCom/FocusLogger.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.ai/skills/repository-analysis .claude/skills/repository-analysis && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
repository-analysis
GitHub stars
213
Token cost
~3.1k tokens
SKILL.md length
1,357 words
Files
1
Skills in repo
7
Repo updated
First seen
Licence
GPL-3.0

At a glance

Generate or refresh .ai/repository-analysis.instructions.md whenever the user needs a repository-wide map of architecture, projects, technology stack, developer workflows, CI/testing, documentation…

  • Works in 7 steps: Set up the task → Inventory repository structure → Inspect build and dependency manifests → …
  • Tasks that involve Codebase onboarding
  • SKILL.md covers What this skill is for, Core principles, Required working files and Read these inputs first, plus 8 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Repository Analysis is an agent skill from JocysCom/FocusLogger. Generate or refresh .ai/repository-analysis.instructions.md whenever the user needs a repository-wide map of architecture, projects, technology stack, developer workflows, CI/testing, documentation, or Mermaid diagrams. Use this skill even when the request only names one slice of that work—such as “summarize the repo”, “map dependencies”, “document the stack”, “refresh onboarding context”, or “update architecture notes”—because those tasks usually need the same factual analysis workflow.

Its SKILL.md is about 3.1k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Codebase onboarding. The repository describes itself as: Find out which process or program is taking the window focus. In-game controls could temporary stop responding if other program steals the focus. The licence is GPL-3.0.

When your agent uses it

  • Tasks that involve Codebase onboarding

Example prompts

  • “summarize the repo”
  • “map dependencies”
  • “document the stack”
  • “/repository-analysis”

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Set up the task
  2. Inventory repository structure
  3. Inspect build and dependency manifests
  4. Map runtime architecture and responsibilities
  5. Map developer workflows
  6. Map documentation
  7. Compile and validate the report

What it can do on your machine

Read from SKILL.md and the folder at commit b32c096. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Repository Analysis loads about 3.1k tokens when it runs. Until then it costs about 129 tokens; SKILL.md has 1,357 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~129
When it runs · the whole SKILL.md, loaded when a task matches
~3.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from JocysCom/FocusLogger at commit b32c096, republished under its GPL-3.0 licence (© JocysCom). 1,357 words, ~3,071 tokens.

Download SKILL.mdSave it as .claude/skills/repository-analysis/SKILL.md (or your agent's skills folder).
name
repository-analysis
description
Generate or refresh `.ai/repository-analysis.instructions.md` whenever the user needs a repository-wide map of architecture, projects, technology stack, developer workflows, CI/testing, documentation, or Mermaid diagrams. Use this skill even when the request only names one slice of that work—such as “summarize the repo”, “map dependencies”, “document the stack”, “refresh onboarding context”, or “update architecture notes”—because those tasks usually need the same factual analysis workflow.

Repository analysis

What this skill is for

Use this skill to create or refresh .ai/repository-analysis.instructions.md as a factual repository reference for humans and AI coding agents. The goal is not just to summarize files, but to explain how the repository is organized, what it builds, how it is operated, and which constraints matter when making changes.

When the user asks for only one slice of repository understanding—such as project mapping, dependency analysis, tech stack documentation, CI/test workflow discovery, or architecture diagrams—still use the same repository-wide workflow so the resulting document stays internally consistent.

Core principles

  • Work from repository evidence first: manifests, source files, configuration, scripts, workflow files, and documentation.
  • Keep the output factual and descriptive. Do not turn the analysis into recommendations, refactoring advice, or implementation instructions.
  • Preserve valuable existing content in .ai/repository-analysis.instructions.md unless it is outdated, contradicted by stronger evidence, or replaced with something clearly better.
  • Distinguish between observed facts and concise synthesis. If something is inferred, make the inference cautious and evidence-based.
  • Prefer completeness over novelty. Missing a key project, workflow, or diagram is worse than writing a shorter summary.

Required working files

Before analyzing the repository, create and maintain these temporary files under .tmp/ at the repository root:

Update the TODO file after each major discovery or writing step. Remove all three temporary files only after the refreshed report has been validated successfully.

Read these inputs first

Start every run by reading the highest-value context files that define the repository's purpose and conventions:

  1. .ai/developer-info.md if it exists. Treat developer-provided clarifications as authoritative unless the user explicitly overrides them.
  2. .ai/repository-analysis.instructions.md if it exists, so you can preserve useful sections and structure.
  3. ReadMe.md and Requirements.md.
  4. .ai/instructions.md and any nearby repository-specific instruction files that materially affect developer workflow.
  5. Top-level solution, manifest, and dependency files such as *.sln*, *.csproj, Directory.Build.props, Directory.Packages.props, package.json, requirements.txt, Dockerfile, Containerfile, appsettings*.json, and CI workflow files under .github/workflows/.

Then expand outward from those anchors into the relevant source folders, documentation folders, scripts, and infrastructure manifests.

Discovery workflow

1. Set up the task
  • Create the requirements and TODO files in .tmp/ at the repository root.
  • If .ai/repository-analysis.instructions.md exists, back it up before editing.
  • Convert the user request into explicit analysis tasks. If the user asked for a narrow slice, add the minimum surrounding tasks needed to keep the report coherent.
2. Inventory repository structure
  • Identify every top-level directory and explain its purpose.
  • Detect major source areas, documentation areas, generated-output areas, test areas, and infrastructure/configuration areas.
  • For very large repositories, sample representative file names rather than dumping huge trees.
3. Inspect build and dependency manifests

Always inspect the repo's real manifests rather than inferring from folder names alone.

  • For .NET repositories, inspect every *.csproj and capture AssemblyName, Description, TargetFramework or TargetFrameworks, key PackageReference items, and ProjectReference relationships.
  • Preserve an existing project <Description> verbatim when present. If it is missing or empty, supply a concise factual summary.
  • Resolve MSBuild variables by checking Directory.Build.props, then Directory.Packages.props, then project-local props files, and note the source of resolved values when that context matters.
  • For JavaScript/TypeScript, inspect package.json, lockfiles when relevant, and documented scripts.
  • For Python, inspect requirements.txt, pyproject.toml, setup.py, or equivalent files.
  • For container/infrastructure tooling, inspect Dockerfile, Containerfile, compose/manifests, deployment scripts, and runtime configuration files.
4. Map runtime architecture and responsibilities

Document how the repository is meant to run, not just how it is stored on disk.

  • Identify the main product surfaces, services, libraries, utilities, scripts, and support assets.
  • Describe the primary architectural pattern only when the evidence supports it.
  • Capture configuration patterns, dependency injection approach, runtime boundaries, communication paths, persistence technologies, and external integrations.
  • Explain how infrastructure scripts, manifests, or orchestration layers relate to application code.
5. Map developer workflows
  • Detect build, run, test, packaging, deployment, backup, and restore workflows from scripts, workflow files, manifests, and docs.
  • Detect test projects and test harnesses automatically and explain how they are run.
  • Prefer repository-owned scripts and documented commands over generic guesses.
  • Capture CI/CD systems, validation scripts, and any automation that affects contributor workflows.
6. Map documentation
  • Detect documentation folders regardless of their names or locations.
  • Summarize the role of each documentation cluster and highlight the most important files.
  • Include a documentation taxonomy diagram when the repo has multiple documentation areas or audiences.
7. Compile and validate the report
  • Update or rewrite .ai/repository-analysis.instructions.md.
  • Keep useful existing headings where possible, but do not preserve inaccurate or thin sections just for continuity.
  • Run a diff against the backup and make sure high-value content was not accidentally lost.
  • Verify the TODO file shows all major tasks complete before cleanup.
Show full SKILL.md (569 more words)Show less

Minimum content the report must contain

The finished report in .ai/repository-analysis.instructions.md must cover these areas, even if some sections are brief:

  1. Repository overview — what the repository is for, its major product or platform goals, and the main audiences.
  2. Top-level structure — every top-level directory and its purpose.
  3. Technology stack and versions — languages, frameworks, major packages or libraries, storage technologies, infrastructure tools, and version evidence.
  4. Architecture and runtime model — main layers, services, modules, orchestration, and interaction patterns.
  5. Project inventory — application projects, libraries, tests, scripts, and important non-code assets.
  6. Dependency and data flow — project references, service relationships, integration paths, and notable shared resources.
  7. Developer workflows — build, run, test, CI/CD, setup, deployment, backup/restore, and other repo-owned operational flows.
  8. Documentation map — documentation folders, key documents, and their intended use.
  9. AI-agent-relevant conventions or constraints — coding standards, operational guardrails, or repository rules that materially affect automated edits.

Output structure

Use this structure unless an existing report already has a clearly better equivalent that should be preserved:

markdown
# Repository Analysis

## 1. Repository Overview

## 2. Top-Level Structure

## 3. Technology Stack & Key Dependencies

## 4. Architecture & Runtime Model

## 5. Project Inventory

## 6. Dependency & Data Flow

## 7. Build, Test, CI/CD & Operational Workflows

## 8. Documentation Map

## 9. AI-Agent-Relevant Conventions and Constraints

For each main ## section, begin with 1-2 sentences explaining why the section is useful. Use tables where they improve scanability, especially for project inventories, technology stacks, workflows, and documentation clusters.

Required diagrams

Include Mermaid diagrams that match the repository shape:

  • Architecture layers or component model — required.
  • Project dependency or service interaction graph — required.
  • Documentation taxonomy — required when the repository has more than one documentation area or audience.

Keep diagrams compact, syntactically valid, and evidence-based. Prefer a few readable diagrams over a single giant graph.

Project inventory requirements

When the repository contains multiple code projects or manifests, include structured metadata for each important unit.

  • For *.csproj, capture path, assembly name, framework target, description, and notable dependencies or references.
  • For test projects, explicitly mark them as tests and explain how they are run.
  • For scripts or infrastructure-only components that are central to the repository, describe their role even if they are not traditional application projects.
  • For non-.NET stacks, use the equivalent metadata that best explains the unit: package name, runtime, entrypoint, key dependencies, and purpose.

Constraints and safety rules

  • Never treat generated artifacts or dependency caches as primary evidence.
  • Do not recurse into node_modules, bin, obj, .git, .vs, packages, .nuget, or similarly generated/cache folders unless the user explicitly asks for them.
  • Limit large folder listings to manageable samples. Show real names, not placeholders.
  • If a file is missing, inaccessible, or clearly corrupted, document the gap and continue.
  • If no *.csproj files exist, record that as a repository characteristic rather than a failure.
  • Do not guess version numbers. If a version cannot be verified from inspected files, say so.
  • Do not force .NET-centric structure onto repositories that primarily use another stack. Inspect whatever manifests the repository actually uses.

Final validation checklist

Before finishing, confirm all of the following:

  • The temporary requirements and TODO files were created and kept current.
  • Every important top-level directory has been accounted for.
  • Every relevant project or manifest type discovered in the repo has been analyzed.
  • Technology versions are backed by inspected files.
  • Existing project descriptions were preserved where present.
  • Required Mermaid diagrams are present and readable.
  • Build, test, CI/CD, and operational workflows are documented from repository evidence.
  • Valuable content from the previous report was not lost accidentally.
  • Temporary files in .tmp/ were deleted after successful validation.

Completion behavior

When the report is complete, explicitly confirm that .ai/repository-analysis.instructions.md was refreshed successfully and that the temporary tracking files were cleaned up.

© JocysCom, GPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .ai/skills/repository-analysis of JocysCom/FocusLogger.

Open the folder on GitHubat commit b32c096

Compare with similar skills

Repository Analysis next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Repository Analysis compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Repository Analysis this skillJocysCom/FocusLogger213—~3.1kAutomated safety check: PassGPL-3.0
Codebase Knowledge Graph Q&AEgonex-AI/Understand-Anything86k1 repos~1.2kAutomated safety check: PassMIT
Understand ExplainEgonex-AI/Understand-Anything86k1 repos~1.3kAutomated safety check: PassMIT
Repomix Codebase Exploreryamadashy/repomix29k1 repos~2.7kAutomated safety check: PassMIT
Code Graph Mermaid Diagramstrailofbits/skills7.4k1 repos~1.7kAutomated safety check: PassCC-BY-SA-4.0
Project Onboarding Guide from Knowledge GraphEgonex-AI/Understand-Anything86k—~1.2kAutomated safety check: PassMIT

Similar skills

  • Codebase Knowledge Graph Q&A

    Egonex-AI/Understand-Anything

    Answers questions about a codebase by searching a prebuilt knowledge graph of its files, functions, classes and dependencies, not by rereading every source file.

    86k GitHub starsUsed in 1 repo~1.2k tokens
    DevelopmentAuto-check passed
  • Understand Explain

    Egonex-AI/Understand-Anything

    Gives an in-depth explanation of one file, function or module by reading the project's knowledge graph and checking that the graph is still fresh.

    86k GitHub starsUsed in 1 repo~1.3k tokens
    DevelopmentAuto-check passed
  • Repomix Codebase Explorer

    yamadashy/repomix

    Packs a local or remote repository into a single AI-friendly file with the Repomix CLI, then reads and searches that output to explain structure, find patterns or report metrics.

    29k GitHub starsUsed in 1 repo~2.7k tokens
    DevelopmentAuto-check passed
  • Code Graph Mermaid Diagrams

    trailofbits/skills

    Official

    Generates Mermaid diagrams from Trailmark code graphs, including call graphs, class hierarchies, module dependency maps, complexity heatmaps and attack surface data flows.

    7.4k GitHub starsUsed in 1 repo~1.7k tokens
    DevelopmentAuto-check passed
  • Writes an onboarding guide for new team members from a project's existing knowledge graph, after checking that the graph still matches the current commit.

    86k GitHub stars~1.2k tokensUpdated 2 days ago
    DevelopmentAuto-check passed
  • GitDiagram Repository Overview

    ahmedkhaleel2004/gitdiagram

    Explains the architecture of a public GitHub repository through GitDiagram: how the code is organized, the main components with paths, and a Mermaid diagram.

    18k GitHub stars~427 tokensUpdated today
    DevelopmentAuto-check passed

More from JocysCom/FocusLogger

  • AI Self Improvement

    JocysCom/FocusLogger

    Update, create, improve, and synchronise this repository's AI agent instructions and related assets (including skills).

    213 GitHub stars~1.1k tokensUpdated 3 mo ago
    Auto-check passed
  • QA Tester

    JocysCom/FocusLogger

    Create and maintain automated tests in Microsoft-native/.NET projects with a minimal stack — MSTest runner, System.Windows.Automation for Windows desktop, Playwright for real browser smoke.

    213 GitHub stars~12k tokensUpdated 3 mo ago
    Auto-check passed
  • Solution Patterns

    JocysCom/FocusLogger

    Establish and enforce deterministic path patterns across Code ↔ UI route/menu ↔ Test for any project.

    213 GitHub stars~8k tokensUpdated 3 mo ago
    Auto-check passed
  • Mermaid Rasterize

    JocysCom/FocusLogger

    Rasterize specific mermaid blocks inside a markdown file into PNG images.

    213 GitHub stars~835 tokensUpdated 3 mo ago
    Auto-check passed
  • Repo Documentation Gatherer

    JocysCom/FocusLogger

    Gather, improve, and curate repository documentation and wiki content.

    213 GitHub stars~1.2k tokensUpdated 3 mo ago
    Auto-check passed
  • PR Review

    JocysCom/FocusLogger

    AI-assisted pull request review workflow for Azure DevOps Git repositories.

    213 GitHub stars~12k tokensUpdated 3 mo ago
    Auto-check: warnings

Categories

Questions about Repository Analysis

What does Repository Analysis do?

Generate or refresh .ai/repository-analysis.instructions.md whenever the user needs a repository-wide map of architecture, projects, technology stack, developer workflows, CI/testing, documentation…. Repository Analysis is an agent skill from JocysCom/FocusLogger.md whenever the user needs a repository-wide map of architecture, projects, technology stack, developer workflows, CI/testing, documentation, or Mermaid diagrams.

When should I use Repository Analysis?

Repository Analysis fits situations like: tasks that involve Codebase onboarding.

How do I install Repository Analysis in Claude Code?

Run `npx skills add JocysCom/FocusLogger --skill repository-analysis -a claude-code`. Or copy the skill folder (.ai/skills/repository-analysis in JocysCom/FocusLogger) into .claude/skills/repository-analysis in your project. Claude Code loads it when a task matches its description.

How do I install Repository Analysis in Codex?

Run `npx skills add JocysCom/FocusLogger --skill repository-analysis -a codex`. Or copy the skill folder (.ai/skills/repository-analysis in JocysCom/FocusLogger) into .agents/skills/repository-analysis in your project. Codex loads it when a task matches its description.

Can I use Repository Analysis in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add JocysCom/FocusLogger --skill repository-analysis -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/repository-analysis, .gemini/skills/repository-analysis, .github/skills/repository-analysis and .opencode/skills/repository-analysis in your project.

What does Repository Analysis need to run?

SKILL.md names no scripts, command-line tools or credentials: Repository Analysis is instructions for the agent only.

Does Repository Analysis access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Repository Analysis safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Repository Analysis use?

Repository Analysis is published under the GPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Repository Analysis use?

About 3.1k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Repository Analysis?

Skills that share tags, products or a category with Repository Analysis: Codebase Knowledge Graph Q&A (Egonex-AI/Understand-Anything, 86k stars), Understand Explain (Egonex-AI/Understand-Anything, 86k stars), Repomix Codebase Explorer (yamadashy/repomix, 29k stars) and Code Graph Mermaid Diagrams (trailofbits/skills, 7.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Repository Analysis?

JocysCom (a GitHub organization) maintains it in JocysCom/FocusLogger, which has 213 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on June 30, 2026.

Source: JocysCom/FocusLogger on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.