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"}]

Quality Root Skill

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.

Steps

cd to the monorepo root (find it by walking up from cwd until you find the top-level Makefile that orchestrates sub-projects).
Run make code-quality with a generous timeout (allow up to 10 minutes for a cold run).
Parse the output:
- If all modules pass: report success with a one-line summary per module.
- If any module fails: extract the exact error lines with file:line references, group them by module, and present them as a prioritised fix list.
If $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.

What to look for beyond ruff/tsc errors

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.
Basedpyright reportRedeclaration — a duplicate symbol, often from an unreviewed merge.
Prettier [warn] lines — formatting drift that will cause the next CI run to fail.

Output format

## 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 --fix and prettier --write for formatting-only failures, or always report-only and let the developer run the fix manually? Agree on this before wiring it into CI.

Más de este repositorio

mismo repositorio

add-fred-capability

ThalesGroup/fred

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).

2026-07-1758

fga

ThalesGroup/fred

Query OpenFGA authorization tuples and explain why a user has (or doesn't have) a permission on an object

2026-07-1358

review-fork

ThalesGroup/fred

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.

2026-06-2558

audit-branch

ThalesGroup/fred

Pre-PR audit of the current branch — dead code, duplicate symbols, contract drift, leftover artifacts, import gaps.

2026-06-1958

merge-review

ThalesGroup/fred

Post-merge validation — check that both sides of a merge were fully integrated, nothing was silently dropped, and quality still passes.

2026-06-1958

test-gaps

ThalesGroup/fred

Identify new code paths added in the current branch that have no test coverage. Reports gaps; does not write tests.

2026-06-1958

Quality Root Skill

Running it per-module is a known failure mode — cross-module issues only appear from the root.

Steps

cd to the monorepo root (find it by walking up from cwd until you find the top-level Makefile that orchestrates sub-projects).

Run make code-quality with a generous timeout (allow up to 10 minutes for a cold run).

Parse the output:

If all modules pass: report success with a one-line summary per module.
If any module fails: extract the exact error lines with file:line references, group them by module, and present them as a prioritised fix list.

If $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.

What to look for beyond ruff/tsc errors

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.

Basedpyright reportRedeclaration — a duplicate symbol, often from an unreviewed merge.

Prettier [warn] lines — formatting drift that will cause the next CI run to fail.

Output format

## 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 --fix and prettier --write for formatting-only failures, or always report-only and let the developer run the fix manually? Agree on this before wiring it into CI.