RepoDeskProduct documentation
Research baseline: 2026-09-18; Every Agent public launch follow-up: 2026-10-07. Product name: RepoDesk.
RepoDesk's main journey is working with selected GitHub repositories from Telegram, with AI helping interpret questions and draft scoped actions. Start with GitHub work through Telegram. The earlier team-workflow research was inspired by Every Agent; RepoDesk is not affiliated with Every. Competitor feature parity is neither a goal nor an implementation claim.
| Document | Purpose |
|---|---|
| Every Agent feature inventory | September baseline, October launch update, RepoDesk feature recommendations, evidence strength and unknowns |
| Source register | URLs, retrieval method, scope, and research limitations |
| Product requirements | Proposed features, priorities, acceptance criteria, permissions, and success measures |
| GitHub work through Telegram | Main user journey, current GitHub capabilities, boundaries and next decisions |
| Telegram image and attachment input | Implemented formats, download controls, media budgets and limits |
| Telegram platform constraints | What changes when Slack becomes Telegram |
| Private conversation threads | Native Topics, discussion memory, cache-aware compaction and private history |
| Group conversations | Per-user continuity, shared discussions and natural follow-up triggering |
| Long-term memory | Scoped private/shared recall, background extraction, user controls and retention |
| Architecture | Implemented local pilot and production boundaries |
| Admin panel | P0 configuration screens, permissions, APIs and acceptance criteria |
| UI rules | User design preferences, their scope, and how to apply and maintain them |
| First-run setup | Initial admin creation, bot onboarding, secrets and activation |
| LLM extensions / plugins | Existing Pi extension loading, headless compatibility, grants and recovery |
| Cloudflare plugin | Browser OAuth, scoped DNS/Pages queries, approved DNS changes and cache purges |
| Agent skills | Web-managed catalog, settings, versioning and Pi integration |
| Workspace membership and access | Active membership, roles, enforcement and revocation |
| Pi + Docker implementation plan | Concrete engineering tasks, architecture decisions, tests and rollout |
| Roadmap | Dependency-ordered milestones and release gates |
| Repository reports, skills and handoffs | Accepted R01–R03 plan, permission contracts, implementation and verification |
| Telegram feedback beta plan | Readable progress, task status, cancellation and failures for friends and colleagues |
| GitHub App connections | Default GitHub tools/skill, App registration, repository connections, permissions and approved PR actions |
| Review Bot | Selected-repository automatic PR reviews and tagged same-PR work |
| Codex coding tasks | Continuous coding tasks, publication settings and local runner setup |
| Continuous Codex collaboration | Continuous tasks: Pi requirements intake, Codex decisions, Telegram questions, repair and same-PR follow-ups; live pilot pending |
| Codex collaboration implementation plan | Protocol proof, durable tasks, original-requirement handoff, Telegram input, repair, same-PR continuation and release gates |
| Codex account authentication lifecycle | Credential generations, automatic refresh persistence, sign-in pauses and authorized continuation |
| Landing-page Codex acceptance | GitHub/Cloudflare test repository, verified VPS environment and live approval/deployment gates |
| Local Codex runner | Automatic Docker VPS runner, Docker isolation, account auth and local publication |
| Alternative Codex sandboxes | Docker/OpenSandbox configuration, isolation and repeatable benchmarks |
| VPS sandbox measurements | Same-host Docker/OpenSandbox fixture, live landing tasks and microsandbox exclusion |
| Local Code Truth | Predefined source-query extension, local MCP service and repository configuration |
| Setup | Local commands, validation, and configuration |
| Implementation evidence | Verified behavior and remaining live release gates |
| Release runbook | Staging demonstration, backup/restore and recovery |
| VPS release deployment | Host provisioning, local release builds, protected cutover and failure recovery |
| Panel updates | Automatic release checks, version indicator, changelog modal and host updater installation |
| Self-hosted Actions runner | VPS runner installation, separate CI Docker daemon, registration and operations |
| Automatic storage cleanup | Daily host release retention, CI post-job cleanup and safe activation |
| Debugging | Operator-provided VPS access and missing-reply diagnosis |
| Telegram experience | Proposed commands, onboarding, and example conversations |
| Assistant personality | Loaded work-buddy voice, forms of address, situational tone and examples |
Evidence vocabulary
- Documented: explicitly described in public product pages; not independently tested.
- Demonstrated: shown in a marketing example; not proof of complete integration support.
- Policy-disclosed: named in privacy/terms material; not proof of a generally available UI.
- Inferred: a plausible interpretation with no explicit product commitment.
- Proposed: our own design decision or requirement.
- Implemented: present in this repository and checked locally.
The local bot, Pi worker, PostgreSQL state, setup wizard, admin panel and bounded GitHub paths are implemented. Read implementation evidence for verified scope, limits and outstanding live release gates. Competitor claims remain research; P1/P2 features remain proposals. No public deployment is implied.