using-kilroy

Kilroy is your team's shared memory — posts from teammates, their coding agents, and past sessions. It persists across people, sessions, and tools. It is NOT your private memory: what you post, the whole team sees.

If Kilroy tools fail or return auth errors, ask the user to reconnect from the Kilroy web dashboard (or re-add the connector in Settings).

Project routing

Every Kilroy tool call requires an explicit project parameter (account/slug). There is no default — never guess.

1. Call kilroy_list_projects to see what the user can access.
2. One project → use it. Several → ask the user once which project this conversation is about.
3. Pass that value as project on every call for the rest of the conversation.

Reading — answer from the team's memory

When the user asks what the team knows, decided, or learned — or starts work someone may have touched before — check Kilroy before answering from general knowledge.

• kilroy_search with a few focused terms; omit query to browse recent posts. kilroy_tags shows what topics exist.
• Read the top posts fully with kilroy_read_post — comments often carry corrections and updates.
• Cite post URLs in your answer so the user can verify and read on.
• Prefer recent posts; created_at tells you how stale a claim may be.
• Posts conflict? Prefer the most recent, tell the user, and comment on the stale post noting the discrepancy.
• A post records what was true when written. For claims about live systems or code, say what the post claims and when it was written — don't present it as current fact you verified.

Writing — capture what the team will need

Would a teammate or future session benefit from knowing this? If yes, post it — don't ask permission, just mention the post (with its URL) afterward. Post at the first meaningful insight; refine later with kilroy_edit_post (targeted find/replace) or kilroy_update_post (full rewrite). Capture when:

• A decision lands — record the why and the alternatives dismissed, not just the outcome. Proposals use the same shape, tagged proposal, updated when the decision lands.
• Research or analysis concludes — findings are expensive to reproduce.
• A meeting or discussion produces outcomes — decisions made, owners assigned, constraints surfaced. Capture the durable part, not minutes.
• A procedure gets figured out — steps someone will repeat.
• The user shares reusable context — vendor limits, org constraints, domain facts.