analyzing-git-sessions

bởi bitwarden

Phân tích các commit git và thay đổi trong một khung thời gian hoặc phạm vi commit, cung cấp các bản tóm tắt có cấu trúc cho việc xem xét mã, hồi tưởng, nhật ký công việc hoặc phiên làm việc…

npx skills add https://github.com/bitwarden/ai-plugins --skill analyzing-git-sessions

Analyzing Git Sessions

Core Responsibility

Generate structured analysis of git activity for specified timeframe or commit range, including commit history, file changes, statistics, and optional diffs.

Inputs

Accept from user:

  • Time range: "last 2 hours", "since 10am", "today", "since 2025-10-23 14:00"
  • Commit range: "abc123..def456", "HEAD~5..HEAD", "feature-branch..main"
  • Optional filters: Specific paths, authors, or file types
  • Output depth: Concise (default), Detailed, or Code Review format

Working Process

Step 1: Parse and Validate Input

  1. Determine range type:

    • Time-based: Parse relative or absolute time
    • Commit-based: Validate commit references exist
    • Branch-based: Resolve branch names to commits
  2. Validate git repository:

    git rev-parse --git-dir
    
  3. Check range has commits:

    git log <range> --oneline | head -1
    

    If empty, inform user and exit.

Step 2: Extract Commit History

# Get all commits in range
git log <range> --oneline --no-decorate

# Get detailed commit info
git log <range> --format="%h|%an|%ar|%s" --no-decorate

# Count commits
git log <range> --oneline | wc -l

Store commit data for summary.

Step 3: Generate Statistics

Overall change statistics:

# Summary stats (insertions/deletions by file)
git diff <start>..<end> --stat

# Numeric stats for parsing
git diff <start>..<end> --numstat

# Count total changes
git diff <start>..<end> --shortstat

Author breakdown (if multiple authors):

git shortlog <start>..<end> -sn

File categorization:

  • Identify new files (show in status "A")
  • Identify deleted files (show in status "D")
  • Identify renamed files (show in status "R")
  • Modified files with change magnitude

Step 4: Identify Key Files for Detailed Analysis

Prioritization rules:

  1. Large changes (>100 lines modified): Always include
  2. New files: Include (especially if >50 lines)
  3. Deleted files: Note but don't diff
  4. Architecture files: build.gradle.kts, AndroidManifest.xml, module configs
  5. Test files: Flag separately for test coverage assessment

Extract key file list:

# Files changed with line counts
git diff <start>..<end> --numstat | sort -rn -k1 -k2

Limit to top 10 files by default to avoid context overflow.

Step 5: Generate Selective Diffs (Based on Depth)

Concise mode: No diffs, stats only

Detailed mode: Diffs for top 3-5 key files

git diff <start>..<end> -- path/to/key/file.kt

Code Review mode: Diffs for all modified files, grouped by module

# Group by directory
git diff <start>..<end> --name-only | cut -d'/' -f1-2 | sort -u

# Generate diffs per module
for module in modules; do
  git diff <start>..<end> -- $module/
done

Context overflow protection:

  • If >10 files changed significantly, limit to top 5 diffs
  • Warn user: "Showing top 5 files by change size. Request specific files for full diffs."

Step 6: Present Structured Summary

Format based on depth:

Concise Summary

## Git Session Summary

**Range**: <start-commit> to <end-commit> (<timeframe>)
**Commits**: X commits by Y author(s)
**Files Changed**: A modified, B added, C deleted
**Net Changes**: +X -Y lines

### Commits

- abc123 Commit message 1
- def456 Commit message 2
  ...

### Top Files Changed

1. path/to/file1.kt (+50 -20)
2. path/to/file2.kt (+30 -15)
   ...

Detailed Summary

Includes:

  • Full commit list with authors and timestamps
  • Complete file list with change stats
  • Author breakdown
  • Top 3-5 diffs for review

Code Review Format

## Code Review Summary

### Overview

- **PR Title**: [Suggested from commit messages]
- **Changes**: X files across Y modules
- **Scope**: [Inferred from changed files]

### Commits

[Formatted commit list suitable for PR description]

### Changes by Module

**Module: app**

- file1.kt: Description of changes
- file2.kt: Description of changes

**Module: core**
...

### Key Changes

[Diffs for significant modifications]

### Test Coverage

- Test files modified: X
- New tests added: ~Y

Output Guidelines

Commit Messages

  • Show short hash (7 chars)
  • Show first line of commit message only
  • Truncate long messages to 80 chars
  • Group by author if multiple contributors

