den / Guide / Start here

den for software developers

The memory your agents and your team share, versioned. What a project keeps, the plugin that installs the connector and the skill together, how a session starts and ends, and how the kind grows into a product of its own.

3 min read · On this page: What a project keeps · Install in Claude Code · How a session runs · Your stack is a skill, not a kind · Many projects, one workspace

den for software developers is the memory an agent reads before it acts and writes after it does. A project is a topic. A topic holds named, versioned artifacts: the status, the journal, the north star, the spec. Every write names the version it read, so an agent and a person editing the same artifact never overwrite each other. A new session starts where the last one stopped, and nobody re-explains the project.

#What a project keeps

The kind den runs itself on is spec-driven-build. Truth flows one way through it: a frozen vision spec, a living product spec, work, then the journal as evidence, and the status derived from it.

Slot	What it is	Who writes it
`north_star`	The one customer, the one thing they get, the metric, the ladder of rungs, the not-now list.	Once, then amended when a rung is climbed.
`status`	One page: where we are, green, red, the next three steps, the risks. Every claim points at a journal date.	Rebuilt from the journal at the end of every session. Never edited to record progress.
`journal`	Append-only, newest first: what was run, what happened, pass or fail.	The agent, after anything verifiable.
`gotchas`	Traps, append-only: symptom, cause, fix, and the rule that now applies.	The agent, when a trap is learned.
`evals`	A table of every measured run, so a change to quality is compared, not argued.	The agent, one row per run.
`product_spec`, `vision_spec`, `design_thesis`, `runbook`, `security_review`	The living spec, the frozen thesis, the UI principles, how the stack runs, the trust surface.	Deliberately, when they change.

Per-subsystem designs live under x-<subsystem>-design until they stabilise. Anything else a project needs is an x- artifact on the topic, never a change to the kind from a chat.

#Install in Claude Code

One plugin brings the connector and the skill that tells an agent how to use it:

claude plugin marketplace add https://den.pkslabs.com/.claude-plugin/marketplace.json
claude plugin install den@den-pkslabs-com

/mcp inside Claude Code opens the browser to sign in; on the consent page you pick the workspaces the agent may act in. A connector bound to your personal workspace is the usual reason den "has nothing" later: pick the shared one your team works in. claude.ai, Claude Desktop and any MCP client that speaks OAuth 2.1 add https://den.pkslabs.com/mcp as a connector and get the same tools; Connect an agent has every client.

#How a session runs

whoami: who the agent acts as, in which workspace, with which role.
get_topic <project>: the topic's instructions, the skills to load first, and the artifact list with head versions.
read_artifact <project> status, then the top of journal. That is the context. The work begins with it, not with a question.
Work. After anything verifiable, append_entry on journal: what was run, what happened, pass or fail. The tool dates it and puts it first.
At the end, write_artifact rebuilds status from the journal, passing the base_version it read.

A stale write is refused and says which version is the head now. A removal nobody confirmed is refused. Those are den's rules, not the skill's advice, and every client honours them.

#Your stack is a skill, not a kind

The kind carries the discipline: what a project keeps and in what order truth flows. What is yours, the cloud, the framework, the design system, the deploy conventions, lives in skills, which den stores as versioned resources of their own. A topic's skills list names what an agent loads before it acts, and get_skill returns the text on any client. Another team installs the same kind and points it at their own skills. Skills has the CLI and the mount side.

#Many projects, one workspace

A workspace is the unit of visibility. Members are owners, admins, members or viewers; a connector is authorized for the workspaces you pick, so an agent working on one client never sees another. Every change is a row in the audit log: who, from which device or agent, which artifact, which version and the one it replaced. Workspaces, roles, and the audit log has the roles table.