Skip to main content
The Knowledge Hub is the central place where all project context lives — wikis, rules, milestones, and the Project Spec. The first time your Project Spec is generated, opens the Knowledge Hub for you. You review and approve the Project Spec here using the chat panel to interact with . It’s how Morph agents stay aligned with each other and with your team’s standards throughout the migration.

What Is the Knowledge Hub

Think of the Knowledge Hub as structured context for Morph agents. Every time an agent works on a task, it reads from the Knowledge Hub to understand the project’s architecture, conventions, and decisions that have already been made. When an agent learns something new during execution — a pattern it discovered, an architectural decision it made — it writes that knowledge back. This is how agents pass knowledge between each other. Milestone 1 might establish a database access pattern. Milestone 5, handled by a different agent, reads that pattern from the Knowledge Hub and follows it. The result: consistent code across your entire migration, even though different agents handled different parts.

What’s Inside

The Knowledge Hub contains four types of knowledge:
TypeWhat It HoldsHow It’s Used
WikiArchitecture docs, design decisions, patterns discovered during migrationAgents read wikis to understand project context and conventions
RulesCoding standards, library preferences, explicit constraintsAgents follow rules as hard requirements in every milestone
Project SpecGoals, scope, and approach for the migrationAgents reference the Project Spec to stay aligned with the overall direction
MilestonesDetailed descriptions and scope for each migration stepAgents use milestone content to understand what each step requires

How Agents Use It

When an agent starts working on a milestone:
  1. It reads the Project Spec to understand the migration’s overall goals
  2. It reads all rules to know which standards to follow
  3. It reads relevant wiki pages to understand architecture and patterns
  4. It reads the milestone description to know what to build
After execution, the agent writes back anything it learned — new patterns, architectural decisions, integration notes — as wiki pages. This keeps the Knowledge Hub growing and increasingly accurate over the course of the migration.

Adding Your Own Knowledge

You can add context to the Knowledge Hub at any time. This is useful when you have documentation, design decisions, or standards that should know about from the start.
When you add content to the Knowledge Hub, it isn’t saved as-is. breaks it down into structured wiki pages and rules, optimizing the content for how agents consume it. A 50-page design doc becomes a set of focused, referenceable wiki entries that agents can query efficiently.

Using the Chat

The Knowledge Hub has a built-in chat panel. You can talk to and ask it to create, update, or reorganize knowledge. To add documentation:
  1. Open the Knowledge Hub from the left sidebar
  2. Open the chat panel
  3. Describe what you want to add
For example:
We use the repository pattern for all database access.
Each entity has its own repository class that extends BaseRepository.
Repositories handle all SQL queries — services never write raw SQL.
Here's an example from our codebase:

class UserRepository(BaseRepository[User]):
    async def find_by_email(self, email: str) -> User | None:
        return await self.find_one({"email": email})
takes this and creates the appropriate wiki pages and rules so that every agent follows this pattern.

Dragging in Files

You can drag text files directly onto the chat panel to import existing documentation. reads the file, extracts the relevant knowledge, and creates wiki pages and rules from it. Supported formats include .md, .txt, .yaml, .json, .py, .ts, .js, and many more text-based files. Example use cases:
  • Drag your team’s CONTRIBUTING.md to import coding standards
  • Drop an architecture decision record (ADR) to capture design choices
  • Import a styleguide.md to encode formatting preferences

From a URL or Repo Path

In the chat, you can also reference external sources:
Please read the coding standards from our wiki at
https://internal-wiki.example.com/coding-standards
and create rules from them.
Or point to a file in your repository:
Read the patterns in src/shared/base-repository.ts
and create a wiki page documenting the repository pattern we use.

Editing Wiki Pages

Wiki pages capture architecture, patterns, and project-specific context. Update them through the chat. Right-click a wiki page in the tree and select Add to Context to attach it to the chat. Then describe the change you want:
Add a section about connection pooling.
We use a max of 20 connections per service instance.
Create a new wiki page about our error handling strategy.
All domain errors should extend AppError. HTTP errors are mapped
in the error middleware, not in individual handlers.

When to Add Wiki Pages

Add wiki pages when you have knowledge that applies broadly but isn’t a hard rule:
  • Architecture decisions — “We chose event sourcing for the order service because…”
  • Integration notes — “The payment gateway expects ISO 8601 dates with timezone”
  • Migration context — “The legacy UserManager class maps to three separate services in the new architecture”
  • Patterns — “All API responses follow the envelope pattern: { data, meta, errors }

Editing Rules

Rules are hard constraints that agents follow in every milestone. Unlike wiki pages (which provide context), rules are treated as requirements. Create and update rules through the chat:
Create a rule: all Python files must use absolute imports.
No relative imports allowed except in __init__.py files.
To update an existing rule, right-click it in the tree and select Add to Context, then describe the change:
Update this rule to also require that every new endpoint
has at least one integration test.

