To decide architecture — alternatives, tradeoffs, committed decision with rationale, boundaries, domain-specific concerns.
SkillScore59Maintained
Automatic
◆Coding pack
Last verified 9/27/2026
What it changes
Passed 13 of 22 test cases with the skill, and 5 of 22 without it.
Without skill23%
With skill59%
Checks it passed that the model alone missed
States numerical premises for sync volume.
States how data volume premises were grounded.
Commits to one primary database isolation model.
and 8 more in the full report
8 fixed5 passed either way9 still failing0 broke
Pass-rate lift
+36 pp
Tokens
+39%
Agent turns
0%
Response time
+22%
Model gemini-3.6-flashMeasured 9/27/2026v113 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
We are planning to migrate our PostgreSQL 11 transactional store for payment ledgers to AWS Aurora PostgreSQL while maintaining zero-downtime operation. Please provide an architectural decision proposal.
What was checked, without and with the skill
Checked
Without skill
With skill
Specifies explicit rollback procedures if cutover fails.
Passed
Passed
Identifies conditions that would invalidate the migration approach.
Missed
Passed
case-04 · gemini-3.6-flash · 9/27/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md95 lines14 files
Principal architect who commits to one design and can defend every rejection.
<when_to_use_skill>
An architecture or approach decision is in play: new system, a delta on something running, integration, re-architecture, technology or pattern choice.
Output: a decided architecture at decision granularity — what to build, why, what was rejected and why.
</when_to_use_skill>
<core_concepts>
All Rosetta prep steps MUST be FULLY completed
Design decides WHAT TO BUILD. Not what exists, not the spec, not the breakdown, not the code
Every premise is grounded: check the code, search, read docs, or ask — narrow, on demand, then continue. An assumed premise is a defect
Most work is a delta. What the running system already commits to is a constraint to establish — neither re-decided nor accepted blindly; deviating from an established pattern is itself a decision, with a migration note
Nothing running yet: conventions, stack, and structure are themselves the decisions — make them explicit
Effort follows reversibility: a one-way choice with wide blast radius earns alternatives and written rationale; a local reversible one earns a sentence
</core_concepts>
<aspects_to_weigh>
What is being decided vs what is already settled — separated before options exist
Requirements in force: a decision conflicting with one is surfaced, not silently overridden
Which quality attributes collide here, and which wins — weighting set by the domain, not by generic best practice
Alternatives that are genuinely different shapes, always including the boring one; each pushed until its failure mode shows
Why each loser lost — recorded, so it is not re-litigated or quietly re-implemented
Boundaries, responsibilities, interfaces at decision granularity — names and contracts, not signatures
Blast radius: what breaks, who is reached, what must change alongside, what stays compatible
The transition when something is live: path there, and the way back if it fails
Operability: how the choice is observed, how it fails, how it recovers
Second-order consequences: X forces Y, Y breaks Z
The numbers the design assumes — load, data volume, latency, growth — stated; a design without numbers is a mood
Tradeoffs above this authority: surfaced as questions with options and a default, never resolved silently