extract

extractスキルの概要

extractでできること

extractスキルは、繰り返し登場するUIコードを、再利用可能なDesign Systems資産へ整理していくためのスキルです。具体的には、重複しているコンポーネント、ハードコードされたデザイン値、実装の揺れたパターンを見つけ出し、共有コンポーネントやトークンとして提案・作成できる形に導きます。

extractが向いている人

このextractスキルは、プロダクトUI、コンポーネントライブラリ、Design Systemsに取り組むチームで、すでにある程度コードの重複があり、それをより体系的に集約したい場合に特に向いています。とくに、フロントエンドエンジニア、デザインシステムの保守担当者、AI支援のリファクタリングワークフローと相性が良いです。

本当に解決したい仕事

多くのユーザーが求めているのは、漠然としたリファクタではありません。実際には「どこを共有コンポーネント化すべきか」「どの値をトークン化すべきか」「アプリを壊さずにどう移行するか」といった判断です。extractスキルは、単なるコード整理ではなく、この意思決定の流れに沿って設計されています。

このextractスキルが違う理由

「これを再利用可能にして」とだけ指示する普通のプロンプトと違い、extractは発見フェーズから始まります。まず既存のデザインシステムを見つけ、命名規則やトークン規約を確認し、繰り返し現れるパターンを洗い出し、本当に抽出する価値があるかを見極めたうえで、移行計画まで考えます。そのため、場当たり的なコンポーネント生成よりも、Design Systemsの作業に適しています。

extractが強くハマる場面

次のようなときにextractを使うと効果的です。

• 繰り返し出てくるUIパターンを共有コンポーネントに集約したい
• 色、余白、タイポグラフィ値など、トークン候補を洗い出したい
• 同じ概念なのに実装がバラついているものを標準化したい
• 新しく一から作るのではなく、既存のデザインシステムを拡張したい
• 多数のファイルを編集する前に、抽出方針を固めたい

インストール前に知っておきたい境界条件

導入時の最大の前提は、extractが「拡張すべき既存のデザインシステムや共有UI構造があるかもしれない」と想定していることです。もし何も存在しない場合、このスキルは先に「どこに、どうやってそれを作るべきか」を確認するよう促します。ゼロからのグリーンフィールドでDesign Systemsアーキテクチャを組み立てたい場合、このスキルだけでは一部しかカバーできません。

extractスキルの使い方

extractスキルをインストールする

リポジトリから次のコマンドでスキルをインストールします。

npx skills add pbakaus/impeccable --skill extract

インストール後は、単発の画面実装ではなく、再利用可能なUIパターンやトークンの抽出が目的のタスクで呼び出すのが適切です。

extractを呼ぶ前に、理想的な入力を押さえる

extractスキルは、次の情報があると最も力を発揮します。

• 対象となる領域、機能フォルダ、または重複しているファイル群
• 現在のデザインシステムや共有UIライブラリの場所
• 使用しているフレームワークとスタイリング構成
• 解決したい再利用の課題
• 「公開export名は変更しない」のような移行制約

「これをきれいにして」といった曖昧な依頼では、推測の余地が大きすぎます。どのパターンが重複していて、どこへ集約したいのかまで明示すると、extractの精度が上がります。

ざっくりした依頼を、強いextractプロンプトに変える

弱いプロンプト:

• “Refactor these components.”

より良いextractの使い方:

• “Use the extract skill on src/features/billing and src/features/settings to find repeated form-row and card patterns. Our shared components live in src/ui. We use React, TypeScript, and CSS modules. Prefer extracting tokens for spacing and colors only if they appear in 3+ places. Propose a migration plan before editing.”

このようなプロンプトなら、スキルは発見・価値判断・過剰抽出の回避に必要な前提をきちんと得られます。

extractが最初に確認すべきもの

最初にスキルへ示すべきなのは、次の場所です。

• 重複が疑われるUI領域
• 共有コンポーネントのディレクトリ
• トークンやテーマのファイル
• 既存のドキュメントやStoryがあればその所在

