Flows Code Review
Run the Flows app certification technical review and produce scored code-review artifacts before design review and external submit.
Overview
Flows Code Review is an agent skill most often used in Ship (also Build integrations) that runs the Flows app certification technical review and produces three scored markdown artifacts per feedback round until no Must F
Install
npx skills add https://github.com/cognitedata/builder-skills --skill flows-code-reviewWhat is this skill?
- Writes three artifacts per round under reviews/code-review/feedback-round-N/: review-files.md, review-packages.md, and c
- Scores findings as Must Fix, Should Fix, and Nice Fix and requires zero open Must Fix items before flows-design-review
- Pre-checks package.json, git repo, and warns when App-Brief.md is missing at repo root
- Increments feedback rounds automatically when re-running until the codebase is clean
- Loads bundled Flows review guidance skills from the same repo before any scoring
- 3 artifacts per feedback round: review-files.md, review-packages.md, code-review-report.md
- 0 open Must Fix items required before flows-design-review
- Severity buckets: Must Fix, Should Fix, Nice Fix
Adoption & trust: 714 installs on skills.sh; 4 GitHub stars; trending (+100% hot-view momentum).
What problem does it solve?
You built a Flows app but lack a standardized technical review package and a clear gate before design review and external submission.
Who is it for?
Indie builders certifying a Node/TypeScript Flows app who already have package.json and git history and want the official multi-round review loop.
Skip if: Non-Flows projects, repos without package.json or git, or teams that only want informal style nits without certification artifacts.
When should I use this skill?
User asks for a Flows code review, technical review, pre-submit review, app certification code review, or says run flows-code-review.
What do I get? / Deliverables
Each round lands review-files.md, review-packages.md, and code-review-report.md with prioritized fixes cleared to zero Must Fix items so you can invoke flows-design-review next.
- review-files.md per-file inventory
- review-packages.md dependency audit
- code-review-report.md with Must Fix / Should Fix / Nice Fix scoring
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship because this skill gates certification on code quality, dependencies, and Must Fix items immediately before design review and launch-style submit. Review subphase matches structured per-file inventory, package audit, and severity-bucket report output—not ad-hoc chat critique.
Where it fits
After wiring Flows SDK calls, run a technical review to catch package and file-level issues before polish.
Execute feedback-round-2 when prior Must Fix items were addressed but dependency audit still flags risks.
Block external submit until code-review-report shows zero open Must Fix and hands off to flows-design-review.
How it compares
Use this structured certification checker instead of generic “review my repo” chat when you need Flows-specific rounds and a hard Must Fix gate.
Common Questions / FAQ
Who is flows-code-review for?
Solo and small-team builders preparing Cognite Flows apps for certification who need file inventory, dependency audit, and scored fix lists in a fixed folder layout.
When should I use flows-code-review?
Use it after build when you need a Flows code review, technical review, pre-submit review, or when the user says run flows-code-review; repeat in Ship until Must Fix is zero, then move to design review.
Is flows-code-review safe to install?
It uses Read, Glob, Grep, Bash, and Write on your repo; review the Security Audits panel on this Prism page and confirm written outputs under reviews/code-review/ before sharing externally.
Workflow Chain
Then invoke: flows design review
SKILL.md
READMESKILL.md - Flows Code Review
# Flows Code Review This skill is the **technical review** step of the Flows app certification flow: ``` flows-app-brief → build → flows-code-review (this skill, repeat until clean) → flows-design-review → flows-external-app-submit ``` ## Pre-checks Before starting, confirm: - `package.json` exists (Node/TS project) - We are inside a git repository (`git rev-parse --git-dir`) - If `App-Brief.md` is missing at repo root, warn the user that `flows-app-brief` should be run first, but continue. Determine the feedback round: look at `reviews/code-review/`. If it doesn't exist, use `feedback-round-1/`. Otherwise increment to the next missing round number. ## Step 1 — Load review guidance Before any scoring, read all relevant skill files. The skills ship alongside this skill in the same repo and are available locally. For each skill below, `Glob '**/skills/<name>/SKILL.md'` and `Read` the first match. **Required reads (always):** | Skill | Informs criteria | | --- | --- | | `correctness-and-error-handling` | 1.1 (bugs), 1.4 (tests), plus error-state patterns | | `security` | 1.2 (CDF via SDK), 1.3 (dependencies, CVEs) | | `dependencies-audit` | 1.3 (packages audit) | | `test-coverage` | 1.4 (coverage gate), 1.6 (testability) | | `code-quality` | 1.5 (dead code), 1.6 (patterns) | | `dm-limits-and-best-practices` | 2.1–2.5 (DMS query patterns, limits, rate) | | `performance` | 2.3–2.4 (pagination, call rate) | | `design` | 3.1 (Aura consistency) | **Conditional read:** - `setup-flows-auth` — read if the app imports `connectToHostApp`, `useHostApp`, or configures OAuth in Vite. **Note on DMS patterns:** the `dm-limits-and-best-practices` skill is the canonical local reference for search vs joins, cardinality, and query-time semantics — no external `semantic-knowledge/` submodule is needed. Do not proceed to scoring until all skill reads are complete. ## Step 2 — Build the file inventory (`review-files.md`) List **all `.ts` and `.tsx` files** in the app (exclude `node_modules`, `dist`, `.cognite-bundles`). For each file assess: - **Structure** (1–5): file size, single responsibility, clear organization - **Quality** (1–5): type safety, no `any`/`unknown` casts, proper error handling, no dead code, clean naming - **Patterns** (1–5 or N/A): DI/testability, correct platform patterns, no anti-patterns; `N/A` for pure utils/types - **Tests**: `✓` adequate | `⚠` has tests with meaningful gaps | `✗` no test file | `N/A` (presentational-only or barrel) Write to `reviews/code-review/feedback-round-<N>/review-files.md`: ```markdown ## File inventory: [app name] | File | Structure | Quality | Patterns | Tests | Notes | | ---- | --------- | ------- | -------- | ----- | ----- | | src/main.tsx | 5 | 5 | N/A | N/A | Clean entry point | | src/services/cdfHelper.ts | 3 | 2 | 2 | ✗ | No DI; raw sdk.get/post; no test file (1.2, 1.6, 2.5) | | ... | ... | ... | ... | ... | ... | ``` ## Step 3 — Build the package inventory (`review-packages.md`) Gather dependency state with two one-shot commands — do **not** loop per package (`npm view <pkg>` is one network call per package; 40–80 calls = 2–4 minutes): ```bash npm outdated --json 2>/dev/null || true # exits 1 when outdated packages exist — normal; parse stdout regardless npm audit --json 2>/dev/null || true # exits 1 when vulnerabilities exist — par