Knowledge Base for TraeCode
TraeCode distinguishes rules, skills and MCP servers. Rules remain in the conversation context; skills load when called; MCP supplies callable tools. Busabase can preserve the reviewed source material and decisions behind those instructions without confusing tool access with trusted knowledge.
The missing layer
A skill defines a method; MCP supplies tools
A testing skill reduces repeated instructions but cannot guarantee every run follows the standard. Separate conventions, capabilities and evidence before deciding what the team accepts.
From proposal to accepted knowledge
Start the next task from accepted knowledge
Read applicable accepted records
Check source dates and applicability before supplying relevant accepted records to the agent.
Propose an evidenced update
Turn a finding into field-level changes with sources, execution version and open questions; submit a ChangeRequest.
Review the exact changes
A reviewer checks changes and evidence, requests revisions, approves or rejects. An authorized role merges approved changes.
Reuse accepted findings
People and agents read the merged state. Propose a revision when a claim changes and retain its history.
What to preserve
Record which pages passed which checks, not just “tests succeeded”
Suppose two desktop pages passed but mobile checks have not run. Preserve that limit; a successful tool call does not establish site-wide acceptance. These are suggested record fields.
Scope and method
Release commit, pages, viewports and skill revision; distinguish covered checks from gaps.
Execution evidence
Test output, screenshot or report links, run time and MCP tool details. Keep original artifacts in the testing system.
Results and exceptions
Passes, failures and accepted exceptions with rationale. Mark checks without evidence as pending.
Review and updates
Owner, decision, follow-up and retest conditions. Propose updates when releases or standards change instead of reusing stale acceptance.
Choose the right knowledge layer
Rules, skills, tools and test findings belong to different layers
A testing skill reduces repeated instructions but cannot guarantee every run follows the standard. Separate conventions, capabilities and evidence before deciding what the team accepts.
| Knowledge layer | Best place for | Basis for trust |
|---|---|---|
| Rules and skills | Rules provide ongoing guidance; skills encode on-demand methods. Version them in their original configuration or repository, rather than storing current acceptance status inside instructions. | Rules and skills |
| MCP and test artifacts | MCP configuration supplies tools; reports show what happened. Tool success does not prove complete coverage or that a defect is closed. | MCP and test artifacts |
| Accepted test findings | Busabase records scope, exceptions and owner so downstream teams can query which pages and versions were accepted without interpreting an entire chat. | A reviewer checks changes and evidence, requests revisions, approves or rejects. An authorized role merges approved changes. |
| Busabase | Suppose two desktop pages passed but mobile checks have not run. Preserve that limit; a successful tool call does not establish site-wide acceptance. These are suggested record fields. | People and agents read the merged state. Propose a revision when a claim changes and retain its history. |
Connection and review boundaries
Verify access, then limit write authority to proposals
The official skills guide explicitly separates how to perform a task from the tools available to execute it. For a testing workflow, preserve the test conventions in the skill, the tool configuration separately, and the evidence used to accept the findings. For a testing standard, keep the skill revision, repository baseline, test output and exception decision together. TraeCode documents Streamable HTTP support; verify the authentication options in the installed client before connecting Busabase. If using a static header, choose a changeRequest-scoped key. The proposed connection has not been end-to-end tested.
When to use
Share reusable acceptance decisions, not duplicate tool configuration
Use shared review
Use this when product, engineering and release teams reuse findings, standard changes affect earlier coverage, or several agents’ reports need one explicit final decision.
Use a simpler tool
Skip it for a single local test, disposable debugging chats, full skill copies or MCP configuration backups. If a testing system already governs acceptance, reference it instead of creating competing records.
Knowledge Base for TraeCode · Questions
Are rules and skills loaded in the same way?
No. TraeCode says rules are loaded in full, while skills are loaded on demand when called.
Does an MCP server supply the team’s method?
Not by itself. MCP provides tools; the skill defines task-specific instructions and conventions.
Does enabling a server approve its returned data?
No. Inspect tool access, verify the target workspace, and review evidence before accepting record changes.
Are passing tests still valid after a skill changes?
Check whether the revision changes coverage or acceptance criteria. Keep the previous skill version and evidence, schedule affected retests, and propose record updates.
Should every screenshot and report be copied into Busabase?
No. Preserve links to original artifacts and the necessary findings. The record explains scope, evidence and decisions without replacing the testing system.
Start with one reviewed record
Give the next task knowledge with sources and an owner
Choose one result the team will reuse, define a minimal record and reviewer, then validate access and proposal permissions using the connection guide.