// Blog / FAQ
FAQ: .knowledge for teams
A practical FAQ for teams that want coding agents to share repo-local context without pretending summaries are source of truth.
// direct answer
Short answer
.knowledge is a repo-local trust and routing layer for AI coding agents. It helps teams share context across tools, mark stale or suspect knowledge, inspect evidence, and keep source code and tests above generated summaries.
Answer common team questions about adopting .knowledge and Pro2Pilot Inspector.
// team adoption
What teams are really asking
Teams do not only ask whether an agent can read a repo. They ask whether context survives handoff, whether stale summaries are visible, and whether reviewers can see what the agent trusted.
.knowledge answers those questions with files inside the repository instead of private chat memory.
Pro2Pilot Inspector adds the visual workflow layer when the team needs repair boards, PR impact, policies, and cross-review operations.
// operating rule
The rule to remember
Use .knowledge to route, inspect, and govern agent context.
Use current source and tests to decide behavior.
When trust is weak or freshness is stale, make the agent re-read code before making claims or changes.
// concrete example
A realistic adoption path
Start by adding .knowledge to one active repository and installing Codex, Claude Code, or OpenCode integrations.
Run import and release checks, then use the static Inspector to review trust and repair state.
Once the team sees repeated handoff or PR-review pain, add Inspector workflows on top of the open core.
// repo proof
Repo proof to inspect
.knowledge/Quick-Start.md
The first-read instructions live in the repo, not in one person's prompt notes.
- Team onboarding
- Agent setup
- Behavior proof
.knowledge/maintenance/routing_bundle.json
Every agent can start from the same compact route.
- Session start
- Module discovery
- Skipping source review
.knowledge/maintenance/trust_report.json
The team can see what is trusted, stale, suspect, or low-confidence.
- Review readiness
- Agent guardrails
- Approving risky edits
.knowledge/inspector/index.html
A generated Inspector makes trust and repair state easier to discuss.
- Team reviews
- Repair planning
- Replacing current code
// command transcript
Commands and expected checks
node .knowledge/tools/install-agent-integrations.js - expected
- Team agent entrypoints are installed or refreshed.
- inspect next
- .agents/skills/ .claude/skills/ and .opencode/commands/
node .knowledge/tools/flow.js import - expected
- Initial repository context is generated without overwriting curated knowledge.
- inspect next
- .knowledge/project_index.json and .knowledge/modules/
node .knowledge/tools/flow.js release --no-color - expected
- Routing, trust, freshness, metrics, search, and Inspector artifacts are rebuilt.
- inspect next
- .knowledge/maintenance/quality_report.json
What teams need to decide
// field guide
Team adoption questions
| Question | Short answer | Artifact to inspect |
|---|---|---|
| Is it open core? | Yes, the repo-local layer is open and local-first. | .knowledge/tools/ and agent-integrations/ |
| Does it replace tests? | No. It routes agents toward the right tests. | source files and test files |
| Does it replace RAG? | No. It complements retrieval with trust and freshness. | trust_report.json and search/index.json |
| Can teams review it? | Yes, because the context is stored as repo files. | .knowledge/ and Inspector output |
| When is Inspector Pro useful? | When the team wants visual repair, policy, and PR impact workflows. | /inspector/ and waitlist |
// guardrails
What the agent should not trust blindly
- Do not sell .knowledge as agent memory that makes code review unnecessary.
- Do not hide stale or suspect modules to make adoption look cleaner.
- Make the source-of-truth order explicit during team onboarding.
// common mistakes
Common mistakes
- Starting with a hosted memory discussion before fixing repo-local onboarding.
- Treating FAQ answers as policy instead of linking them to artifacts.
- Adding Inspector visuals before the underlying trust files are healthy enough to show.
// quick FAQ
FAQ
Is .knowledge a product or a standard?
The core is a repo-local open layer. Pro2Pilot builds product workflows, Inspector views, and team operations on top of it.
What should a team try first?
Install it in one active repository, run import and release, open the Inspector, and make one AI-generated PR include trust and source checks.
// page-specific next step
Use this page when onboarding a team
Start with one repository, install integrations, run import and release checks, and show the team how trust state changes the agent workflow.