Reference

MCP tools reference

`get_product_context`	Learn PugBase's concepts (sessions, notes, plans, sources) - call once per session.
`list_workspaces`	List the workspaces your key can access.
`get_plan_spec`	Read the full plan, aggregated - tasks grouped per feature, each note with its assignee and live done="X/Y" progress (a `- [x]` is already done, by you or another agent). Call this first when building from a plan.
`list_plan_notes`	List the plan's notes - to target push_result.
`list_notes`	List every note in the workspace with its session/folder.
`search_notes`	Full-text search notes by keyword; returns best matches with previews.
`get_note_spec`	Read a single note's content (docs and diagrams).
`list_sources`	List a note's ingested sources (meeting transcripts, PDFs, docs).
`get_source_transcript`	Read a source's full transcript - the ground truth behind a requirement.
`get_note_comments`	Read the human review comments on a note.
`create_note`	Create a new note (reports, specs, docs); optional folder organises a doc set.
`save_memory`	Save a durable fact (decision, convention, gotcha, feedback) into the team's shared Memory - future sessions start knowing it.
`export_memories`	Compile the whole Team Memory into one markdown doc - e.g. to write a CLAUDE.md snapshot into a repo.
`create_diagram_note`	Create a diagram note (flowchart from Mermaid, ER from DBML).
`push_result`	APPEND a result into an existing note (reports, findings).
`update_note`	REPLACE a doc note's content when it is now wrong; the old body is version-backed-up first.
`update_diagram`	REPLACE a diagram note's content; the old canvas is snapshotted to history first.
`mark_task_done`	Tick a checklist task so the human sees progress. First tick on an unassigned note claims it for your member; ticking another member's note returns a warning.
`reopen_task`	Reopen a task that was marked done but is NOT actually done (QA found a bug / missing case), WITH a reason. The reason shows on the Status board and in get_plan_spec so the owning agent fixes exactly that.
`upload_image`	Upload a screenshot; returns an inline image.
`upload_file`	Upload a self-contained .html; returns an interactive embed.

Teach Claude once with `CLAUDE.md`

Save this in your project root and Claude Code picks up the whole workflow automatically every session - no need to re-explain.

# PugBase + Claude Code

This project is connected to a PugBase workspace over MCP (see .mcp.json).
Read the plan from PugBase and report your work back into PugBase notes.

## MCP tools (server: pugbase)
- get_product_context    - PugBase concepts primer (call once per session)
- get_plan_spec          - read the full plan (call this first when building)
- list_plan_notes        - list the plan's notes (to target push_result)
- list_notes / search_notes - find any note (search by keyword, not by scanning)
- get_note_spec          - read one note's content (docs and diagrams)
- list_sources / get_source_transcript - a note's ingested files (e.g. the
  meeting transcript behind a requirement - the ground truth when specs clash)
- get_note_comments      - human review feedback on a note (overrides the body)
- create_note            - create a new note (reports, specs, docs)
- save_memory            - save a durable fact into the team's shared Memory
- export_memories        - compile the whole Team Memory into one markdown doc
- create_diagram_note    - create a diagram note (Mermaid flowchart / DBML ER)
- push_result            - APPEND a result to an existing note
- update_note            - REPLACE a doc note that is now wrong (old body is
  version-backed-up; never create a "v2 copy" of a doc just to update it)
- update_diagram         - REPLACE a diagram note (old canvas snapshotted)
- mark_task_done         - tick a checklist task (mirror of real progress)
- reopen_task            - reopen a "done" task that failed QA, WITH a reason
  (the reason reaches the owning agent via get_plan_spec - the QA feedback loop)
- upload_image           - upload a screenshot, returns ![](url)
- upload_file            - upload a self-contained .html, returns a ```embed block

## Team memory
The workspace keeps a shared memory: each memory is a note in the "Memory"
session, indexed in "MEMORY.md" (announced on connect when memories exist).
Read the index before your first task; open a memory only when relevant.
When something durable happens - a human corrects your work, a decision is
settled, a gotcha costs real time - write it back with save_memory so every
future session (anyone's) starts knowing it. Reuse the slug to update.

## Standing instructions as a note
You can keep this project's real instructions IN PugBase instead of in this
file: create a note titled "CLAUDE.md" (or "AGENTS.md" / "skill.md") in the
workspace. The MCP server announces it on connect - read it with
get_note_spec BEFORE the first task of every session and follow it exactly
as you would a local CLAUDE.md. Edit the note in PugBase to change the
rules; no commit needed.

## Workflow
1. Read the plan with get_plan_spec.
2. Build it. Follow the Constraints exactly; if a point is ambiguous or
   offers a choice, ask before guessing - and check get_note_comments /
   the source transcripts before guessing at intent.
3. Report back to PugBase as you finish each part (push_result), tick the
   checklist (mark_task_done), and fix any doc the change made stale
   (update_note / update_diagram).

## Team plans (feature split + claim)
- A plan's Tasks are grouped per FEATURE, and a task note can carry an
  assignee (the member who owns it). Work ONLY the feature your user asked
  for; solo users can say "build all features" and you work through them in
  build order.
- NEVER tick tasks on a note assigned to another member - their own agent
  works it in parallel. Your first tick on an UNASSIGNED note claims it for
  your user; if a tick response carries a WARNING that the note belongs to
  someone else, surface it and stop unless your user explicitly asked.

## Writing good reports
- Default to NATIVE markdown: headings, pass/fail tables, findings, and
  screenshots embedded with upload_image. It is readable and the team can
  comment on each block.
- Use a ```embed block (upload_file of a SELF-CONTAINED .html, all assets
  inlined as data URIs) ONLY for genuinely interactive extras: a full test
  report, a trace, or a chart. Comments do not work inside an embed, so keep
  discussion-worthy content native.

## Test reports (Playwright etc.)
- Run with `--reporter=json`, parse pass/fail.
- create_note "QA Report" with a pass/fail table + findings + failure
  screenshots (upload_image). Add a ```embed only if an interactive report
  genuinely adds value.
- When a test FAILS on a task another agent marked done, reopen_task that
  task with the failure as the reason. The owning agent then sees the reason
  in get_plan_spec and fixes exactly that - that is the QA feedback loop.

Reference

MCP tools reference

Teach Claude once with CLAUDE.md

Teach Claude once with `CLAUDE.md`