About Botree Software
In India, consumer goods companies supply kirana stores through networks of distributors and field sales teams. These neighbourhood shops number more than 13 million and account for over 90 per cent of fast-moving consumer goods (FMCG) sales.
Botree Software has developed software for this distribution network for more than 25 years. Its distributor management system (DMS) and sales force automation (SFA) products are used by more than 80 consumer goods companies. The software supports 100,000 distributors and 40,000 field sales staff, and reaches more than 5 million retail outlets in India and other emerging markets.
The Goal
Botree set out to adopt an agentic software development lifecycle (SDLC), using AI agents such as Claude Code to analyse code, implement changes and fix defects. Engineers direct the work, review the output and approve changes. The goal was faster feature delivery and issue resolution aligned with the Company’s state charter of providing a world-class experience to each Customer. Botree partnered with Amotion AI, an Anthropic partner, for this initiative.
The Challenge
Botree's products run on large codebases, including versions customised for individual customers. Incomplete documentation can lead an agent to overlook a condition, such as a validation rule that applies to only one order type, and propose an incorrect change. Botree needed accurate documentation of the architecture, business rules and dependencies, with references engineers could verify against the code and a process for keeping it current.
The Solution
Botree worked with Amotion AI to create an AI-ready knowledge base in each repository using Claude Code. Engineers and AI agents use it to understand the application, its business rules and earlier engineering decisions.
Knowledge Base Structure
- Entry files and index: CLAUDE.md and AGENTS.md contain build instructions, coding conventions and requirements for AI-assisted work. The index lists available documentation by engineering task.
- Documentation layer: system architecture, module descriptions, business processes and rules, screens and fields, database structures, and dependencies between modules, data and reports. Engineers use these to assess the impact of a change.
- Memory layer: module notes record related tickets, defect causes, fixes and design decisions that subsequent changes must preserve. Separate notes cover decisions affecting several modules.
- Code anchors: references to the files, line ranges, classes, methods, queries or tables engineers can use to verify an explanation against the code.
Claude Code Skills and Plugin
Botree developed reusable instructions for Claude Code and a separate plugin to support repository documentation. Engineers use these capabilities to produce and review the following outputs.
| Engineering task | What the tools help engineers produce |
|---|---|
| Set up documentation | A documentation structure within the repository, project instructions based on the code and a prioritised module list. Existing instructions are preserved; engineers review additions and choose which module to document next. |
| Understand a module | An explanation of how an operation starts, which services it calls, how data is saved, how statuses change and which downstream systems are affected, with references to the relevant code. |
| Plan a feature or fix | A proposed implementation plan based on the requested change, current system behaviour and recorded module knowledge. Engineers review the plan before implementation. |
| Investigate a defect | A root cause analysis that explains the defect and the reason for the proposed fix. Engineers check the analysis against the code and associated ticket. |
| Review proposed changes | A comparison of the proposed code changes with earlier fixes, design decisions and exceptions that must be preserved. Engineers assess conflicts before requesting review. |
| Record a completed change | Updated module notes containing the ticket, date, user impact, cause or design rationale, changed files, fix and tests. Earlier ticket history is retained. |
| Find relevant code and notes | The optional plugin can generate inventories of supported source-code elements, including endpoints, entities and services, and display available documentation in a browser. Coverage and reference checks identify areas requiring review. |
Verification and Quality Gates
Automated checks identify structural and reference problems. Engineers verify the accuracy of the explanations before treating them as current documentation.
| Check | What is checked | Engineering review |
|---|---|---|
| Structure and sensitive data | Required files, unfilled entry-file placeholders and selected sensitive-data patterns. | Engineers resolve blocking failures, review advisories and inspect content for sensitive information the checker may miss. |
| Code references | Whether supported file ranges and code symbols in module notes can be found. | Engineers inspect the cited code and references in changed documentation. A valid reference alone does not establish that an explanation is correct. |
| Behaviour and decisions | Engineers compare explanations with current code, relevant settings, tests and ticket history. | Engineers correct inaccurate statements, mark unconfirmed claims as gaps and retain the reasons for necessary exceptions. |
| Practical usefulness | An engineer uses the documentation and references to answer a real task question. | Engineers add missing explanations or references. A coverage score alone does not demonstrate that the documentation is useful. |
Botree's standard requires the structure checker to run in continuous integration, so proposed documentation changes are checked with the pull request. Code changes also follow the applicable testing and QA process.
Knowledge Base Maintenance
Engineers update the affected documentation after work on a ticket changes a module. The procedure covers both the current behaviour and the reason for the change.
- 1 Identify
Find the notes affected by the ticket and code change.
- 2 Verify
Check the cited code, behaviour and ticket reasoning.
- 3 Update
Correct the explanation and record the change history.
- 4 Review
Review the changes and commit the verified update.
Keep current behaviour accurate. Update the affected business rules, flows, screens, interfaces and dependencies. If code moves, repair its reference; if behaviour changes, correct the explanation too.
Preserve the reason for the change. Retain the ticket history, fix, tests and decisions that future work must respect. Update the module index so engineers can find the revised notes.
Identify further review work. The plugin's optional post-commit hook identifies outdated references and prepares a worklist. Engineers verify and approve corrections. Engineers using the separate documentation kit follow that kit’s update procedure.
Agentic SDLC in Practice
Botree engineers use Claude Code and the repository knowledge base during feature development, defect resolution and code review:
- Planned changes: engineering and QA work is tracked in Linear. The configured GitHub integration links branches and pull requests by issue ID and updates selected issue states after review and merge events. Designated team members approve QA sign-off and releases.
- Incidents and bug fixes: customer incidents recorded in the Customer Support Management System are linked to the associated engineering work. Engineers include the incident number in the branch name, use Claude Code to prepare a bug-fix plan and root cause analysis, and record the fix and its rationale in the module notes.
- Recurring tickets: engineers use Claude Code to identify the code and underlying causes associated with repeated support issues, then plan corrective changes.
- Measurement: Botree's engineering standards define deployment frequency, time from story creation to production, failed-deployment rate, recovery time, defects reaching customers and engineer onboarding time. The engineering and support systems provide actionable data for these measures.
The Results
- Engineers and AI agents use reviewed documentation of Botree's code, business rules and dependencies when preparing explanations or proposed changes.
- Engineers use AI agents for coding and bug-fixing tasks while retaining responsibility for technical direction, review and approval.
- Reviewers assess proposed code changes against recorded design decisions and earlier fixes, including the reasons for important exceptions.
- Engineers update the affected documentation and module notes as part of completing a change.
- Leadership can review delivery speed and quality through defined measures using data from the team's engineering and support systems.
Botree's process for preparing, verifying and maintaining documentation with Claude Code supports its broader goal of faster feature delivery and defect resolution across legacy codebases.