Two related workflows for a locally-cloned codebase, in one skill. Documentation mode produces a single, comprehensive, verifiable architecture document primarily by reading files on disk (local-first) — use it whenever the user wants to understand, map, document, research, or onboard onto a codebase ("research this repo", "write up the architecture", "do an architecture deep dive", "document how this codebase works", "map the system design", "create an onboarding doc"). Modernization mode gener
SkillScore77Maintained
Automatic
◆Doc Ops pack
Last verified 8/2/2026
What it changes
Passed 15 of 19 test cases with the skill, and 6 of 19 without it.
Without skill32%
With skill77%
Checks it passed that the model alone missed
Selects a beachhead walking skeleton migration strategy.
Labels remote-sourced facts or remote metrics with an unverified tag.
Prohibits cutting phase branches from unmerged sibling phase branches.
and 9 more in the full report
10 fixed7 passed either way5 still failing0 broke
Pass-rate lift
+45 pp
Tokens
+516%
Agent turns
0%
Response time
-12%
Model gemini-3.6-flashMeasured 8/2/2026v117 of 22 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 10
Prompt
While auditing the codebase, we found that README.md claims the system uses PostgreSQL 12, but compose manifests configure PostgreSQL 15 and code drivers use features introduced in version 15. How should our architecture document present this conflict?
What was checked, without and with the skill
Checked
Without skill
With skill
Inspects the codebase to determine the true operational version when documentation disagrees with code.
Passed
Passed
Labels resolved discrepancies in the document with a resolved contradiction tag.
Missed
Passed
case-16 · gemini-3.6-flash · 8/2/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md831 lines3 files
Documentation & Modernization
Two complementary workflows for a repository the user already has checked out
locally, bundled as one skill:
Documentation mode — produce one definitive, cited architecture document
from the code on disk. Ideal for onboarding, system-design maps, or as the
evidence base for a modernization effort.
Modernization mode — turn that architecture into a phased, safety-laddered
plan to upgrade, migrate, or rewrite a legacy system.
Mode selection
If the user wants to understand, document, map, research, or onboard onto a
codebase, run Documentation mode.
If the user wants to modernize, migrate, upgrade, or rewrite a system, run
Modernization mode. Modernization mode is self-sufficient: if no
architecture document exists yet, it runs the Documentation mode workflow
first (in the same pass), then continues straight through to the plan.
When in doubt, produce the architecture document first — it is the audited
evidence base both modes rely on.
Documentation mode
Generate one definitive, cited architecture document for a repository the user
already has checked out locally. The goal is a writeup someone could hand to a
new engineer as their onboarding reference — broad enough to cover the whole
system, deep enough on the hard parts to be useful, and trustworthy because
every claim traces back to a file on disk.
Why local-first
Reading from the local checkout (not the GitHub API or the web) is the deliberate
default. It is faster, free, avoids rate limits, and — most importantly — it
describes the exact code in front of you rather than whatever main happens
to look like remotely. The one tradeoff is that remote-only facts (star counts,
full CI run history, sibling repos) aren't visible. That's fine: state those as
out-of-scope or mark them [UNVERIFIED] rather than guessing.