File Paths

  • Use relative paths from repo root
  • Format as code: path/to/file.kt
  • Include line change magnitude: (+X -Y)
  • Highlight file type (source, test, config)

Statistics

Present in clear tables:

| Metric        | Count |
| ------------- | ----- |
| Commits       | 15    |
| Files Changed | 23    |
| Insertions    | +450  |
| Deletions     | -180  |

Diffs

  • Include file path as header: ### path/to/file.kt
  • Use code blocks with syntax highlighting
  • Show context lines (git default: 3 lines before/after)
  • Truncate very large diffs (>200 lines) with summary

Context Budget Management

Monitor diff sizes:

  • Small session (<10 files, <500 lines): Safe for detailed mode
  • Medium session (10-30 files, 500-2000 lines): Use selective diffs
  • Large session (>30 files, >2000 lines): Concise mode with warnings

Progressive disclosure:

  1. Always start with concise summary
  2. Ask user: "Would you like detailed diffs for specific files?"
  3. Generate diffs on demand rather than upfront

Fallback for large sessions: "This session modified 45 files with 5000+ line changes. Showing concise summary. Request specific files or modules for detailed diffs."

Anti-Patterns to Avoid

Don't:

  • Generate diffs for all files in large sessions (context overflow)
  • Include full diffs without asking (waste context on unneeded details)
  • Ignore file types (treat test changes same as source changes)
  • Lose context on what user wants to know
  • Use generic summaries ("modified 10 files") without specifics

Do:

  • Ask user what level of detail they need
  • Prioritize key files by change magnitude
  • Categorize files (source, test, config, docs)
  • Provide actionable summaries
  • Offer to drill down on specific files

Success Criteria

A good git session analysis should:

  1. Inform: User understands scope of changes at a glance
  2. Focus: Highlights most significant changes first
  3. Actionable: Provides paths and diffs for deeper review
  4. Efficient: Doesn't waste context on unnecessary details
  5. Adaptable: Adjusts depth based on session size and user needs

Example Outputs

See contexts/example-outputs.md for detailed examples of concise summaries and code review formats.

Thêm skills từ bitwarden

figma-to-angular
bitwarden
Kỹ năng này chuyển đổi bản thiết kế Figma thành một component Angular được triển khai đầy đủ với các story Storybook trong monorepo Bitwarden Clients. Đầu ra phải khớp với thiết kế về mặt hình ảnh đồng thời tuân thủ tất cả các quy ước codebase.
force-multiplier
bitwarden
Áp dụng một ý định trên nhiều mục tiêu cùng lúc — một loạt kho lưu trữ trong hệ sinh thái Bitwarden, hoặc nhiều dự án trong một monorepo — như N nhất quán,…
coordinating-cross-team-breakdown
bitwarden
Phối hợp đánh giá và phê duyệt giữa các nhóm cho một Bản Phân Tích Kỹ Thuật Bitwarden. Sử dụng khi xác định các nhóm bị ảnh hưởng, xây dựng bảng phê duyệt Phần 3, theo dõi…
assessing-jira-issue-relevance
bitwarden
Sử dụng khi người dùng cung cấp một mã số vấn đề Jira duy nhất và hỏi liệu vấn đề đó có còn liên quan, còn áp dụng, còn đang chờ xử lý, còn là lỗi, đã được sửa, hay có thể…
assessing-test-coverage
bitwarden
Sử dụng khi xác định mức độ bao phủ kiểm thử ĐÃ tồn tại cho một thay đổi cụ thể (một PR, khóa Jira, tài liệu Tech Breakdown, CSV Testmo, các đường dẫn đã thay đổi, hoặc các mục được đặt tên…
retrospecting
bitwarden
Thực hiện phân tích toàn diện các phiên Claude Code, xem xét lịch sử git, nhật ký hội thoại, thay đổi mã nguồn và thu thập phản hồi từ người dùng để tạo ra…
reviewing-incremental-changes
bitwarden
Sử dụng kỹ năng này khi xem lại một PR đã có bình luận hoặc khi phản hồi các thay đổi của nhà phát triển sau lần xem xét ban đầu. Áp dụng khi có các luồng thảo luận trong PR hoặc…
starting-breakdown
bitwarden
Sets up a new Bitwarden Tech Breakdown in the bitwarden/tech-breakdowns repo. Creates a per-breakdown folder (`<team>/<JIRA-KEY>-<short-slug>/`) containing…