process-parity

Audit and synchronize API contracts and features across mini-program, admin, and server surfaces.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a product ships on multiple client surfaces, changes made in one client often drift out of sync with the others, causing broken API contracts, inconsistent auth flows, and undocumented feature gaps. This Skill enforces a structured protocol to keep the WeChat mini-program, admin portal, server, and shared package aligned. ## Core Features & Use Cases - Cross-Surface Change Protocol: Apply changes in a fixed order — shared types first, then server, then mini-program, then admin — so contracts never diverge. - Parity Gap Auditing: Systematically check auth flows, API conventions, WeChat Pay integration, onboarding nextStep handling, and UI copy consistency across surfaces. - Anti-Pattern Guardrails: Prevents blind component porting between Taro and React, surface-specific DTOs, and accidental targeting of the archived web client. - Use Case: You add a new payment flow to the mini-program. Use this Skill to update the shared API types, extend the server route, expose management controls in the admin portal, and validate both builds. ## Quick Start Ask the AI to audit feature parity between the mini-program and admin portal for the feature you are currently changing.

Frequently Asked Questions about process-parity

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

FAQPage Schema
How do I keep API contracts consistent across multiple client apps?

Define all shared API types in a single shared package (packages/shared/src/api.ts) and have every client import from it rather than creating surface-specific DTOs. Apply changes shared-layer first, then server, then each client, and run typechecks on all surfaces.

How to audit feature parity between a mini-program and an admin portal?

Map which surfaces the feature touches, then check auth flows, API conventions, payment integration, onboarding nextStep handling, and UI copy on each surface. Document any differences as explicit, intentional parity decisions rather than leaving them accidental.

Can I reuse React components directly in a Taro mini-program?

No. Taro mini-programs use native primitives like ScrollView and rpx units with page lifecycles such as onLoad and onShow, not React Router transitions. Adapt each surface's UI using its own idiomatic components instead of copying code across frameworks.

When should I not apply cross-surface parity changes?

Skip the parity protocol for single-surface features with an explicit product exclusion, backend-only changes with no client impact, and admin-only changes. Parity differences are acceptable when they are documented and intentional.

What happens if clients use different DTOs for the same API concept?

Divergent DTOs cause contract drift, type mismatches, and subtle runtime bugs between surfaces. The fix is to consolidate on shared types in the shared package so all clients consume identical contracts.