Stay close to the work
Diversio Engineering shares tools, writing, systems notes, and working practices in the open. This is where to start if you want to follow the work, use it, or contribute back to it.
Choose the path that matches your interest
The best way in depends on whether you want to read, inspect, use, or contribute.
Engineering writing
Original posts, curated reposts, and longer-form thinking about the systems and habits behind the work.
Read the blog → SystemsSystems
Workflows, stack choices, guardrails, and design decisions behind the tools and docs.
Browse systems → Agentic ToolsAgentic Tools
Registry, deep docs, and runtime-specific guides for the open tools and packages we publish.
Open tools → ContributeCollaborate on the open-source work
The most active contribution surface today is Agentic Tools, where skills, docs, manifests, and Pi packages move through normal review.
See contribution paths →Projects you can explore right now
Agentic Tools is the largest open surface, alongside a smaller set of related repos from Diversio Engineering.
Agentic Tools
The main open repository includes plugins, skills, Pi packages, docs, publishing workflows, and the engineering site itself.
Open repository →clickup-mcp
Connect ClickUp tasks and workspace context to MCP-enabled tools.
DiversioTeam/clickup-mcp Open repository → MCPgemini-cli-mcp
Expose Gemini CLI workflows through MCP for research and automation.
DiversioTeam/gemini-cli-mcp Open repository → Shared runtimepi-cmux
Shared cmux utilities used in Pi-powered terminal workflows.
DiversioTeam/pi-cmux Open repository →How contribution usually works
If you want to contribute directly, this is the main path.
Start with the source
Use the repo when you need the actual code, package layout, docs, manifests, or recent implementation history.
Report drift and propose changes
Use issues when behavior, docs, or metadata stop matching what the repository actually does.
Keep changes reviewable
Skills, manifests, docs, and Pi packages all move through normal PR review, so changes should stay scoped and easy to inspect.
Understand the repo conventions
Read the guide for package shape, wrapper expectations, validation commands, and doc-sync rules before opening larger changes.
How collaboration tends to go well
The strongest contributions usually make the code, the reasoning, and the next step easier to understand.
Start from a concrete problem
The best discussions begin with something real: a workflow that drifts, a missing piece of documentation, a tool gap, or a repeated source of friction.
Keep the reasoning close to the change
Changes land faster when the intent is visible in the docs, the issue, the PR, or the implementation itself instead of hidden in private context.
Prefer reusable improvements
Strong contributions do more than fix the local issue. They often leave behind a clearer workflow, a better guardrail, or a tool the next engineer can use.
Use the channel that fits
Some conversations belong in the repo. Others belong in writing, systems notes, or direct technical contact. Picking the right path keeps momentum higher.
Need help, want to reach out, or found something sensitive?
Use the path that matches the conversation so it gets handled in the right place.
Email the engineering team
Use email for broader technical questions, collaboration notes, or when GitHub is not the right first step.
Responsible disclosure
If the issue is sensitive, use the security page instead of opening a public thread.
Read policy → DocsTooling and distribution docs
The docs section explains package shape, runtime distribution, install flows, and the conventions behind the tooling.
Open docs →