Platform Detector

Platform Detector

Purpose

Translate a fuzzy product idea or an unfamiliar repository into a concrete target-platform matrix the rest of the skill chain can plan against. Without this, security, testing, performance, accessibility, and store-policy choices drift.

Inputs

1. Read references/platform-matrix.md.
2. Collect inputs from init-project: stack fingerprint, user intent, deployment markers.
3. List the explicit platforms named by the user. If none were named, derive candidates from fingerprint markers and ask the user to confirm before locking in.
4. For each candidate platform, name the store/distribution policy that applies (App Store, Google Play, Microsoft Store, Steam, web, internal enterprise, console SDK, package registry).

Decision process

1. Build the platform matrix: rows are platforms; columns are runtime, distribution channel, accessibility baseline, performance budget, security track, testing matrix, telemetry constraints.
2. Mark which cells are unknown and would benefit from Context7 MCP lookups (current SDK version, store policy revision, browser support floor, OS version coverage).
3. For each platform, pin the security track: web/API/backend → security-owasp-web; native iOS/Android → security-mobile-masvs plus backend/API security-owasp-web when applicable; LLM feature → security-owasp-llm; agentic surface → security-owasp-agentic; game → cheat-surface review plus dependency CVE checks.
4. Set a minimum testing matrix: e.g., web → 2 browser engines + 1 mobile viewport; iOS → 2 device sizes + dark mode + accessibility audit; Android → 2 API levels + at least one form factor.
5. Surface conflicts: platforms whose budgets, policies, or stores disagree (for example, an iOS feature blocked by App Store rules but used freely on web).
6. Hand the matrix to architecture-review and requirements-quality so non-functional requirements pick it up automatically.

Decision boundaries

• Use Context7 MCP whenever current store policy, browser support, OS version table, or platform SDK behavior changes the answer.
• Keep a decision trace: candidate platforms, why included or excluded, store-policy risks, accessibility floor, security track per platform.
• Escalate before locking in a platform whose store policy or certification path could block release.

Decision record

• Platform matrix (platform × runtime × distribution × accessibility × performance × security × test × telemetry)
• Per-platform security track assignment
• Per-platform testing matrix floor
• Open Context7 lookups required before architecture
• Conflicts and store-policy risks list

Ready when

• Never silently expand the platform list beyond what the user confirmed.
• Never claim store-policy compliance without naming the policy version and date.
• Never let two platforms share a single security track if they have different surface areas.
• Never let unverified browser/OS support assumptions enter the matrix.

Handoff

Hand off the matrix and per-platform tracks to requirements-quality, architecture-review, and the relevant security-* skill. Flag any conflict that must be resolved before service-implementation.

References

• references/platform-matrix.md: template platform × constraints matrix with default budgets and security tracks.