AI Skill Report Card
Auditing Tauri App Architecture
Quick Start14 / 15
Given a codebase (e.g. a Tauri app: src-tauri/src/*.rs + src/*.tsx), produce a brief with this exact spine:
- What it is — one paragraph, the product framed as its distinctive idea, not its tech stack.
- Shape of the system — process/data-flow diagram in prose + a dependency table (crate/package → one-line purpose).
- The part worth arguing about — the single design decision that makes the project interesting, quoted from source (types, not summaries).
- IPC/API surface — full enumeration table: every entry point, what it does, wired/unreferenced/dead.
- Defects — each one: severity tag, exact file:line, minimal code excerpt, why it matters in this domain specifically, one-line fix.
- Smaller things worth knowing — real but non-urgent observations (path fragility, serialization waste, hash stability, etc.).
- Provenance — state plainly what was read vs. run, and any corroborating artifact (e.g. a data file that confirms the static analysis).
Output is a report, not a patch. Do not fix anything — trace and name.
Recommendation▾
Add a second, richer example with concrete before/after defect output (e.g., actual severity tag, file:line, snippet) to fully satisfy 'concrete input/output pairs' rather than prose summaries.
Workflow13 / 15
Progress:
- Map the process topology: how many runtimes, how do they communicate, who owns state, where does state persist vs. vanish
- Identify the "distinctive idea" — the one abstraction the whole app exists to serve — and pull its actual type definitions verbatim
- Enumerate every command/route/handler exhaustively; cross-reference registration against call sites to classify wired/unreferenced/dead
- Grep for the failure-prone patterns below across every stream/subprocess/IPC handler; diff similar handlers against each other to find the one that's correct and the ones that aren't
- For each defect: pin exact line numbers, quote the minimal offending snippet, state the concrete failure mode (not "this could be a bug" — trace to what actually happens), give a one-line fix pointing at the working reference implementation if one exists in the same file
- Note structural gaps where two subsystems that look connected never actually call each other (search for the exact bridging function that's registered but never invoked)
- Collect smaller non-urgent findings (fragile paths, unstable hash types, oversized single components, waste in serialization)
- Write provenance: what was statically read, what would need a build/run to confirm, what independent artifact (log, cache file, data dump) corroborates the static findings
Recommendation▾
Consider a minimal template/table skeleton (e.g., markdown table headers for the IPC surface enumeration) to make the report spine more directly actionable.
Examples16 / 20
Example 1: Input: A Tauri app with a Rust core shelling out to two CLI backends and a React frontend with a custom "reservoir" state concept. Output: Report identifies (a) a cancellation bug where one of three near-identical stream handlers forgets to register its PID — found by diffing the three handlers against each other; (b) a UTF-8 corruption bug from fixed-size byte-buffer reads, worse than usual because the domain's actual content is multi-byte symbols; (c) two parallel subsystems (library metadata vs. chat-time extraction) that share a bridging function which is registered but never called, verified against a zeroed-out on-disk cache file.
Example 2: Input: A single well-behaved CRUD handler with no counterpart to diff against. Output: Note it as correct/wired, move on — don't manufacture a defect where the diffing technique has nothing to compare against.
Recommendation▾
The skill is fairly Tauri/Rust-React specific — could briefly note how to generalize the method to other cross-language IPC systems for broader applicability.
Best Practices
- Quote types and code verbatim, don't paraphrase them. A
type ContextBlock = {...}shown raw carries more evidential weight than a description of it. - Diff sibling implementations. When three handlers do structurally the same job (three stream spawners, three CRUD triggers), the fastest way to find the broken one is lining them up — the correct ones become the fix.
- Classify every surface entry, not a sample. "23 commands, 13 used" is a finding; "here are some interesting commands" is not.
- Distinguish read from run. Never claim a bug "occurs" from static reading alone — say what the code does, and let runtime claims be explicitly flagged as unverified unless corroborated by an artifact (log, cache, dump).
- Lead defects with severity and a line reference, not narrative build-up.
HIGH — lib.rs:952before the explanation. - Ask the interesting adversarial question of the design, don't just praise it — e.g. "does this typed distinction actually change downstream behavior, or is it a label?"
- Give the fix as a pointer, not a diff. "Copy the Kosmos handler's insert call" is more useful in a brief than rewritten code.
Common Pitfalls
- Don't summarize file-by-file — organize by finding, not by source layout.
- Don't call something a "bug" without a concrete failure path (input → what breaks → observable symptom).
- Don't treat every deviation from convention as a defect — relative paths and
DefaultHasherare structural risks ("not bugs yet"), not the same tier as silent cancellation failure. - Don't skip the count. "10 of 23 commands unreferenced" is more useful than naming three examples.
- Don't claim to have run something you only read. If a build wasn't exercised, say so explicitly and say why (missing toolchain, etc.).
- Don't let the single most interesting design idea crowd out the mundane structural audit (state persistence asymmetry, component size, path resolution) — both belong in the brief.