mcpField
N
nuqs-scaffolder

nuqs-scaffolder

github.com/pproencaDevelopment218136 installsUpdated 11w ago
Repository

About nuqs-scaffolder

A template-driven skill for generating a coordinated set of nuqs files from a parameter spec. It is intended for developers adding URL-backed state to Next.js pages, with shared parser definitions for client and server files.

Key features

  1. 01Generate nuqs files from a spec
  2. 02Support multiple query parameter types
  3. 03Create client and server parser maps
  4. 04Render filter components and optional tests
  5. 05Configure output paths and naming

Use cases

  1. 01Add URL-backed search, filters, pagination, or sorting
  2. 02Replace ad hoc useState filters with nuqs
  3. 03Keep client and server parser definitions aligned

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/pproenca/dot-skills --skill nuqs-scaffolder

After installing, type/nuqs-scaffolderin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

AGENTS.md
config.json
gotchas.md
metadata.json
assets/templates/
filters.test.tsx.template
filters.tsx.template
searchParams.server.ts.template
searchParams.ts.template
spec.json.template
references/
conventions.md

Details

From the project README

nuqs Scaffolder

Generate a coherent set of nuqs files from one spec. The skill is template-driven — you read the spec, copy the templates, and substitute placeholders. No build step, no codegen runtime; the templates ARE the artifact.

When to Apply

Use this skill when:

  • A new Next.js page needs URL-backed filters, pagination, search, or sort state
  • You're standardising an existing page's ad-hoc useState filters onto nuqs
  • A code review keeps catching client/server drift in parser definitions — this skill makes drift mechanically impossible because both sides import the same map
  • A user asks to "add Standard Schema validation to these query params for tRPC" — the generated searchParams.server.ts already exports the schema

If the codebase has legacy nuqs patterns instead, run the nuqs-codemod-runner skill first.

How to Use

  1. Read or create a spec. Start from assets/templates/spec.template.json and fill in name, module, and params. See "Spec Format" below.
  2. Render each template by replacing placeholders with values derived from the spec.
  3. Write each rendered file to the path computed from config.json (overridable per-call).
  4. Show the user the diff before committing — this skill never modifies existing files; if a target path exists, ask before overwriting.

The agent does the rendering — Claude is the templating engine. Each template is annotated with markers (/*= ... =*/) that name the placeholder slot and document the substitution rule.

Spec Format

{
  "name":   "Search",                    // PascalCase — drives the exported symbol names
  "module": "search",                    // kebab-case — drives file paths and the "module" folder

  "params": {
    "q":          { "type": "string",                                    "default": "" },
    "page":       { "type": "integer",                                   "default": 1 },
    "limit":      { "type": "integer",                                   "default": 10 },
    "categories": { "type": "array-of-string-native",                    "default": [] },
    "sort":       { "type": "string-literal", "values": ["asc","desc"],  "default": "asc" },
    "minPrice":   { "type": "float",                                     "default": null },
    "lastSeen":   { "type": "iso-date",                                  "default": null }
  }
}
Supported type values
typeParser usedNotes
stringparseAsString
integerparseAsInteger
floatparseAsFloat
booleanparseAsBoolean
iso-dateparseAsIsoDateDate-only
iso-date-timeparseAsIsoDateTimeDate + time
timestampparseAsTimestampms since epoch
hexparseAsHexNumeric value, hex URL form
indexparseAsIndex0-based in code, 1-based in URL
array-of-stringparseAsArrayOf(parseAsString)?tags=a,b,c
array-of-string-nativeparseAsNativeArrayOf(parseAsString)?tag=a&tag=b — requires nuqs ≥ 2.7
string-literalparseAsStringLiteral(values)Requires values: string[]
number-literalparseAsNumberLiteral(values)Requires values: number[]
jsonparseAsJson(SchemaName.parse)Generates a Zod schema stub; mark default separately

If default is null, the param is nullable; otherwise the template uses .withDefault(...).

Available Templates

TemplateRenders to (default)Loaded when
searchParams.ts.templatelib/{module}-search-params.tsAlways
searchParams.server.ts.templatelib/{module}-search-params.server.tsAlways
filters.tsx.templatecomponents/{module}/{name}-filters.tsxAlways
filters.test.tsx.templatecomponents/{module}/{name}-filters.test.tsxIf config.generate_tests is true
spec.json.templateAnywhere — starter for the userFirst-run prompt

Template files end in .template so editors don't apply syntax highlighting to placeholder markers — the original extension is preserved as the suffix-before-.template so you can still tell at a glance what the rendered file will be.

Paths are configurable in config.json — override globs, file naming style (kebab vs PascalCase), and whether tests are emitted.

Placeholder Reference

All templates use the same placeholder syntax. The agent substitutes them in one pass:

PlaceholderSourceExample
__NAME__spec.nameSearch
__name__camelCase form of spec.namesearch
__module__spec.modulesearch
/*= PARSERS =*/Iterate spec.params → key: parseAsXxx.withDefault(...) linessee template
/*= COMPONENT_FIELDS =*/Iterate spec.params → one input/select per typesee template
/*= TEST_CASES =*/Iterate spec.params → one assertion per defaultsee template
/*= NULLABLE_IMPORTS =*/Add Nullable helper import if any param is nullableconditional
/*= ZOD_SCHEMAS =*/For json type params, emit a Zod schema stubconditional

/*= ... =*/ markers are instructions to the agent, not literal substitutions. Replace the entire marker (including the /*= =*/ delimiters) with the expanded content.

Conventions

Read references/conventions.md for:

  • File naming (kebab-case) and why
  • Import ordering (external → nuqs → internal → relative) and why
  • Why the server file exists as a sibling, not inside app/
  • When to fork the templates (you usually shouldn't)

Setup

config.json is pre-populated with sensible Next.js App Router defaults. Override only if your repo uses different conventions:

{
  "lib_dir": "lib",
  "components_dir": "components",
  "generate_tests": true,
  "test_runner": "vitest"
}

On first use, the agent should ask the user for the spec via AskUserQuestion if no spec file is provided.

Related Skills

  • nuqs — Best-practice reference these templates encode. Read it to understand WHY the templates are shaped this way.
  • nuqs-codemod-runner — Run BEFORE this skill if migrating an existing page from pre-v2.5 nuqs.

Gotchas

See gotchas.md for edge cases discovered during use.

Comments

Markdown supported