frame-data-consistency-review - SKILL.md Agent Skill

name: frame-data-consistency-review description: "Review the V6 frame-data exports for a frame type (assembly substitution formulas, joints, annotations, bags, and attribute selections) against each other and against the product manuals, to surface likely setup mistakes and produce a per-frame-type 'things to confirm' checklist. Use when a user has per-frame-type export folders from the GET macros and wants to find inconsistencies (the 'most frames right, a few wrong' pattern), reconcile them with manual evidence, and decide what a human should verify. This is the lighter manual+V6 data-review pass; it is NOT the manifest/BOM-run baseline pipeline (see product-series-review-pipeline)."

Frame Data Consistency Review

Overview

Use this skill to turn a frame type's V6 export set into a concrete, reviewer-grade list of things to confirm. The job is to catch the common failure mode in V6 resource setup: most frames in a type are set up correctly, and a few are quietly wrong — a missing bag, a substitution formula that differs from its siblings, an annotation worded differently, an attribute defaulted instead of set. You find those outliers by comparing frames against each other (internal consistency) and against the manuals (product truth).

This skill is deliberately narrower than product-series-review-pipeline. It does not build manifests, run quote/BOM sweeps, or set baselines. It reviews the already-exported per-frame-type data and produces a confirm-list.

Use the sibling skills for the detailed work:

Use manual-labour-analysis to read the manuals and produce source-backed evidence/checklists. This skill consumes that evidence as the product-truth side of the comparison.
Use saxbasic-v6-macro-local if an export looks wrong because the GET macro is extracting it wrong (fix the macro before trusting the data).

Core Rules

Treat the manuals as product truth. Treat the V6 exports as evidence of current system behaviour, not proof that the behaviour is correct.
Keep three things separate at all times: what the export shows, what the manual says, and your conclusion.
Default to the consistency signal: within a frame type (or a tighter family), the value/formula/annotation/bag that most frames share is the likely-correct one; the minority that differ are the likely mistakes — but say "confirm", not "wrong", unless the manual settles it.
Every finding names the exact frame code(s), the exact attribute/bag/assembly/annotation, the observed value, and the expected value or sibling value. No generic lines.
Cite both sides: the export location (file + row/sheet/cell or frame_type_ref + attr_code) and, when used, the manual (Source: <PDF>, <section/page>).
Do not invent expected values. If neither the sibling consensus nor the manual establishes the right answer, list it as an open item to confirm, not a defect.
One review output per frame type. Frame types are independent; do not blend findings across types.
If an export is internally incoherent in a way that looks like an extraction bug (not a data error), flag it as a macro issue and stop trusting that column until the macro is checked.

Inputs

Per-frame-type export set, organized as <folder>/<FrameTypeCode>/ (the GET macros write here). Typical contents:

*_Formula_And_Joints_Extraction.xlsx — per-frame assembly substitution formulas + joints (from get_set_sub_form_assy).
*_ANNOS_GET_EXT.csv — per-frame annotations (name, style, position formulas, tokens).
*_BAGS_GET.xlsx — per-frame bags in columnar layout, formulas in cell notes.
ATTRIBUTE_DETAILS.csv + ATTRIBUTE_SUMMARY.csv — per-frame and per-type attribute selections.
Manual evidence for the series (from manual-labour-analysis) and/or the manuals themselves.

Read references/export-inputs.md for what each file and key column means.

Recommended Workflow

1. Assemble the per-type record

For one frame type, gather every export listed above from its folder.
Build a per-frame view: for each frame code, its attribute selections, substitution formulas (by assembly/position), annotations, and bags.
Note the frame count and which frames are present in each export (a frame missing from one export but present in others is itself a signal).

2. Run internal-consistency (odd-one-out) checks

Find where most frames of the type agree and a minority diverge. The ATTRIBUTE_SUMMARY.csv is built for this — frame_count, observed_value_count, and observed_values per attribute tell you directly where a type is split.

Read references/inconsistency-heuristics.md for the specific patterns (majority value, sibling-formula divergence, presence/absence, naming drift, default-vs-set, handing symmetry).

3. Cross-check against the manuals

Compare the type's observed setup to what the manual specifies: components, hardware, seals, processing, configuration rules, handing.
Flag: manual specifies something the export doesn't reflect; export has something the manual doesn't justify; values that disagree.
Use manual evidence to resolve outliers from step 2 (is the majority actually right, or is the whole type wrong together?).

4. Classify each finding

Mark every finding as one of:

internal-inconsistency — frames of the same type disagree where they should match
manual-mismatch — export disagrees with the manual
missing-in-export — manual/sibling implies it should be present but it isn't
extraction-suspect — looks like the GET macro mis-read it, not a data error
unproven — looks odd but neither siblings nor manual settle it

5. Emit the per-type review MD

Produce one <FrameTypeCode>-review.md per type folder. Use concrete Check ... lines grouped by area, each with the exact target, the observed vs expected, the classification, and citations. End with a Top Likely Misses block.

Read references/review-output-format.md for the exact shape and example lines. The reviewer-grade checklist style from manual-labour-analysis applies here too.

Running at scale

Frame types are independent, so this review parallelizes cleanly: one reviewer per <FrameTypeCode>/ folder, each producing that type's MD. When run that way, keep each type's evidence and output self-contained; do not let one type's consensus leak into another's.

Output Expectations

For each frame type:

A per-type review MD with concrete, cited confirm items grouped by area (attributes, substitution formulas, joints, annotations, bags).
A Top Likely Misses section with the highest-risk exact items.
Any extraction-suspect items called out separately so the macro can be checked before trusting that data.

Anti-Patterns

Calling the minority "wrong" when neither siblings nor the manual establish the correct value — say "confirm".
Generic lines like "check the bags" instead of "frame X is missing bag REVEALS that the other 7 frames in this type all have".
Blending findings across frame types into one sheet.
Trusting an export column that is internally incoherent in a way that smells like a macro bug.
Mixing "the manual says" and "I think" in one statement.
Burying the highest-risk misses in a long flat list instead of surfacing them.

References

references/export-inputs.md — what each export file/column means.
references/inconsistency-heuristics.md — the odd-one-out patterns and how to use the summary columns.
references/review-output-format.md — the per-type review MD shape and example lines.