The caj-brief skill

---
name: caj-brief
description: Read and propose changes to this task's shared brief on caj — the team's versioned, authoritative statement of what they currently believe about the work. Use when you learn something that contradicts or should be added to the brief, when you need the agreed context before acting, or when the user asks to check or propose against a caj task.
---

# caj — the shared task brief

A **task** on caj carries one canonical **brief**: what the team currently
believes about the work. Goals, constraints, assumptions, decisions, open
questions, whatever they need.

Nobody edits the brief directly. You **propose a diff** against it, the team
discusses and votes, and accepted proposals become new immutable versions.
Read `get_brief` before you rely on any shared context, and before you propose.

The brief is not a summary of what everyone believes. It is the team's current
authoritative position under the task's rules. Disagreement is recorded rather
than resolved away — read the votes on a proposal to find it.

## The boundary you must respect

**You cannot vote, and you must not try to.** There is no vote tool. Accepting
a change to the team's shared position is a human act performed by a human in
the web UI. Do not ask a user to relay your vote, and do not describe a
proposal as agreed until `get_brief` shows it in the brief.

**Private stays private.** Your conversation with the user, your notes, your
scratch work, your context and memory are local. Nothing is uploaded unless the
user explicitly asks you to put it into a proposal or a comment. When you think
something from your working session belongs in the brief, say so and ask —
then propose it.

## When to propose

Propose when you learn something the brief should say and does not:

- a decision the user just made, with its reasoning
- an assumption you have been working under that is not written down
- a constraint you discovered (an API limit, a deadline, a dependency)
- an open question you hit that only a teammate can settle
- something in the brief you found to be wrong

Do not propose your own progress, your plan, or a status update. The brief is
the shared model of the work, not a log of what you did.

Say in one line what the change is and why (`summary`). Send the **complete
brief as you want it to read** in `content` — call `get_brief` first and edit
that text. Pass the `base_version` it returned; if the brief moved while you
were drafting, the proposal is refused and you re-read rather than silently
clobbering someone.

Mark a proposal `editorial` only when it changes no meaning at all — a typo,
grammar, formatting. Editorial changes land faster, so miscategorising a real
change to slip it through is a serious misuse.

## Two kinds, two rules

| | accepted when |
|---|---|
| `normal` | every active main user votes +1 — or, after 7 days with no activity, more +1 than −1 |
| `editorial` | one other main user votes +1 — or, uncontested, after 24 hours with no activity |

A −1 must carry a comment explaining the objection, and an objection takes an
editorial change off the fast path. Any vote, comment, or edit resets the
inactivity clock. People who mark themselves away are not waited on.

Editing a proposal's text clears every vote already cast on it: people voted on
that proposal, not on the idea behind it. Expect to lose them.

## Tools

| tool | what it does |
|---|---|
| `list_tasks` | the tasks you take part in, with your role and each brief's version |
| `get_brief` | the current brief — read this first |
| `get_history` | accepted versions, who proposed each, who supported, who objected |
| `list_diffs` | proposals on a task, optionally by status |
| `get_diff` | one proposal: the change, every vote with its reasoning, the discussion |
| `propose_diff` | open a proposal (the whole brief as you propose it should read) |
| `edit_diff` | revise your own proposal — clears its votes |
| `comment_diff` | add to a proposal's discussion |

`task` takes a `tsk_` id or, when the task is linked to a repository, the repo
(`owner/repo` or a git URL) — so from inside a checkout you can usually just
pass the repo.

## Connect

```sh
claude mcp add --transport http caj https://codeasjunk.com/mcp --header "Authorization: Bearer <token>"
```

Create the token on the tokens page at https://codeasjunk.com.

Free tier: 3 tasks, 4 invited participants per task, 20 proposals per task per
UTC day.