Cliper

Cliper helps non-technical teams understand engineering updates and project architecture in real time without waiting for developers response. It works by syncing real time git activities of dev team.

Comment

Inspiration

From a POV of a non-technical co-founder , marketer , designer etc. in Slack's workspace, i noticed few issues . Slack Organisation teams always faces challenges knowing about the development progress and product architecture/technicalities in real time. Before Cliper , Non-tech professionals needs to sync up with engineering team which makes developers go off their work and explains it in details over huddle call or chat conversations. These traditional way is not efficient when it comes to engineering syncs since it consumes a lot of time for both the professionals. There are options available which scrapes the previous chats and makes a response about the queries but they are not optimal because codebases are changing and developments is happening consecutively every minutes , every hours. Even though we use ai models with the previous conversation history , it's difficult to stay relevant and response with the exact engineering knowledge about the product because neither of them tracks git activities and response with real time data.

What it does

Cliper makes your codebase a Slack teammate with advance agentic capabilities with it's persistent memory that can be easily pluggable to the workspace from the agent bar. A engineer from engineering team needs to type out one command inside the repo they want to initialise :

cliper init

and once the cliper is initialized over the codebase , the engineer can bind it with any slack channel , which non-technical teammates can use to query anything from the latest or the past git activities happening and happened over the engineering department. A non-technical teammate can query anything and get the accurate answer but here are few examples that demonstrate the power of Cliper with persistent memory .

Emma from BD team asked : "What's still open on the roadmap?"

Priya from Product team asked : "What features shipped this month? , Is the multi-provider support done or planned?"

David from Marketing team asked : "Explain with diagram, what the incremental sync feature does, in simple terms? please share the flow , What's technically unique about our memory layer?"

Andrew from DevOps team asked : "What external services does this repo depend on? , Which modules touch the encryption layer?"

Bred, CEO asked : "Summarize engineering progress this week , What are the riskiest undocumented parts of our codebase? "

Even engineering team itself can use it : "How does the auth flow work end to end? , Which files does the sync command touch?"

How we built it

  • Slack agent (Bolt.js, Socket Mode, deployed on Railway): built on Slack AI capabilities - the Assistant class with setSuggestedPrompts and setStatus, app mentions, slash commands, App Home via Block Kit. The agent holds zero tokens; all identity resolution is server-side.

  • We build a CLI/SDK(TypeScript, open source, on npm as cliper-memory) : cliper-memory basically scans the repository and creates 2 things:

  1. Memory objects for each git activity of the codebase from the time repo was created to till date.

  2. Relationship Graph memories are connected by explicit, first-class relationships - this is what makes Cliper a knowledge graph rather than a document dump.

All these memory objects & relationships are stored in Cognee cloud which builds searchable knowledge graphs and makes it easily accessible over the slack workspace.

Memory Object types Cliper uses:

Memory Type What it captures
Repository Memory Identity of the project - name, purpose, top-level shape
File Summary Memory Per-file semantic summary: what the file does, not just its name
Responsibility Memory The role a file/module plays in the system
Architecture Memory Module boundaries, layering, structural patterns
Dependency Memory Internal import edges - who depends on whom
External Package Memory Third-party packages and where they are used
Git Memory Branch state, working tree context
Commit Memory Individual commits with messages, authors, changed files
Release Memory Release points in project history
Timeline Memory The evolution of the repository over time
Issue Memory GitHub issues attached to the repository
Pull Request Memory GitHub PRs with their commit and file linkage
Gap Memory Undocumented patterns and risky corners, ranked by severity

Different relationship graph 

Repository ──▶ Commit          Repository ──▶ Issue
Repository ──▶ Release         Repository ──▶ Pull Request
Repository ──▶ Timeline

File ──▶ Dependency            Commit ──▶ Changed Files
File ──▶ Responsibility        Pull Request ──▶ Commit
Module ──▶ Architecture        Pull Request ──▶ File
Package ──▶ Repository         Gap ──▶ File Release ──▶ Commit
  • Backend is built on Express + Supabase + Deployment on Railway : GitHub OAuth -> JWT, repository registry, Slack account linking (slack_links), channel -> repo bindings, and a chat proxy that resolves channel -> repo -> owner's encrypted Cognee credentials.

Challenges we ran into

Cognee ingestion at repo scale: sending one large context document blew up Cognee's extraction step (IncompleteOutputException). The fix became a design principle , One self-describing chunk per memory object, batched adds, single cognify. Reliable at 300+ memories per repo.

Memory that doesn't relearn daily: full re-uploads made "memory" a lie. We built manifest-based incremental sync and now every chunk content-hashed; an unchanged repo syncs in ~2 seconds with zero API calls.

The authorization model: requiring every asker to link GitHub would have locked out exactly the people Cliper serves (PMs, leadership, Designers etc.). We inverted it: the developer's act of binding a repo to a channel is the authorization; Slack membership is the credential.

Production honesty: a silent RLS misconfiguration made account linking "succeed" while writing nothing; a Bolt version mismatch crashed only in deployment. Both taught the same lesson, make failures loud, pin versions, verify with curl not vibes.

Our Cognee tenant went down mid-build once: per-user credentials meant a fallback to self-hosted Cognee would have been a config swap, not a rewrite. We are coming up with new providers soon , so we don't have the dependency on Cognee. we are able to do that because the actual memory type and relationship is build on our end inside Cliper sdk so building and plugging new providers like a local-Json Object provider can really help us with this. along with other list of providers we have in the pipeline like Supermemory , Neo4j etc.

Accomplishments that we're proud of

  1. We have a live npm package called cliper-memory which anyone can use link .

  2. We just made our sdk repo open-source and we got 5 star as of now . and one external contributors. (not much but we'll work on this eventually).

  3. Diagrams from memory , ask for an architecture flow over slack and the agent draws it.

  4. A working end-to-end agent: link, bind, ask, answer running entirely on deployed infrastructure, nothing on a laptop.

  5. The zero-setup team model: our test "product manager" account asked the codebase questions with no GitHub, no keys, no onboarding. Shared in the demo video.

  6. We also started with our socials.

What we learned

Chunking discipline matters more than model choice, Graph quality tracked how well we structured memories, not how much we sent. Authorization boundaries should follow human trust structures (a channel) rather than developer plumbing (a token). Socket Mode makes agents absurdly portable. Our "deployment" was moving a process, zero URL registration. And the oldest lesson, relearned at 1 AM: when the deadline is 36 hours away and i thought of rewriting the working backend in a new framework , which after a walk , i realized that it's not the right approach to proceed it. so i decided to move after this hackathon.

What's next for Cliper

  1. Next, we'll add new memory providers to make memory objects and relationships accessible across different storage backends.

List of the upcoming providers:

  • Local JSON Memory Provider
  • Supermemory Provider
  • Neo4j Memory Provider
  • LanceDB Memory Provider
  • Graphiti Memory Provider
  • PostgreSQL + pgvector Memory Provider
  • Memgraph Memory Provider

2 MCP Server: Expose repository memory as MCP tools so any MCP-compatible client, including Slack's MCP client, can consume it.

3 Shift the backend from Express.js to NestJS. Reorganize the web components to make them more accessible to the vibe coding community. Continue development of the React Native (Expo) application, which is currently halfway complete.

4 Slack Marketplace listing.

5 Agent task execution: dispatch coding tasks from Slack to the developer's laptop, where Claude Code runs briefed by the same cliper memory and does edits, tests, and commits stay local; only knowledge travels.

Built With

Share this project:

Updates