What Ticulate is
An always up-to-date status page for a project — and the shared record around it that people and agents both read from and write to.
The problem it exists for: nobody can answer where is this project at? without reassembling it from a task board, a few documents, a chat thread and their own memory. Every answer is a re-derivation, and it is stale the moment it is given. Agents have the same problem in a sharper form — a session that ends takes its context with it.
Three audiences, one page
A Ticulate project is read by three kinds of reader, and the shape of it follows from that.
- An agent picking the project up. It calls one tool and gets the architecture, the conventions it must not break, the decisions already settled, and the work still outstanding — so it starts from where the last session stopped instead of re-deriving it.
- Several people and agents working together. Every write is attributed, and the writes that replace a whole section can be refused if someone changed the project underneath you.
- Stakeholders. A live window into where things stand, and somewhere to push the project forward without chasing anyone for an update.
What a project holds
A project is not a blank document. It is a set of named parts, each with its own shape and its own writer, and that is what makes an agent's work reviewable rather than a diff against prose.
| Part | Holds |
|---|---|
| Purpose | Why it exists, who for, what success looks like, and the constraints it must hold to |
| Architecture | Services, where to start reading, environments, conventions, open questions |
| State | Status, the standing paragraph, and exactly one next step |
| Features | Capabilities that shipped, with the review asked of each |
| Roadmap | In progress, planned, considering |
| Tasks | The work list — jobs to do, as distinct from features |
| Activity | Updates and decisions, one timeline for people and agents |
| Feedback | Problems, requests and questions from anyone with the link |
| People | Humans and agents, with the access each holds |
Features are not tasks
This distinction does more work than it looks like it should. A feature is a capability somebody could have an opinion about — it is what stakeholders are asked to review. A task is a job on the list: deploy, migrate, refactor, tidy up. Filing build work as features buries the things you actually want opinions on.
The test: would a stakeholder have a view on this, or does it just need doing?
Fixed vocabularies
Five words for status, no synonyms, so a project's standing means the same thing everywhere:
shipped · ontrack · atrisk · blocked · idle
Visibility is private, shared or public. Access is read only or read + write.
Where to go next
- Quickstart — connect an agent and publish a page
- The agent layer — what the skill asks an agent to do, and why
- Published pages — what a visitor sees, and what stays private