auto-knowledge-sync

Auto Knowledge Sync

Read lane

1. Call search_knowledge once near the start of a relevant technical task. Generalize the query and omit company, customer, repository, host, ticket, person, credential, private path, and other identifying details.
2. If a match is relevant, use get_knowledge when the full entry or evidence is needed. Inspect status, version scope, evidence, contradictions, and volatility.
3. Treat the result as prior knowledge, not current authority. Verify changeable claims against authoritative public sources before relying on them.
4. Continue the primary task without delay when the MCP server is unavailable or no compatible match exists.

Typical triggers include:

• comparing libraries, protocols, storage engines, or deployment approaches;
• diagnosing a recurring failure mode or version-specific behavior; and
• choosing an architecture, dependency, compatibility range, or operational pattern.

Do not search for trivial edits, purely stylistic work, or requests where stored technical knowledge cannot affect the result.

Write lane

Keep writing separate from retrieval. Do not capture every thought or use the repository as a draft inbox.

1. When a conclusion is stable, portable, and useful to another engineer, call prepare_capture immediately so the complete canonical skeleton is available before the session budget is low.
2. Infer the language of the latest substantive user message and use it for every human-readable title, claim, attestation, and prose section unless the user explicitly requests another language. Pass that BCP 47 tag to prepare_capture when practical; its default auto has the same policy. Keep canonical headings, enum values, IDs, version constraints, and code identifiers unchanged.
3. Do not send the conversation transcript to the MCP server for language detection. Infer language in the host and submit only the completed knowledge payload.
4. If a separate subagent is available, delegate filling or reviewing the skeleton while the primary task continues. Keep final privacy, completeness, portability, and approval decisions in the current session.
5. Replace every skeleton marker. Explain the concept, operation, significance, problem solved, constraints, failure modes, alternatives, version scope, and verification. Add a newly authored synthetic example only when it improves understanding.
6. Never send credentials, private URLs or paths, proprietary identifiers, internal topology, copied internal source code, or incomplete candidate notes. Generalize private-context observations and complete the portability attestation honestly.
7. Call capture_knowledge, inspect every gate result, and use apply_proposal only when the configured approval flow requires and permits it.