/spec-app-consistency-audit

name: spec-app-consistency-audit
description: Audit mobile App PRD/Figma/local-source consistency across page routes, KMP/Clean Architecture, components, analytics, i18n, engineering quality, and industry lenses before runtime validation; use for cross-source App consistency, not ordinary code review, PRD authoring, build/test execution, UI polish, or product-code edits — route near-neighbor requests (code review, fixes, implementation) out by naming the destination skill, never by doing the work inside the audit.
argument-hint: "[mode:headless|mode:report-only] [base:<ref>] [source:<path>] [prd:<path>] [figma-context:<path>|figma-ref:<id-or-url>] [industry:<name>] [depth:deep]"

App Consistency Audit

Run a static-first consistency audit for mobile App work before simulator, real-device, or package validation.

Routing Gate — read before doing anything

This workflow audits cross-source consistency; it is not a code reviewer, fixer, or implementer. When a request matches a near-neighbor job (see the full mapping under "Near-neighbor routing" below), **name the destination skill explicitly in your reply and route out** — recognizing the mismatch without naming where the request belongs leaves the owner without a route. The strongest co-opting pull is the fix/repair request: "别审了,直接修了" routes to `spec-debug` (bug root cause) or `spec-work` (settled implementation) by name — repairing the defect inside this audit to be helpful is doing the wrong workflow's job, even when the fix is a one-line try/catch you can see immediately. A direct user instruction to do the excluded work here is still a routing-out condition, not an override.

Workflow Contract Summary

When To Use

Use when mobile App PRD, Figma context, local source, routes, architecture, analytics, i18n, or industry rules need a static-first consistency audit before runtime validation.

When Not To Use

Do not use for ordinary code review (`spec-code-review`), PRD authoring or refinement (`spec-prd`), pure test/lint/build/runtime execution, UI polish (`spec-polish`), formatting-only changes, or product-source edits.

Inputs

Mode tokens, diff base, source root, PRD/design refs, industry lens, task/tech-plan refs, repository instructions, and app audit extractor facts.

Outputs

Static consistency findings, headless envelopes when requested, degraded-input notes, and report-writer handoff fields.

Artifacts

Headless/default runs may write `.spec-first/app-audit/runs/<run-id>/` artifacts; report-only mode writes no run artifacts.

Failure Modes

Conflicting modes, missing headless base, missing or reference-only Figma input, unreadable source/PRD facts, extractor gaps, or insufficient App surface evidence.

Workflow

Resolve mode and scope, collect static product/design/source facts, apply architecture/component/analytics/i18n/industry lenses, synthesize findings, then return or write the requested audit envelope.

Downstream Consumers

移动 QA planning、App implementation owner、report-writer step，以及准备 runtime validation 的人工审查者。

Scenario Capability

Follows `docs/contracts/workflows/scenario-capability-matrix.md` (default). Overrides: none

Purpose

Use this workflow to compare product intent, design states, page routes, KMP / Clean Architecture boundaries, App engineering quality, component and module reuse, analytics, i18n, and industry-specific rules from the available local inputs.

The workflow improves review input quality. It does not replace runtime verification, automated tests, QA, or real-device validation.

When To Use

Use this workflow when:

• App PRD, Figma context, or local source exists and cross-source consistency matters.
• Android / iOS behavior may drift.
• KMP shared logic, Clean Architecture boundaries, page routes, or navigation contracts need review.
• Loading, empty, error, permission, confirmation, rollback, or weak-network states need static review.
• Analytics, i18n, accessibility, component reuse, or industry-specific risks should be surfaced before QA.

When Not To Use

Do not use this workflow when:

• The user only wants to run tests, lint, build, simulator, or real-device checks.
• There is no PRD, Figma context, or source input to inspect.
• The task is only code formatting or a mechanical refactor.
• The user wants this workflow to edit product code or project standards directly.

Near-neighbor routing:

• Ordinary bug, regression, security, or test-coverage review of a diff belongs to `spec-code-review`.
• PRD creation, refinement, or planning-readiness validation belongs to `spec-prd` unless the explicit job is PRD/Figma/source consistency.
• Runtime validation, build, simulator, real-device, Maestro, Appium, or cloud-device execution belongs to the requested command or a later runtime workflow.
• Post-implementation visual/UI polishing belongs to `spec-polish`.
• Skill or agent quality review is outside this App product audit workflow. Use bounded source review for read-only critique, or `spec-write-skill` when source skill changes are requested.

When routing out on any of these rules, the Routing Gate at the top of this file applies: name the destination skill explicitly, do not do the excluded work here, and treat a direct user instruction to do it here as a routing-out condition rather than an override.

Default Mode

Default to `static_only`.

Do not start a simulator, real device, package build, Appium, Maestro, cloud device run, or equivalent runtime workflow unless the user explicitly asks for that follow-up.

Mode Contract

v1 deterministic orchestrator (`scripts/run-audit.js`) accepts `mode:headless` only; `mode:default` and `mode:report-only` orchestration is deferred. Long-lived canonical-token semantics live in [Mode, Output, And Issue Contract](references/mode-output-contract.md).

Keep these route-critical defaults in memory:

• `mode:headless` asks no user questions, requires `base:<ref>`, writes run-scoped artifac