analyze-changes

Analyze git changes (branch, commit, or current branch) and produce a design-oriented markup document with Mermaid diagrams, query/usage examples, data walkthroughs, PR context, and impact assessment.

Ir a la instalación

Repositorio: JetBrains/youtrackdb
Última actividad en el origen: 6 de mayo de 2026 a las 11:02
Idioma detectado de SKILL.md: inglés
Estrellas: 433
Forks: 16

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Un comando directo omite el prompt de revisión. Revisa el origen antes de ejecutarlo.

npx skills add https://github.com/JetBrains/youtrackdb --skill analyze-changes

El comando permanece en una sola línea. Desplázate horizontalmente para revisarlo antes de copiarlo.

¿Prefieres una copia local? Descarga los archivos que SkillsMP tiene disponibles ahora.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

SKILL.md

Instrucciones de origen · Vista previa de solo lectura

Volver a la búsqueda Volver a la instalación

name	analyze-changes
description	Analyze git changes (branch, commit, or current branch) and produce a design-oriented markup document with Mermaid diagrams, query/usage examples, data walkthroughs, PR context, and impact assessment.
argument-hint	[branch-name \| commit-sha]
user-invocable	true

Analyze the git changes specified by the argument and produce a design-oriented analysis document.

Input

The argument $ARGUMENTS is either:

Empty / not provided — analyze the current branch compared to develop
A commit SHA (short or full) — analyze that single commit
A branch name — analyze all commits on that branch relative to develop

Steps

1. Determine the input type and gather changes

If $ARGUMENTS is empty or blank, get the current branch name:

git rev-parse --abbrev-ref HEAD

Then treat it as a branch name (see branch handling below).

Otherwise, run these git commands to figure out what was provided:

git cat-file -t "$ARGUMENTS" 2>/dev/null
git branch --list ""

# Change Analysis: <short description> **Ref**: `<SHA or branch name>` **PR**: [#<number> <title>](<url>) *(if PR exists, omit section if no PR)* **Date**: <commit date(s)> **Author**: <author(s)> ## Summary <2-5 sentence high-level summary of what these changes accomplish and why.> ## Design <Start with the shared concepts that apply across all changes: the overall algorithm/approach, common data structures, shared invariants, configuration. Then break into per-feature/per-algorithm subsections.> ### <Shared concept: e.g., overall algorithm, detection pipeline> <Explain the top-level algorithm or decision flow that ties the changes together. Include a Mermaid diagram showing the overall flow.> ### <Shared concept: e.g., common data structures, eligibility checks> <Describe data structures, class relationships, and preconditions shared across multiple features. Include a class diagram if new types are introduced.> ### <Feature/Algorithm 1> <For each distinct feature or algorithm, write a SELF-CONTAINED section that flows in this order:> **Algorithm.** <What it does, when it triggers, what the eligibility conditions are. Keep this concise — the reader should understand the approach before seeing code or examples.> **Execution flow:** <Mermaid diagram showing the internal decision/data flow for this specific feature. NOT a rehash of the overall diagram — zoom into this feature's logic.> **Query/usage example:** <A concrete, real-world example that triggers this code path. For a database, this is a SQL query with schema context. For an API, this is a request/response. For a library, this is a code snippet. Pick the most representative example — prefer production queries (e.g., from benchmarks) over synthetic test data.> **Data walkthrough:** <Walk through the example step by step with ACTUAL VALUES. Show what the old code did (with cost), then what the new code does (with cost). Use concrete data — not "vertex A" but "Alice" or "n1". Show the build phase output, the probe phase per row, and the final result. This is what makes the design understandable — abstract descriptions alone > <Repeat for each feature/algorithm.> ### Summary Provide a table mapping each feature to its trigger condition, implementation class, data structure, and real-world impact (benchmark numbers if available). | Feature | Trigger | Implementation | Data Structures | Impact | |---|---|---|---|---| | ... | ... | ... | ... | ... |> ## PR Discussion Summary *(Only if a PR with comments exists)* <Summarize key points from PR comments and reviews. Note any decisions made, concerns raised, or alternatives discussed.> ## Impact Assessment - **Risk level**: Low / Medium / High - **Affected components**: <list> - **Testing considerations**: <what should be tested> - **Backward compatibility**: <any breaking changes?>

analyze-changes

Opciones de instalación

Revisa los archivos de origen

Input

Steps

1. Determine the input type and gather changes

Input

Steps

1. Determine the input type and gather changes

2. Check for an associated Pull Request

3. Read all changed files at their final state

4. Analyze the changes

5. Generate the markup document

Important Rules

analyze-changes

Datos de origen

Opciones de instalación

Revisa los archivos de origen

Más de este repositorio

Más de este repositorio

Input

Steps

1. Determine the input type and gather changes

Input

Steps

1. Determine the input type and gather changes

2. Check for an associated Pull Request

3. Read all changed files at their final state

4. Analyze the changes

5. Generate the markup document

Important Rules