Who Is Actor — Git Repository Developer Profiling Skill

🔗 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.

---

💬 Natural Language (Recommended)

You don't need to memorize any commands or parameters — simply describe what you need in any language:

English

CODEBLOCK0

中文

CODEBLOCK1

日本語

CODEBLOCK2

한국어

CODEBLOCK3

Español

CODEBLOCK4

Français

CODEBLOCK5

Deutsch

CODEBLOCK6

---

⚙️ Parameters

Parameter	Description	Required	Default
INLINECODE14	Absolute path to the target Git repository	✅ Yes	—
INLINECODE15

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.

---

Security Specification

All shell command parameters MUST be strictly validated before execution to prevent command injection attacks.

Dry-Run Mode (Recommended for First Use)

Before executing any commands, the agent SHOULD offer a dry-run mode that:

1. 1. Collects and validates all parameters per the rules below
2. Constructs the full list of shell commands that would be executed
3. Prints every command to the user for review WITHOUT executing any of them
4. Waits for explicit user approval before proceeding to actual execution

To trigger dry-run mode, the user can say:
CODEBLOCK7

This allows the user to verify that every command strictly matches the whitelist below.

Command Whitelist (Only These Commands Are Allowed)

This skill only permits the following predefined read-only git subcommands. No other shell commands may be executed:

Allowed Command	Purpose	Modifies Repo?
INLINECODE21	Verify the path is a valid Git repository	❌ Read-only
INLINECODE22

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:

• - ❌ Any write operations: git push, git commit, git merge, git rebase, git reset, git checkout, INLINECODE31
• ❌ Any non-git commands: curl, wget, python, node, bash -c, sh, eval, rm, cp, INLINECODE41
• ❌ Any file writes or redirections: >, >>, tee (pipe | is only allowed to connect read-only text-processing tools: cut, sort, uniq, awk, grep, wc, sed, head)
• ❌ Any network operations: git fetch, git pull, git clone, INLINECODE57

If the AI agent attempts to execute a command outside the whitelist, the user should immediately reject execution.

Input Validation Rules (Must Be Completed Before Any Git Command)

1. 1. repo_path (Repository Path) Validation:

