evolution-scan

Narrates codebase evolution from Sokrates git history exports into eras, focus shifts, and trajectory findings.

3|1|Updated Aug 26, 2026
One-click install
npx skills add https://github.com/zeljkoobrenovic/sokrates-skills --skill evolution-scan-zeljkoobrenovic
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: evolution-scan
Source: https://github.com/zeljkoobrenovic/sokrates-skills/tree/main/skills/scanners/evolution-scan
Command: npx skills add https://github.com/zeljkoobrenovic/sokrates-skills --skill evolution-scan-zeljkoobrenovic

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Sokrates reports churn, file age, and contributor counts as static numbers, but those numbers cannot explain how a codebase got to its current state. This Skill reads the git history behind a Sokrates analysis and turns it into a verifiable story: development eras, growth origins, shifting areas of activity, contributor arrivals and departures, rewrites and abandoned code, and where the project is heading. ## Core Features & Use Cases - Deterministic timeline digest: A bundled Python script parses git-history.txt and git-commits.txt into periods, focus-shift tables, people statistics, and lifecycle data, so no trend is derived by hand. - Structured findings across six groups: Eras, growth, focus-shift, people, lifecycle, and trajectory, each with stable IDs so re-runs and diffs stay consistent. - Evidence-based narration: Every claim is backed by citable commit messages, changelogs, or current files, with severity calibrated to what a trend costs if ignored. - Use Case: A tech lead inherits a five-year-old repository and asks "how did this codebase get here and is it stagnating?" The scan produces era chapters, a velocity trend with 90-day comparisons, and flags risks like a stalled migration or a departed core owner. ## Quick Start Run the evolution scan on this repository's _sokrates analysis and tell me the story of how the codebase evolved and where it is heading.

Frequently Asked Questions about evolution-scan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I analyze the history of a codebase from git data?

Run the evolution_timeline.py script against the repository's git-history.txt and git-commits.txt exports to get a JSON digest of periods, areas, people, and lifecycle events. The scanner then narrates that digest into era, growth, focus-shift, people, lifecycle, and trajectory findings.

What inputs does the evolution scan require?

It requires a completed Sokrates analysis with git history, specifically git-history.txt and git-commits.txt at the source root, or zips/git-history.zip inside the extracted data.zip. Supplying the extracted data directory additionally enables current file inventory, deletion detection, and area size figures.

What happens if a repository has no git history export?

The timeline script exits with code 3 and the scan writes a single info finding in the trajectory group stating that evolution cannot be measured, with stats.history_data set to absent. It never reconstructs history from file dates or guesswork.

How does the scan detect contributor departures and turnover?

The script classifies each author as active, fading, or gone based on their last commit date relative to a threshold of 180 days or a quarter of the history. It also lists arrivals in the last year, fading major contributors whose 90-day output halved, and rising contributors.

Can the commit theme trends be trusted for all projects?

Only when commit messages are classifiable. The digest reports theme_other_pct, and when over 30 percent of messages are unclassified the theme trend is flagged unreliable, so the work mix should be judged from notable commits instead of keyword themes.

Why do area share percentages not sum to 100 in the focus shift table?

Shares count the percentage of a period's commits that touch each area, and a commit touching three areas counts in all three. They should be read as 'touched by 45 percent of commits', never as a partition of the work.