How I Distilled My Coding DNA from 694 Git Commits into an AI‑Powered Coding Twin

Problem Statement

When prompting Claude to generate a user‑list page, the output used snake_case, generic comments, and placed API calls inside the component. The model lacked the developer’s coding DNA (variable naming, comment style, layering).

Distilling Coding DNA

Data Collection

Git auto‑collection: recent 50 commits via git log --stat -50, commit messages via git log --format="%H|%ai|%s%n%b" -50, file‑change frequency via

git log --pretty=format: --name-only -50 | sort | uniq -c | sort -rn

. Extracts technology preferences, naming, indentation, comment fingerprints, layering habits, commit granularity, hot files.

Project documentation: scans docs/, README, design docs with scripts/collect-docs.sh.

Personal reflection: structured questionnaire records satisfied decisions, biggest pitfalls, three coding concerns, and review focus.

Git alone recovers ~60 % of style; adding docs and reflection raises fidelity.

Multi‑Dimensional Analysis

Expression layer: commit language distribution, naming style, comment purpose (WHY vs WHAT), semicolon/quote/indentation usage.

Architecture layer: organization of pages/, api/, utils/, components/; independence of API layer; reuse strategy.

Decision layer: technology‑selection principles, refactor triggers, debugging flow (console → network → source).

Anti‑pattern layer: hard‑coded domains, reinventing wheels, vague commits, recorded deviations such as emergency fixes with var or comments that only state WHAT.

Statistics from 694 commits across 18 projects: 86 % Chinese, 14 % English; 85 % follow Conventional Commits (feat > fix > refactor > chore > docs). These numbers are baked into the skill.

Triple‑Validation

Each rule must satisfy three criteria to receive a ⭐⭐⭐ label:

Appears in ≥ 2 projects.

Can predict a new scenario.

Has a concrete example.

Levels: ⭐⭐⭐ (must obey), ⭐⭐ (recommended), ⭐ (optional).

Skill Engineering

File Structure (based on frontend‑team‑toolkit/skill‑engineering )

SKILL.md

(517 lines)

references/output-contract.md

references/examples.md

(4 scenarios)

references/dev-patterns.md

agent.md

CHANGELOG.md

.skill-meta.json

(v2.1.1)

Evaluation assets: evals/evals.json, evals/trajectory-evals.json, test-prompts.json (7 prompts), results.tsv Evolution assets: skill-issues.jsonl, evolution-hypothesis.json Scripts: scripts/darwin-eval.sh (8‑dimensional scoring), scripts/incremental-update.sh (diff, append, backup), scripts/collect-docs.sh,

scripts/validate-output.sh

Maturity Stages

Phase 0 Draft → Phase 1 Baseline → Phase 2 Iterate → Phase 3 Stable. Current state: stable; Baseline 7/7 passed; Darwin evaluation 100/100 (S‑grade); still iterating in Phase 2.

Baseline Evaluation (7 scenarios)

Write user‑list page – happy‑path – output matches Output Contract – P0 – passed.

“Help me write a page” with missing input – missing‑input – prompts for missing info, no fabrication – P0 – passed.

Code review – capability – points out issues and suggests improved code – P0 – passed.

Requirement decomposition – capability – splits into independent tasks – P1 – passed.

Technology selection – capability – compares options and gives recommendation – P1 – passed.

Write polling mechanism – capability – outputs standard implementation – P2 – passed.

Update after API change – capability – incremental modification, no full regeneration – P2 – passed.

Regression 2/2 (100 %), Capability 5/5 (100 %).

Darwin Evaluation (8 dimensions)

Expression consistency – 15/15 – triple‑validation complete.

Architecture soundness – 15/15 – layering, reuse, independent API layer.

Decision accuracy – 10/10 – selection and refactor triggers.

Anti‑pattern coverage – 10/10 – includes critic’s perspective.

Output contract – 15/15 – four mandatory deliverables.

User‑feedback satisfaction – 10/10 – correction layer built.

Test pass rate – 15/15 – all 7 tests passed.

Iteration frequency – 10/10 – CHANGELOG continuously updated.

Total – 100/100 (S‑grade)

v2.1 Enhancements

Correction layer – records user feedback such as “variables must be camelCase” and applies it instantly to subsequent outputs.

Triple‑validation – prioritizes rules based on ⭐⭐⭐/⭐⭐/⭐ levels during iteration.

Critic’s perspective – logs real deviations (e.g., emergency var usage, comments that only state WHAT).

Darwin evaluation – automated 8‑dimensional scoring via scripts/darwin-eval.sh.

Incremental update – scripts/incremental-update.sh performs diff, appends new material, backs up to avoid full overwrite.

Multi‑source collection – combines Git, project docs, and planned IM and code‑review records.

Usage Scenarios

Code Generation

Prompt “Twin, write a user‑list page”. Output uses camelCase variables, kebab-case filenames, places API call in api/user.js, reuses existing pagination, comments explain WHY, and follows the Output Contract (Summary, Main Output, Assumptions & Gaps, Next Steps).

Code Review

Input

var userList = axios.get('/api/user').then(res => this.data = res)

. The twin suggests replacing var with const or let, extracting the call to the api/ layer, avoiding hard‑coded domains, and provides a corrected snippet.

Requirement Decomposition

Adding a user‑management module is split into five parts (list, detail, edit, API layer, routing). Each part includes input/output definitions, reusable code snippets, effort estimate, risk points, and priority.

Technology Selection

Comparing Vue 2 + ECharts, Vue 3 + D3, and React + AntV on performance, maintenance cost, and team familiarity. The recommendation favors the Vue 2 stack for a Vue 2‑centric team, with explicit risk notes.

Correction in Action

When the AI outputs a PascalCase variable, stating “variables must be camelCase” records the rule in the Correction layer, rewrites the current output, and enforces camelCase for all future interactions.

Value Assessment

For individuals: makes personal coding habits explicit, provides predictable AI output via workflow and Output Contract, catches high‑risk changes through checkpoints, and closes the loop with Eval + Correction + Darwin.

For others: the skill structure can be copied to create personal twins; demonstrates how to turn personal ability into a reusable asset; Output Contract serves as a team delivery template.

For teams: unifies naming, layering, and review standards; personal habits become inheritable; reduces friction from style mismatches.

Methodology

Five Practical Steps

Identify business‑specific content (domains, API chains, domain rules, pitfalls).

Abstract into generic patterns (API‑doc driven, config‑driven, environment isolation).

Apply the skill-engineering template (evaluation, gatekeeping, versioning).

Combine Baseline, Darwin, and Correction into an evolution loop.

Reference colleague‑skill (Correction, incremental merge) and nuwa‑skill (triple‑validation, Darwin).

Principle Mapping

Capability vs Knowledge – style is a programming capability, not a domain encyclopedia.

Generic vs Specific – abstract generic first, then strip business details.

Professional vs Casual – use templates, evaluation, version control.

Reusable vs Personal – others can copy the structure and fill in their own DNA.

Evolvable vs Static – evaluation and correction mechanisms are mandatory.

Real vs Perfect – critic’s perspective records real deviations.

References

colleague‑skill – persona architecture, correction layer, incremental merge.

nuwa‑skill – six‑channel research, triple‑validation, critic’s perspective, Darwin evolution.

awesome‑persona‑skills – collection of persona‑distillation methodologies.