Menu
Run make code-quality from the monorepo root, covering all modules. Never run it per-module.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | quality-root |
| description | Run make code-quality from the monorepo root, covering all modules. Never run it per-module. |
| user-invocable | true |
| argument-hint | [{"optional":"module name to focus report on"}] |
Run make code-quality from the monorepo root (/home/dimi/Work/swift), which covers all
modules in dependency order: libs/fred-core, libs/fred-sdk, libs/fred-runtime,
libs/fred-agents, apps/control-plane-backend, apps/knowledge-flow-backend, apps/frontend.
Running it per-module is a known failure mode — cross-module issues only appear from the root.
cd to the monorepo root (find it by walking up from cwd until you find the top-level Makefile
that orchestrates sub-projects).make code-quality with a generous timeout (allow up to 10 minutes for a cold run).$ARGUMENTS names a specific module (e.g. knowledge-flow-backend), still run the full root
check but highlight that module's results at the top of the report.After the tool run, also scan the raw output for these softer signals that tools don't flag as errors but that indicate real problems:
# type: ignore comments that suppress reportMissingImports — the module probably doesn't exist yet.reportRedeclaration — a duplicate symbol, often from an unreviewed merge.[warn] lines — formatting drift that will cause the next CI run to fail.## Quality gate — <date>
| Module | Status | Issues |
|--------|--------|--------|
| libs/fred-core | ✅ pass | — |
| apps/knowledge-flow-backend | ❌ fail | 2 basedpyright errors |
...
### Failures
**apps/knowledge-flow-backend**
- `structures.py:417` — reportRedeclaration: duplicate validator `_normalize_retry_initial_interval`
Open team decision — auto-fix on pass: Should this skill offer to auto-run
ruff format --fixandprettier --writefor formatting-only failures, or always report-only and let the developer run the fix manually? Agree on this before wiring it into CI.
Author a new Fred agent capability (manifest + middleware) built on fred-sdk. Picks the right authoring lane, maps each runtime need to a middleware hook, wires entry-point registration, and enforces the capability boundary (never hand-edit union/registry hotspots, no capability code in control-plane, no runtime info in LLM tool signatures).
Query OpenFGA authorization tuples and explain why a user has (or doesn't have) a permission on an object
Safety-first review of an external pull request from an untrusted fork. Fetches the diff read-only into an isolated worktree, scans for supply-chain / exfiltration / CI-tampering threats, checks scope, then delegates correctness review. Never builds or runs the fork's code.
Pre-PR audit of the current branch — dead code, duplicate symbols, contract drift, leftover artifacts, import gaps.
Post-merge validation — check that both sides of a merge were fully integrated, nothing was silently dropped, and quality still passes.
Identify new code paths added in the current branch that have no test coverage. Reports gaps; does not write tests.