Projects-as-code

Planarise Compose

Your project's structure: workflows, states, fields, labels, is a first-class artifact. Define it in code and version it in Git. Introducing, the first-ever framework for Projects-as-code.

Read the docs

CLI firstGitOps readyBuilt for scale

~/projects/acme

COMPOSE

❯

zshauthenticated

See it in action

Watch how Planarise Compose transforms project management workflows

Capabilities

Everything you need to manage
projects-as-code

Bootstrap instantly

Initialize a project scaffold with one command. Enforce strict directory structure for predictable automation.

planarise init
# Select workspace → Set project key
# Creates:
#   planarise.yaml
#   .planarise/
#   schema/
#   work/

Schema as YAML

Define states, labels, workflows, types, and custom fields in YAML. Keep everything version-controlled and human-readable.

# schema/workflows/sprint.yaml
states:
  - name: backlog
    color: "#6B7280"
  - name: in-progress
    color: "#3B82F6"
  - name: done
    color: "#10B981"

Push and pull

Sync changes both ways between local files and Planarise. Use Git-style operations your team already knows.

planarise schema pull   # Fetch remote → local
planarise schema push   # Apply local → remote
planarise push          # Sync work items
planarise pull          # Pull work items

Clone your project

Clone an entire project to disk. Replicate the same configuration across workspaces without rework.

planarise clone PROJECT_ID
# Edit planarise.yaml → new project name
planarise schema push
# → Identical structure, new project

What is Projects-as-code

Every project has two layers: the work and the structure that holds it.

The work includes tasks, issues, and tickets. It changes daily. It is meant to be completed and archived. But a project also accumulates data that should persist. Specs, decisions, templates, intake patterns, recurring checklists, and the context that keeps work understandable over time.

Then there is the structure. Workflows, states, labels, types, and custom fields. Structure defines how your team operates. It is the shape of your process.

UI configuration does not scale. You cannot diff it, review it, or reliably standardize it without rebuilding it by hand.

Projects-as-code changes this. Your project becomes a set of files that are readable, versionable, and deployable. It lives in Git alongside your code. Changes go through pull requests. You can clone it, diff it, roll it back, and reuse it across projects and workspaces.

The same rigor you apply to your codebase, applied to how projects are defined—and how project context is preserved.

How it works

Four commands to transform
your workflow

Initialize

Scaffold a strict directory structure with planarise.yaml manifest and schema directories.

Define

Configure states, labels, workflows, and custom fields in human-readable YAML.

Push

Apply your configuration to Planarise with interactive confirmation.

Version

Commit your project configuration to Git. Review changes via pull requests.

Why this matters

Project management hasn't caught up
to how developers work

$2T

Wasted annually on poor project management

60%

Time spent on "work about work"

28×

Less waste with IaC principles

Start building with Planarise Compose

Define your projects declaratively. Version everything in Git.
Start treating project configuration as the infrastructure it is.