platform-coordination-protocol

Reviews cross-platform coordination for mini-program auth, API, and payment changes.

Updated Dec 24, 2025
One-click install
npx skills add https://github.com/JoyJoin-Tech-Limited/JoyJoin_app_v0.1 --skill platform-coordination-protocol-joyjoin-tech-limited
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: platform-coordination-protocol
Source: https://github.com/JoyJoin-Tech-Limited/JoyJoin_app_v0.1/tree/main/.github/skills/platform-coordination-protocol
Command: npx skills add https://github.com/JoyJoin-Tech-Limited/JoyJoin_app_v0.1 --skill platform-coordination-protocol-joyjoin-tech-limited

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Changes to auth, API, or payment flows in the JoyJoin monorepo can silently drift between the mini-program, the shared package, and the server. This Skill prevents that drift by enforcing a review protocol before treating any change as platform-local. ## Core Features & Use Cases - Sibling review rules: Checks docs/PLATFORM_COORDINATION.md and duplicated hotspots before finalizing changes to apps/mini-program/src/lib/api/api.ts or payment pages. - Scope classification: Labels changes as MINI_PROGRAM_ONLY, WEB_ONLY, or BOTH_REQUIRED, defaulting to BOTH_REQUIRED when heuristics and the playbook disagree. - Shared package drift detection: Inspects both clients for consumers when packages/shared/src types or utilities change. - Use Case: You updated auth handling in the mini-program API wrapper and need to know whether shared session types or server contracts also require review before merging. ## Quick Start Ask the AI to review whether your change to the mini-program payment or auth flow requires sibling platform or shared package updates.

Frequently Asked Questions about platform-coordination-protocol

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I know if a mini-program change needs cross-platform review?▼

Check whether the touched file appears in docs/PLATFORM_COORDINATION.md or is a known duplicated hotspot like the auth API wrapper or payment pages. If heuristics and the playbook disagree, treat the change as BOTH_REQUIRED until verified.

What should I check after changing packages/shared types?▼

Inspect both clients for imports of the changed type and review the duplicated auth and payment hotspots listed in the coordination playbook. Shared type changes can cause hidden drift between the mini-program and server contracts.

Does the archived web client still need updates?▼

No. The web client apps/user-client was archived to archived/workspaces/user-client/, and the mini-program is the only active user-facing client. The historical coordination table is kept for reference only.

What if the mini-program build is unavailable in my environment?▼

Run the shared checks that exist, such as npm run typecheck -w @joyjoin/shared or npm run typecheck -w @joyjoin/server, and note the mini-program validation gap in the PR description.

When should a change be classified as BOTH_REQUIRED?▼

Classify as BOTH_REQUIRED when the change alters duplicated business logic, shared types, or coordinated auth/payment/API behavior. When you cannot tell whether a change is business logic or renderer wiring, default to BOTH_REQUIRED.