🔗 Project Repository: https://github.com/wscats/who-is-actor
Zero install dependencies, zero scripts. Collects data purely through native read-only git commands and standard Unix text utilities (cut, sort, awk, grep, etc. — already present on most systems). The AI is responsible only for interpreting already-aggregated, locally-redacted statistical metrics to generate a collaboration-pattern report.
⚠️ READ THIS BEFORE USING — Privacy, Consent & Scope Notice
- Other people's data may be involved. A Git repository typically contains commit metadata (display names, timestamps, commit message subjects, file paths) authored by people other than the user invoking this skill. Before running, the user MUST confirm they have authority to analyze the repository and that doing so does not violate workplace, contractual, or local-law obligations. The agent SHOULD remind the user to inform analyzed contributors when used in a team context.
- Not for HR / personnel decisions. The output, including the repository-wide visible-activity index, MUST NOT be used as the basis for performance reviews, hiring/firing decisions, compensation, layoffs, ranking, or any personnel-style judgment of individuals. The agent MUST refuse such requests and respond only with non-personalized, aggregate observations. This skill produces no per-contributor breakdown, scoring, or ranking of any kind.
- Sensitive content may exist in commit metadata. Commit messages and filenames can contain ticket IDs, incident references, secrets, customer names, URLs, or other confidential information. This skill mandates that such raw text remain local-only and that only aggregate, redacted metrics ever reach the AI model. See "Sensitive Data Filtering Rules" for binding enforcement.
- Read-only, scoped, no network. The skill executes only the read-only git subcommands enumerated in the Command Whitelist, against the single user-supplied repository path. No writes, no network, no traversal outside the repo root.
"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.
⚠️ Hard activation constraint (binding on the agent): The phrasings below are reference templates for expressing intent. The agent MUST NOT start collection merely because the user mentioned topics like "analyze repository", "profile developers", "commit habits", "developer report card", "code quality", "engagement", "研发效率", or "开发者画像". Collection may begin only after ALL of the following are satisfied:
- The user has explicitly stated an intent to analyze a specific Git repository;
- The user has supplied a concrete repository path (absolute) or an unambiguous repo reference;
- The user has confirmed they have authority to analyze that repository, and (in team contexts) has informed or will inform the analyzed contributors;
- The user has acknowledged the privacy notice and that the report MUST NOT be used for personnel decisions;
- Dry-Run preview is recommended before actual execution.
If the user uses any of the phrasings below without supplying a repository path, the agent MUST first ask for the repository path and authority confirmation, and only then proceed.
You don't need to memorize any commands or parameters — simply describe what you need in any language (please supply an absolute repository path along with the request):
💬 "Analyze the repository at /path/to/my-project"
💬 "Generate a repository-level collaboration-pattern report for /path/to/my-project"
💬 "Show aggregate commit-cadence and churn signals for /path/to/my-project since 2024-01-01"
💬 "What does the commit-time distribution look like on branch main in /path/to/my-project?"
💬 "Is there a bus-factor risk in /path/to/my-project?"
> The agent MUST refuse phrasings that ask for individualized judgments, comparisons between named people, "best/worst contributor" rankings, performance verdicts, or personnel-style assessments — even if a repository path is provided. In such cases the agent MUST decline and offer instead to describe repository-level workflow patterns.
💬 "分析一下 /path/to/my-project 这个仓库的协作模式"
💬 "生成 /path/to/my-project 的仓库级提交节奏与流失率报告"
💬 "从 2024 年 1 月开始，分析 main 分支的提交节奏分布"
💬 "看看这个仓库有没有巴士因子风险"
💬 "统计 /path/to/my-project 中提交消息的约定式合规率"
> 代理必须拒绝任何要求对具名个人作出评判、对比、排名、"谁最好/最差"或任何人事性评估的措辞——即便仓库路径已经提供。这种情况下，代理应说明本技能不做个人评估，并改为提供仓库级别的工作流程模式描述。
💬 "このリポジトリの協作パターンを分析してください /path/to/my-project"
💬 "このリポジトリのコミット時間分布とチャーン率レポートを作成してください"
💬 "このリポジトリの bus-factor リスクを確認してください"
💬 "이 저장소의 협업 패턴을 분석해 주세요 /path/to/my-project"
💬 "이 저장소의 커밋 케이던스와 churn 지표 보고서를 만들어 주세요"
💬 "이 저장소의 bus-factor 리스크를 확인해 주세요"
💬 "Analiza los patrones de colaboración del repositorio en /path/to/my-project"
💬 "Genera un informe a nivel de repositorio sobre cadencia de commits y churn"
💬 "¿Existe riesgo de bus-factor en /path/to/my-project?"
💬 "Analyse les motifs de collaboration du dépôt à /path/to/my-project"
💬 "Génère un rapport au niveau du dépôt sur la cadence des commits et le churn"
💬 "Y a-t-il un risque de bus-factor dans /path/to/my-project ?"
💬 "Analysiere die Kollaborationsmuster des Repositories unter /path/to/my-project"
💬 "Erstelle einen Repository-Level-Bericht zu Commit-Kadenz und Churn"
💬 "Gibt es ein Bus-Factor-Risiko in /path/to/my-project?"
| Parameter | Description | Required | Default |
|---|---|---|---|
repo_path |
Absolute path to the target Git repository | ✅ Yes | — |
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 |
No
authorsparameter. This skill is intentionally repository-scoped and does NOT support per-contributor filtering or per-contributor analysis. Earlier versions exposed anauthorsparameter; it has been removed because per-contributor filtering enables individualized profiling, which is out of scope.
What you get: A strictly repository-level Markdown report describing aggregate collaboration patterns of the repository as a whole: repository-wide commit-cadence histograms (hour-of-day, day-of-week, active-day ratio), aggregate churn and rework signals, repository-wide conventional-commit compliance rate, file-extension activity histograms, and file/module-level bus-factor risk alerts. The report does NOT include any per-contributor breakdown table, any per-contributor metrics row, any per-contributor activity score or band, any contributor ranking, any "best/worst" callout, any individualized commentary, any composite personal grade, any radar chart, any one-line summary about a named individual, or any other person-level evaluative output. Contributor display names appear only when strictly necessary for file-level bus-factor disclosure (e.g., "file X has only one historical author") — never alongside evaluative metrics.
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> rev-parse --show-toplevel |
Resolve the repository root when the user-supplied path is a sub-directory | ❌ 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 flags only) | ❌ Read-only |
git -C <path> diff --stat ... |
Get change statistics | ❌ Read-only |
Any git invocation that is not represented by one of the rows above MUST be rejected, even if it appears read-only. Adding a new command to the whitelist is a deliberate change to the skill's safety contract and requires updating both this table and the dry-run verification checklist.
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 parameter — NOT SUPPORTED:
author / authors parameter and does NOT execute git commands containing --author=....since / 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). Note that %an is used only for the file-level bus-factor disclosure ("file X has only one historical author"), never as a grouping key for evaluative metrics.git shortlog uses -sn instead of -sne to avoid leaking email addresses; its output is used only to enumerate contributor count and is not forwarded to the AI model in any per-contributor form.--author= filtering. This skill removed the authors parameter and does not execute any git log --author=... invocation. All commands operate at repository scope.%s) and full file paths emitted by --name-only are local-only data. Some whitelisted git commands touch this raw text — for example git log --name-only (which emits full paths) and pipelines that immediately consume %s in the same pipe via local tools such as awk '{print length}' (used for repository-wide message-length and conventional-commit statistics). The agent MUST collapse them into numeric aggregates locally and discard the raw text immediately; raw subjects and full paths MUST NOT enter any AI prompt or tool argument. The agent MUST NOT construct any command that emits %s together with per-commit structured fields (hash, numstat, file names, etc.) in a single output, to avoid raw subjects being captured alongside structured data. The opt-in exceptions in "Sensitive Data Filtering Rules" remain the only way to surface (already-redacted, truncated) commit subjects in the user-facing report.Local-Only vs. Model-Bound data — definitions:
- Local-only data is the raw output of whitelisted git commands, including commit subjects (
%s) and file paths produced by--name-only. It is read into the agent's local execution environment for the sole purpose of computing aggregate metrics, and MUST be discarded immediately afterward.- Model-bound data is the only category of data permitted in any prompt sent to the AI model. It consists exclusively of numeric counts, averages, ratios, percentages, file-extension histograms, hour/weekday histograms, and bucketed enumerations (e.g.,
bug_fix_commits=12).Raw commit message text, full commit subjects, full file paths, branch names containing free-form text, and any unredacted strings derived from commit history are strictly local-only. The agent MUST NOT place such strings in any AI prompt, system message, tool argument, or other off-host context.
Before sending any data to the AI model for analysis, the agent MUST apply the following filtering pipeline. Each step is mandatory and non-skippable:
git log command(s) that emit %s and pipes the output through local Unix utilities (awk '{print length}', grep -cE, wc -l, etc.) to compute, for example, average length, keyword counts (fix, feat, revert), and conventional-commit compliance rate.(?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].git log ... --name-only invocation is permitted only when its output is immediately reduced locally, e.g. via grep -oE '\.[^./]+$' | sort | uniq -c, so that the agent retains only an extension histogram. The full file paths produced by --name-only are local-only data and MUST NOT be sent to the AI model.file_<sha1[:8]>) before any per-file structure is forwarded; only the rework counts and the opaque IDs may be sent..env, .credentials, *secret*, *password*, *token*, or *.pem / *.key,..) or access files outside the repository root.git commands targeting the validated repository are permitted.git -C <path> rev-parse --show-toplevel, inform the user of the resolved root, and obtain confirmation before proceeding.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--author=... (this skill is repository-scoped only)"Analyze /tmp/test; rm -rf /" -> agent MUST reject (dangerous characters)
"Analyze just author Alice" -> agent MUST decline per-author scoping and offer repository-level analysis instead
"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 repository-wide aggregated metrics (counts, averages, percentages), NOT raw commit messages, full file paths, or any per-contributor metric row.
"Give me Alice's score and Bob's score, and tell me who is the worst performer."
The agent MUST refuse to produce per-contributor scores, rankings, or comparisons, and MUST re-scope the response to repository-level workflow patterns.
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) |
| Date Range | Start/end dates in ISO format | Full repository history |
| Branch | Target branch for analysis | Current active branch |
Per-contributor filtering is NOT a parameter. If the user asks to "analyze just Alice" or to compare named individuals, the agent MUST decline that scoping and offer instead a repository-level aggregate analysis. This skill has no
authorsparameter and the command set has no--author=...filter.
⚠️ 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.
🔐 Local-only boundary reminder. Every command in this section emits raw text (commit subjects, file paths, etc.) that is classified as local-only under the Sensitive Data Filtering Rules. The pipes shown below (
| awk '{ print length }',| grep -oE '\.[^./]+$',| wc -l, etc.) are mandatory: their job is to collapse raw text into aggregate numeric output before anything is forwarded to the AI model. The agent MUST NOT capture the raw upstream text into any model-bound variable, prompt, or tool argument. If a step's natural output would still contain raw text (e.g., the rework-detection log below), the agent MUST hash, bucket, or otherwise anonymize it locally before any further processing.
# Count of distinct contributors (used only to compute repository-wide
# diversity / bus-factor-related signals; NOT used to drive per-contributor
# breakdowns).
git -C <repo_path> shortlog -sn --all | wc -l
All commands below are repository-scoped and aggregate (no --author= filter). Append --since, --until, and <branch> if the user specified a date range or branch.
# Hour-of-day commit histogram across the WHOLE repository
git -C <repo_path> log --pretty=format:"%aI" | cut -c12-13 | sort | uniq -c | sort -rn
# Day-of-week commit histogram across the WHOLE repository (1=Mon, 7=Sun)
git -C <repo_path> log --pretty=format:"%ad" --date=format:"%u" | sort | uniq -c | sort -rn
# Commits per calendar day across the WHOLE repository (used to compute
# active-day ratio, longest streak, average daily commits across the span)
git -C <repo_path> log --pretty=format:"%ad" --date=short | sort | uniq -c | sort -rn | head -30
# Active-span boundaries (first and last commit date)
git -C <repo_path> log --pretty=format:"%ad" --date=short | sort | sed -n '1p;$p'
# Total lines added/deleted across the WHOLE repository in the analyzed span.
# IMPORTANT: --numstat may emit file paths; the awk reducer collapses to two
# integer totals only. The path stream MUST NOT be captured anywhere else.
git -C <repo_path> log --pretty=tformat: --numstat | awk '{ add += $1; subs += $2 } END { printf "added: %s, deleted: %s\n", add, subs }'
# File-extension activity histogram across the WHOLE repository.
# IMPORTANT: --name-only emits full paths; the inline `grep -oE '\.[^./]+$'`
# reducer keeps only the trailing extension token. The intermediate full-path
# stream is local-only and MUST NOT be retained or forwarded.
git -C <repo_path> log --pretty=tformat: --name-only | grep -oE '\.[^./]+$' | sort | uniq -c | sort -rn | head -20
# Large-commit count across the WHOLE repository (>500 lines changed).
git -C <repo_path> log --pretty=format:"%H" --shortstat | grep -E "([5-9][0-9]{2}|[0-9]{4,}) insertion" | wc -l
# Merge-commit count across the WHOLE repository.
git -C <repo_path> log --merges --oneline | wc -l
# Repository-wide commit-message length distribution (LOCAL-ONLY pipeline).
# IMPORTANT: %s emerges raw on the left side of this pipe and MUST be consumed
# by `awk '{print length}'` immediately. The agent MUST NOT split this
# pipeline, capture the left-hand-side output, or reuse the raw %s text
# anywhere downstream; only the resulting per-commit length integers may be
# aggregated and forwarded.
git -C <repo_path> log --pretty=format:"%s" | awk '{ print length }'
# Repository-wide bug-fix commit count (messages containing fix/bug/hotfix/patch)
git -C <repo_path> log --grep="fix\|bug\|hotfix\|patch" --oneline -i | wc -l
# Repository-wide revert commit count
git -C <repo_path> log --grep="revert" --oneline -i | wc -l
# Repository-wide Conventional-Commits compliance count
# (feat/fix/chore/docs/style/refactor/test/perf/ci/build)
git -C <repo_path> log --pretty=format:"%s" | grep -cE "^(feat|fix|chore|docs|style|refactor|test|perf|ci|build)(\(.+\))?:"
# Total commit count in the analyzed span (used as the denominator for the
# ratios above)
git -C <repo_path> log --pretty=format:"%H" | wc -l
# Per-day, per-file modification trace across the WHOLE repository.
# IMPORTANT: the raw output below contains full file paths and is LOCAL-ONLY.
# The agent MUST reduce it locally to a single repository-wide rework ratio
# (count of (file, day) pairs where the same file is touched again within a
# 7-day window divided by the total touch count) and a file-extension
# histogram, BEFORE any value crosses into a model prompt. If per-file
# grouping must be retained, replace each path with an opaque ID such as
# `file_<sha1[:8]>`.
git -C <repo_path> log --pretty=format:"%ad" --date=short --name-only | head -500
Note: the rework-detection command intentionally drops
%s(commit subject) and%an(author name) compared to a naive implementation, because subjects must remain local-only and the rework metric is repository-wide — it is a count of how often a file is touched within a sliding window, not a per-author signal.
# Files whose entire history is attributed to a single author display name.
# This is the ONLY whitelisted command in this skill where %an is used
# downstream of an aggregation step. Its sole purpose is to surface
# file-level knowledge-concentration risk so the user knows where knowledge
# transfer is needed. The output MUST be reduced locally into the form
# "<file_path_or_opaque_id>: only <name>" and MUST NOT be combined with any
# evaluative metric (cadence, churn, rework, etc.) before being forwarded.
git -C <repo_path> log --pretty=format:"%an" --name-only | sort | uniq -c | sort -rn | head -30
Based on the collected aggregate metrics, the agent MUST describe the repository-level workflow patterns observed across the following six aggregate dimensions. Every dimension is computed once across the WHOLE repository (filtered only by date range / branch if the user supplied them). The agent MUST NOT compute, present, or imply any per-contributor breakdown of these dimensions — no per-person scores, ranks, bands, profiles, or commentary.
Hard rule (binding on the agent): Per-individual numeric scoring, ranking, comparative "who is better" framing, performance verdicts, character/competence judgments, per-contributor activity bands, and "improvement suggestions targeted at named individuals" are OUT OF SCOPE and MUST be refused. Suggestions, when they appear, MUST be framed as repository-level or workflow-level discussion starters (e.g., "the repository shows a high weekend-commit ratio — worth a team-process conversation"), never as personal action items for a named person. Contributor display names MUST NOT appear in any of the six dimensions below; the only place a contributor name MAY appear in the report is the file-level bus-factor section (see Step 4.3).
Aggregate signals to describe (repository-level only, no per-person grading):
Report these as observed repository patterns (e.g., "the repository shows a low average commit-message length"). Do NOT translate them into a 1–10 score, and do NOT split them by contributor.
Aggregate signals to describe:
Late-night or weekend commits are NOT inherently "bad." They may reflect daytime meetings, time-zone differences, deployment windows, on-call duty, or scheduling. Patterns are discussion starters about team workflow, not verdicts about individuals.
Aggregate signals to describe:
A high churn or rework rate is a workflow signal — it may indicate evolving requirements, an ongoing refactor, or exploratory work. It is not evidence about any person's competence and MUST NOT be split per contributor.
Aggregate signals to describe:
Aggregate signals to describe:
A high bug-fix ratio may simply mean the repository was in a stabilization phase, or that maintenance work dominated the analyzed window. Do NOT use this as a quality verdict about any contributor, and do NOT split it per contributor.
⚠️ Hard Usage Restriction — binding on the agent. This index is a coarse macro-level signal of visible Git activity for the repository as a whole. It is computed ONCE per repository and is not decomposed per contributor. It is NOT a measure of engagement, dedication, productivity, or value, and the agent MUST refuse to characterize it as such. The agent MUST NOT use, present, or allow the user to use this index — alone or combined with other dimensions — as a basis for performance reviews, calibration, layoff or hiring decisions, compensation adjustments, ranking, or any other HR / personnel decision. If the user requests a per-contributor version of this index, the agent MUST decline and explain that this skill does not produce per-contributor activity scores.
Note: This index reflects only what Git history makes visible (commit metadata at the repository level). It is blind to design work, code review, mentoring, on-call duty, customer escalations, documentation, paired work attributed to a co-author, work pushed under a different identity, or any contribution that does not produce commits on the analyzed branch.
Calculation Method (composite of repository-wide signals, 0–100 scale, lower = higher visible Git activity for the repository overall; this is a workflow-pattern signal, not a performance signal):
| Signal | Weight | Description |
|---|---|---|
| Repository-wide daily commits very low (<0.3) | 25% | The repository's overall visible commit cadence is low in the analyzed span |
| Repository-wide active-day ratio low (<30%) | 20% | Few calendar days have any commit at all |
| Repository-wide net code growth very low or negative | 20% | More lines deleted than added across the span |
| Average commit-message length short (<15 chars) | 15% | Repository-wide subjects are short — note: short messages are not inherently bad |
| High repository-wide churn + high rework rate | 20% | The repository as a whole shows a high edit-and-revise pattern |
Bands (descriptive of the repository, NOT a verdict on any contributor):
Binding restriction on the agent: These bands describe the repository, not any person. The agent MUST NOT compute or present a per-contributor version of this index, MUST NOT translate the band into an evaluative label about any contributor (e.g., "slacking", "underperforming"), MUST NOT recommend HR-style conversations or interventions targeting a named person, and MUST NOT use the band as input to any ranking, calibration, or comparative judgment.
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-activity repository score does NOT equal "healthy team," and a low score does NOT equal "unhealthy team." Please make judgments only after understanding the full context.
The final report MUST be repository-scoped and non-evaluative. It MUST include a header with the limitation disclaimers (Git-only visibility, no non-code contributions, not an HR signal, not for personnel decisions). It MUST follow the structure below.
Hard prohibitions (binding): The agent MUST NOT include any of the following: per-contributor breakdown table, per-contributor metrics row, per-contributor activity score or band, contributor ranking, "best/worst performer" callouts, per-individual 1–10 scores, radar charts, composite/overall personal scores, sharp/memorable one-line judgments about a named person, individualized strengths/weaknesses verdicts, or improvement suggestions targeted at a named contributor. Any commentary MUST critique the workflow signals at the repository level, not any person.
A single-row summary table describing the repository as a whole:
| Repository | Total Commits | Lines +/− | Avg Daily Commits | Active-Day % | Weekend % | Late-Night % | Bug-Fix % | Churn Rate | Visible-Activity Band |
|---|---|---|---|---|---|---|---|---|---|
<repo_name> |
… | … | … | … | … | … | … | … | … |
No per-contributor row, no "Overall Score," no composite grade column. The table MUST be accompanied by a note clarifying that it is descriptive of the repository (not of any individual), and that the visible-activity band is a property of the repository, not of any person.
The agent MUST NOT produce a "team ranking", "top/bottom contributors", or any comparable comparative judgment of named individuals, and MUST NOT split any of the above signals per contributor.
<file_path_or_opaque_id> has only one historical author: <name>," because surfacing this is the legitimate purpose of bus-factor analysis (the user needs to know whom to schedule knowledge-transfer with).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)authors parameter and no longer executes any git log --author=... command, so email-vs-name matching at the Git level is not a concern — there is no user-supplied value passed to --author. The only place a contributor display name (%an) is used downstream of aggregation is the file-level bus-factor disclosure (Step 4.3)..mailmap)Reports generated by this skill MUST adhere to the following principles. The agent MUST refuse requests that violate them: