Spark
Sign In
Tool

Run a headless CMS workspace where AI agents manage tasks and content

Barkpark is a headless CMS for AI agents with a shared, real-time task board, Studio, CLI, TUI, and REST API.

Get this
Works with postgresgithubcaddy
github
Own this? Claim it

Maintainer of this project? Claim this page to edit the listing.

90
Spark score
out of 100
Updated last month
Version 1.0.0
Add to Favorites

Why it matters

Give AI agents a structured workspace to store, claim, and complete tasks while humans collaborate on the same content in real-time through a web or terminal interface, with atomic concurrency controls and dependency graphs.

Outcomes

What it gets done

01

Atomically claim and close tasks from a priority-ordered queue with dependency tracking

02

Sync content changes in real-time between AI API calls and human browser edits

03

Deploy a full-stack CMS to any Ubuntu server with one command

04

Organize experiments in isolated workspaces with separate schemas and datasets

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/frikkern-barkpark | bash

Overview

Barkpark

Barkpark is a headless CMS built for AI agents: a shared, real-time task board, papers, and media store editable via CLI, TUI, Web Studio, or REST API. Use it when an AI agent needs a shared task board or content store a human can co-edit in real time. No MCP server yet; some CLI commands are stubs in v1.

What it does

Barkpark is a headless CMS built specifically for AI agents: a shared workspace where an agent stores, sorts, and structures content - tasks, papers, media - while a human edits the same documents in a browser Studio, with both sides seeing every change in real time. Task management is the headline use case: tasks are plain documents with a lifecycle (open -> in_progress -> done, plus blocked/cancelled), a dependency graph, priorities, labels, and an atomic claim/close contract built for concurrent agent workers (fencing epochs, 300-second lease sweeps).

When to use - and when NOT to

Use it when an AI agent needs a shared, real-time task board or content store that a human can also edit directly - the agent claims and closes tasks over HTTP while a person flips lifecycle states and sets priority/assignee in the Studio, with claims and dependencies rendering read-only there since the API owns them. It is honest about v1's gaps: there is no MCP server yet (deferred), bp login/completion are stubs, scoped_prefix has no effect yet, and --dry-run is only a client-side preview - not a fit for teams needing MCP integration or full auth scoping today. Disposable experiments get their own isolated workspace (own schemas, tasks, papers, media) via bp workspace create, so nothing leaks back into production data.

Inputs and outputs

Input: tasks, papers, or media created via any of four interchangeable surfaces - the bp CLI (a single static binary that reads the whole API live from GET /v1/capabilities), the multi-pane Web Studio at /studio, a keyboard-driven terminal TUI, or the REST API itself (public reads, token-authed writes, a Sanity-compatible mutation envelope, and an SSE change stream). Output: real-time-synced content across whichever surfaces are open, with structured task state and a dependency graph other agents can query.

bp task ready                # what's unblocked, priority-ordered
bp task next agent-1         # atomically claim the next ready task
bp task close t1 agent-1 1   # CAS on the claim epoch

Install via a curl script, then bp setup walks through local dev, an SSH deploy to any Ubuntu 22.04+ box, or connecting to a running server. A single SchemaDefinition drives the Studio panes, TUI desk, REST contract, and CLI verbs together, and the server projects every noun, verb, and route into that same GET /v1/capabilities manifest every client reads.

Integrations

Ships bundled plugins for Tasks (the core board above), Bulldocs (portable documentation papers), Media (an asset library), OnixEdit (ONIX 3.0 book metadata plus Bokbasen submission), and Frt (Godot game content) - all built on the same Barkpark.Plugin behaviour, so a new plugin's schemas, routes, workers, and CLI verbs travel from one Elixir module to every client surface with no additional client code. The fresh-install invariant is that Barkpark still works with every plugin disabled. Runs on Elixir/Phoenix LiveView/PostgreSQL/Oban plus a Go CLI/TUI binary and Caddy, backed by 2,400+ mix tests and 89 HTTP integration tests.

Who it's for

Teams running AI agents that need a shared task board or content store a human can co-edit in real time, rather than a one-way agent-writes/human-reads setup. Open source under the MIT license.

Source README

Barkpark

The workspace your AI works in. Barkpark is a headless CMS built for AI agents: a place where an AI stores, sorts, and structures content - tasks, papers, media - while you edit the same documents in a browser Studio. The agent drives the API; you drive the panes; both see every change in real time.

Live demo: https://api.barkpark.cloud/studio

Your AI's task board

Task management is the headline use case. Tasks are plain documents with a lifecycle (open → in_progress → done, plus blocked/cancelled), a dependency graph, priorities, labels, and an atomic claim/close contract built for concurrent workers (fencing epochs, 300s lease sweeps):

bp task ready                # what's unblocked, priority-ordered
bp task next agent-1         # atomically claim the next ready task
bp task close t1 agent-1 1   # CAS on the claim epoch
bp task ls --limit 20        # everything, goals included

Open /studio and the same queue is the Tasks ✅ pane: you flip lifecycle states and set priority/assignee while the agent claims and closes over HTTP (claims and dependencies render read-only - the API owns them). A root task is a goal; subtasks nest under it via parent_id. Guide: docs/setup/TASK-SYSTEM.md · cheatsheet: docs/cheatsheets/tasks.md.

Install

curl -fsSL https://raw.githubusercontent.com/FRIKKern/barkpark/main/scripts/install-cli.sh | sh
bp setup        # wizard: local dev · deploy a server · connect - tasks + papers pre-checked
bp task ready   # you're in

The wizard covers every route: local stack (native or Docker), SSH deploy to any Ubuntu 22.04+ box (ARM64 or x86_64), or connect to a running server. Walkthrough: docs/setup/QUICKSTART.md. Hacking on Barkpark itself: docs/setup/SETUP.md.

Play around without stacking up mess

One call spins up a workspace - it arrives with you as owner, a Default project, and a production dataset. Experiments live in their own workspace with their own schemas, tasks, papers, and media; when the spike is done, nothing leaks back into your real work:

bp workspace create Spike
bp workspace project-create spike agents-v2

Four ways in

Surface What it is
bp CLI One static binary that speaks the whole API - bp <noun> <verb>, assembled live from GET /v1/capabilities. Same binary as the TUI.
Web Studio Multi-pane LiveView desk at /studio - drill, filter, edit-with-autosave, publish. Real-time across tabs.
Terminal TUI The same desk in your terminal, keyboard-driven (barkpark with no args).
REST API Public reads, token-authed writes, Sanity-compatible mutation envelope, SSE change stream.

Stack: Elixir 1.15+ / Phoenix LiveView 1.1 / PostgreSQL / Oban · Go 1.24+ (CLI + TUI, one binary) · Caddy. 2400+ mix tests, 89 HTTP integration tests.

Design philosophy

  • Built for agents. bp capabilities -o json teaches the whole API in one call; JSON defaults when piped; atomic batch writes via -f; --dry-run previews; -q minimal receipts; stable exit codes.
  • One schema, multiple surfaces. A single SchemaDefinition drives the Studio panes, the TUI desk, the REST contract, and the CLI command surface.
  • Manifest-driven contract. The server projects nouns, verbs, and routes into GET /v1/capabilities; every client reads the same projection. Default-deny and existence-hiding, keyed on the caller's auth tier.
  • The plugin highway. Plugins are first-party Elixir modules riding the documented Barkpark.Plugin behaviour - schemas, routes, workers, cron, resolvers, desk items, CLI verbs travel from Elixir module to manifest to bp shell with no client code at any hop. With all plugins off, Barkpark still works - the fresh-install invariant is the test of correctness.

Bundled plugins: Tasks (the /v1/tasks/* board above) · Bulldocs (portable-doc papers at /papers/:slug) · Media (asset library) · OnixEdit (ONIX 3.0 book metadata + Bokbasen submission) · Frt (Godot game content).

v1 scope, honestly

No MCP server yet (deferred); bp login/completion are stubs; scoped_prefix has no effect yet; --dry-run is a client-side preview. The TUI edits v1 primitive fields natively - v2 plugin types render as JSON there (edit in Studio). Plugins disable, never delete. Ledger: docs/decisions/deferred.md.

Deploy

One command on any Ubuntu 22.04+ box. deploy.sh requires DOMAIN - the public DNS hostname, never an IP (it pins Phoenix check_origin):

DOMAIN=api.barkpark.cloud ssh root@YOUR_VPS_IP "DOMAIN=$DOMAIN bash -s" < deploy.sh

Or let the wizard drive it: bp setup --target deploy. Updates: ssh in, cd /opt/barkpark && git pull (post-merge hook rebuilds + restarts). Ops canon: docs/ops/PROD_OPS.md.

Documentation

Doc What
docs/INDEX.md Catalog of every card, contract, and runbook
docs/setup/TASK-SYSTEM.md The task system - agent loop, Studio collaboration, goals
docs/cli/HANDBOOK.md Full bp CLI manual
docs/cheatsheets/ One-pagers: bp, tasks, HTTP API, papers
docs/api-v1.md · docs/auth.md HTTP contract · tokens and tiers
docs/cards/plugins.md Build a plugin (contract: api/lib/barkpark/plugin.ex moduledoc)

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.