Skip to main content

authoring-projects

Author a new standalone NVIDIA Elements workspace project containing a Lit component, including package files, the five test types, Wireit tasks, workspace and CI registration, metadata generation, documentation-site integration, dependency-lint configuration, and generated lock/notice files. Use when creating or scaffolding a new `projects/<name>` package based on the standalone component-library pattern. Do not use for adding a component to an existing project; use the authoring-components skill instead.

Source facts

Repository
NVIDIA/elements
Last source activity
August 13, 2026 at 13:59
Detected SKILL.md language
English
Stars
93
Forks
18

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
3 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
authoring-projects
description
Author a new standalone NVIDIA Elements workspace project containing a Lit component, including package files, the five test types, Wireit tasks, workspace and CI registration, metadata generation, documentation-site integration, dependency-lint configuration, and generated lock/notice files. Use when creating or scaffolding a new `projects/<name>` package based on the standalone component-library pattern. Do not use for adding a component to an existing project; use the authoring-components skill instead.
# Authoring Projects Create a private-by-default project from a current in-repository reference, then wire every consumer before customizing the component. ## Required context 1. Read the repository `AGENTS.md`. 2. Read [references/integration-checklist.md](references/integration-checklist.md). 3. Use the `authoring-components` skill for the component class, API, examples, and five test files. 4. Use the `guidance-build-system` skill for Wireit changes and the `authoring-testing` skill when modifying tests. 5. Read `projects/internals/RELEASE.md` only when the user wants the package published. ## Workflow 1. Confirm the kebab-case project/component name, purpose, package description, and whether the project is private or publish-ready. Default the component name to the project name and keep a new scaffold private. 2. Inspect `git status`, confirm `projects/<name>` does not exist, and preserve unrelated work. 3. Preview the deterministic scaffold from the repository root: ```shell node .agents/skills/authoring-projects/scripts/scaffold-project.mjs \ --name <component-name> \ --description "<package and component description>" \ --dry-run ``` 4. Review the planned paths, then rerun without `--dry-run`. Pass `--reference <project-name>` when another standalone project is a better structural match. 5. Customize the placeholder component through the `authoring-components` workflow. Keep `index.ts` side-effect free, isolate registration in `define.ts`, use `@since 0.0.0`, and make the `@documentation` URL match the generated site route. 6. Refresh generated workspace state: ```shell mise exec -- pnpm install mise exec -- pnpm run format:fix mise exec -- pnpm run notice ``` 7. Run the project checks listed in its `DEVELOPMENT.md`, then verify the repository integrations: ```shell mise exec -- pnpm -C projects/<component-name> run ci mise exec -- pnpm -C projects/<component-name> run test:lighthouse mise exec -- pnpm -C projects/internals/metadata run generate:api mise exec -- pnpm -C projects/internals/metadata run build mise exec -- pnpm -C projects/site run build mise exec -- pnpm run lint:knip ``` 8. Use targeted project checks for isolated changes. Because scaffolding affects cross-project interfaces, generated artifacts, and more than one package, run broader CI from the repository root after the targeted checks: ```shell mise exec -- pnpm run ci ``` Inspect the final diff for generated artifacts, missing build edges, copied visual baselines, and unrelated lockfile churn. ## Guardrails - Never overwrite an existing project or reuse another component's visual baselines. - Declare every generated metadata/site input with its matching Wireit build dependency. - Keep site-only workspace packages in `projects/site` dev dependencies and its workspace-scoped dependency-lint ignore because Eleventy creates their imports dynamically. - Include CSS linting and use the repository-root stylelint path (`../../stylelint.config.mjs`) from a top-level project. - Do not create tags, publish packages, edit release wiring, or make a private project public without explicit user authorization. - Treat commit `c88b885b` as historical evidence, not a byte-for-byte template; the checklist records the defects that the scaffold must avoid.
View on GitHub