GitHub Knowledge Management for AI Coding Work

GitHub stores code, version history and documentation well. What it does not store is what your AI coding assistant needs right now: the approved architecture decision from last Tuesday, the half-finished feature, the rule about how errors are handled in this service. Those belong in a live work record that any assistant reads before it starts.

Splitting the two is the foundation of a useful knowledge management setup for coding work. Tools like fenbs hold decisions, lessons and where the work stands. GitHub holds the code and the documentation that describes it. Neither replaces the other, and confusing them creates a record nobody trusts.

Two kinds of knowledge in a coding project

Repository knowledge is stable and attached to the code: a README explaining the project, an AGENTS.md giving coding assistants file-level instructions, a CONTRIBUTING.md describing conventions. It changes slowly and belongs in version control, where its history and authorship are tracked.

Work knowledge is current: what is being built right now, what was decided yesterday, what remains untested. It changes with every session and belongs in a tool that treats it as a live record rather than a versioned document. Claude Code reads AGENTS.md natively, which is useful for stable instructions, but a checked-in file cannot hold the current task progress or this week's architecture decision.

What belongs in the repository

Keep in GitHub anything that describes the codebase or guides contributors. These files answer "what is this code and how does it work?" They do not need to say what was decided last week or which task is waiting for a test.

• README.md: project purpose, setup steps, how to run tests and how to contribute.
• AGENTS.md or CLAUDE.md: standing instructions for AI coding assistants reading the repository natively.
• CONTRIBUTING.md: conventions for naming, branching, commit messages and review.
• docs/: longer architecture notes, API references, decision records that are stable and tied to specific code versions.

These files are most useful when they describe constraints and structure rather than current work. An architecture diagram that shows how the services connect is a good repository document. A note saying which service is being refactored this week is not: it belongs somewhere that updates without a commit.

What belongs outside the repository

Decisions that guide work belong outside the repository when they change faster than a commit cycle. "Use the Result pattern for error handling in all service methods" is a decision that AI assistants need before they suggest code. It does not need to be buried in a README; it needs to be in a record an assistant reads at the start of every session.

In-progress tasks, accepted findings from a code review and the current next step are all live facts. A task that moves from To Do to In Progress, then needs a review decision, changes multiple times in a single day. Tracking that with Git commits would be noise. Tracking it in a work tool with clear lane states and task notes is the right fit.

Lessons learned also belong outside the repository. A lesson such as "always run the integration test suite before merging changes to the payment service, not just the unit tests" is useful to every future session, not just to the one that discovered it. Linking it to the task that prompted it makes the context available later. For an overview of agentic GitHub workflows, see that guide.

How AI coding assistants read context

Most AI coding assistants read context in two ways: from the repository files they can see and from MCP tools they are connected to. Repository context is useful for stable facts about the code; MCP context is useful for what is happening now.

Claude Code reads AGENTS.md natively and can be connected to MCP servers for live work context. GitHub Copilot connects to MCP sources in the editor environment. Cursor supports MCP configuration. Integrations lists the supported assistants and how to connect each one to fenbs. The GitHub Copilot app guide covers the Copilot-specific setup.

Keeping decisions and lessons across sessions

A decision recorded in a chat is gone when the chat closes. A decision recorded in a shared work record is available to the next session, the next assistant and the next person who joins the project. This is the practical difference between a knowledge management system and a collection of useful conversations that nobody can find.

Write decisions with enough context to be useful without the conversation that produced them. "Use the Result pattern for error handling, agreed October 2026, reason: consistent with the existing service layer and reduces unhandled exception paths" is more useful than "use Result." The full reasoning can live in a task note; the standing rule needs to be brief enough to be read before each session starts.

Lessons follow the same principle. "Run integration tests before merging payment service changes" is actionable. A paragraph describing the incident that produced the lesson can live in the linked task. The lesson itself is the instruction to carry forward. Good agile workflow applies the same discipline: keep the actionable rule close to where the work happens.

Separate the stable fact from the live instruction when you write a lesson down. A lesson that says "always run integration tests before merging the payment service" applies to every future session. A lesson that says "the payment service was slow last month because of a connection pool setting" describes one incident. Keep the instruction; link to the incident task for anyone who needs the full story.

Handling handoffs when work pauses

A handoff happens every time a coding session ends, intentionally or not. If nothing is recorded, the next session starts by reconstructing what happened. That reconstruction takes time and introduces the risk of treating a draft as finished or missing an untested change.

Before a session ends, ask the assistant to save where each active task stands: what was completed, what was checked, what remains and what is waiting on a person. That note becomes the Where we left off that the next session reads. It takes a minute and prevents the next session from wasting time on questions the previous one already answered.

Give the handoff note a structure: what was completed, what was checked and the result, what remains, and what the next step is. That structure lets the next session scan quickly rather than read everything in full. For longer projects worked across multiple tools and team members, the agentic workflows guide covers how to build handoffs into the normal session loop.

How to structure the two records together

The most practical arrangement is: stable code instructions in AGENTS.md inside the repository, live work context in fenbs outside it. Neither record tries to do the other's job. An assistant that reads both gets what it needs: how the code is organized and what is happening with it right now.

Review the AGENTS.md whenever a significant convention changes. Review the fenbs work record at the end of each session. The two schedules are different because the two kinds of knowledge change at different rates. Keeping that separation prevents both from becoming outdated at once.

How to do this with fenbs

1. Create a free account at fenbs.ai and add a project for the repository you are managing.
2. Add your architecture decisions as Decisions and rules. Mark the ones that apply to every session as standing rules so they appear first in the AI context.
3. Add tasks for work in progress. Use the task note to describe the goal and what the assistant needs to know before starting.
4. Connect your coding assistant from Integrations. Ask it to read the project AI context at the start of every session.
5. At the end of each session, ask the assistant to save progress and update Where we left off for the project.

Keep AGENTS.md in the repository for instructions that belong with the code: setup steps, file structure, how to run tests, stable conventions. Use fenbs for what is live: current decisions, open tasks and handoff notes. The two records complement each other; they do not overlap.