- Must be an absolute path (starting with /) - Must NOT contain any of these dangerous characters or substrings: ;, |, &, $, ` `, (, ), >, <, \n, \r, $(), .. - Path must be a real, existing Git repository (verified via git -C rev-parse --is-inside-work-tree returning true) - If validation fails, **immediately abort and report the error to the user — no subsequent commands may be executed** 2. **author (Author Name) Validation:** - Only allowed characters: letters (a-z A-Z), digits (0-9), spaces, hyphens (-), underscores (), dots (.) - **The @ symbol is NOT allowed** (email format is prohibited to align with privacy protection rules) - Regex whitelist: ^[a-zA-Z0-9 .-]+$ - Maximum length: 128 characters - If input contains @, prompt the user to use the author's display name instead, then skip that author 3. **since / until (Date Parameters) Validation:** - Must match ISO date format: ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ - If validation fails, ignore the parameter and warn the user 4. **branch (Branch Name) Validation:** - Only allowed characters: letters, digits, /, -, , . - Regex whitelist: ^[a-zA-Z0-9/.-]+$ - Must NOT contain the .. substring - If validation fails, use the default branch and warn the user ### Privacy Protection Rules - **Developer email addresses are NOT collected.** All git commands use only %an (author name) to identify developers, never %ae (author email). - **git shortlog uses -sn instead of -sne** to avoid leaking email addresses. - **The authors parameter only accepts display names, NOT email addresses.** Input validation rejects values containing @. - Note: The 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. - The final report MUST NOT contain any email addresses. ### Sensitive Data Filtering Rules (Mandatory) Before sending **any** data to the AI model for analysis, the agent MUST apply the following filtering: 1. **Commit messages are processed locally for statistics only:** - The agent collects commit message **lengths** (character counts) and **keyword matches** (e.g., fix, feat, revert) locally via shell commands. - **Full commit message text MUST NOT be forwarded verbatim to the AI model.** Instead, send only aggregated metrics (average length, keyword counts, conventional commit compliance rate). - If the user explicitly requests to see specific commit messages, the agent MUST: 1. First apply all redaction patterns listed below 2. Truncate each message to a maximum of 120 characters 3. Display redacted messages **only in the final user-facing report**, never in intermediate AI prompts 4. Warn the user that commit messages may contain sensitive information 2. **Automatic redaction of secret patterns:** Before any text (commit messages, filenames, branch names) is included in the AI prompt, the agent MUST scan for and redact the following patterns: - API keys / tokens: strings matching (?i)(api[-]?key|token|secret|password|credential|auth)[=:]\s\S+ - AWS keys: AKIA[0-9A-Z]{16} - Private keys: -----BEGIN . PRIVATE KEY----- - Connection strings: (?i)(mysql|postgres|mongodb|redis)://\S+ - Generic secrets: any string longer than 20 characters containing only alphanumeric characters that appears after = or : in a key-value pattern - Replace matched content with [REDACTED] 3. **Filename filtering:** - Filenames are collected only to determine **file extensions** for language/type statistics. - Full file paths SHOULD NOT be sent to the AI model unless the user explicitly requests file-level analysis. - If full paths are sent, redact any path components that match common secret file patterns: .env, .credentials, secret, password, token. ### Repository Path Scope Rules - The agent MUST only access the specific repository path provided by the user. - The agent MUST NOT traverse parent directories (..) or access files outside the repository root. - The agent MUST NOT list or read arbitrary files from the filesystem — only git commands targeting the validated repository are permitted. - If the user provides a path to a subdirectory within a repository, the agent should use the repository root (as determined by git -C rev-parse --show-toplevel) and inform the user. ### Enforcement Verification Protocol 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):** 1. **Dry-run test:** Ask the agent to analyze a test repo using dry-run mode. Verify that: - Every proposed command appears in the Command Whitelist table above - No commands use %ae (email format) or -sne flags - All user-supplied values (path, author, dates) are properly quoted 2. **Input validation test:** Deliberately provide invalid inputs and verify rejection: CODEBLOCK8 3. **Data filtering test:** After a dry-run, ask the agent: CODEBLOCK9 The agent should confirm it sends only aggregated metrics (counts, averages, percentages), NOT raw commit messages or full file paths. 4. **Redaction test:** If commit messages are requested, verify that: - Messages are truncated to <=120 characters - Patterns like APIKEY=xxx appear as [REDACTED] - Messages appear only in the final report, not in intermediate processing > **If any verification step fails, do NOT use the skill on sensitive repositories.** Report the failure to the skill maintainer. ## Use Cases - When users need to analyze each developer's real behavioral profile in a Git repository - When users want to compare team members' commit habits, work rhythms, and code quality - When users want to understand the team's engagement distribution - When users need honest evaluations of each developer's strengths and weaknesses with improvement suggestions ## Core Principles > **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. ## Workflow ### Step 1: Confirm Analysis Parameters 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.** ### Step 2: Data Collection (Pure Git Commands) 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, , , etc. are placeholders for validated safe values from Step 1. #### 2.1 Contributor Overview CODEBLOCK10 #### 2.2 Per-Author Commit Details For each author to be analyzed, execute the following commands (append --since, --until, parameters if a date range or branch was specified): CODEBLOCK11 #### 2.3 Code Quality Signals CODEBLOCK12 #### 2.4 Team-Level Data CODEBLOCK13 ### Step 3: AI Analysis & Evaluation Based on the collected raw data, analyze each developer across the following **six dimensions**, assigning a score of 1–10 for each: --- #### 📝 Dimension 1: Commit Habits **Analysis Factors:** - Total commit count, average daily commit frequency - Average lines changed per commit (additions + deletions) - Average commit message length and quality - Merge commit ratio - Frequency of large commits (>500 lines) **Scoring Criteria:** - 10: 2–5 daily commits, 50–200 lines each, clear and well-formatted messages - 5: Inconsistent frequency, occasional giant commits, mixed message quality - 1: Very few commits or frequent giant commits with one-word messages --- #### ⏰ Dimension 2: Work Habits **Analysis Factors:** - Commit time distribution (peak hours) - Weekend commit percentage - Late-night coding ratio (22:00–04:59) - Longest consecutive coding streak (days) - Active days / total span days **Scoring Criteria:** - 10: Regular working hours, late-night/weekend ratio <10%, consistent and steady output - 5: Some late-night/weekend commits, moderate rhythm fluctuations - 1: Almost all commits at night/weekends, or extremely irregular patterns > Note: Late-night/weekend coding is not inherently "bad," but persistent patterns may indicate process or resource issues. --- #### 🚀 Dimension 3: Development Efficiency **Analysis Factors:** - Net code growth rate: (additions - deletions) / additions - Code churn rate: deletions / additions - Rework ratio: frequency of modifying the same file within 7-day windows - Average daily output during active days **Scoring Criteria:** - 10: High net growth rate, churn rate <20%, low rework ratio, stable output - 5: Moderate churn rate, some rework - 1: Massive code deletions, frequent rework, highly volatile output --- #### 🎨 Dimension 4: Code Style **Analysis Factors:** - Primary programming languages / file type distribution - Conventional Commits compliance rate - Whether commit messages reference issue numbers - File modification focus (concentrated on a few modules vs. scattered) **Scoring Criteria:** - 10: >80% Conventional Commits compliance, messages reference issues, focused modifications - 5: Partial compliance, occasionally scattered - 1: Almost no compliance, meaningless messages --- #### 🔍 Dimension 5: Code Quality **Analysis Factors:** - Bug fix commit ratio - Revert commit frequency - Large commit (>500 lines) ratio - Frequency of test-related file modifications **Scoring Criteria:** - 10: Bug fix ratio <10%, no reverts, large commits <5%, test files modified - 5: Bug fix 15–25%, few reverts, some large commits - 1: Bug fix >30%, frequent reverts, many giant commits --- #### 📊 Dimension 6: Engagement Index > **⚠️ 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:** - 0–20: Highly active — consider whether burnout risk exists - 21–40: Steady participation, consistent output - 41–60: Moderate participation, room for improvement - 61–80: Low participation — check if there are non-code contributions not captured - 81–100: Very low participation — recommend discussing with the individual to understand the full picture > **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. ### Step 4: Generate Report The final report MUST include the following structure: #### 4.1 Summary Table | Developer | Commits | Lines +/- | Daily Avg | Weekend% | Late-Night% | Bug Fix% | Churn Rate | Engagement | Overall Score | |-----------|---------|-----------|-----------|----------|-------------|----------|------------|------------|---------------| | ... | ... | ... | ... | ... | ... | ... | ... | ... | ... | #### 4.2 Individual Developer Profiles For each developer, output: 1. **Data Dashboard**: Key metrics for all six dimensions 2. **AI Commentary**: Serious, direct assessment of strengths and weaknesses (no sugarcoating) 3. **Improvement Suggestions**: Specific, actionable recommendations for each weakness 4. **Six-Dimension Radar Score**: 1–10 per dimension 5. **Overall Score**: Weighted average (Commit Habits 15%, Work Habits 15%, Dev Efficiency 25%, Code Style 15%, Code Quality 20%, Engagement Index inverse 10%) 6. **One-Line Summary**: A sharp, memorable sentence summarizing this developer #### 4.3 Team Cross-Comparison - Rankings across all dimensions - Highlight best / worst performers - Overall team health assessment - Bus factor risk alerts ## Commentary Style Requirements - **Serious and direct**: No sugarcoating, no hedging. Let the data speak — good is good, bad is bad. - **Warm but firm**: Point out problems while providing a path to improvement. Critique the work, not the person. - **Sharp but fair**: Like a senior Tech Lead conducting an annual Code Review — neither pulling punches nor being cruel. - **Data-driven**: Every conclusion MUST be backed by corresponding data. No gut feelings. ## Important Notes - All data collection uses only native git commands — **no pip packages, no Python/Node scripts installed or executed** - **Required system binaries:** git, cut, sort, uniq, awk, grep, sed, wc, head — these must be available on the host (pre-installed on most Unix-like systems) - **All user inputs MUST be validated per the "Security Specification" rules before execution** to prevent command injection attacks - **Dry-run mode is recommended for first use** — review all commands before allowing execution - **Enforcement verification:** Before using on sensitive repos, run the "Enforcement Verification Protocol" on a test repository to confirm your agent correctly implements all validation, whitelisting, and redaction rules - **Sensitive data protection:** Commit messages are processed locally for statistical metrics only (lengths, keyword counts) — **full commit message text is NOT sent to the AI model by default.** Common secret patterns (API keys, tokens, credentials, connection strings) are automatically redacted before any data leaves the local environment. See "Sensitive Data Filtering Rules" for details. - **Repository scope:** The agent only accesses the specific repository path provided — no parent directory traversal or arbitrary filesystem access is permitted - **Developer emails are NOT collected** to protect personal privacy - For large repositories, consider limiting the date range to control command execution time - Be aware that the same person may have different name variants (can be unified via .mailmap`)

• - Timezone differences may affect work-hour analysis — use the timezone from the commit records
• The Engagement Index is based solely on Git commit data and does NOT reflect non-code contributions (design, reviews, mentoring, etc.) — it should not be the sole basis for performance evaluation

Ethical Use Policy

Reports generated by this skill should adhere to the following principles:

1. 1. Supplementary reference, NOT a decision-making basis: Reports are for internal team reference only, to help understand collaboration patterns and areas for improvement. They are strictly prohibited from being used directly for performance reviews, layoff decisions, compensation adjustments, or other HR decisions.
2. Transparency: If using this tool within a team, it is recommended to inform all analyzed team members in advance.
3. Full context: Any citation of the report should include complete limitation disclaimers to avoid being taken out of context.
4. Critique the work, not the person: The goal is to improve team collaboration processes and individual work methods, not to judge a person's worth.