Rules vs. Wiki Pages

RulesWiki Pages
Agent behaviorTreated as requirements — agents must follow themTreated as context — agents use them to inform decisions
ScopeApply to every milestoneReferenced when relevant
Best forCoding standards, library mandates, naming conventionsArchitecture docs, design decisions, integration notes
Example”Use pytest for all tests. No unittest.""The authentication service uses JWT with RS256 signing.”
Use rules when you want to enforce something. Use wiki pages when you want to inform agents.

Editing Milestones

You can review milestone descriptions in the Knowledge Hub. To adjust scope, add requirements, or change descriptions, use Editing Milestones from the milestone review flow. You can also ask to restructure milestones through the Knowledge Hub chat. For example, to merge two milestones:
Merge Milestone 3 ("Migrate user authentication") and
Milestone 4 ("Migrate session management") into a single milestone.
They're tightly coupled and should be done together.

Locked Milestones

Milestones that are in progress, under review, or already merged cannot be edited. Only milestones with a Not Started status are editable. If you need to adjust a milestone that’s already executing, wait for the current execution to complete and then make your changes before re-running.
For small, recurring adjustments across milestones, add a Rule instead of editing each milestone individually. Rules apply to all milestones automatically.

Updating the Project Spec

The Project Spec is the top-level document that defines your migration’s goals, scope, and approach. Ask in the Knowledge Hub chat to refine the migration direction; substantial changes may also go through your Project Spec approval flow. Changes to the Project Spec can affect how agents approach future milestones, so be deliberate about what you request.

Viewing Changes

When modifies knowledge during an agent execution (for example, an agent discovers a pattern and writes a wiki page), you can see exactly what changed. Click Highlight changes (the diff icon) in the Knowledge Hub toolbar to toggle an inline diff view:
  • Green highlights show added content
  • Red highlights with strikethrough show removed content
  • A summary shows the total lines added and removed
  • Modified items are marked with a yellow indicator in the tree navigation
This makes it easy to review what agents learned and wrote back during execution.

How Knowledge Stays in Sync

The Knowledge Hub stays aligned with running work as agents read and write knowledge, and as you add or update context through the chat. When you ask for changes while an agent is running, incorporates them so agents can pick up new rules and wiki context in subsequent steps.

Examples

Setting Up a New Project’s Knowledge

When you start a migration, front-load the Knowledge Hub with what you know:
Our project follows clean architecture. The layers are:
- Domain (entities, value objects, repository interfaces)
- Application (use cases, DTOs, application services)
- Infrastructure (database repos, external API clients, message handlers)
- Presentation (controllers, middleware, request/response models)

Dependencies point inward. Infrastructure depends on Domain,
never the reverse. Use dependency injection everywhere.
creates wiki pages for the architecture and rules for the dependency direction constraint.

Correcting Agent Behavior

After reviewing a PR, you notice agents are using console.log for debugging:
Create a rule: never use console.log in production code.
Use the logger service from src/shared/logger.ts for all logging.
Debug logs should use logger.debug(), errors should use logger.error()
with the full error object.
All future milestones follow this rule.

Importing Team Standards

Your team has a docs/coding-standards.md in the repo:
  1. Drag the file onto the Knowledge Hub chat
  2. reads it and says: “I’ve extracted 4 rules and 2 wiki pages from your coding standards document…”
  3. Review the created entries in the tree navigation
  4. Ask the chat to adjust any entries that need refinement

Adding Context Mid-Migration

At Milestone 4, you realize agents don’t know about a critical integration:
The user service calls the billing service over gRPC.
The proto files are in shared/proto/billing.proto.
When migrating user-related code, preserve all billing
service calls and use the generated Python client from
shared/generated/billing_pb2_grpc.py.
Milestones 5 onwards now have this context.

Best Practices

Let the Chat Do the Structuring

Don’t worry about formatting your input perfectly. Describe what you want in natural language and structures it into the right wiki pages and rules. A rough paragraph of context works better than trying to manually create the “right” wiki page.

Review Agent-Created Knowledge

After each milestone, check the Knowledge Hub for new wiki entries. Agents write back what they learned. If something is inaccurate, ask the chat to correct or remove it before the next milestone picks it up.

Use Rules for Enforcement, Wikis for Context

If you find yourself writing a wiki page that says “always do X” — that’s a rule. Move it there so agents treat it as a hard requirement, not optional context.

Creating Rules

Deep dive into writing effective rules with examples

Editing Milestones

How to adjust milestone scope and descriptions

Core Concepts

Morph terminology and mental model

Project Spec

Review and approve in the Knowledge Hub using chat