dev.kit turns repositories into self-explaining repo contracts for humans, scripts, and CI/CD.
It helps teams and repositories:
- understand how the repo actually works
- keep repo standards, manifests, refs, and dependency contracts traceable
- regenerate reliable context from repo signals instead of tribal knowledge
The model is:
- repo-first
- gap-aware
- regeneration-friendly
- standard-driven
- manifest-driven
npm install -g @udx/dev-kitcurl -fsSL https://raw.githubusercontent.com/udx/dev.kit/latest/bin/scripts/install.sh | bash# make sure your dev.kit install is current first
cd my-repo
dev.kit # inspect environment and repo context status
dev.kit repo # generate or refresh .rabbit/context.yamlOptional capability refresh:
dev.kit envdev.kit uses staged repo-driven context generation:
dev.kit
→ inspect environment
→ summarize repo-local context status
→ warn when existing context is stale
→ point to the next safe step
dev.kit env
→ detect tools, auth, and resolution capabilities
dev.kit repo
→ resolve repo standards, manifests, refs, dependency contracts, and gaps
→ ensure a minimal repo-owned structure when needed
→ generate .rabbit/context.yaml
Each step produces metadata that guides the next safe repo repair or regeneration step.
dev.kit repo generates .rabbit/context.yaml as the repo operational contract.
It may include:
- generator metadata
- manifests
- refs
- workflows
- commands
- dependencies
- dependency repo contracts
- coverage gaps
- repair hints
The repo should remain usable even when dev.kit is unavailable.
Committed repo-local context should stay useful for maintenance and automation.
Agent instruction files such as AGENTS.md or CLAUDE.md are optional repo-owned policy surfaces.
dev.kit can point maintainers toward the kind of guidance those files should contain. A repo may keep that guidance in docs and, if preferred, normalize it into AGENTS.md as a maintained repo-owned surface.
Use those files for consumer behavior rules and team-specific operating guidance. Keep .rabbit/context.yaml focused on generated repo facts.
This repo is intentionally split by responsibility:
src/configs/configuresdev.kitdetection, gap rules, context sections, and other module inputs- scripts, workflows, and YAML manifests are the programmatic execution layer
docs/documentsdev.kitbehavior, repo-context boundaries, workflow, and outputsdocs/references/is a small knowledgebase for developers and agents when gaps or contract surfaces need interpretationtests/validates command flow, generated context, and user-facing outputs
dev.kit repo is safe to run on nearly empty repos.
It can establish a minimal default structure so the repo becomes regeneration-friendly immediately:
README.md.github/dependabot.yml.github/workflows/.rabbit/docs/
That gives the repo clear places for context coverage, workflow traceability, docs, and future repair loops without inventing app-specific structure.
dev.kit resolves refs using:
- manifest metadata/header refs
- repo-local usage
- dependency-repo usage and workflow relationships
If refs cannot be resolved:
- gaps are emitted
- repair hints are suggested
- unresolved state is preserved instead of guessed
Example:
dev.kit repoThen read:
README.mddocs/.rabbit/context.yaml
| Command | Purpose |
|---|---|
dev.kit |
Inspect repo context status and suggest next steps |
dev.kit env |
Detect tools, auth, and resolution capabilities |
dev.kit env --config |
Configure capability restrictions |
dev.kit repo |
Generate .rabbit/context.yaml |
dev.kit repo --force |
Re-resolve repo and dependency context |
All commands support --json.
dev.kit repo also points to a small set of supporting UDX repos when you need shared worker, workflow, or repo-contract tooling:
- https://github.com/udx/worker
- https://github.com/udx/reusable-workflows
- https://github.com/udx/github-rabbit-action
- automate what can be verified
- expose unresolved gaps instead of guessing
- prefer refs over duplicated docs
- stay app-agnostic and language-agnostic
- keep repo-owned contracts compact and markdown-friendly
- degrade gracefully when tooling, auth, or external context is unavailable
- optimize for operational clarity over automation complexity
- How It Works
- Repo Contract Boundary
- Environment Config
- Context Coverage
- Integration
- Smart Dependency Detection
- Reference Docs
- Reference: Command and Workflow Surfaces
- Reference: Agent and Developer Workflow
- Reference: Repo Design
- Installation
bash tests/suite.sh --only corebash tests/worker-smoke.shbash tests/real-repos.sh /path/to/repo1 /path/to/repo2