Skip to content
Notifications
Clear all

Showcase: Our internal wiki is now way more useful thanks to Claude summaries

4 Posts
4 Users
0 Reactions
3 Views
(@emma23)
Estimable Member
Joined: 6 days ago
Posts: 68
Topic starter   [#21243]

Okay, I have to share this because it’s saving our team so much time. 😅

We use Confluence for our internal wiki, and it’s… well, a bit of a mess. Pages are super long, and finding the key takeaway for a process or a project update was taking forever.

Now, we’ve set up a simple automation where Claude automatically generates a summary for every new or updated page. It pulls the page content via the API, and Claude spits out a clear, 3-4 bullet point summary that gets pinned at the top.

The difference is huge:
* New team members can actually onboard themselves.
* We all skim the summaries in the weekly digest email instead of skipping it.
* Meetings start faster because everyone’s already caught up on the context.

It’s basically like having a super-organized teammate who reads everything for you and gives you the highlights. No more info overload!

Has anyone else tried something similar with their internal docs? Would love to swap tips on the prompt you used for summaries.

~E


Trial first, ask later.


   
Quote
(@datadog_dave)
Reputable Member
Joined: 2 months ago
Posts: 157
 

Love this idea! We did something similar for our runbooks in Confluence. The trick was tweaking the prompt to focus on action items for incidents - "if you see X, do Y" kind of bullets. Made a huge difference during on-call handoffs.

One caveat we found: summaries for highly technical design docs sometimes missed crucial nuance. We added a manual review step for those pages. Still saves time overall though.

What prompt are you using? Ours is pretty basic, wondering if you've tuned it for different page types.


Dashboards or it didn't happen.


   
ReplyQuote
(@backend_perf_guru)
Estimable Member
Joined: 4 months ago
Posts: 155
 

The productivity gains from reducing cognitive load are real, but I'm curious about the latency profile of this automation. Every new or updated page triggers an API call to an external LLM service. Have you measured the P99 latency for page save operations since implementing this? I've seen similar setups introduce multi-second delays that frustrated authors.

Also, summaries pinned at the top become stale cache entries. If someone rapidly iterates on a draft with minor edits, you're either generating wasteful, expensive summaries or need a debounce mechanism. Did you build in a delay or an edit count threshold before triggering Claude?

For prompts, we found structuring them as a query plan works best: "Extract the primary objective, list explicit action items, note any stated deadlines or owners, omit background unless critical." This gives more consistent output than a generic "summarize this."


--perf


   
ReplyQuote
(@cloud_cost_analyst_pro)
Reputable Member
Joined: 4 months ago
Posts: 168
 

Good points on latency and cost. The debounce mechanism is essential.

We implemented a 90-second delay after the last edit before triggering the API call. Saves a significant amount on tokens for drafts. We also cache the summary against a hash of the content, so minor edits don't trigger a regen.

The prompt structure you mention is key. We found adding "Assume the reader is a technical team member familiar with our stack, omit basic glossary terms" cut down on fluff and improved accuracy.


cost per transaction is the only metric


   
ReplyQuote