lfx-mcp: Skill for Claude Code

LFX MCP Server Code Review

Judge the implementation the way a senior reviewer the team trusts would: thorough yet pragmatic, catching real issues while respecting the author's time. Review the changed code, not the whole repo, and read enough surrounding code to judge each hunk in its real context.

The house standards

The repo defines its own standards; hold the diff to them, and name the documented source in any standards finding. They live in the repo's documentation (CLAUDE.md / the root AGENTS.md, ARCHITECTURE.md, and what they point to): code layout, the error model, how tools are registered and described, test expectations, license headers. Read the parts relevant to the diff before judging, every run, because the standards belong to the repo and move with it.

Enforcement runs in both directions: code that violates a documented standard is a finding, and a documented standard the code has visibly outgrown is a finding against the docs. If a documented convention is wrong for this specific change, say so explicitly and explain the trade, rather than silently waiving or silently enforcing it.

The standing distillate

These are the repo's most load-bearing, CI-enforced conventions, distilled so no review misses them. They summarize the docs, never replace them — when the docs and this list drift, the docs (and the code) win, and the drift is a finding against this skill.

• License header: every tracked source/config file (Go, YAML, shell, Makefile, etc.) begins with the two-line LF/MIT header. The wording varies by file type in this repo — Go files use // Copyright The Linux Foundation and contributors. while YAML, shell, and Makefile use # Copyright The Linux Foundation and each contributor to LFX. — both followed by SPDX-License-Identifier: MIT in the same comment syntax. Match the surrounding convention for the file type; missing headers are the #1 cause of CI failure (license-header-check.yml).
• Package doc comments: every non-test .go file needs // Package <name> ... immediately above package (revive package-comments via MegaLinter; _test.go exempt). .mega-linter.yml is the single source of truth for what else is enforced.
• Layout: entry point, config, and tool registration in cmd/lfx-mcp-server/main.go; one file per tool/domain in internal/tools/; scope constants in internal/tools/scopes.go; JWT and API-key verification in internal/auth/; the LFX V2 client (token exchange, slug resolver, access checks) in internal/lfxv2/; the generic downstream HTTP client in internal/serviceapi/.
• The tool pattern: args struct with json + jsonschema tags → Register<ToolName> calling mcp.AddTool → handle<ToolName> → registration in newServer() gated on canRead/canManage → name added to defaultTools. A Register call without the defaultTools entry means the tool silently won't run — a classic miss. Read tools always set ReadOnlyHint: true; write tools explicitly set DestructiveHint.
• Conventions: schemas are generated from struct tags (no manual schema files); the package-level schemaCache is shared across per-request server instances — never duplicated; slog for logging with const errKey = "error" for structured error keys; scope enforcement is inline in newServer(), never wrapper functions.