Lovable で反復する指示を再利用可能なスキルに変換する方法（14 分読了）

AI エージェントの現状について一言。彼らは一般化された存在です。Lovable を開くたびに、あなたがどのように作業を好むかを覚えていません。あなたの慣習やスタイル、あるいは十回以上説明してきた物事の伝え方などはすべて消えてしまいます。そのため、あなたはまた同じことを説明します。そしてまた繰り返すのです。これは積み重なると大きな摩擦となる小さな問題の一つです。 ## スキルとは何か 昨年末、Anthropic は「スキル」と呼ばれる形式を導入し、それは急速に広まりました。Lovable や OpenAI など多くの企業が数ヶ月のうちにこれを取り入れました。その考え方はシンプルです。一度作成した再利用可能な指示や文脈を、関連する際に AI が使用することで、自分が繰り返し説明する必要がなくなります。それだけです。これが全体像です。背景にはより微妙なニュアンスがあり、後ほど詳しく触れますが、核心を言えば、スキルとは「あなたが物事をどのように処理してほしいか」についての AI へのメモに過ぎません。 さらに進む前に、一つ言っておくことがあります。Lovable にはすでに永続的な文脈を提供するツールとして、「ワークスペースとプロジェクトの知識」という機能があります。これは、コーディング規約やブランドの声、あるいは製品が実際に何をするかなど、あなたが構築するすべてのものに適用されるルールや事実を記述するためのテキストフィールドです。知識は常に有効ですが、スキルは異なります。特定の種類のタスクが発生した時のみ表示されます。これら二つがどのようにペアとして機能するかについては、後ほど詳しく説明します。 さて、形式についてです。スキルは単なる Markdown ファイルです。Markdown を触ったことがない方でもご安心ください。これはフォーマット用のいくつかの簡単な記号を含むプレーンテキストであり、あらゆるテキストエディタで開くことができます。ただし、なぜ Markdown が選ばれたのかには明確な理由があります。なぜ AI アプリ内の設定パネルではないのでしょうか？なぜ AI のメモリに記憶させるだけではないのでしょうか？その理由は三つあります。スキルは「ポータブル（携帯可能）」「可読性がある」「編集可能」です。ポータブルなのは、単なるファイルだからで、ツール間を自由に持ち運べます（Lovable、Anthropic、OpenAI など、多くのプラットフォームが対応しています）。可読性があるのは、人間であるあなたが実際にファイルを開いて中身を確認できるからです。これは一見すると大したことないように思えるかもしれませんが、非常に重要です。これが、誤動作するスキルを修正したり、チームメイトと共有したり、AI に何を与えられているかを監査したりする方法だからです。編集可能なのは、一度更新すればその変更が以降のすべての処理に適用されるからです。Markdown を恐れる必要はありません。ただのテキストです。 スキルは個人用也可以是共有用にもできます。一人での開発者なら、それはあなたのプライベートなツールキットになります。チームで作業する場合は、全員が同じワークフローに収束するための手段となります。例えば、共通のリリースチェックリストや、特定のタスクを処理する統一された方法などです。誰かが記憶したり、再度説明する必要はありません。ここでスキルはナレッジ（知識）と非常に相性が良くなります。ナレッジは、全員が共有する常時有効なルールを保持します。一方、スキルは、誰でもアクセスできるタスク固有のプレイブックを保持します。よく書かれたスキルとは、新しいチームメンバーが初日にすぐに手に取って使えるようなものです。 用語の整理を簡単に。これらの概念はすぐに混同しがちです。プロンプト（Prompting）とは、今すぐ欲しいものを作るためにその瞬間に Lovable に対して伝えることです。知識（Knowledge）とは、背景で常に把握しておくべき情報、つまりあなたの規約や製品の詳細のことです。スキル（Skills）とは、頻繁に現れるワークフローで、特定のタスクが発生した際にすぐに実行できる状態のものです。これら三つは連携して機能します。こう考えてみてください：プロンプトが「今」、知識が「不変値」、スキルが「プレイブック」です。 ## 1 つの中に何が含まれているか スキルとはフォルダのことです。そのフォルダの中には、メインファイルである SKILL.md と、追加したいサポートファイルが含まれます。メインファイルこそが実際にスキルが存在する場所です。サポートファイルは、メインファイルを煩雑にしたくない詳細情報を記述するために使われます。これらについては後ほど詳しく説明します。 ## 構造の視覚的な例： ![image](https://storage.googleapis.com/lovable-assets/blog-posts/skill-file-example.png) メインファイルには三つの要素があります。名前、説明、そして指示そのものです。それぞれを見ていきましょう。 名前は、スキルを手動で呼び出したいときに「/」の後にタイプする言葉であり、ワークスペース UI 上に表示される名称でもあります。短く、すべて小文字にし、ハイフンで繋いでください。「Our Beautiful Design System for the Marketing Team」ではなく、「design-system」とします。これはあなたがタイプするものです。 説明は、聞こえる以上に重要です。ついてきてください。 Lovable がスキルを使用するかどうかを判断する際、それは説明のみを確認します。指示やサポートファイルは一切見ません。説明だけです。指示は、スキルが選択された後に読み込まれます。つまり、美しく書かれていても説明が弱いスキルは、存在しないのと同じです。なぜなら Lovable はそれには到達できないからです。説明こそが、スキル内の他のすべての要素に意味を持たせるものです。これについては後で戻ります。 指示とは、新しいチームメイトがこのタスクをあなたのために実行する場合に何を伝えるかを記述する場所です。何をするべきか、何をしてはいけないか、エッジケース、経験則、あるいはその他すべてを記します。どのような形式でも構いません。箇条書き、文章、ステップバイステップなど、情報を明確に整理できるものであれば何でも可能です。必須の構造はありません。 長さに関する簡単な経験則として、メインの SKILL.md ファイルが 1〜2 ページを超えそうになったら、その一部をサポートファイルへ移動させる合図です。メインファイルには形状（何をするべきか、何を避けるべきか、カテゴリ）を保持させます。サポートファイルには詳細を記述します。 ファイルのサポートに関する重要な点があります。スキルが発火するたびにファイルが読み込まれるわけではありません。メインの SKILL.md ファイルが特定のファイルを指し、Lovable がその詳細を本当に必要と判断した場合にのみ読み込まれます。そのため、後ほどご覧いただく例には「[View palette](https://lovable.dev/blog/colors.md)」のような行が含まれています。これらの Markdown リンクは、メインファイルが Lovable に対して「完全なパレットはこちらにあります、必要であれば取得してください」と伝える手段です。これにより、スキルは長く詳細であってもコスト高になることなく機能します。メインファイルは短く高速に保たれ、深い内容は必要な時だけ読み込まれます。 ここでよくある誤解があります。スキル単体では何も実行しません。スクリプトでもボットでもなく、サイトをスキャンしたりチェックを実行するものでもありません。あくまで Lovable が読んで従うための指示です。実際の作業はすべて Lovable が行います。スキルはその作業へのアプローチ方法を形作るだけです。ソフトウェアをインストールするようなものではなく、作業を開始する前にチームメンバーに 1 ページのガイドを手渡すようなものと捉えてください。 ## スキルの動作について スキルの中身がわかったところで、ワークスペース内で実際にどのように振る舞うかについて、理解しておくべきいくつかのポイントをご紹介します。 まず、スキルはオンデマンドです。Lovable はすべてのスキルを事前に読み込むのではなく、説明に基づいて関連するときにのみ読み込みます。つまり、ワークスペースに 10 個、20 個、30 個のスキルがあっても互いに競合することはありません。各スキルの説明が強力であれば、Lovable が適切なものを選択します。（これが説明がこれほど重要になる理由です。今ではその理由がお分かりいただけたでしょう。） 次に、同じタスクに対して複数のスキルが発火することがあります。Lovable にマーケティングページの構築を依頼し、「design-system」スキルと「landing-page-copy」スキルの両方を持っている場合、両方が読み込まれます。一方はページの見た目を形作り、他方はコンテンツの内容を形作ります。これらが組み合わさることで、それぞれ単独では不可能なものが生み出されます。これが、スキルを最大限に活用する人々が、一つの大規模で何でもこなすスキルではなく、数個の焦点を絞ったスキルを構築する傾向がある理由です。焦点を絞ったスキルはきれいに積み重なり、大規模なスキルは互いを押し出してしまいます。 第三に、スキルを手動で実行することもできます。プロンプト内で「/」の後にスキルの名前を入力するだけです。Lovable は他の処理を行う前にそのスキルを優先して使用します。これは、どのスキルを使用するか明確に分かっており、説明によるマッチングに任せたくない場合に役立ちます。ただし一つ知っておいてほしいことがあります。スキルを強制実行すると、それが適切なタスクかどうかに関わらず実行されてしまいます。もし強制したスキルの出力が違和感がある場合、その原因は通常、そのスキルがあなたが求めた作業のために本当に作られていなかったことにあります。自信がない場合は、説明によるマッチングに任せる方が安全なデフォルト設定と言えます。 ![image](https://storage.googleapis.com/lovable-assets/blog-posts/skill-files-explainer.png) ## 実際の運用ではどう見えるか では、実際のスキルはどのようなものなのでしょうか？Lovable ユーザーが実際に構築しそうな例を三つ挙げ、その後に説明と指示のどちらが効果的に機能するかを並べて比較します。 これらを読む前に一言：各ファイルの上部にある名前と説明を囲む「---」という行は、「フロントマター」と呼ばれます。装飾的なものではありません。これはシステムに対して「これらのダッシュの間には構造化されたメタデータが含まれている」と指示するものです。メタデータとは、単に「データに関するデータ」を指すややこしい用語です。これらを削除するとスキルが機能しなくなります。残しておけば、わざわざ意識する必要もありません。 ## design-system フォルダ構成: design-system/ ├── SKILL.md ├── components-reference.md └── colors.md SKILL.md: --- name: Design System description: サイト上のあらゆるページ、セクション、またはコンポーネントを構築・変更する際に使用してください。サイトが異なるアイデアの寄せ集めではなく、一つの製品として統一された印象を持たせるためのビジュアルルールを適用します。コピーライティングやページに含めるコンテンツの選定には使用しません。 --- # デザインシステム このサイトのすべてのページは、同じ製品の一部分であるべきです。構築、リスタイル、再配置を行うあらゆるものにこれらのルールを適用してください。 ## 色 (Colors) colors.md に記載されているブランドパレットの色のみを使用してください。デフォルトの AI 由来の青、緑、グレーに頼ってはいけません。パレットに含まれていない色がある場合は、追加しないでください。 [パレットを表示](./colors.md) ## スペース (Spacing) - スペースは余裕を持って一貫性を持たせてください。迷ったときは、少ないスペースではなく、より多くのスペースを使用してください。 - 同じ種類の要素には、毎回同じだけの余白（呼吸する空間）を確保してください。あるページでボタンが見出しの下に適切なギャップで配置されている場合、他のすべてのページでも同じギャップを維持してください。 ## タイポグラフィ (Typography) - 見出しフォントは 1 つ、本文フォントは 1 つのみ使用してください。3 つ目を導入してはいけません。 - 単一のページで見出しサイズは最大 2 つまでとします。 - 本文テキストは、スマホでズームインすることなく読みやすいものであるべきです。 ## コンポーネント (Components) - ボタン、カード、フォームがすでにサイトに存在する場合は、それを再利用してください。既に存在するものの別バージョンを新たに発明しないでください。 - 新しいコンポーネントは、既存のものと同じファミリーに属しているように見える必要があります：角の形状、シャドウの重さ、ホバー時の挙動はすべて同じにしてください。 [既存のコンポーネントを表示](./components-reference.md) ## 避けるべきこと - 同じページ内で角丸と鋭い角を混ぜないこと - 重すぎたり浮いて見えたりするドロップシャドウは避け、控えめなものに留めること - 1 つのセクション内で注意を奪い合うアクセントカラーが複数ある状態にしないこと ## フレッシュアイズレビュー フォルダ: fresh-eyes-review/ ├── SKILL.md ├── feedback-examples.md └── common-traps.md SKILL.md --- name: Fresh Eyes Review description: ユーザーが、Lovable が初めて訪れた見知らぬ人であるかのように、サイトに対する正直なフィードバックを求めている場合に使用します。「同意するアシスタント」モードから抜け出し、「他のタブを開いたままの懐疑的な訪問者」として振る舞います。完成したコピーの推敲や特定のバグ修正のためではなく、実際の初回訪問者が何に気づくかをユーザーに伝えるためのものです。 --- # フレッシュアイズレビュー あなたはもはやこのサイトを構築するのを手伝った AI ではありません。友人からテキストメッセージで送られたリンクからたどり着いた見知らぬ人です。他のタブも開いています。もし注意を引く価値がなければ、7 秒以内にこのページを閉じてしまいます。 その視点からサイトを見直してください。不快な場合でも、真実を伝えてください。 ## 何に注目すべきか 1. **5 秒テスト**。ページに到着してから 5 秒以内に、これが何者なのか、誰向けなのか、なぜ自分が関心を持つべきなのかを説明できますか？もしできないなら、それが見出しの課題です。他のことを言う前に、まずそれを指摘してください。 2. **「えっ？」と感じる瞬間**。普通の人が立ち止まり、目を細めたり、読み直すためにスクロール戻りしたりする箇所はどこですか。セクションごとに名前を付けてください。 3. **信頼性のギャップ**。サイトが未完成の途中経過やサイドプロジェクトのように感じさせる要素：プレースホルダーテキスト、壊れた画像、奇妙な余白、自己矛盾するコピー、どこにも繋がらないリンクなどです。 4. **退屈な中間部分**。ほとんどのサイトには、注目が失われる中間の区間があります。ここではどこで注目が失われますか？具体的に記述してください。 5. **「それで？」と感じるセクション**。読んでいて何も感じなかった箇所はどこですか。削除するか、そのスペースに値する内容にするかのどちらかです。 ## フィードバックの与え方 - 実際に機能している部分から始めましょう。1〜2 文で。飾り立てないこと。 - 次に、深刻度順に並べた実際の課題を提示します。最もダメージが大きいものから。 - 一般論より具体性を優先。「ヒーローセクションの『モダンなチーム向けのモダンなソリューション』という文言は、あなたが何をしているのか伝わらない」という指摘の方が、「ヒーローセクションが曖昧だ」よりも優れています。 - 遠回しな表現は避けてください。「〜を検討するかもしれません」といった言い方は不要です。何か問題があるなら、はっきりと言葉にしてください。 - トーンについては feedback-examples.md を参照してください。直接的で具体的、かつ親切だが容赦ないトーンです。 [フィードバック例を見る](./feedback-examples.md) ## 避けるべきこと - どのサイトにも当てはまるような汎用的なフィードバック（「もっと魅力的にしてください」「ビジュアルをもっと追加してください」など） - 他の部分を和らげるために、評価すべきでないものを褒めること - ユーザーが求める前に修正を提案すること。まずは診断し、必要であればユーザーの希望に応じて支援を提供する - common-traps.md に記載されている一般的な罠（各サイトで見落としがちで頻繁に発生する問題） [一般的な罠を見る](./common-traps.md) ## landing-page-copy フォルダ: landing-page-copy/ ├── SKILL.md ├── voice-examples.md └── cta-library.md SKILL.md: --- name: Landing Page Copy description: ランディングページ、ヒーローセクション、またはマーケティングページの文章を作成・書き直す際に使用します。ブランドのトーンと、訪問者を実際にコンバージョンに導く構造を強制します。ブログ記事、ヘルプドキュメント、アプリ内部のテキストには適用しません。 --- # ランディングページのコピー 以下のトーンと構造に従ってランディングページの文章を作成してください。目的は、訪問者がページに着いてから 5 秒以内に「これが何で」「なぜ自分が関心を持つべきか」を理解することです。 ## トーン - 読者について語るのではなく、読者に語りかけます。「ユーザー」や「顧客」という言葉ではなく、「あなた」という人称を使用してください。 - 平易な単語のみを使用します。禁止用語：シナジー、レバレッジ、アンロック、エンパワーメント、リボリューションライズ、シームレス、ロバスト、ワールドクラス。 - 短い文を心がけてください。20 語を超える文がある場合は、必ず 2 つに分割してください。 - 私たちが目指すトーンについては voice-examples.md を参照してください。そこには、私たちが目指すべきトーンの例が 3 つと、避けるべきトーンの例も 3 つ記載されています。 [トーンの例を見る](./voice-examples.md) ## Structure すべてのページはこの順序に従う。例外はない。 1. **ヒーローセクション**。12 語以内の具体的な約束を提示する。製品が何であるかではなく、読者が得られるものを伝えること。 2. **3 つのベネフィットブロック**。それぞれは読者にとっての結果から始める。機能の羅列は避けること。 3. **証明**。実際の引用や数値を示す。もしそれらがない場合はこのセクションを省略する。決して捏造してはならない。 4. **1 つのアクション呼び出し（CTA）**。上部と下部で同じ言葉を使用する。3 つの競合するアクションではなく、単一の行動に集中させること。 [CTA の一覧を見る](./cta-library.md) ## Avoid - ヒーローセクションでの機能リスト — これらはさらに下段に配置すべきである - 「最高」「首位」「No.1」といった表現。これらは主張でありベネフィットではない。実際の成果名を代わりに使用すること。 - 3 文を超える段落 - 同じページ上で注目を争う 2 つの CTA これら 3 つは思考を刺激するためのものだ。ポイントは、スキルとは何でもあり得るということだ。Lovable に毎回同じワークフローを繰り返し説明しているなら、それはすぐにでもスキル化できる待機中の機会である。最後に繰り返したことは何だったか？さあ、スキルを作ろう！ ## Good vs. bad さて、機能するスキルと機能しないスキルを分けるいくつかの例を見ていこう。 ## Description Example 1 ## Bad: *description: オンボーディングをサポートします。* 失敗する理由：「Helps with（〜を支援する）」はトリガーではなく、曖昧な表現です。Lovable はいつこのスキルを発火させるべきか分かりません。「onboarding（オンボーディング）」という言葉一つだけで、フローの設計、ウェルカムメールの作成、サインアップの不具合修正、ダッシュボードへのツールチップ追加など、五十通りの意味が含まれる可能性があります。そのため、このスキルは実行すべき時にスキップされるか、新規ユーザーに関する言及があるあらゆる場面で呼び出されてしまい、本来発火すべき他のスキルを埋もれさせてしまいます。 ## 良い例： *説明：初回ユーザー体験の設計や改善時（サインアップフロー、ウェルカム画面、空の状態表示、製品内の最初のセッション）に使用してください。まだサインアップしていない人向けマーケティングページには使用しないでください。 なぜこれが機能するか：これは具体的なトリガー（初回体験の設計または改善）、対象となる具体的な領域（サインアップ、ウェルカム、空の状態、最初のセッション）、そして境界線（サインアップ前のマーケティングページは除く）を明確に示しています。最後の部分、つまり Lovable がいつ発火させないかを伝えることが、優れた説明と素晴らしい説明を分ける鍵となります。 ## 説明例 2 ## 悪い例： *説明：デザイン、UI、スタイリング、コンポーネント、色、レイアウト、間隔、タイポグラフィ、ボタン、フォーム、ナビゲーション、ページ、画面、およびウェブサイトの視覚的またはフロントエンド関連のあらゆるもののために使用してください。 なぜこれが失敗するか：「何でも詰め込んだ（kitchen-sink）」説明はすべてにマッチするため、実質的に有用な何にもマッチしません。このスキルはすべてのフロントエンドタスクで発火し、本来実行されるべきより具体的なスキルを埋もれさせてしまいます。 ## 良い例： *description: UI コンポーネントやページを構築、スタイリング、または修正する際に使用します。プロジェクトのビジュアル規約（色、間隔、タイポグラフィ、コンポーネントパターン）を強制します。コンテンツやコピーに関する意思決定には使用しません。 なぜ機能するか：トリガーが明確なアクション（UI の構築、スタイリング、修正）にスコープされ、スキルが実際に何をするか（規約を強制する）を明記し、境界線（コンテンツには適用しない）を引いています。信頼性高く発火するのに十分具体的でありながら、他のスキルを圧迫しないほど狭い範囲です。 ## 指示の例 ## 悪い例： ブランドチェック：サイトのブランド一貫性を確認してください。すべてがブランドに合っており、ベストプラクティスに従っていることを確認してください。おかしいと思われるものはすべてフラグを立ててください。ブランドはプロフェッショナルで統一された印象を保ってください。 なぜ失敗するか：すべての単語が汎用的です。「ブランドに合っている」「ベストプラクティス」「プロフェッショナル」「一貫性のある」といった表現は、Lovable がデフォルトですでに行うべきことを何も伝えていません。従うべきルールも、一致させるべき詳細も、尊重すべき境界線もありません。このスキルは情報をゼロしか追加しません。 ## 良い例： 以下のブランド規則に対してサイトを監査してください。違反があるたびに、それが現れるページとセクションを特定し、どの規則に違反しているかを明記してください。 ## 色 - 鮮やかな青はボタンとリンク専用です。背景や本文には決して使用しないでください。 - ブランドパレットの 4 つのニュートラルカラーのみを使用し、それ以外を使わないでください。他のグレーが紛れ込まないようにしてください。 - 純粋な黒も純粋な白もどこにも使用しないでください。パレットに対して強すぎます。 - 赤はエラーと警告専用です。アクセントやハイライトとして決して使用しないでください。 ## タイポグラフィ - ヘディング用フォントは 1 つ、本文用フォントは 1 つ。3 つ目のフォントが現れた場合は違反です。 - 1 ページあたりのヘディングサイズは最大 2 つまで。 - ヘディングは文頭大文字（センテンスケース）で記述します。タイトルケースやすべて大文字は避けてください。 ## ボイス - 読者について語るのではなく、読者に語りかけます。「ユーザー」や「顧客」と言う代わりに、「あなた」と呼びかけてください。 - 禁止用語：シナジー（synergy）、レバレッジ（leverage）、アンロック（unlock）、エンパワー（empower）、シームレス（seamless）、ロバスト（robust）、ワールドクラス（world-class）。 - エラーメッセージと確認メッセージ以外では感嘆符を使用しないでください。 ## 避けるべきこと - ポップアップやモーダルを除くすべての要素にドロップシャドウを適用しないこと。 - ヒーローセクション以外でグラデーションを使用しないこと。 - オフィスでラップトップを指差している人々のストックフォトの使用は避けてください。 これが機能する理由はいくつかあります。具体的なルールに従う必要があります。「1 ページあたりのヘディングサイズは最大 2 つまで」「純粋な黒や純粋な白は使用しないこと」「ヘディング用フォントと本文用フォントはそれぞれ 1 つずつ」といったルールです。これらはサイトを確認するだけで実際に検証可能なものです。禁止用語や禁止色は明示的に名前を挙げて指定しています。なぜなら、AI に「何をしてはいけないか」を伝える方が、「何をすべきか」を伝えるよりも有用な場合が多いからです。カテゴリは暗黙の了解ではなく明記されており、Lovable が「ブランドイメージに合致する」という意味を推測する必要はありません。すでに指示されています。「Avoid（避けるべきこと）」セクションも設けられています。なぜなら、ネガティブスペース（何もしない領域）もポジティブな指示と同じくらい重要だからです。優れた指示には両方が含まれています。 ## 正直な注意点 さて、午後だけで 20 のスキルを作成しようとする前に、知っておくべきいくつかの正直な事実があります。スキルは素晴らしいものですが、魔法のようなものではなく、いくつかの点で失敗する可能性があります。 これが最大のポイントです。スキルは、その中身次第で良し悪しが決まります。質の低いスキルは何もせず放置しているだけでなく、Lovable のパフォーマンスを低下させます。なぜなら、そこに曖昧で役に立たない指示が混入してしまうからです。ゴミを入れればゴミが出るのです。スキルを一度で完璧に仕上げることはできませんが、それは問題ありません。重要なのは、実際に使ってみてその様子を確認し、調整することです。Lovable が曖昧な返答をする場合は指示を厳密にし、不要な時に発動する場合は説明を明確にします。場合によっては両方とも行う必要があります。 次に重要な点です。スキルはプロンプトの代わりにはなりません。プロンプトを補強するものですが、置き換えるものではありません。「ランディングページ」だけを Lovable に指示し、他の文脈がない場合、どんなに優れたランディングページ用スキルがあっても、どの製品、どのターゲット層、どの目標に向けたものかを読み取ることはできません。依然として、プロンプトが主役です。 いくつかの小さなポイントも、早口で説明します。スキルは単発タスクには役立ちません（これは単なるオーバーヘッドです）。重複するスキルが多すぎるとそれ自体が問題になります（数は少なく、鋭いものが勝ります）。スキルはモデルの限界を解決しません（Lovable がスキルなしではできないことを、スキルを追加しても突然可能になるわけではありません）。そして、メンテナンスが必要です。状況は変化し、3 ヶ月前には正しかったスキルも、静かに陳腐化してしまうことがあります。 更新に関する小さな注意点です。スキルを変更した場合、新しいバージョンは今後のチャットにのみ適用されます。会話中に何かを修正して、Lovable が即座に従ってくれると期待しても、それは起こりません。新しいチャットを開始してください。 そしてもう一つ、重複に関する話です。時として2つのスキルが矛盾することがあります。一方は角丸を主張し、他方は鋭い角を主張するといった具合です。そのような場合の解決策は、通常、ルールをさらに積み重ねることではありません。むしろ、両方のスキルが最初から同じタスクで発火しないように、記述内容をより厳密にすることです。競合はほとんど常にスコープの問題です。 これらはスキルを使わないよう説得するための話ではありません。スキルは本当に有用であり、一度2つや3つの良いスキルを構築すれば、もう元には戻れません。これは、決して役に立たないスキルに午後の時間を費やす前に知っておくべき事項に過ぎません。 ## 始め方 始めるのは簡単です。ワークスペース設定へ移動してください。管理者とオーナーはここで、チーム全体のメンバーが使用できるスキルを作成・編集・管理できます。個人用ワークスペースの場合、それはあなた自身のみを指します。あなたは好きなようにスキルを作成し、使用する完全な権限を持っています。スキルは数種類の異なる方法で立ち上げることができます：設定内で直接追加する、既存のスキルをアップロードする、またはメインチャットでLovableに「これをスキルとして保存して」と頼むことです。そうすれば、LovableがSKILL.mdファイルを生成してくれます。手始めに、ゼロから新しいスキルを構築する手順を案内してくれる組み込みの/skill-creatorスキルを試してみてください。また、このアップデートではすぐに試せるよう、いくつかの事前構築済みスキルも提供しています。例えば/redesign、/accessibility、/SEO-review、/movie-creatorなどです。これらを使うことで、自分自身でスキルを構築する前に、実際にスキルが動く様子を確認できます。一度スキルがワークスペースに追加されれば、チーム内の誰でもそれを利用できるようになります。 スキルは本日、Lovable で利用可能になりました。今週中に一つ作ってみましょう！初めて Lovable が、あなたが何を望んでいたかを言うまでもなく、どのようにして欲しいかを知り、すべてがすっきりと理解できる瞬間が訪れます。あなたの作り方がどう変化していくかを楽しんでご覧ください！

Lovable で反復する指示を再利用可能なスキルに変換する方法（14 分読了）

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト