微信扫一扫SuiteManager
Manage kit $ARGUMENTS — scaffold, validate, test, and publish reusable concept packages.
When to use: Use when creating, validating, testing, or managing suites. Covers the full kit lifecycle from scaffolding to publishing.
Design Principles
- Suite as Reusable Unit: A suite bundles related concepts and syncs into a single distributable package — like an npm package for Clef.
- Cross-Suite Isolation: Concepts in one kit never reference concepts in another suite directly — cross-suite integration happens through syncs and type parameter alignment.
- Required vs Recommended Syncs: Suite syncs are tiered: required syncs are load-bearing, recommended syncs provide useful defaults, integration syncs wire to other suites.
Step-by-Step Process
Step 1: Create Suite
Scaffold a new suite directory with kit yaml , concept and sync subdirectories , and example files
Arguments: $0 name (string)
Checklist:
- [ ] Suite name follows naming convention?
- [ ] Suite.yaml has required fields (name, version, description)?
- [ ] Example concept spec is valid?
Examples: Create a new suite
clef suite init my-suite
Step 2: Validate Suite
Validate a suite manifest , its concept specs , sync definitions , and cross kit concept references
Arguments: $0 path (string)
Checklist:
- [ ] All concept specs parse successfully?
- [ ] All sync files compile?
- [ ] Cross-suite references resolve?
- [ ] Type parameters align across concepts?
Examples: Validate a suite
clef suite validate ./suites/my-suite
Step 3: Test Suite
Run conformance and integration tests for a suite Tests invariants from concept specs and validates sync compilation
Arguments: $0 path (string)
Checklist:
- [ ] Conformance tests pass?
- [ ] Integration tests pass?
- [ ] No failing assertions?
Examples: Test a suite
clef suite test ./suites/my-suite
Step 4: List Active Suites
List all suites used by the current application , including their versions and concept counts
Examples: List active suites
clef suite list
Step 5: Check Overrides
Verify that application sync overrides reference valid syncs in the target kit
Arguments: $0 path (string)
Checklist:
- [ ] Override references valid syncs?
- [ ] Override parameters match original sync signature?
Examples: Check sync overrides
clef suite check-overrides ./suites/my-suite
References
Supporting Materials
Quick Reference
| Action | Command | Purpose |
|--------|---------|---------|
| init | clef suite init <name> | Scaffold a new suite |
| validate | clef suite validate <path> | Validate suite manifest |
| test | clef suite test <path> | Run suite tests |
| list | clef suite list | List active suites |
| checkOverrides | clef suite check-overrides <path> | Verify sync overrides |
Example Walkthroughs
For complete examples with design rationale:
Anti-Patterns
Cross-suite concept reference
Suite A's concept imports Suite B's types directly instead of using type parameters.
Bad:
# In kit-a/concepts/order.concept
concept Order [O] {
state { customer: O -> kit_b.User } # Direct reference!
}
Good:
# In kit-a/concepts/order.concept
concept Order [O, U] {
state { customer: O -> U } # Type parameter, wired by sync
}
Monolithic kit
Suite bundles unrelated concepts — violates the reusable unit principle.
Bad:
# suite.yaml
kit: { name: everything }
concepts: [User, Article, Payment, Analytics, Email, Notification]
Good:
# Split into focused kits
kit: { name: content } # concepts: [Article, Tag, Comment]
kit: { name: commerce } # concepts: [Payment, Invoice, Refund]
Validation
Validate a suite:
npx tsx cli/src/index.ts suite validate ./suites/my-suite
Run suite tests:
npx tsx cli/src/index.ts suite test ./suites/my-suite
List active suites:
npx tsx cli/src/index.ts suite list
Related Skills
| Skill | When to Use |
| --- | --- |
| /concept-designer | Design concepts to include in the suite |
| /sync-designer | Write syncs that wire kit concepts together |
| /deployment-config | Deploy suites to production runtimes |