元のスキルでも、まずデザインシステムを見つけることが重視されています。これは、抽出の質が既存の命名、構成、import規約、ドキュメントの書き方にきちんと合うかどうかに左右されるためです。

Design Systems向けextractの推奨ワークフロー

実践的なextractの進め方は、次のようになります。

1. 現在のデザインシステムまたは共有UIフォルダを特定する
2. 対象領域を走査し、繰り返し使われるコンポーネントやハードコード値を探す
3. 見た目が少し似ているだけのものまで全部抽出せず、近いパターンごとに束ねる
4. 何を共有プリミティブ、合成コンポーネント、トークンにすべきか判断する
5. 抽出計画を提案する
6. 利用側ファイルを慎重に移行する

この順序こそがextractスキルの中核的な価値です。抽象化を早まるリスクを下げられます。

リポジトリ内で最初に読むべきもの

このスキルは軽量です。まず SKILL.md を読み、実質的な運用ガイドとして扱うのが基本です。特に注目すべきセクションは次のとおりです。

• Discover
• Plan Extraction
• Extract & Enrich
• Migrate

このスキルフォルダには補助スクリプトや追加の参照資料がないため、実際の価値の大半は、この判断順序を正しくなぞることにあります。

extractは何を「再利用すべき」と判断するのか

extractを導入すべきかどうかは、「すべてを抽出すべきではない」というこのスキルの前提に納得できるかにかかっています。強みを発揮するのは、パターンが複数回使われていて、今後も再登場する可能性が高く、意味的に安定しており、中央管理する価値がある場合です。マーケティング用の単発レイアウトが多いコードベースでは、有用性は下がります。

extractの出力として期待すべきもの

extractスキルがうまく機能すると、出力には次のような内容が含まれます。

• コンポーネント候補の特定
• トークン候補
• なぜ集約するのかという根拠
• 想定されるAPIや命名方針
• 移行の順序

もし、共有資産の置き場所を確認しないまま、いきなりコード生成に入るようなら、プロンプト側の文脈が不足しているサインです。

extractの実用性を上げるコツ

より良い結果を得るには、次の点を明示すると効果的です。

• 「3回以上使われている場合だけ抽出する」のように再利用の閾値を指定する
• 正式な配置先フォルダを明記する
• 現在の公開APIを維持するかどうかを伝える
• 編集前に計画を出すよう求める
• コードベースが散らかっているなら、トークン抽出とコンポーネント抽出を分ける

こうした情報は、抽出計画の質を目に見えて左右します。

extractスキルのよくある誤用

次の用途にはextractを使わないほうがよいです。

• 繰り返し元となるパターンがない、新規コンポーネントの発明
• 大規模なビジュアルリデザイン
• ステークホルダーの指針なしに、ゼロからDesign Systems全体を設計すること
• 共有抽象化が不要な、ごく小さな単一ファイルの整理

このようなケースでは、extractスキルより通常の実装プロンプトのほうが早いことがあります。

extractスキルFAQ

extractは普通のプロンプトより良い？

Design Systemsの作業では、多くの場合で良い選択です。通常のプロンプトは抽象化を急ぎすぎたり、既存システムの構造を見落としたりしがちです。何を中央管理すべきかを見つけ、既存のUIシステムへどう移行するかが本題なら、extractスキルのほうが向いています。

extractは初心者向け？

中程度です。ワークフロー自体は明快ですが、デザインシステムの場所、トークンファイル、命名規約を見分けられないと、初心者には難しい場面があります。フロントエンドアーキテクチャに不慣れなら、パスを明示し、変更前にトレードオフの説明も求めると使いやすくなります。

既存のデザインシステムは必須？

必須ではありません。ただしextractスキルは、既存システムがある可能性を明確に前提としており、新しい仕組みを作る前にそこを確認するよう促します。リポジトリに共有UIレイヤーがない場合、extractは自律的にアーキテクチャを決めさせるより、発見と計画の用途に寄せて使うのが安全です。

