The aim is to create a lightweight cross platform bot (starting with Telegram) that removes most of the admin now done by a project manager.
https://david.vision.ide.earth/assets/review-bot/review-bot.m4a
Review Bot audio note and transcript 
The bot should listen for audio updates, transcribe them, and use AI to extract the key details needed for weekly review and invoicing (such as who spoke, what work was done, the date, the number of hours, and the category of work).
Daily audio notes are meant to function as simple Scrum updates where each person says what they did, what they will do next, and any blockers. At the end of the week, the bot should turn these into a rough review and planning document with totals by person and links back to the source material.
This process is meant to support a simple Dynamic Equity system. Once the team agrees the weekly review is accurate (either by pressing a button or using a spoken approval phrase), the approved hours should be added to a record and then connected to the Slicing The Pie method or API.
The wider goal is to make it easy to add or remove contributors flexibly, including volunteers, without increasing admin. The system should stay very lightweight, mainly using audio based scrum updates and a bot generated review summary, while allowing the team to discuss disputes over effort, scope, or efficiency during the review meeting.
# Planning Meet
The planning meeting is where most of the important work should happen. People should roughly agree in advance what they expect to work on and how many hours they think they can contribute that week. That gives everyone a brief, makes later review easier, and creates a clearer basis for discussing whether work took more or less time than expected.
# Review Meet
Review meetings should then compare what was planned with what was actually done, helping the group discuss lessons learned, blockers, efficiency, and whether time claimed matches agreed priorities.
# Team Roles
There should still be a responsible person each week (described as a scrum manager or agile manager), but their role should be minimal because the bot should do most of the heavy lifting. If an audio note is incomplete, corrupted, or missing hours, the bot should flag this clearly and the responsible person should follow up.
Any disagreements about over reporting, under reporting, or work done outside agreed scope should be settled by the group or manager during review. Meetings should be short and practical, with detailed misunderstandings handled later in one to one conversations rather than slowing down the main group session.
# Future Developments
The first version should stay simple and focus on dynamic equity time tracking from audio notes, but there is a broader vision around Proof Of Understanding, trust building, and richer project management.
Meeting records could become evidence of shared understanding, helping generate trust graphs, knowledge maps, and visualisations of where alignment is strong or weak in the team.
There is also interest in linking this work into a podcast style format where weekly reviews become recorded, public facing updates with AI generated media and optional guest participation. Access could range from fully public to invitation only, depending on the project.
On the technical side, audio transcription should ideally use a local or self hosted Whisper setup rather than paid transcription services, to keep costs low and make the system more sustainable.
The audio files, transcripts, and summaries should be stored in a simple structured way, such as flat files linked to wiki pages, while keeping the option to move later to other storage back ends. Longer term, the project could expand into integrations with GitHub, issue trackers, quality review tools, and more advanced scrum platforms, but the immediate priority is a practical minimum system that helps early stage teams coordinate work and manage Dynamic Equity with as little friction as possible.
# A lightweight AI bot for weekly reviews, dynamic equity, and audio-first scrum Want to replace clunky project admin with a simple Telegram bot and short voice notes? This workflow turns daily audio updates into transcripts, summaries, weekly review documents, and dynamic equity records — with minimal overhead, clearer accountability, and a path towards richer Scrum and project-management tooling. --- ## Overview This transcript outlines a proposed system for running a lightweight weekly review process using a bot, initially on Telegram, to reduce the need for manual project management administration. The core idea is simple: 1. Team members send short audio updates. 2. A bot transcribes them. 3. Artificial intelligence|AI extracts key information such as: - who did the work, - when the work was done, - how many hours were spent, - what category or task the work belongs to, - any relevant links or outputs. 4. At the end of the week, the bot compiles this into a review and planning document. 5. Once agreed, the approved hours are recorded into a dynamic equity system, potentially using the principles or APIs of Slicing Pie. The intention is to make the whole process as lightweight as possible, especially for early-stage teams, volunteer collaborations, and experimental projects. --- ## The problem being solved The discussion begins with a practical need: to avoid paying a project manager to manually collect updates, summarise work, and administer weekly reviews when existing tools and team members should be able to handle most of that process automatically. The proposal is not to build a full enterprise project-management suite from day one. Instead, the aim is to create a minimal, functional workflow that is: - cheap to run, - easy for contributors to understand, - suitable for small and evolving teams, - flexible enough to support people joining and leaving, - able to feed into a dynamic equity model. This is framed as a pragmatic, early-stage coordination tool rather than a replacement for mature systems such as Jira, GitHub, or Monday.com. --- ## The basic bot workflow ### 1. Team members post audio notes The starting point is a bot that listens for an audio file posted in a Telegram channel or group. At first, the implementation should stay simple. There is mention that it could later become more sophisticated by using keywords or command structures, but the first version only needs to do the basics reliably. Each audio note functions as a kind of daily scrum update. A contributor would describe: - what they did since the previous update, - how much time they spent, - what they are planning to do next, - any blockers they have encountered, - any links or outputs that should be referenced. A typical update might include points such as: - “I spent two hours discussing the plan for the week with Matt.” - “I then wrote that up and posted it to the Telegram group.” - “I spent an hour writing about the Berlin meeting and the identity work, because I want to share it with Audrey Tang.” - “I will link the URL and post it to the wiki.” - “Tomorrow I plan to do X.” - “These are my blockers.” This turns informal voice notes into structured work records. --- ### 2. The bot transcribes the audio Once an audio note is received, the bot should transcribe it automatically. A significant point raised in the transcript is that transcription should ideally be done using a locally hosted Whisper (speech recognition)|Whisper model rather than a paid transcription API. The reasoning is cost efficiency. The view expressed is that paying a third-party service for something that can be transcribed locally is unnecessary, especially when the system may eventually process many audio notes. A local or self-hosted transcription setup would avoid wasting money on repeated token or API costs. The preferred options are: - run Whisper (speech recognition)|Whisper locally on a development machine, - or host it on the team’s own server, - while keeping the option to move between environments as needed. This reflects a wider design principle in the conversation: use local and self-hosted tools where practical, while still allowing cloud deployment where necessary. --- ### 3. AI extracts structured information After transcription, the bot should use an AI prompt to identify and pull out the information needed for reporting. For the weekly review, the key fields include: - the named person, - the date or day of the work, - the number of hours, - the category or topic of work, - the title or summary of the activity, - links to relevant outputs, - a link back to the transcript or original audio file. For example, if someone says they spent two hours planning with Matt, the bot should be able to extract: - contributor: David, - duration: 2 hours, - activity: weekly planning discussion, - associated record: transcript/audio link. This is important because the weekly review should not merely store raw transcripts; it should generate useful summaries of effort and deliverables. --- ## Daily audio notes as lightweight scrum The transcript describes these notes as effectively audio-based Scrum updates. The suggestion is that work areas for the coming week should ideally already have been discussed in a planning meeting, probably on a Sunday or perhaps on a Monday morning. However, it is also said that the planning meeting is not absolutely essential in every case. What matters most is that each person gives a simple account of what they are doing. This produces a lightweight process in which: - contributors check in by sending audio, - other team members can listen to the updates, - the bot captures a record automatically, - the group remains aware of who is doing what without needing heavy written admin. The aspiration is to make scrum “fun to listen to” rather than burdensome. --- ## The weekly review document At the end of the week, someone should be able to trigger the bot with a command such as: “Review — create review planning document.” The bot would then compile a summary for the week. An example output might say: - David worked Monday, Wednesday, Thursday, and Friday. - Total time: about 24 hours and 10 minutes. - Topics worked on: specific projects, pages, or categories, with links. - Matt worked 6 hours on another area. - Other contributors’ work is listed similarly. This document should ideally be generated before the review meeting so that whoever is facilitating the meeting can open it, inspect it quickly, and perhaps tidy it up slightly rather than creating it from scratch. The weekly review therefore becomes a discussion around an automatically prepared document rather than an exercise in manual note-taking. --- ## The role of the review meeting The review meeting is not just for listing hours. It also serves as a collective sense-making process. The transcript suggests that the meeting should include discussion of: - how the week went overall, - what everyone did, - lessons learned, - what could be improved, - any disagreements or questions about effort, scope, or efficiency. If everyone agrees with the review, a final approval step can be taken. This might be: - pressing a button in the bot, - or giving another agreed audio command. One suggested phrase is “burn to dynamic equity”, meaning that the agreed record of hours is now committed into the equity-accounting system. --- ## Dynamic equity and Slicing Pie A major purpose of the system is to support dynamic equity, where contributors accumulate equity based on work contributed over time. Once the weekly review is approved, the bot should add the agreed hours to: - a text file, - a database, - or another record system, which could then call an API connected to the Slicing Pie framework or a similar mechanism. The transcript makes clear that the long-term goal is not necessarily to depend permanently on another platform, but rather to: - lean on the methods, - adopt useful contracts and models, - learn from established approaches, - and eventually integrate them into the team’s own platform. This is seen as especially valuable because it allows fluid collaboration. For example: - a new volunteer could join for one week and earn dynamic equity, - an existing contributor could step away for two months, - someone else could temporarily take over a workstream such as the “Oasis” component, - the team can remain flexible without losing track of contribution and fairness. In short, the review process and the equity process should be linked, but with as little administrative burden as possible. --- ## Handling disputes and judgement calls The transcript recognises that not all work reporting can or should be fully automated. Examples are given of two kinds of edge case: ### Under-claiming Someone may have done significant work but only report or invoice a small fraction of it because they lack confidence in the value of their contribution. For example, if someone spent a full day in a useful meeting but only claimed four hours, the group may wish to correct that and encourage more accurate accounting. ### Over-claiming or off-scope work Someone may report many hours on work that was not part of the agreed priorities for the week. For instance, a person might say they spent 20 hours on some code, but if that was not what the team agreed should be done, the group may decide only part of that time should count towards the week’s approved work. This is where human governance still matters. The transcript suggests that these judgements should be handled by: - the scrum manager, - the agile manager for the week, - or the consensus of the group. The bot should facilitate the process, not replace collective judgement. --- ## Error handling and safeguards A specific question raised in the discussion concerns what should happen if a voice memo is incomplete or missing important information. The answer is that the bot should have basic safety and validation features. For example, if: - the audio file is corrupted, - the transcription fails, - no hours are detected, - key fields are missing, then the bot should return a clear error message such as: - “I couldn’t transcribe this.” - “I transcribed this, but no hours were registered.” At that point, the responsible human — described as the scrum manager or agile manager for that week — should intervene by: - listening to the original note, - reading the transcript, - asking the contributor to clarify, - checking whether they intended not to claim hours. Again, the principle is that the bot should do as much as possible, while the designated human only handles exceptions. --- ## The importance of planning meetings Although one comment suggests the planning meeting can sometimes be skipped, the broader discussion makes clear that planning is actually where much of the work should be done. In the planning meeting, team members would estimate what they intend to contribute in the coming week. For example: - Max might say he is busy with paid work but can still attend meetings and spend about 3 hours thinking about the anarchive and swarm work. - Someone else might say they are preparing for a Berlin trip, want to spend 2 hours each morning writing, and also need to get up to speed on Oasis while helping build the bot. - The group might then decide that the website is a higher priority than the bot and redirect effort accordingly. - A contributor might then commit to, say, 10 hours on graphic design for the website, 8 hours on writing, and collaboration with Henry on named tasks. This creates a rough weekly brief. Then, during the week, daily updates can be compared to that expected allocation. At the review meeting, the group can ask useful questions such as: - You said you would spend 10 hours on this — why did it end up taking 16? - Was the estimate wrong? - Was the task more complex than expected? - Did priorities change? This is presented not as punishment, but as a basis for learning, negotiation, and process improvement. --- ## From rough process to better project discipline One important idea in the transcript is that this simple workflow could become the training ground for better collaboration. By repeatedly comparing: - planned work, - reported work, - delivered work, - and reviewed work, the team can gradually build more robust working agreements. This could help with: - negotiating expectations with developers, - understanding what good estimates look like, - identifying inefficiencies, - documenting norms and rules, - and eventually training the bot on those patterns. In other words, the bot is not only an automation tool; it could also become a repository of project-management practice. --- ## Positioning: early-stage tool, not enterprise software The speaker makes a distinction between this proposed system and mature platforms such as Jira, GitHub, or Monday.com. The idea is not to compete immediately with those systems on all features. Instead, the goal is to create a very lightweight entry point for teams that are: - small, - emergent, - open-source oriented, - volunteer-heavy, - using dynamic equity or time-based contribution models. A person should not need to be a professional software developer or trained project manager to use it. Ideally, they just learn to send voice notes in a certain format and can then participate in coordinated teamwork. Later, if a project becomes more serious or more complex, they can: - migrate to a dedicated scrum system, - hire a professional agile manager, - integrate with more advanced services, - or extend the bot’s functionality. This is a deliberately staged approach. --- ## Product and service possibilities The transcript also hints at a broader ecosystem around this idea. There could eventually be: - multiple service levels, - libraries of support services, - professional scrum or agile managers who can be hired, - options for payment in cash, time banking|time-bank credits, or dynamic equity, - configurable modules for different team types. The team behind this particular tool would specialise in the early-stage dynamic equity use case: a “good enough” process that reduces avoidable arguments and creates clarity where things are straightforward. --- ## Building on existing work and integrating with Mitch’s bot A question is raised about how far along Mitch is with his existing Telegram bot, and whether any of that can be reused. The answer is essentially yes: the intention is to build upon what already exists where possible. This reflects a general preference in the discussion for iterative development rather than starting from zero. Existing bot functionality should be incorporated if it is useful, especially if that accelerates getting a basic workflow into use. --- ## Audio, podcasting, and public process Another important dimension is that the workflow is not only administrative; it is also potentially media-facing. There is a desire to integrate the daily check-ins and weekly reviews into a podcast-like or publicly accessible process. The idea is that: - daily updates could be mixed with AI-generated background elements, - weekly reviews could become recorded meetings, - graphics might be shown, - AI voices or other generated media might be used, - guest participants could occasionally join. This is framed as a form of open process: a visible, ongoing account of what the team is doing week by week. Different visibility settings could be offered: - fully public, - publicly discoverable but not actively promoted, - invitation-only, - restricted to members or a current project group. So the system is conceived not only as internal coordination infrastructure, but also as something that can support open documentation and public storytelling. --- ## Proof of understanding and trust graphs A particularly interesting idea in the transcript is that meetings and confirmations can be used as inputs to a “proof of understanding” system. For example: - Mitch says he is going to do certain tasks. - The project manager repeats back their understanding: “What I understand you to mean is X, Y, and Z.” - Mitch confirms that this is correct. That exchange creates a record that both parties share the same understanding. Similarly, in a review meeting, the group can confirm that the expected work was actually delivered. This becomes another trust-building signal. From these interactions, it may be possible to generate: - trust graphs, - understanding maps, - visualisations showing where alignment is strong, - indicators of where knowledge is concentrated or where misunderstandings are more likely. For instance, the system might reveal that: - Max has strong understanding of one cluster of work, - David is working on another area that others understand less well, - a future meeting should therefore focus on improving shared understanding in that weaker area. This could become part of a wider coordination and onboarding system. --- ## Onboarding, personality types, and richer team intelligence The transcript briefly suggests that this project could eventually connect with: - onboarding systems, - team-type or personality models, - action-orientated profiles, - broader project graphing and visualisation tools. These are mentioned as future layers that could feed into the overall system. However, the speaker is careful to emphasise that the immediate focus should remain narrow: - get the bot working, - process the audio updates, - track time for dynamic equity, - and only then experiment with more complex prompts, graphs, and visualisations. This staged sequencing is important, because it avoids overbuilding before the core workflow is proven useful. --- ## Storage of audio files, transcripts, and summaries There is also discussion of how to store the underlying materials. The current preferred approach is very simple: - create a weekly page for each documentable activity, - include an embedded audio player for the full recording, - include a link to the transcript, - include a link to the AI summary, - store the audio file in a named folder that matches the related wiki page. This creates a flat-file structure that is easy to inspect and manage. However, the transcript also makes clear that storage should remain flexible. Possible locations include: - a local filesystem, - a server such as Vercel, - a PostgreSQL or MongoDB database, - decentralised or replicated storage options, - external file services such as Pinata. The key architectural principle is abstraction: the code should target a stable API so that storage back-ends can be swapped later without rewriting the whole application. --- ## Oasis and replication The discussion references Oasis as part of a desired longer-term architecture, especially in relation to replication and storage flexibility. The idea appears to be that content should be capable of being placed: - on a local file system, - on cloud infrastructure, - in databases, - or via alternative storage layers, while maintaining a consistent application interface. This aligns with the broader philosophy of portability, resilience, and avoiding lock-in. --- ## Local-first development and deployment flexibility A strong technical preference expressed in the transcript is that code should run locally first, but also be deployable to a shared server so that it can become globally accessible. The envisioned workflow is: - develop and test locally, - use local mirrors where useful, - deploy the same code to a server when wider access is needed, - retain the option of home-lab or self-hosted deployment, - avoid unnecessary dependence on expensive third-party processing. This local-first but deployment-flexible approach is especially important for a project that wants to support experimentation, autonomy, and cost control. --- ## Future extensions Once the core bot is working, the transcript imagines many possible extensions. These include: - assessing work quality by reviewing GitHub commits, - integrating with the GitHub API, - using issue trackers as part of the workflow, - adding richer project-management features, - building more elaborate summaries and visualisations, - allowing the community to fork and adapt the system, - potentially monetising code or custom versions. This is described in terms of “vibe coding the future”: creating a working prototype that can evolve through use, experimentation, and community adaptation. --- ## What the first version should actually do Despite all the future possibilities, the immediate goal is much narrower and more practical. The first version should: 1. Accept audio notes, probably via Telegram. 2. Transcribe them using a local or self-hosted Whisper (speech recognition)|Whisper setup. 3. Extract: - contributor name, - hours, - date, - task category, - short summary, - relevant links. 4. Store: - the original audio, - the transcript, - the AI summary. 5. Produce a weekly review and planning document on request. 6. Allow a human-led review meeting to confirm, adjust, or dispute entries. 7. On approval, commit the agreed hours to a dynamic equity record. 8. Minimise admin for the scrum or agile manager by only escalating errors and ambiguities. That is the real operational core. --- ## Final framing The transcript presents this as a practical and philosophical project. Practically, it is about reducing friction in team coordination, especially for small groups with limited resources. Philosophically, it is about creating a lightweight, transparent, audio-first collaboration method that supports: - fairness, - flexibility, - trust, - open process, - and gradual scaling. Rather than starting with a heavyweight system, the approach is to begin with the simplest thing that works: voice notes, transcription, summaries, review, agreement, and dynamic equity accounting. If that works well, richer project-management, trust mapping, public reporting, and community tooling can grow from there. --- ## Concise takeaway The proposed system is a lightweight Telegram-based bot for audio-first Scrum updates and weekly reviews. It transcribes voice notes, extracts hours and tasks, generates review documents, and feeds approved contributions into a dynamic equity system inspired by Slicing Pie. The emphasis is on keeping admin minimal, using local tools such as Whisper (speech recognition)|Whisper to reduce costs, and building a flexible foundation that can later expand into richer project-management, trust, and public-process tooling.
# Assets
review-bot
# See - Hitchhiker Agents and Marvin - Energy Accounting