fusion-tea: Skill for Claude Code

Before executing this skill, read .agentic-mbse/claude.md in Claude Code or .agentic-mbse/codex.md in Codex. Resolve supporting paths from this skill’s installed directory; keep generated outputs in the project or a temporary directory. Read referenced skills from .agents/skills/<name>/SKILL.md when their guidance is needed.

Audit Models

Use the assigned scope and “Review Brief and Context Limits” in modeling_project/MODELING_PROCESS.md. For a focused question, read only the supplied entry sections and primary evidence within the brief’s budget; return missing evidence before expanding. Apply the broader checks below only to claims in scope. Save a short finding in the existing work record or requested evidence path; a separate report is useful for a substantive assessment.

Independently assess whether the model supports its promised outcomes and intended use. Run as a fresh non-author reviewer without inherited author conversation. For a substantive audit, save work/analysis/YYYYMMDD-HHMMSS_audit_{scope}.md and link it from the work item or epic.

Choose the Scope

• Work item audit: verify the spec outcomes, changed behavior, and affected dependencies/consumers. Read the plan's evidence and relevant design sections; expand where a finding requires it.
• Epic audit: verify epic success criteria, item audit evidence, dependency handoffs, and cross-item integration. Positive item audits do not establish the integrated outcome by themselves.
• Project audit: assess the requested broader system claims against project requirements, source evidence, and actual model coverage.

Use the already authorized scope or clarify what is to be assessed. State the examined revision, supported use, and evidence limits. A narrow audit must not read as certification of every parameter or engineering assumption.

Verify the Outcome

Read the four-view completion obligation and relevant architecture/pattern rules in modeling_project/MODELING_PROCESS.md, the applicable requirements and architectural decisions, and the implementation. Check the physical and behavioral relationships behind the calculations where they matter to the claim. Trace the affected claim through requirements, behavior, component occurrences/interfaces, analytical bindings, and verification evidence. Component ownership, interfaces, analytical bindings, and consumer interpretation must agree. Check that documented approximations still support the claim; an inventory of declarations does not establish this. When calculation wiring changes, inspect which occurrence each input resolves to and check that relevant public-input changes reach its consumers.