add-shared-schema

Add cross-package API contracts, enums, and Zod schemas to a shared package.

Updated Sep 16, 2026
One-click install
npx skills add https://github.com/PT-Perkasa-Pilar-Utama/axentra --skill add-shared-schema-pt-perkasa-pilar-utama
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: add-shared-schema
Source: https://github.com/PT-Perkasa-Pilar-Utama/axentra/tree/main/.claude/skills/add-shared-schema
Command: npx skills add https://github.com/PT-Perkasa-Pilar-Utama/axentra --skill add-shared-schema-pt-perkasa-pilar-utama

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? In a monorepo, duplicating literals and validation logic across the API, worker, and web packages causes drift and inconsistent contracts. This Skill guides you to place stable shared contracts in packages/shared so every consumer uses one source of truth. ## Core Features & Use Cases - Centralized Contracts: Add response envelopes, enums, and Zod schemas to packages/shared/src and export them from its index file. - Compatibility Discipline: Confirm task scope and compatibility impact before changing shared code, and update API and UI consumers in the same PR. - Test Coverage: Add tests for both valid and invalid values for every new shared schema. - Use Case: When a new API error code is needed by both the Hono API and the React UI, define it once in packages/shared, export it, test it, and update both consumers together. ## Quick Start Ask the assistant to add a new shared Zod schema or enum to packages/shared and update the API and UI consumers in the same change.

Frequently Asked Questions about add-shared-schema

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

FAQPage Schema
How do I share Zod schemas between frontend and backend in a monorepo?▼

Place the schema in a shared package such as packages/shared/src and export it from that package's index file. Both the API and UI then import the same schema, keeping validation consistent across packages.

When should validation live in a shared package versus next to a feature?▼

Shared packages should hold stable API contracts, response envelopes, and enums consumed by more than one package. Feature-only validation should stay next to the feature to avoid bloating the shared contract surface.

Can a shared package import app-specific modules?▼

No. Shared packages must not import app-specific modules, because that creates circular dependencies and couples the contract layer to one application. Keep shared code dependency-free and domain-neutral.

What tests are needed when adding a shared schema?▼

Add tests covering both valid and invalid values for the new schema or literal. This ensures the contract rejects bad input consistently for every consumer that relies on it.

Should API and UI consumers be updated in the same PR as a shared schema change?▼

Yes. Updating all consumers in the same PR keeps the repository in a consistent state and prevents version drift between the shared contract and the packages that depend on it.