shared-schemas
Contributor guide for InsForge shared schema packages.
Install
mkdir -p .claude/skills/shared-schemas && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/12739" && unzip -o skill.zip -d .claude/skills/shared-schemas && rm skill.zipInstalls to .claude/skills/shared-schemas
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use this skill when contributing to InsForge's shared schema package. This is for maintainers editing published Zod contracts, exported types, and shared API payload definitions consumed by InsForge packages in this repo and other InsForge tooling.Key capabilities
- →Define cross-package payloads
- →Organize schemas by domain
- →Update backend validation and response usage
- →Update shared dashboard services
- →Check for import sites across packages
- →Call out downstream impact of changes
How it works
This skill ensures consistency by centralizing shared schema definitions and guiding updates across dependent InsForge packages and tooling.
Inputs & outputs
When to use shared-schemas
- →Updating a shared API contract
- →Defining new cross-package payloads
- →Refactoring shared domain models
About this skill
InsForge Dev Shared Schemas
Use this skill for packages/shared-schemas/ work in the InsForge repository.
Scope
packages/shared-schemas/src/**- any code in this repo that consumes the changed contracts
- downstream InsForge tooling that depends on the published
@insforge/shared-schemaspackage, including consumers not present in this repository
Working Rules
-
Treat
packages/shared-schemas/as the source of truth for cross-package payloads.- If a request, response, or domain shape is shared across InsForge surfaces, define it here.
- Do not duplicate the same contract in package-local files.
- Remember that this package is not only for the repo's backend and dashboard packages. It is also consumed by other InsForge tooling, including MCP and SDK code that may live outside this repository.
-
Keep schemas organized by domain.
- Follow the existing
*.schema.tsand*-api.schema.tssplit when it fits the current package pattern. - Keep
packages/shared-schemas/src/index.tsaligned with the intended public API. - Treat exported names and schema shapes as a public contract surface, not just an internal refactor target.
- Follow the existing
-
Use schema changes as a synchronization trigger.
- Update backend validation and response usage.
- Update shared dashboard services, hooks, and UI assumptions in
packages/dashboard/. - Check for import sites across
packages/*,frontend/, andbackend/before finishing. - Call out likely downstream impact on MCP, SDK, or other external InsForge consumers when a change alters exported names, schema semantics, or payload shape.
- Be conservative with breaking changes. If a breaking contract change is necessary, make it explicit in the handoff.
- Never use the TypeScript
anytype. Shared contracts should stay explicit and trustworthy across package boundaries.
Validation
cd packages/shared-schemas && npm run buildcd backend && npx tsc --noEmitcd packages/dashboard && npm run typecheck
Run package-specific tests as needed where behavior changed. If external consumers such as MCP or SDK cannot be validated from this repo, say that clearly instead of implying they were covered.
When not to use it
- →When defining package-local contracts
- →When working with non-InsForge tooling
- →When using the TypeScript 'any' type
Limitations
- →Does not cover package-local files
- →Does not cover external tooling not dependent on @insforge/shared-schemas
- →Does not permit the use of TypeScript 'any' type
How it compares
This workflow enforces a single source of truth for shared data contracts, preventing duplication and ensuring API consistency across multiple consumers.
Compared to similar skills
shared-schemas side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| shared-schemas (this skill) | 0 | 4mo | No flags | Intermediate |
| nodejs-backend-patterns | 12 | 2mo | No flags | Intermediate |
| springboot-patterns | 11 | 5mo | No flags | Intermediate |
| backend-architect | 10 | 4mo | No flags | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
nodejs-backend-patterns
wshobson
Build production-ready Node.js backend services with Express/Fastify, implementing middleware patterns, error handling, authentication, database integration, and API design best practices. Use when creating Node.js servers, REST APIs, GraphQL backends, or microservices architectures.
springboot-patterns
affaan-m
Spring Boot 架构模式、REST API 设计、分层服务、数据访问、缓存、异步处理和日志记录。适用于 Java Spring Boot 后端工作。
backend-architect
sickn33
Expert backend architect specializing in scalable API design, microservices architecture, and distributed systems. Masters REST/GraphQL/gRPC APIs, event-driven architectures, service mesh patterns, and modern backend frameworks. Handles service boundary definition, inter-service communication, resilience patterns, and observability. Use PROACTIVELY when creating new backend services or APIs.
customerio-reference-architecture
jeremylongshore
Implement Customer.io reference architecture. Use when designing integrations, planning architecture, or implementing enterprise patterns. Trigger with phrases like "customer.io architecture", "customer.io design", "customer.io enterprise", "customer.io integration pattern".
moai-domain-backend
modu-ai
Backend development specialist covering API design, database integration, microservices architecture, and modern backend patterns.
vendor-implementation
No-Trade-No-Life
基于Hyperliquid成功实现经验，为新交易所供应商提供Yuan框架集成指南。使用此技能当需要为新的交易所创建供应商实现，包括项目结构设计、API集成、核心服务实现和最佳实践。适用于交易所API集成、金融系统开发、微服务架构设计。