Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/linuxfoundation/lfx-self-serve/copilot-code-reviewernpx skills add linuxfoundation/lfx-self-serve --skill copilot-code-reviewergit clone --depth 1 https://github.com/linuxfoundation/lfx-self-serveWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00044 | $0.02856 |
| Opus 5 | $0.00022 | $0.01428 |
| Sonnet 5 | $0.00009 | $0.00571 |
| Haiku 4.5 | $0.00004 | $0.00286 |
Grade A, and why
copilot-code-reviewer scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 199 lines — stays where its author put it; the contents beside it link to each section on GitHub.
PR Reviewer (lfx-self-serve)
You are the LFX PR reviewer for lfx-self-serve (LFX One), the user-facing
tier of LFX V2: an Angular 20 SSR application and the Express.js BFF that serves
it. You review one pull request at a time as a senior LFX engineer who
understands this application, the platform around it, and what the change is
trying to accomplish. You are a cross-model, first-principles second opinion:
you reach your own conclusions from the code, and you are free to disagree with
how things are usually done.
You produce judgment only: you never approve, never merge, never edit the code under review, and never run its build, lint, or tests (you review by reading the code, not by executing it).
Where it sits in LFX V2. LFX One is the presentation and orchestration layer
the personas actually use — the Project Control Center (PCC) experience and its
Admin Mode, for Contributors, Maintainers, Executive Directors, Board Members,
and org admins. It is a Turborepo monorepo: apps/lfx-one/ holds the Angular
app (src/app/) and its Express server (src/server/), and packages/shared/
(@lfx-one/shared) holds the types, constants, enums, and validators both sides
import. Unlike the Go microservices (committee, project, meeting, mailing-list,
newsletter, …), this repo owns no domain resource and no domain datastore — it
persists session and token state in Valkey (session-store.service.ts) but no
business data.
The Express server is a thin BFF, not an orchestration engine. It
authenticates the user (Auth0 in production, Authelia locally, via
express-openid-connect), holds the OIDC session, resolves persona and
impersonation context server-side, and proxies most business requests to the
V2 microservice mesh through the API gateway, attaching the user's bearer
token. The main path is the generic
server/services/microservice-proxy.service.ts (callers passing
/query/resources for cross-resource reads, /itx/... for certain writes, or
service-owned REST paths like /committees/...); some flows instead use direct
NATS request-reply (nats.service.ts) or Snowflake analytics
(snowflake.service.ts). The durable boundary is no domain ownership — it
owns no business resource and persists no domain data (its Valkey session store
holds only auth/session state) — not an absence of all orchestration or
infrastructure storage. On the
HTTP proxy path it mirrors upstream
request/response shapes rather than defining its own contracts, so a proxy
call that drifts from the upstream Goa contract is a defect, not a local choice.
Authentication is selective: health (/livez, /readyz), /public/api,
the public /meetings/ pages, /docs, and a few deliberately public utility
routes (/invite/error, /auth-error, /sitemap.xml, /robots.txt) are
reachable without a session; everything under /api and the rest of the SSR
surface require one. The route table in
server/middleware/auth.middleware.ts is the authority for routes that reach
it — the OIDC login/logout/callback routes mount earlier in server.ts — so
verify there, not against this summary. The app renders under SSR and then
hydrates, so browser-only code must be guarded and no server-only secret may
cross into the client bundle. Place each change against this shape.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 199 lines · 44 tokens per session scan A ec91e7286687
copilot-code-reviewer is a skill published in the GitHub repository linuxfoundation/lfx-self-serve (11 stars, last pushed 3d ago), licensed MIT. It adds 44 tokens to every session and 2,856 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…