Coding Fingerprint Wizard

Create a reusable coding fingerprint from example projects.

The goal is not to infer formatter trivia or generic "clean code" advice. The goal is to identify the decisions that make a person's work recognisable: how they shape modules and repositories, where they validate, what they test, what they document, how they use frameworks, what they refuse to abstract, and which trade-offs they make repeatedly.

The output is a coding-fingerprint-[name]/SKILL.md file that another agent can apply when planning, writing, reviewing, or refactoring code.

When To Apply

Use this skill when the user wants to capture a person's:

coding style
engineering principles
repo-shaping preferences
architectural tendencies
testing and validation habits
abstraction thresholds

Do not use it for superficial style analysis, formatter imitation, or one-project hero worship.

Operating Model

Treat this as a strict diverge-converge workflow:

Prepare: define the sample set and its caveats
Discover: gather project-level evidence in parallel
Define: converge on durable cross-project patterns
Develop: challenge the draft fingerprint for overfitting and weak inference
Deliver: generate the reusable fingerprint skill
Validate: check whether another agent can actually use it

Do not collapse early. Breadth comes before synthesis, and challenge comes before canonisation.

Coordinator Default

The top-level agent is a coordinator.

Spawn sub-agents for detailed analysis.
Run parallel sub-agents where the work is independent.
Use references/analysis-worksheet.md as the source of truth for artefact contracts.
Decide when the evidence is broad enough to converge.
Resolve conflicts between worker outputs.

Do not let the coordinator do the full analysis itself unless it is reconciling disagreements, repairing a failed handoff, or validating the final result.

Sample Quality

Prefer 2-5 samples with real authorship signal.

Strong samples usually have:

meaningful code rather than generated scaffolding
tests, docs, commit history, or review context
similar era and responsibility level
code the subject would still endorse

Weak samples usually include:

heavily templated repositories
one-off experiments with little behavioural signal
team code with unclear authorship
repos dominated by framework defaults

If the sample set mixes very different contexts, record that explicitly and treat context-specific patterns as weaker evidence.

Read Order

Start with SKILL.md.
Read references/REFERENCE.md to choose the next file deliberately.
Read references/analysis-worksheet.md before creating or checking any _working/coding-fingerprint/ artefact.
Read references/fingerprint-template.md only when Phase 4 begins.
Read references/example-coding-fingerprint.md only if the output shape is unclear or you are calibrating the result.

Phase Gates

Phase 0: Prepare

Create the sample inventory before any synthesis work. Record scope, samples, evidence quality, and caveats in _working/coding-fingerprint/ using the worksheet contract.

Phase 1: Discover

Run sub-agents in parallel.

Default shape:

one worker per project for project-profile-<slug>.md
optional lens workers for testing, architecture, review style, or error handling when the projects are large

The goal here is breadth. Collect evidence first; do not collapse to principles early.

Phase 2: Define

Run a synthesis worker after the project profiles exist.

Only promote a pattern if it appears across projects or is supported by strong surrounding evidence. Separate:

durable fingerprint traits
context-specific choices
contradictions
open questions

Treat repo-shaping as first-class output. A good fingerprint should help another agent choose module boundaries, repo layout, contract surfaces, CI defaults, and dependency posture.

Phase 3: Develop

Stress-test the draft fingerprint before it becomes canonical.

At minimum, challenge:

overfitting to one project
avoidances and things the author consistently does not do
reproducibility across independent analysers
predictive power on plausible implementation choices

Phase 4: Deliver

Generate the final fingerprint skill using references/fingerprint-template.md.

Save it as:

coding-fingerprint-[name]/
└── SKILL.md

Phase 5: Validate

Use a fresh sub-agent with access only to the generated fingerprint and a small representative task. Compare its choices back to the source projects.

Refine the fingerprint if it sounds generic, contradicts evidence, overfits one codebase, captures style without principles, or cannot be applied reliably by another agent.

Signal Quality

Prefer high-signal patterns over surface polish.

Strong signals:

where validation lives
how boundaries are drawn
how repositories are split once boundaries appear
what gets abstracted versus duplicated
what gets generated versus handwritten
how tests express intent
preferred error semantics
docs, CI, and drift-check habits around important contracts
naming choices that reveal domain modelling

Weak signals:

formatter output
language defaults with no visible choice
isolated clever code
framework boilerplate

Failure Modes

Avoid:

reducing the fingerprint to style-guide cliches
treating one impressive project as the whole person
confusing ecosystem constraints with personal preference
inferring principles without citing evidence
producing a fingerprint that another agent cannot operationalise
skipping the challenge phase because the synthesis looks right

Quality Bar

The final fingerprint is good only if it helps another agent answer questions like:

How would this person split the module?
How would this person shape the repository or workspace?
Where would they validate input?
What would they test first?
What docs, schemas, or CI checks would they expect to exist?
Which abstraction would they reject as premature?
What code smell would they flag immediately?

If the skill cannot answer those questions, the fingerprint is still too vague.

Additional Resources

Reference router: references/REFERENCE.md
Artefact contracts and worker deliverables: references/analysis-worksheet.md
Final output template: references/fingerprint-template.md
Worked example: references/example-coding-fingerprint.md

Related Skills

Use working-docs when you need scratch notes outside this workflow
Use test-driven-development when validating the generated fingerprint against an implementation task

coding-fingerprint-wizard