extractが特に得意なパターンは？

繰り返し使われるコンポーネント、ハードコードされたデザイン値、同じUI概念の実装揺れ、再利用しやすいコンポジションパターンに強いです。一方で、再利用可能なUI構造に結びつかないビジネスロジック中心のリファクタでは、魅力は下がります。

extractを使わないほうがいいのはいつ？

重複が表面的なだけの場合、再利用するとかえってAPIが悪化する場合、またはパターンが不安定で中央管理に向かない場合は、extractは避けたほうがよいです。抽出には保守コストが伴うため、再利用の価値が長続きする場面で最も有効です。

extractはコンポーネント専用？

いいえ。元のガイドには、コンポーネントだけでなくデザイントークンや再利用パターンも明示的に含まれています。そのため、JSXの重複だけを見るプロンプトよりも、Design Systems向けのextractのほうが実用的です。

extractスキルを改善する方法

extractにより強いアーキテクチャ文脈を渡す

extractの出力を最も手早く改善する方法は、次の情報を与えることです。

• コンポーネントライブラリのパス
• token/themeのパス
• フレームワークとスタイリング構成
• 維持したい命名規則
• 移行上の制約

この文脈がなくても、スキルは重複の検出自体はできます。ただし、結果を既存システムへ無理なく配置するところまではうまくいきません。

実装の前に、発見フェーズを要求する

より質の高い出力がほしいなら、モデルに対してextractを2段階で使うよう指示してください。

1. 発見と提案
2. 承認後に実装

これにより、最大の失敗パターンである「間違った抽象化へ早すぎる段階で抽出してしまうこと」を減らせます。

再利用の閾値を明示する

extractの改善策として特に有効なのが、次のようなルールを足すことです。

• “Only extract patterns used in 3 or more places”
• “Only create tokens for values repeated across features”
• “Do not centralize one-off layout wrappers”

こうした条件を入れることで、extractをDRY原則だけでなく、保守性の観点にも揃えやすくなります。

コンポーネント抽出とトークン抽出を分ける

この2つは関係していますが、同じ作業ではありません。散らかったコードベースでextractに両方を一度に求めると、結果が混線しやすくなります。次のように分けたほうが、より良いプロンプトになります。

• まず共有コンポーネント候補を特定する
• 次にトークン候補を特定する
• その後で移行計画を立てる

そのほうが、出力は整理されやすく、不要な手戻りも減ります。

過度に一般化されたAPIに注意する

extract運用でよくある失敗は、いくつかの「ほぼ似ている」実装を無理に統合しようとして、propsが多すぎる共有コンポーネントを作ってしまうことです。提案されたAPIが重複コードそのものより複雑に見えるなら、スコープを狭めるか、バリアントを分けて維持するようスキルに求めるべきです。

初回出力のあとに移行品質を高める

最初の出力のあとには、次のような追加質問をすると効果的です。

• “Which consumers should migrate first?”
• “What breaks if we replace the old implementations?”
• “Which props or styles should stay local?”
• “Can you propose a compatibility layer?”

この段階になると、extractは単なるパターン検出を超えて、導入リスクのコントロールにも役立ちます。

extractは具体的な対象フォルダと一緒に使う

「アプリ全体を見て」ではなく、次のように指定してください。

• “Use extract on src/features/checkout against src/components”
• “Review apps/web/src/account for token extraction into packages/ui/tokens”

スコープを具体化すると、分析の精度が上がり、コストも抑えやすくなり、extractの計画もそのまま実行に移しやすくなります。

その抽出が本当に有効かを検証する

どんなextractワークフローでも、最も有効な改善は、提案された各抽象化に根拠を求めることです。

• どの重複を解消するのか
• どれくらいの頻度で現れるのか
• 共有APIがなぜ安定しているのか
• ローカル実装のままだと何が悪いのか

このひと手間だけで、気の利いたように見えて価値の薄い抽出をかなりふるい落とせます。