Recommend a data-portal architecture (storage, compute, catalog, access, hosting, metadata) from stated needs, then hand off to the build skills. The advisory entry point.
SkillScore82Maintained
Automatic
◆Data Engineer pack
Last verified 8/13/2026
What it changes
Passed 17 of 21 test cases with the skill, and 5 of 21 without it.
Without skill23%
With skill82%
Checks it passed that the model alone missed
Configures DATA_QUERY mode to duckdb.
Assigns dataset tier to LFS or inline.
Configures the DATA_QUERY build knob to flat.
and 14 more in the full report
13 fixed5 passed either way4 still failing0 broke
Pass-rate lift
+59 pp
Tokens
+19%
Agent turns
0%
Response time
-47%
Model gemini-3.6-flashMeasured 8/13/2026v118 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 13
Prompt
We want an ultra-minimal static portal with zero WebAssembly or DuckDB runtime footprint, where clients simply download small raw files directly. Which DATA_QUERY knob setting should we pick?
What was checked, without and with the skill
Checked
Without skill
With skill
Configures the DATA_QUERY build knob to flat.
Missed
Passed
case-10 · gemini-3.6-flash · 8/13/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md90 lines2 files
PortalJS — Architect
Overview
The advisory entry point for a PortalJS project. Before anything gets scaffolded, this
skill works out what to build: given the kind of portal, the shape of the data, and its
purpose, it fills six architecture slots (storage, catalog, compute, access, hosting,
metadata), resolves two build-time knobs (per-dataset data tier and the portal-wide
DATA_QUERY mode), and hands off to the concrete build skills. It decides; it does not
build. When the brief is thin it interviews in short rounds and never dead-ends — every
question has a sensible default, reachable by replying "use defaults."
Prerequisites
A rough idea of the portal's purpose and data (exact numbers are not required — the
interview supplies defaults for anything missing).
Optional: local files or a directory of sample data to inspect for size and shape.
No PortalJS project needs to exist yet; this skill runs before scaffolding.
Instructions
The canonical, full step-by-step workflow lives in
.claude/commands/portaljs-architect.md —
that file is the single source of truth. Follow it when executing this skill:
Parse $ARGUMENTS for anything already specified, then interview for what's
missing, one round at a time: (1) what's being built, (2) what the data is,
(3) what it's for, (4) constraints. Accept "use defaults" at any point. Inspect
named files/directories with du -sh and line counts to ground size guesses.
Derive the recommendation by matching the answers against the decision tables —
Storage/Catalog/Compute by data volume and query needs, Access/Hosting by public
vs. private, Metadata by standards-compliance needs — then resolve the two
build-time knobs: per-dataset data tier (inline | LFS | external) and the
portal-wide DATA_QUERY mode (flat | duckdb).
Echo the architecture brief (stack, reasoning per slot, deviations from default,
deferred items) and wait for confirmation ("go") or corrections.
On confirmation, persist the brief to ./ARCHITECTURE.md in the working directory.
Hand off to the build skills — /portaljs-new-portal, /portaljs-add-dataset,
/portaljs-connect-ckan, /portaljs-define-schema, /portaljs-deploy — mapped
from the brief, and offer to run the first one.
Output
Created:./ARCHITECTURE.md documenting the six slots, the two build-time