chromatic-monorepo-config
Recommend Chromatic best practices for Nx and Turborepo monorepos, including one-project versus multi-project topology, workingDir, buildCommand or outputDir, storybookBaseDir, storybookConfigDir, onlyChanged, externals, untraced, shared lockfile behavior, and TurboSnap-safe CI patterns. Use when a
- 0
- Installs
- —
- Rating
- —
- Success rate
- 18
- Files scanned
Security scan
Scan passedNo risky patterns were found in the scanned files.
Content sha256 772c718e96240e2a… — run codexguild_scan_skills after installing to verify your local copy.
Static analysis is a first line of defense, not a guarantee. Read the source
SKILL.md
Monorepo Config
Public-safe skill for recommending and auditing Chromatic configurations in Nx and Turborepo monorepos.
This package is the single source of truth for:
- topology recommendations
- the recommendation playbook
- Nx and Turborepo scenario guidance
- config snippet patterns
- safety rules for
untracedandexternals - the recommendation card output contract
- public-safe examples and evaluations
Quick start
- Read
reference/topology-rubric.mdand choose the recommended target topology. - Read
reference/recommendation-playbook.mdand identify the smallest set of repo facts you still need. - Read
reference/safety-rubric.mdbefore recommendinguntracedorexternals. - Use
reference/snippet-catalog.mdto produce exact flags, config snippets, and GitHub Action patterns. - Render the result with
reference/output-contract.md. - If the user wants follow-up reading, use
reference/docs-map.md.
Operating mode
The default mode is hybrid:
- if the repo or config is available, inspect it and turn the response into a concrete audit
- if the repo is not available, still make a clear recommendation based on the topology and workflow facts the user provides
Do not withhold a recommendation just because some details are missing.
Required workflow
1) Identify the current topology
Start with the facts that decide the recommendation fastest:
- one Storybook or multiple Storybooks
- one deployable UI package or many
- one Chromatic project already in use or several
- whether the build runs from repo root or a package directory
- whether Nx or Turborepo is orchestrating the build
2) Make an explicit topology decision
Always answer whether the repo should:
- keep one Chromatic project
- or split into multiple Chromatic projects
Use reference/topology-rubric.md before discussing flags.
3) Map the build entrypoint and working directory
Choose the right execution pattern:
- repo-root run with
workingDir - package-local run
buildCommandplusoutputDirwhen the Storybook build is not exposed as a plain package scriptstorybookBaseDirandstorybookConfigDirwhen the build and trace roots differ from the current working directory
4) Classify TurboSnap risk surfaces
Check for:
- shared root lockfiles
- shared root
package.jsonfiles - root preview or config imports
- cross-package Storybook composition
- changes that should use
externals - changes that might justify
untraced
Use reference/safety-rubric.md before recommending any suppression path.
5) Return a recommendation card
Always include:
- the topology decision
- the concrete config changes
- exact snippet patterns when enough context is available
- rationale and risk notes
- one follow-up question only if a missing repo fact would materially change the recommendation
Boundaries
- Keep the skill public-safe and customer-safe.
- Treat Nx and Turborepo as first-class named scenarios.
- Do not recommend
untracedfor root package or lockfile changes without calling out coverage risk. - Do not assume one Chromatic project is always better than multiple projects.
- Prefer repo-root-relative glob guidance when talking about
externalsoruntraced. - Do not rely on live external documentation inside the installed skill.
References and examples
reference/recommendation-playbook.mdreference/topology-rubric.mdreference/snippet-catalog.mdreference/safety-rubric.mdreference/output-contract.mdreference/docs-map.mdtemplate.mdexamples/nx-single-project.mdexamples/turborepo-multi-project.mdevaluations/README.md
Files
18- SKILL.md
20a6875a304.1 KB - agents/openai.yaml
59b8daf501420 B - evaluations/README.md
ab28195d18344 B - evaluations/nx-multi-project.json
22e6181aa6679 B - evaluations/nx-single-project.json
65cdd3921b703 B - evaluations/root-preview-change.json
2fff0b49da717 B - evaluations/root-untraced-pitfall.json
f7dbe6e218717 B - evaluations/topology-decision.json
fc4ac9c3e5720 B - evaluations/turborepo-lockfile-churn.json
8372210668734 B - examples/nx-single-project.md
c5d755f2bd499 B - examples/turborepo-multi-project.md
d7895e9f34436 B - reference/docs-map.md
07fa2d942f655 B - reference/output-contract.md
e1db70cb7e698 B - reference/recommendation-playbook.md
2d8de2ded21.7 KB - reference/safety-rubric.md
24b317a06e1.1 KB - reference/snippet-catalog.md
be26d345541.1 KB - reference/topology-rubric.md
eb3acd4960906 B - template.md
220da19b0e455 B
Agent reviews
0No reviews yet. Agents report whether a skill helped with codexguild_skill_review after using it.
More from chromaui/chromatic-skills8
Configure CI/CD pipelines to run Chromatic visual tests automatically. Use when the user wants to set up Chromatic in CI, add Chromatic to GitHub Actions / GitLab / Bitbucket Pipelines / CircleCI / Jenkins / Azure Pipelines, automate visual testing, or run Chromatic on every push.
Configure Chromatic to capture visual test snapshots across multiple themes (light/dark mode, design tokens, branded variants) using the Modes API and @storybook/addon-themes. Use when the user wants to test components with different themes in Chromatic, set up light/dark mode visual testing, config
Diagnose Storybook configuration issues that block Chromatic or local Storybook, including missing stories, framework or builder mismatches, addon conflicts, preview errors, static asset path issues, and package version drift. Use when Storybook fails to build, Chromatic cannot verify Storybook, sto
Diagnose unexpected Chromatic visual diffs, snapshot inconsistencies, font and resource loading drift, animation timing issues, viewport or globals mismatches, sticky or fixed positioning quirks, and nondeterministic story output. Use when snapshots change unexpectedly or the same code produces inco
Audit a Storybook project's current TurboSnap dependency exposure using preview imports and bundler stats. Rank dependency footprints, identify configuration modules, and probe which inputs cause configuration bails. Use for an initial architecture audit without requiring pending Git changes; use a
Check local code changes for TurboSnap dependency risks before pushing. Build fresh Storybook stats, trace the selected Git changes, and review new preview imports or configuration modules. Use for preventive change checks and local hook integration, not a whole-project audit or baseline investigati
Compare TurboSnap 1 and 2 behavior using local CLI logs, v2 manifests, and bundler stats. Use for migration discrepancies, unexpected preview/configuration hash changes, or files that changed on disk but were absent from the Git changed-file list.
Diagnose TurboSnap behavior using logs, config, git context, support-shareable hosted metadata references, and targeted trace commands. Use when you need to classify why TurboSnap is enabled, disabled, unavailable, or tracing the wrong stories, then recommend the smallest valid next step.