🔗 Project Repository: https://github.com/wscats/who-is-actor
Zero install dependencies, zero scripts. Collects data purely through native git commands and standard Unix text utilities (cut, sort, awk, grep, etc. — already present on most systems), interpreted by AI, to generate a serious, direct, and unsparing report card for every developer.
"Zero dependency" clarification: This skill installs nothing — no pip packages, no npm modules, no custom scripts. However, it does require the following standard system binaries to be available on the host:
git,cut,sort,uniq,awk,grep,sed,wc,head. These are pre-installed on virtually all Unix-like systems (macOS, Linux). On Windows, use Git Bash or WSL.
You don't need to memorize any commands or parameters — simply describe what you need in any language:
💬 "Analyze the repository at /path/to/my-project"
💬 "Profile all developers in this repo"
💬 "Who are the most active contributors in /path/to/my-project?"
💬 "Compare commit habits of Alice and Bob"
💬 "Show me the code quality report for this project since 2024-01-01"
💬 "What does each developer's work pattern look like on branch main?"
💬 "Give me an honest review of every contributor's strengths and weaknesses"
💬 "Is there a bus-factor risk in /path/to/my-project?"
💬 "分析一下 /path/to/my-project 这个仓库"
💬 "帮我看看这个项目里每个开发者的提交习惯"
💬 "对比一下 Alice 和 Bob 的研发效率"
💬 "生成这个仓库的开发者画像报告"
💬 "这个项目的代码质量怎么样？"
💬 "从 2024 年 1 月开始，分析 main 分支的提交记录"
💬 "团队里谁的代码风格最好？谁需要改进？"
💬 "看看这个仓库有没有巴士因子风险"
💬 "このリポジトリの開発者を分析してください /path/to/my-project"
💬 "各開発者のコミット習慣を比較してください"
💬 "このプロジェクトのコード品質レポートを作成してください"
💬 "チームの開発効率を評価してください"
💬 "이 저장소의 개발자 프로필을 분석해 주세요 /path/to/my-project"
💬 "각 개발자의 커밋 습관을 비교해 주세요"
💬 "이 프로젝트의 코드 품질 보고서를 만들어 주세요"
💬 "팀의 개발 효율성을 평가해 주세요"
💬 "Analiza el repositorio en /path/to/my-project"
💬 "Compara los hábitos de commit de todos los desarrolladores"
💬 "Dame un informe de calidad del código de este proyecto"
💬 "¿Quién es el desarrollador más activo del equipo?"
💬 "Analyse le dépôt situé à /path/to/my-project"
💬 "Compare les habitudes de commit de chaque développeur"
💬 "Génère un rapport de qualité du code pour ce projet"
💬 "Qui est le contributeur le plus actif de l'équipe ?"
💬 "Analysiere das Repository unter /path/to/my-project"
💬 "Vergleiche die Commit-Gewohnheiten aller Entwickler"
💬 "Erstelle einen Code-Qualitätsbericht für dieses Projekt"
💬 "Wer ist der aktivste Entwickler im Team?"
| Parameter | Description | Required | Default |
|---|---|---|---|
repo_path |
Absolute path to the target Git repository | ✅ Yes | — |
authors |
Comma-separated display names (emails NOT accepted) | No | All contributors |
since |
Start date in ISO format (YYYY-MM-DD) |
No | Full history |
until |
End date in ISO format (YYYY-MM-DD) |
No | Full history |
branch |
Target branch to analyze | No | Active branch |
What you get: A structured Markdown report with a summary table, per-developer profiles (six-dimension radar scores, strengths/weaknesses, improvement suggestions), team comparison, and bus-factor risk alerts.
All shell command parameters MUST be strictly validated before execution to prevent command injection attacks.
Before executing any commands, the agent SHOULD offer a dry-run mode that:
To trigger dry-run mode, the user can say:
💬 "Show me the commands first before running them"
💬 "Do a dry run on /path/to/repo"
💬 "先列出要执行的命令，不要运行"
This allows the user to verify that every command strictly matches the whitelist below.
This skill only permits the following predefined read-only git subcommands. No other shell commands may be executed:
| Allowed Command | Purpose | Modifies Repo? |
|---|---|---|
git -C <path> rev-parse --is-inside-work-tree |
Verify the path is a valid Git repository | ❌ Read-only |
git -C <path> shortlog -sn --all |
Get contributor list and commit counts | ❌ Read-only |
git -C <path> log ... |
Get commit history details | ❌ Read-only |
git -C <path> diff --stat ... |
Get change statistics | ❌ Read-only |
Strictly Prohibited Command Types:
git push, git commit, git merge, git rebase, git reset, git checkout, git branch -dcurl, wget, python, node, bash -c, sh, eval, rm, cp, mv>, >>, tee (pipe | is only allowed to connect read-only text-processing tools: cut, sort, uniq, awk, grep, wc, sed, head)git fetch, git pull, git clone, git remoteIf the AI agent attempts to execute a command outside the whitelist, the user should immediately reject execution.
repo_path (Repository Path) Validation:
/);, |, &, $, `, (, ), >, <, \n, \r, $(), ..git -C <path> rev-parse --is-inside-work-tree returning true)author (Author Name) Validation:
-), underscores (_), dots (.)@ symbol is NOT allowed (email format is prohibited to align with privacy protection rules)^[a-zA-Z0-9 _.-]+$@, prompt the user to use the author's display name instead, then skip that authorsince / until (Date Parameters) Validation:
^[0-9]{4}-[0-9]{2}-[0-9]{2}$branch (Branch Name) Validation:
/, -, _, .^[a-zA-Z0-9/_.-]+$.. substring%an (author name) to identify developers, never %ae (author email).git shortlog uses -sn instead of -sne to avoid leaking email addresses.authors parameter only accepts display names, NOT email addresses. Input validation rejects values containing @.git --author parameter matches against both name and email fields. Since this skill prohibits email-format values, --author will only match via the name portion and will not utilize the email field.Before sending any data to the AI model for analysis, the agent MUST apply the following filtering:
fix, feat, revert) locally via shell commands.(?i)(api[_-]?key|token|secret|password|credential|auth)[=:]\s*\S+AKIA[0-9A-Z]{16}-----BEGIN .* PRIVATE KEY-----(?i)(mysql|postgres|mongodb|redis)://\S+= or : in a key-value pattern[REDACTED].env, .credentials, *secret*, *password*, *token*...) or access files outside the repository root.git commands targeting the validated repository are permitted.git -C <path> rev-parse --show-toplevel) and inform the user.Because this is an instruction-only skill (no executable code), safety guarantees depend on the AI agent correctly implementing the rules above. Users SHOULD verify enforcement before trusting the skill on sensitive repositories.
Verification steps (run on a safe test repository first):
%ae (email format) or -sne flags"Analyze /tmp/test; rm -rf /" -> agent MUST reject (dangerous characters)
"Profile author user@email.com" -> agent MUST reject (@ not allowed)
"Analyze since 2024-13-99" -> agent MUST reject or warn (invalid date)
"Analyze branch ../../etc/passwd" -> agent MUST reject (.. not allowed)
"What data will you send to the AI model?"
The agent should confirm it sends only aggregated metrics (counts, averages, percentages), NOT raw commit messages or full file paths.
API_KEY=xxx appear as [REDACTED]If any verification step fails, do NOT use the skill on sensitive repositories. Report the failure to the skill maintainer.
Install nothing, run no scripts. All data collection is done exclusively through native git commands (
git log,git shortlog,git diff --stat, etc.). The AI is responsible for interpretation and evaluation.
Security first. All user inputs must pass the validation rules above before being incorporated into shell commands. Any validation failure must result in termination or graceful degradation — never skip validation.
Confirm the following with the user (use defaults if not specified):
| Parameter | Description | Default |
|---|---|---|
| Repository Path | Absolute path to the target Git repository | (Required) |
| Target Authors | Specific developers to analyze; leave blank for all | All contributors |
| Date Range | Start/end dates in ISO format | Full repository history |
| Branch | Target branch for analysis | Current active branch |
⚠️ Before executing Step 2, ALL parameters MUST be validated according to the "Security Specification" above. Parameters that fail validation MUST NOT be used in command construction.
Execute the following git commands in sequence to collect raw data. All commands run against the target repository directory — no dependencies need to be installed.
In the examples below,
<repo_path>,<author>, etc. are placeholders for validated safe values from Step 1.
# List all contributors with commit counts (no email to protect privacy)
git -C <repo_path> shortlog -sn --all
For each author to be analyzed, execute the following commands (append --since, --until, <branch> parameters if a date range or branch was specified):
# Detailed commit log: hash, author name, date, message, file stats (no email)
git -C <repo_path> log --author="<author>" --pretty=format:"%H|%an|%aI|%s" --numstat
# Commit count per hour of day (for work habit analysis)
git -C <repo_path> log --author="<author>" --pretty=format:"%aI" | cut -c12-13 | sort | uniq -c | sort -rn
# Commit count per day of week (1=Mon, 7=Sun)
git -C <repo_path> log --author="<author>" --pretty=format:"%ad" --date=format:"%u" | sort | uniq -c | sort -rn
# Lines added/deleted summary
git -C <repo_path> log --author="<author>" --pretty=tformat: --numstat | awk '{ add += $1; subs += $2 } END { printf "added: %s, deleted: %s\n", add, subs }'
# Commit message lengths
git -C <repo_path> log --author="<author>" --pretty=format:"%s" | awk '{ print length }'
# File types touched
git -C <repo_path> log --author="<author>" --pretty=tformat: --name-only | grep -oE '\.[^./]+$' | sort | uniq -c | sort -rn | head -20
# Commits per day (for frequency analysis)
git -C <repo_path> log --author="<author>" --pretty=format:"%ad" --date=short | sort | uniq -c | sort -rn | head -20
# Recent rework detection: files modified multiple times within 7-day windows
git -C <repo_path> log --author="<author>" --pretty=format:"%ad %s" --date=short --name-only | head -200
# Bug fix commits (messages containing fix/bug/hotfix/patch)
git -C <repo_path> log --author="<author>" --grep="fix\|bug\|hotfix\|patch" --oneline -i | wc -l
# Revert commits
git -C <repo_path> log --author="<author>" --grep="revert" --oneline -i | wc -l
# Large commits (>500 lines changed)
git -C <repo_path> log --author="<author>" --pretty=format:"%H" --shortstat | grep -E "([5-9][0-9]{2}|[0-9]{4,}) insertion" | wc -l
# Merge commits
git -C <repo_path> log --author="<author>" --merges --oneline | wc -l
# Conventional commit check (feat/fix/chore/docs/style/refactor/test/perf/ci/build)
git -C <repo_path> log --author="<author>" --pretty=format:"%s" | grep -cE "^(feat|fix|chore|docs|style|refactor|test|perf|ci|build)(\(.+\))?:"
# Files with only one contributor (bus factor risk)
git -C <repo_path> log --pretty=format:"%an" --name-only | sort | uniq -c | sort -rn | head -30
# Active date range per author
git -C <repo_path> log --author="<author>" --pretty=format:"%ad" --date=short | sort | sed -n '1p;$p'
Based on the collected raw data, analyze each developer across the following six dimensions, assigning a score of 1–10 for each:
Analysis Factors:
Scoring Criteria:
Analysis Factors:
Scoring Criteria:
Note: Late-night/weekend coding is not inherently "bad," but persistent patterns may indicate process or resource issues.
Analysis Factors:
Scoring Criteria:
Analysis Factors:
Scoring Criteria:
Analysis Factors:
Scoring Criteria:
⚠️ Usage Restriction: This index is intended solely as a macro-level reference for team collaboration patterns. It is strictly prohibited to use it as a basis for individual performance reviews, layoff decisions, compensation adjustments, or any other HR decisions. Users should understand the limitations of this index and bear corresponding ethical responsibility.
Note: This index aims to objectively measure visible participation levels in the code repository as a supplementary reference. Git records only reflect code commit activity and do not represent a developer's full body of work (design, code review, communication, mentoring, etc. are not captured by Git).
Calculation Method (composite of the following signals, 0–100 scale, lower = higher visible engagement):
| Signal | Weight | Description |
|---|---|---|
| Very low daily commits (<0.3) | 25% | Output during active days is too low |
| Low active-day ratio (<30%) | 20% | Large time span but few actual working days |
| Very low or negative net code growth | 20% | More code deleted than written |
| Careless commit messages (avg <15 chars) | 15% | Not taking commit records seriously |
| High churn rate + high rework rate | 20% | Large amount of wasted effort |
Levels:
Important: This index is calculated solely from Git commit records and cannot reflect code reviews, architecture design, technical discussions, team mentoring, or other work that doesn't produce commits. A high score does NOT equal "slacking," and a low score does NOT equal "efficient." Please make judgments only after understanding the full context.
The final report MUST include the following structure:
| Developer | Commits | Lines +/- | Daily Avg | Weekend% | Late-Night% | Bug Fix% | Churn Rate | Engagement | Overall Score |
|---|---|---|---|---|---|---|---|---|---|
| … | … | … | … | … | … | … | … | … | … |
For each developer, output:
git commands — no pip packages, no Python/Node scripts installed or executedgit, cut, sort, uniq, awk, grep, sed, wc, head — these must be available on the host (pre-installed on most Unix-like systems).mailmap)Reports generated by this skill should adhere to the following principles: