Most documentation tools live outside your repository. Your code changes. Your docs don’t. Drift is inevitable. Doclific addresses this problem in two ways: 1. Your docs all live in one place: your repo. This is the way it should be, ensuring engineers always have access to the correct version of docs. 2. Doclific features ERDs, architecture diagrams, smart snippets, etc. No more context switching. No more drift. Oh, and if you're lazy, you can just prompt the AI to generate docs for you!
This project originated from a real need. Internal documentation is almost always either outdated or in a poor format (KT sessions, spread out over several Google Docs + Lucid Charts, etc). I aim for Doclific to be a free, all-in-one solution to this problem.
Please, be brutally honest, would you use this? What other challenges do you encounter with documenting currently?
This Smart Snippets feature feels like it has massive potential. It links code snippets directly to documentation, so when the code changes, the relevant documentation sections get an automatic update prompt. In theory, this should completely solve the problem of outdated docs. I’m curious how accurate and flexible this intelligent linkage is in practice, though. For example, can it accurately detect refactoring actions like function renaming—instead of triggering an update prompt for every tiny line tweak, and avoid creating too much update noise?
The advantage of open-source projects is their continuous improvement, but as a user, I may not have the ability to solve technical problems on my own. Does this project currently have an active developer community or forum? If I encounter bugs during use or have ideas for new features, are there channels to get help or provide feedback?
Congrats on the launch! My doc in cursor always get messy after several modifications, contents of the same feature got scattered in different places. Would Doclific prevent this from happening?
The core idea of controlling an entire computer with "micro-movements" is incredibly clever, and in theory, it should adapt to the residual motor abilities of different users. Before actual use, for my specific and potentially extremely weak movement signals, is the system’s calibration process intuitive and user-friendly enough? About how many repeated attempts does it take to achieve usable accuracy?
Doclific sounds like a huge relief for anyone tired of outdated documentation! I’m really curious how it handles complex architecture diagrams can the AI actually visualize the code structure accurately just from a prompt? Since everything lives in the repo, I wonder if the docs stay readable for non-technical teammates or if it’s strictly for engineers. Does the "smart snippets" feature update automatically when the source code changes, and is the AI smart enough to document legacy code that’s a bit messy? It would also be great to know if it integrates with existing CI/CD pipelines to flag any documentation drift during a pull request!
If this is true auto curation of documentation then it will be awesome. Documentation has become so much more important in the age of AI Agents as a means of keeping them grounded in the reality of the codebase that they work within.
Woah, congrats man. This is awesome. I am so intrigued to play with this. We've been doing lots of work with docs lately
Docs-in-repo is the right call, but at scale the hard part is drift detection across monorepos where refactors and renames silently break code-linked snippets and diagrams.
Best practice is a CI gate that resolves references via AST/symbol IDs (not just file paths), runs link checks, and posts PR annotations with suggested doc patches plus a fail threshold you can tune per directory.
How are you extracting and versioning “smart snippets” (tree-sitter/TS compiler API, etc.), and can Doclific auto-open a PR with regenerated MDX when referenced symbols change?
The 'Docs as Code' approach is the only way to truly fight drift. Keeping docs in the repo ensures they undergo the same PR process as the code, which is a massive win for consistency. You asked for honesty: I’d definitely use this if it replaces the nightmare of syncing Notion/Confluence with GitHub. My question: (1) Since the docs live in the repo, how does Doclific handle non-technical stakeholders (like PMs) who might need to read or edit the docs without diving into the codebase? (2) Are these diagrams stored as code-based definitions so they are version-controlled, or are they handled differently? When code changes significantly, does Doclific have a 'check' or 'alert' system to remind engineers that a specific doc or snippet might now be 'drifting' and needs a re-prompt?
Luke
This project originated from a real need. Internal documentation is almost always either outdated or in a poor format (KT sessions, spread out over several Google Docs + Lucid Charts, etc). I aim for Doclific to be a free, all-in-one solution to this problem.
Please, be brutally honest, would you use this? What other challenges do you encounter with documenting currently?