Treat @contractspec/lib.contracts-spec as a compatibility surface, not an implementation detail.
Every meaningful change must:
- update the contract source first
- classify compatibility intent
- pass through ContractSpec Connect before risky edits or shell execution
- preserve policy/workflow integrity
- leave behind review and replay evidence when escalation is required
- keep package docs, website docs, and release capsules aligned when the public contract surface or workflow changes
Mission: ContractSpec is the open spec system for AI-native software: explicit contracts, aligned surfaces, safe regeneration, and an operating layer on top when teams need it.
| Concern | Rule File | Key Points |
|---|---|---|
| Contracts | contracts-first.md |
Spec before implementation |
| Mission & Context | contractspec-mission.md |
Why we exist, who we serve |
| Architecture | package-architecture.md |
libs → integrations/modules → bundles → apps |
| Code Quality | code-quality-practices.md |
Testing, naming, standards |
| File Organization | code-splitting.md |
Max 250 lines, domain grouping |
| Type Safety | type-safety-dependencies.md |
No any, latest deps |
| Frontend | frontend.md |
Atomic design, state handling |
| Backend | backend.md |
Hexagonal, DDD |
| Design System | design-system-usage.md |
No raw HTML |
| Delivery Lifecycle | lifecycle-loop.md |
Ideation → plan → ship → review → observe → document |
| Cursor Marketplace | cursor-marketplace-readiness.md |
Plugin metadata, artifact safety, publish readiness |
| AI Governance | ai-agent.md |
Traceability, composability |
| Documentation | docs.md |
DocBlocks first |
- Spec-First: Contracts define behavior before implementation
- Multi-Surface Consistency: One spec → API, DB, UI, events
- Safe Regeneration: Code can be regenerated without breaking invariants
- Standard Tech: TypeScript, Zod, no magic abstractions
- Incremental Adoption: Stabilize one module at a time
packages/libs/: Foundational contracts, runtimes, agent systems, design system primitives, and shared utilities.packages/integrations/: Runtime, provider, and environment bridges that connect core libs to concrete execution targets.packages/modules/: Domain and feature modules that compose libs and integrations into reusable product surfaces.packages/bundles/: Higher-level product composition for docs, workspace, marketing, and other cross-feature surfaces.packages/examples/: Runnable or importable reference implementations that demonstrate the package stack in practice.packages/apps/andpackages/apps-registry/: Deployable shells such as CLIs, MCP servers, APIs, websites, mobile apps, and registry surfaces.packages/tools/: Build, lint, docs, config, and agentpacks tooling used across the repository and downstream workspaces.
- The root
AGENTS.mdis generated from this overview rule and gives repository-wide guidance. - Package-level
AGENTS.mdfiles are the authoritative local guides for touched packages; always prefer the nearest one when editing code. - When the root guide and a package guide differ, follow the more specific package guidance unless it conflicts with higher-priority safety or security rules.
- Treat root
README.md, the nearest packageREADME.md, the nearest packageAGENTS.md, the website docs, and/llms*guidance as one public documentation surface. - When contributor or user workflows change, use the paired
.changeset/*.mdand.changeset/*.release.yamlfiles as the canonical release-facing source of truth for what must be reflected in docs. - Update the source rule files that generate root guidance instead of hand-editing generated root
AGENTS.md. - If a website or changelog surface depends on generated release artifacts, run
contractspec release buildbefore treating that surface as current.
- Language: TypeScript (strict mode)
- Formatting: 2 spaces, semicolons, double quotes, trailing commas
- Types: Explicit, no
any, proper type guards - Files: Max 250 lines (components: 150, utilities: 100)
- Read relevant rules for your change type
- Check the nearest package
README.mdandAGENTS.mdbefore changing behavior - If the change affects public behavior or operator workflow, inspect the related
.changeset/*.mdand.release.yamlfiles before updating docs - Check existing patterns in the codebase
- Plan with DocBlocks if adding new features
- Run
/ai-auditto verify decisions
When working with AI assistants:
- Rules are applied contextually based on file type
- Treat
package.json,src/, localREADME.md, and localAGENTS.mdas the source of truth for package behavior - MCP schemas, exported subpaths, CLI signatures, and generated artifacts are compatibility surfaces and should be changed deliberately
- Keep generated docs,
/llms*, and release-manifest-backed website surfaces aligned with the same underlying source docs and release capsules - Conflicts resolved by: Security > Compliance > Safety > Quality > UX > Performance
- All decisions should be traceable and reversible
- Use
/ai-auditto verify governance compliance
/commit- Create conventional commit/test- Run tests with analysis/lint- Check and fix lint issues/fix- Auto-fix common issues/explain- Understand code/ideate- Shape idea into a scoped brief/analyze-codebase- Audit architecture/contracts/quality hotspots/impact- Analyze change impact before build/PR/review-plan- Review plan before coding/refactor- Guided refactoring/ship- Run release-readiness checks/draft-pr- Create draft PR with checklist/review-pr- Code review/audit-health- File/layer/reuse health audit/audit-observability- Logging/metrics/analytics audit/document- Sync docs with implementation/cursor-plugin- Build Cursor plugin artifacts/ai-audit- Governance check
- Check the specific rule file for detailed guidance
- Use
/explain <concept>for architecture questions - Run
/ai-auditto verify your approach