buildEmbedText() eagerly constructs full = meta + "\n\n" + ch.Code and then later converts the whole string to []rune. For very large ch.Code values this forces a full copy/allocation (and a full rune slice) even though the result will be truncated, which can significantly increase memory/CPU during indexing. Prefer computing rune lengths and truncating the code portion without concatenating/allocating the full payload up front (e.g., build only the needed prefix up to maxChars).

The comment references rag_read_file_context, but that tool name doesn't appear to exist in this codebase (the MCP tool is get_code_context). This can confuse users reading logs; consider updating the comment to the correct tool name or removing it.

Tool schema for apply_update documents force as defaulting to false, but ApplyUpdateTool.Execute defaults force to true when the argument is omitted. This mismatch can lead to surprising behavior for MCP clients relying on the schema. Align the schema description with the implementation, or change the tool default to match the documented default.

The PR description/title focuses on embedding payload truncation (#53), but this change set also adds a skills system and updater tools (list_skills/install_skill/check_update/apply_update) plus background update checks. This looks like a significant scope increase that isn't reflected in the PR metadata; please update the PR description (and possibly the title) to cover these additions, or split the updater/skills changes into a separate PR to keep review and rollback risk manageable.

buildEmbedText() does not guarantee the returned text stays within maxChars when the metadata (docstring/signature) alone exceeds the limit. In that case metaWithSep is returned in full and can still overflow the embedding model context window, reintroducing the original failure mode. Consider enforcing the cap unconditionally (e.g., always keep signature, truncate docstring next, then code) and add a test where Docstring length > maxChars.

The defer os.Remove(tempFile) will not execute because os.Exit(0) is called at the end of this block (line 470). In Go, defer statements are not run when os.Exit() is called. Since this is a short-lived CLI path, you should manually call os.Remove(tempFile) before os.Exit(0) or wrap this logic in a function to ensure the temporary archive is cleaned up.

Add unicode/utf8 to the imports to support memory-efficient rune counting and prefixing in the buildEmbedText function.

Converting the entire full string to a []rune slice just to check its length is memory-intensive for large code chunks. Consider using utf8.RuneCountInString(full) which calculates the rune count without allocating a new slice.

	if utf8.RuneCountInString(full) <= maxChars {
		return full, false
	}

Converting the potentially massive ch.Code string to []rune can lead to high memory usage or OOM for very large files. Since you only need a prefix of at most remaining runes, you can optimize this by converting only a safe byte-prefix of the string.

	codePrefix := ch.Code
	if len(codePrefix) > remaining*4 {
		codePrefix = codePrefix[:remaining*4]
	}
	codeRunes := []rune(codePrefix)
	if remaining > len(codeRunes) {
		remaining = len(codeRunes)
	}

If the metadata (metaWithSep) alone exceeds maxChars, the remaining count becomes 0, but the full metadata is still returned. This means the payload could still exceed the model's context window. While metadata is typically small, a strict cap would be safer to prevent the context overflow error mentioned in the PR description.