本文へ移動
cccskills
無料GitHub で公開

consumer-impact

Use when asked to test a Lumen change against consumer repos before releasing it: a breaking or architectural change, a lint-plugin upgrade, peer/prod dependency moves, build or packaging changes, or to check how consumers use a component, prop or variant. Runs the change (or a usage scan) across the production consumers in the adoption registry and outputs a shareable HTML report.

インストール方法を見る

含まれるファイル(3)

  • SKILL.md4.8 KB
  • assets/report-template.html7.8 KB
  • scripts/scan-manifests.mjs2.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Consumer impact

Answers "what breaks, and for whom, if we ship this?" by running the change in real consumer repos.

1. Frame

  • Change under test: the branch, PR or diff, and which @ledgerhq/lumen-* packages it touches.
  • Mode:
    • Usage scan: where consumers use a component, prop, variant, token or export. Read-only, no install.
    • Install & check: install the changed packages in each consumer, then run its checks (install, typecheck, lint, build, tests).
  • Repos: all production consumers by default, or the subset the user names.

2. Consumers

The registry is internals/adoption-tool/data/consumers.json. Read it, never copy it, and keep only production repos:

jq -r '.[] | select(.status == "production") | .repo' internals/adoption-tool/data/consumers.json

For each repo, packageJsonPath / packageJsonPaths say which workspace declares Lumen, and notes flags pnpm catalogs (the version lives in pnpm-workspace.yaml). For owners, run npx nx run adoption-tool:owners (see the lumen-adoption-report skill) from a checkout with node_modules installed and GITHUB_TOKEN set; it prints nothing otherwise.

Start every run with the manifest scan. It reads each production consumer's Lumen workspace package.json (and pnpm catalog) through the GitHub API, with no clone, and prints one TSV row per workspace:

node .claude/skills/consumer-impact/scripts/scan-manifests.mjs '^(@ledgerhq/lumen-|tailwindcss$|tailwind-merge$)'

The argument is a regex of the dependency names to report.

3. Get the change as installable packages

Pick one:

  • PR with the publish-dev-package label: use the install URLs from the PR's "Dev packages published" comment (see docs/pull-requests.md). These are the easiest to share and reproduce.
  • Local branch: build and pack the touched libs: npx nx run-many -t build --projects=<packages>, then npm pack in each libs/<lib>/, and use the .tgz paths.

Lumen packages pin each other exactly (e.g. ui-react → design-core), so when a change touches several packages, install all their tarballs and force them with the consumer's override mechanism (npm overrides, pnpm pnpm.overrides, yarn resolutions). Otherwise the consumer pulls the published sibling and silently tests the old code.

4. Run

Use parallel subagents, one per repo, when available.

  • Usage scan (no clone): start from the manifest scan, then gh search code "<import or symbol>" --repo <repo> and read the hits with gh api repos/<repo>/contents/<path>. Clone only when the search is too fuzzy. Code search covers default branches only: report counts as a floor.
  • Install & check: one shallow clone per repo in tmp/consumer-impact/ (gitignored): gh repo clone <repo> tmp/consumer-impact/<name> -- --depth 1.
    1. Baseline: detect the package manager from the lockfile, install as-is, then run the scripts the consumer actually has in that workspace (typecheck, lint, build, test). Record pass/fail per check.
    2. Point the Lumen packages at the tarballs (catalog repos: edit the entry in pnpm-workspace.yaml) with the overrides above, and reinstall.
    3. Run the same checks again. A check that fails now but passed at baseline is caused by the change; record its first relevant errors. One that already failed at baseline is reported as pre-existing.
  • Skip a repo that is too heavy or fails at baseline, and say so. Never commit, push, or open a PR in a consumer repo; clones are throwaway.

5. Report

Copy assets/report-template.html whole (title, styles and all) and replace only what sits between the REPORT CONTENT markers: the change, the matrix (repo × check, baseline vs change), the breakages with error excerpts and owners, and the suggested fix or migration note per breakage. Delete the template's example rows and comments. The <title> names the change in 2–4 words. Write it to tmp/consumer-impact/report-<YYYY-MM-DD>-<slug>.html (gitignored), never elsewhere in the repo tree.

  • With the Artifact tool (Claude Code): publish that file (private until shared), reply with the link and a one-paragraph summary.
  • Otherwise: wrap it in a full HTML document (see the template's header comment), and reply with its path and the summary.

Never commit a report or consumer code excerpts: this repo is public and most consumers are private.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Creates and maintains Figma Code Connect files (`*.figma.tsx`) that map Figma components to code via the parser-based `figma.connect()` API. Use when the user mentions Code Connect, Figma component mapping, design-to-code translation, or asks to create/update .figma.tsx files.

日本語の概要は準備中です。原文の説明を表示しています。

LedgerHQ/lumen232026年10月17日 更新

Use when creating, naming, or placing a file or folder in libs/*, or when modifying or adding a file to an existing component (even when the barrel isn't touched) — component vs utility naming, the one-responsibility-per-file layout, when a folder needs an `index.ts` barrel (public API only), and the required set of files a component needs per lib. Load this before scaffolding or restructuring a component so the layout matches the codebase.

日本語の概要は準備中です。原文の説明を表示しています。

LedgerHQ/lumen232026年10月17日 更新

Use when designing or changing a component's public API, its composition, or its state model in libs/ui-react or libs/ui-rnative — layering (core vs internal vs primitives), BaseProps/Props splits, converting a component to compound / changing its composition with createSafeContext, controlled/uncontrolled state, prop-naming conventions, and cross-platform API parity. Load this before shaping a new component, changing its props, or refactoring its composition.

日本語の概要は準備中です。原文の説明を表示しています。

LedgerHQ/lumen232026年10月17日 更新

Use when writing or editing Storybook MDX docs (*.mdx) — the two-tab Overview/Implementation structure, story-backed `<Source>` examples, and doc table guidelines.

日本語の概要は準備中です。原文の説明を表示しています。

LedgerHQ/lumen232026年10月17日 更新

Use when creating or editing Storybook stories (*.stories.tsx, React or React Native) — story layout, controls, and export naming conventions.

日本語の概要は準備中です。原文の説明を表示しています。

LedgerHQ/lumen232026年10月17日 更新

Use when building or styling a component in libs/ui-react or libs/ui-rnative — the cross-platform styling principles, plus routing to the platform mechanics: Tailwind + cva + cn on web, useStyleSheet + themeJS + lx on React Native. Load this before writing component styles.

日本語の概要は準備中です。原文の説明を表示しています。

LedgerHQ/lumen232026年10月17日 更新

LedgerHQ のスキルをすべて見る

このスキルの問題を報告する