TraeCodeのナレッジベース
TraeCodeではRule、Skill、MCPの役割が異なります。Ruleは会話contextに残り、Skillは呼び出すときに読み込まれ、MCPはtoolを提供します。Busabaseには、その指示の根拠となる確認済み資料と判断を保存できます。
不足している層
Skillは手順、MCPはtoolを提供する
テスト方法をSkillにすると説明の繰り返しは減りますが、毎回の結果が基準を満たす保証にはなりません。約束、ツール、根拠を分けて、何を採用するか判断します。
提案から正式な知識へ
次の作業を採用済みの知識から始める
適用できる正式な記録を読む
資料の日付と適用範囲を確認し、作業に関係する正式な記録をAgentに渡します。
根拠を添えて更新を提案する
結論を項目ごとの変更に整理し、出典、実行の版、未解決事項を添えてChangeRequestで提案します。
具体的な変更を確認する
担当者が変更と根拠を確認し、修正、承認、却下を判断します。承認後、権限のある役割がマージします。
採用した結論を再利用する
人とAgentはマージ後の状態を読みます。結論が変わったら修正を提案し、履歴を残します。
残すべき情報
「成功」ではなく、どのページで何を確認したか残す
デスクトップの二ページだけで確認が済み、モバイルが未検査なら、その範囲を明示します。ツール一回の成功をサイト全体の検収完了に広げません。以下は設計例です。
範囲と方法
公開コミット、ページ、画面幅、Skillの版。検査済み範囲と未検査範囲を分けます。
実行の根拠
テスト出力、画像や報告へのリンク、実行時刻、MCPツール情報。原本はテストシステムに残します。
結果と例外
成功、失敗、採用した例外と理由。根拠のない検査は保留にします。
確認と更新
担当者、判断、次の作業、再テスト条件。版や基準が変わったら更新を提案します。
知識の置き場所
Rule、Skill、ツール、テスト結果の役割を分ける
テスト方法をSkillにすると説明の繰り返しは減りますが、毎回の結果が基準を満たす保証にはなりません。約束、ツール、根拠を分けて、何を採用するか判断します。
| 知識の層 | 残す情報 | 信頼の根拠 |
|---|---|---|
| RuleとSkill | Ruleは継続的な指示、Skillは必要時に使う手順です。元の設定やリポジトリで版管理し、現在の検収状態を指示へ書き込みません。 | RuleとSkill |
| MCPとテスト成果物 | MCPはツールを提供し、報告は実行結果を示します。ツールの成功だけでは網羅性や問題の解決を証明できません。 | MCPとテスト成果物 |
| 採用したテスト結果 | Busabaseに範囲、例外、担当者を残します。下流の担当者は会話を解釈せず、検収済みのページと版を確認できます。 | 担当者が変更と根拠を確認し、修正、承認、却下を判断します。承認後、権限のある役割がマージします。 |
| Busabase | デスクトップの二ページだけで確認が済み、モバイルが未検査なら、その範囲を明示します。ツール一回の成功をサイト全体の検収完了に広げません。以下は設計例です。 | 人とAgentはマージ後の状態を読みます。結論が変わったら修正を提案し、履歴を残します。 |
接続と確認の境界
アクセスを確認し、書き込みを提案に限定する
公式のSkillガイドは、作業方法と実行toolを区別しています。Testのworkflowなら、規約はSkillに、tool設定は別に、採用した結論には実際のtest結果を残します。 Test規約なら、Skillのversion、repositoryのbaseline、test出力、例外の判断を残します。TraeCodeはStreamable HTTPに対応しますが、Busabaseの接続前にclientの認証方式を確認します。静的headerの場合はchangeRequest権限のkeyを使います。接続のend-to-end検証は未実施です。
適する場面
再利用する検収判断を共有し、設定の複製は避ける
共有する確認が必要
製品、開発、公開担当者が結果を共有する場合、基準変更の影響を追跡する場合、複数Agentの報告に一つの最終判断が必要な場合に適します。
より簡単なツールで十分
一度のローカルテスト、仮のデバッグ会話、Skill全体のコピー、MCP設定のバックアップには不要です。既存のテストシステムに正式な状態があれば参照します。
TraeCodeのナレッジベース · よくある質問
RuleとSkillは同じ方法で読み込まれますか？
いいえ。Ruleは全体が読み込まれ、Skillは呼び出すときに読み込まれます。
MCPだけでteamの作業方法が決まりますか？
いいえ。MCPはtoolを提供し、Skillはtaskの指示と規約を定義します。
Serverを有効にするとデータも承認されますか？
いいえ。アクセスとworkspaceを確認し、recordの変更を採用する前に根拠をreviewします。
Skillが変わっても以前のテストは有効ですか？
対象範囲や合格基準への影響を確認します。旧版と根拠を残し、影響する部分を再テストして記録更新を提案します。
画像や報告をすべてBusabaseへコピーすべきですか？
いいえ。原本へのリンクと必要な結果を残します。記録は範囲、根拠、判断を説明し、テストシステム全体を置き換えません。
確認済みの記録から始める
次の作業に出典と担当者のある知識を渡す
チームで使う結果を一つ選び、最小限の記録と確認者を決めます。接続ガイドでアクセスと提案権限を検証します。