This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Packages

The package tiers, from a minimal bootstrap context to a fully managed workspace.

1: minimal
2: managed
3: software
4: research
5: product

Packages are opinionated bundles of skills. Pick one tier as your starting point, then add or remove skills through your installer or local package metadata when you need a narrower context.

The five tiers

Package	Extends	Best for
`minimal`	—	Solo developers, side projects, early-stage experiments
`managed`	`minimal`	Small teams who want a shared backlog and cadence rituals
`software`	`managed`	Engineering teams building production software systems
`research`	`managed`	Data science, ML, and research-heavy projects
`product`	`software`	Full product teams: engineering + design + product ops

managed is the recommended default. Start there and add skills as needed rather than starting with software or product.

What each tier adds

Each tier is cumulative — higher tiers include everything below them.

Tier	Key additions over the tier below
`minimal`	Backlog (WorkItem), event-log, actor-profile, git-workflow, debugging, testing-strategy, error-handling
`managed`	Roles, decisions (DecisionRecord), scopes, standup, session-handover, retrospective, release-semver, code-review, refactoring, TDD, documentation, dependency-management
`software`	Architecture, API design, databases, infrastructure (Docker, k8s, Terraform), security (OWASP, auth), observability, performance
`research`	Data science, data pipeline, data quality, feature engineering, pandas/polars, RAG, ML pipeline, prompt engineering, LaTeX, infographics
`product`	Frontend design, mobile design, logo design, FastAPI, TypeScript, Flutter, Tailwind, Reflex, SEO, PRD writing, user research

How composition works

Packages compose via spec.extends. The effective skill set of a package is the union of its parent(s)’ effective skill sets plus its own includes.skills. Cycles are not allowed.

minimal ── managed ── software ── product
                   └─ research

Using a package

When installing manually, select a package by copying the shipped context and then enabling the tier through your own harness or installer configuration. Managed installers can expose this directly. For example, aibox uses:

# aibox.toml
[processkit]
source = "https://github.com/projectious-work/processkit.git"
version = "v0.25.1"

[context]
packages = ["software"]

Creating a project package

For deeper customization, create your own package file under context/packages/:

---
apiVersion: processkit.projectious.work/v1
kind: Package
metadata:
  id: PKG-my-team
  name: my-team
  version: "1.0.0"
spec:
  description: "Custom bundle for my team."
  extends: [managed]
  includes:
    skills:
      - rust-conventions
      - auth-patterns
      - logging-strategy
---

then reference it from your installer or package selection config:

[context]
packages = ["my-team"]

Source files

Each tier is defined in a YAML file in src/.processkit/packages/ : minimal.yaml, managed.yaml, software.yaml, research.yaml, product.yaml. The YAML is the source of truth; these docs pages summarize the intent.

Why packages are standalone

processkit packages are content, not environment machinery:

Reusable content. The skills, schemas, and MCP servers in processkit work with any compatible agent harness or MCP client. They are not tied to a specific devcontainer implementation.
Forkable catalog. Organisations can maintain a private fork of processkit with custom skills, schemas, and MCP servers. That fork is consumable by any installer that can copy the release files and launch the MCP commands.
Independent release cadence. Content (skills, primitives) changes more frequently than infrastructure. Keeping packages in processkit lets users update process content without changing their harness.

1 - minimal

Intended for: solo developers and small side projects. Extends: — (the base tier)

The lightest footprint package. Just enough structure to track work and debug effectively — no roles, no scopes, no governance artifacts.

Included skills

event-log — foundation: probabilistic append-only event log
actor-profile — basic Actor entities
workitem-management — WorkItem creation and transitions
git-workflow — branch/commit/PR conventions
debugging — systematic debug workflow
testing-strategy — unit vs integration vs E2E guidance
error-handling — cross-language patterns

When to upgrade

You’re joining a team → managed
You need formal decision records, scopes, and process artifacts → managed
You’re building production software → software
You’re doing data/ML work → research
You need the kitchen sink → product

Source

src/packages/minimal.yaml

2 - managed

Intended for: small teams with a shared backlog and process cadences. Extends: minimal

The recommended default. Adds roles, decisions, scopes, and all lightweight process artifacts (standups, retros, session handovers) on top of minimal.

What managed adds on top of minimal

Process primitives and cross-cutting process skills: role-management, decision-record, scope-management, category-management, cross-reference-management, binding-management, process-management, state-machine-management, gate-management, schedule-management, constraint-management, discussion-management, metrics-management.

process-management, schedule-management, and state-machine-management are included for legacy v1 migration guidance. They are not first-class v2 primitive authoring surfaces.

metrics-management remains a managed-package skill, but Metric is no longer a primitive. Metric specifications are tracked as artifacts and observations as LogEntries or external time-series data.

Lightweight process artifacts: backlog-context, decisions-adr, standup-context, session-handover, context-archiving, retrospective, estimation-planning, code-review, documentation, refactoring, tdd-workflow, incident-response, postmortem-writing, release-semver, integration-testing, dependency-management.

When to upgrade

You need production-grade infrastructure, observability, and security skills → software
You need data/ML skills → research
You need design + frontend + everything → product

Source

src/packages/managed.yaml

3 - software

Intended for: software engineering teams building production systems. Extends: managed

The “serious software team” tier. Adds architecture, API, database, infrastructure, security, observability, and performance skills on top of managed.

Highlights

Architecture: software-architecture, system-design, domain-driven-design, event-driven-architecture, concurrency-patterns
API: api-design, graphql-patterns, grpc-protobuf, webhook-integration
Database: database-modeling, database-migration, sql-patterns, sql-style-guide, nosql-patterns, caching-strategies
Infrastructure: ci-cd-setup, container-orchestration, dockerfile-review, kubernetes-basics, terraform-basics, linux-administration, dns-networking, shell-scripting
Security: auth-patterns, secret-management, secure-coding, threat-modeling, dependency-audit
Observability: logging-strategy, metrics-monitoring, alerting-oncall, distributed-tracing
Performance: performance-profiling, load-testing

When to upgrade

Only if you also need design, mobile, frontend framework skills → product.

Source

src/packages/software.yaml

4 - research

Intended for: research teams, data science projects, ML engineering. Extends: managed

Managed plus data, ML, AI, and research-documentation skills.

Highlights

Data: data-science, data-pipeline, data-quality, data-visualization, feature-engineering, pandas-polars, database-modeling, sql-patterns
AI/ML: ai-fundamentals, ml-pipeline, prompt-engineering, llm-evaluation, embedding-vectordb, rag-engineering, code-generation
Research authoring: latex-authoring, documentation, infographics, excalidraw
Infrastructure bits research projects touch: shell-scripting, container-orchestration

Source

src/packages/research.yaml

5 - product

Intended for: end-to-end product development teams. Extends: software

The most comprehensive tier. Software plus design, mobile, framework, and product-specific skills. Use when engineering, design, research, and operations all live in the same repository.

What product adds on top of software

Design: frontend-design, mobile-app-design, logo-design
Framework: fastapi-patterns, tailwind, typescript-patterns, flutter-development, reflex-python
Data subset: data-visualization, feature-engineering, ai-fundamentals, prompt-engineering, llm-evaluation
Language conventions: python-best-practices, rust-conventions, go-conventions, java-patterns
Documentation: latex-authoring, excalidraw, infographics
Product ops: seo-optimization, agent-management

When NOT to use product

If you don’t actually need design, mobile, or framework skills — stick with software. The product tier is large and expecting every team to manage it is false economy.

Source

src/packages/product.yaml