Pack Capabilities and Lint Rules Research

Question

Do scaffold packs currently support tools, skills, and lint rules?

Three readonly lanes checked the public pack schema, runtime application path, and tests and documentation. This report records current behavior. It does not propose a schema change.

Trusted facts

• Packs directly declare skills and lint assets. The public pack schema includes skills, lintAssets, hooks, prompt surfaces, prompt details, and optional example repositories. It does not include a direct tools or requiredTools field. Sources: packages/scaffold/src/catalog.ts and apps/cli/src/data/catalog/packs.ts.
• Tools are supported indirectly. Selected packs contribute skills; skills declare requiresTools; scaffold combines those requirements with the always-required baseline tools and records the resulting required-tool configuration. Sources: apps/cli/src/data/catalog/skills.ts, apps/cli/src/content/tools.ts, and apps/cli/src/scaffold/run.ts.
• Lint support is executable, not documentation-only. A lint asset can carry Oxlint presets, preset-local rules, native and JavaScript plugins, settings, rules, required development dependencies, package targeting, ignore patterns, and placement guidance. Sources: apps/cli/src/data/catalog/lint.ts and apps/cli/src/content/lint.ts.
• Effect, Next.js, quality, React, and TanStack Query packs currently select lint assets. Examples include Effect's no-barrel-import rule, React's framework and unnecessary-effect policy, and the Vitest preset in the quality pack. Source: apps/cli/src/data/catalog/packs.ts.
• Scaffold resolves selected lint assets per workspace, generates an executable oxlint.config.ts, and adds missing oxlint, ultracite, and plugin dependencies. Existing JSON or JSONC Oxlint rules and dependency versions are preserved when merged. Sources: apps/cli/src/scaffold/output.ts and apps/cli/src/scaffold/run.test.ts.
• Tests execute generated configurations through Oxfmt and Oxlint and exercise the Effect rule. This is stronger evidence than the requirements document, whose exact pack membership list has drifted behind the live catalog. Sources: apps/cli/src/scaffold/run.native.test.ts and docs/reference/hi-requirements.md.

Limits and uncertainty

• Saying "packs support tools" needs qualification. Tool installation and verification are part of the pack-to-skill flow, but packs cannot directly list tools in the current schema.
• Existing .oxlintrc.json and .oxlintrc.jsonc files are merge inputs. Existing TypeScript oxlint.config.ts files are not parsed as merge inputs.
• Pure Python workspaces without JavaScript dependencies are skipped. Pack-owned Ruff rules remain future work in the requirements document.
• In monorepos, generated lint configuration targets package workspaces rather than the root manifest. Wiki workspaces do not receive the general generated Oxlint config because the wiki owns a separate starter baseline.
• .devpunks/specs/lint/* records selection and audit evidence. Enforcement comes from generated workspace configuration and dependencies.

Synthesized conclusion

Yes, packs support skills and real lint rules/configuration. Tools are also supported operationally, but indirectly: packs select skills, and skills declare their required tools. There is no direct pack-level tools field today.

Next local action

No change is required to answer the question. If direct pack-owned tools are a desired product capability, route that as a separate schema and lifecycle decision instead of describing the current indirect model as direct support.