[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CSQAK03XCB6SERHJ9V4NJD":3,"skill-same:01M6CSQAK03XCB6SERHJ9V4NJD":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":36,"commitSha":37,"skillDirectory":38,"forksCount":39,"repositoryHtmlUrl":40,"repositoryHomepageUrl":6,"ownerHtmlUrl":41,"ownerBlogUrl":6,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M6CSQAK03XCB6SERHJ9V4NJD","bad-name",null,"Use this skill when testing invalid skill directory names.","bitflight-devops\u002Fskilllint","bitflight-devops","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F83852040?v=4","01M6CSPE9HM6TQTDJPPR9ZGV3T","BitFlight DevOps - Jamie Nelson","01M6CSPEDJ8KR2QNV9RZX8R8RE",7,"MIT","https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Ffailing-examples\u002FSK008\u002Finvalid-directory-name\u002Fskills\u002Fbad_name\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27],"bad name","bad","name","testing","directory","use","invalid skill","invalid","when","2026-11-10 10:12:30",false,"---\nname: japanese-tech-writing\ndescription: 日本語の技術文書・書籍原稿の文章規範。段落と論証の構成（パラグラフライティング）、論証の厳密さ（ツッコミどころの除去）、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、翻訳調の比喩と擬人化の禁止（「運ぶ」「効く」「開かれた問い」など）、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、または推敲・リライトするときに使用する。\nlicense: Unlicense（https:\u002F\u002Fgist.github.com\u002Fk16shikano\u002F67625f2a7d96e3bbdfae8d571a936063）\n---\n\n# 日本語技術文書の文章規範\n\n日本語で技術的な原稿（書籍の章、記事、解説文）を書く・推敲するときは、以下の規範に従う。\n\n## 段落と論証の構成\n\nパラグラフライティングを基本とする。段落は論証の一歩であり、読者は段落単位で論理を追えなければならない。\n\n- 一つの段落には一つのトピックだけを置く。場面の進行（調査、報告、検証、評価）が複数混ざった長い段落は、一歩ずつの段落に分割する。\n- 段落の最初の文を読めば、その段落が何の話かわかるようにする。\n- 段落の先頭では、前の段落との論理関係を接続表現で明示する（「であれば」「実際」「しかし」「この例自体からも」）。\n- 論証は一方向に進める。結論を出してから反論を処理し、結論を言い直す構成にしない。反論と疑念の処理を終えてから、結論を一度だけ置く。\n- 例への弁明（作為的に見える、への先回りなど）は、場面の山場の直後に挟んで流れを切らない。次の節の冒頭でまとめて処理する。\n- 読者が立てそうな誤った解釈は、明示的に否定してから本当の理由を述べる（「その理由は『〜だから』ではない。〜だからだ」）。\n- 「AではなくB」と否定するときは、否定の根拠を一文添える。反実仮想（「もしAなら、〜だっただろう」）が使えることが多い。\n- 同じ概念を二つの対象で対比定義するときは、両文の述部を同じ型にする。既出の説明の回収は文頭の枠に置き、定義そのものを「〜だと説明した」に埋め込まない。特徴の句は「」で切り出し、対比の接続を明示する。第二極について続ける属性は、主語を改めて名乗らず継承する。\n- 譲歩（「確かに〜」）では、事実の確認にとどめる。あとで訂正する内容を著者の声で因果として断定すると、自己矛盾になる。表面的な診断を一度認めたいときは、読者や通説の声に帰属させる（「〜と要約できてしまうかもしれない」）。\n- 山場で効かせたい情報（数値、固有の事実）は、その手前の段落で先出ししない。\n- 何かを否定・限定するときは、否定する命題そのものを「」で正確に書き出す（「明文化されていればすべてを任せられる」を意味しない、など）。「何もかもが解決するわけではない」のような漠然とした否定で済ませない。\n- 「後の章で扱う」のような前方参照は、論証が一段落した位置（段落末・節末）に置く。論証の途中に挟んで流れを切らない。\n\n## 論証の厳密さ\n\n文章の論理にツッコミどころを残さない。書き上げたら、読み手の反論を先回りして次の点を点検する。\n\n- 推量・可能性・読者の疑念・反実仮想として書かれている文を、機械的に断定へ変えない。\n  「かもしれない」「だろう」「ようだ」「らしい」は、根拠なく主張を弱めている場合だけ削る。\n  事実未確認の可能性、作中人物の認識、ログからの推定、読者が抱きそうな疑念、反実仮想を表す場合は、その不確実性を保つ。\n  断定に直せるのは、本文内の根拠によって命題が確定している場合に限る。\n  悪い例：「提示し続けているかもしれない」を「提示し続けている」に変える。\n  良い例：「提示し続けている可能性がある」のように、不確実性を残して文を整える。\n- 異なるものを「同じ」とまとめない。区別すべき対象（別々の決定、別々の原因、種類の違う問題）を一括りの言葉でくくらない。悪い例：相互依存する三つの未決事項を「同じ決定を別々に下していた」と書く。良い例：「どれも別々の決定であり、しかも互いに依存している」と腑分けする。\n- 複数の要因がある事象を、単一の原因に還元しない。例が複数種類の問題を含むなら、それぞれを切り分け、どの道具がどれを説明するのかを対応づける。悪い例：契約の不在と情報隠蔽の失敗が混ざった事故を、丸ごと「情報隠蔽の問題」と説明する。\n- 章・節をまたいで、同じ概念の扱いを一致させる。ある節で「人間が決める」と分類したものを、別の節で「チームで合意する」と書かない。分類・定義・用語の地位は全体で揃える。\n- 因果を主張するときは、その機構（なぜそうなるのか）を一文で示す。「AだとBになる」とだけ書いて理由を省略しない。悪い例：「手順で分けると変更が全体に波及する」。良い例：「各工程がデータを受け渡すための表現を共有してしまい、その表現を変えると全体に波及する」。\n- 検出・保証・解決を「必ず」できるかのように書かない。条件付きで正確に述べる（「〜しやすい」「〜できることが多い」「〜が成り立つときに限り」）。\n- 主張は、挙げた例が実際にその全体を支えているかを確認する。例が主張の一部しか支えないなら、主張の範囲を例に合わせて狭める。\n- 「次節で扱う」と前方に逃がした論点は、本当にそこで回収されることを確認する。回収しない伏線を張らない。\n- 譲歩や限定（「ただし」「とはいえ」）を置いたら、その後で必ず論を進める。逆接で終えて宙吊りにしない。\n- 節の中心となる語は、その節以前に定義・対象範囲を述べてから使う。定義せず使い始めない。\n- 複数の概念を一つの上位語にまとめるときは、命名の直前に、それらが同じものに帰着すると\n  一文で述べる。腑分けの逆の操作にも橋を架ける。\n\n## 読み手の負荷の管理\n\n読者の記憶と注意は有限の資源として扱う。\n\n- 読者が順読みで保持する情報は、一度に一段だけ増やす。箇所を削ったら残った言及を辿り、この文書のほかで使われなくなった主題は落とす。直前までの文の上に一段で足りる許可や読み方は直接書く。\n- 後で参照する必要のない固有名（ファイル名、関数名、識別子）を出さない。「仕様書」「金額計算のユーティリティ」のような一般的な言い方で済ませる。\n- 抽象的な言い回しの指す内容が文脈から一意に決まらないときは、可能なときは丸括弧による同格挿入でその場で特定し、できるだけ読者に前を読み返させない。\n- 概念を初めて示す文では、読者が順に読んだだけで、まずその概念が何であるか（データ構造、手順、制約などの種類や地位）を読み取れる順序にする。その概念を既に知っている読者にだけ自然な性質・仕組み・制約を、種類の同定より前に置かない。前置すると、未習の読者は文を読み終えた時点で逆戻りしなければ核となる情報を見逃すか、理解が滞る。\n- 新しい例や場面を追加して、読者が保持すべき文脈が増えるときは、前の例と何が違うのか、なぜもう一つ必要なのかを前置きして納得感を与える。\n- 同一節内に図、表、コードなど複数の提示があるとき、各媒体が担う説明（配置の見え方、数値、手順など）を分けて書く。媒体間で型やデータを揃える必要はなく、別例として並べてよい。指示語（「この2つ」「上記の例」）は、どの媒体のどの例を指すか文脈だけで一意に決まるように置く。一つの媒体で確認した性質を、別の媒体の例にもそのまま当てはめない。二方式を「Aの代わりにB」と対比するときも、やめる側と採る側の語順を置換関係と一致させ、後に書く側が採用される方式であることを順読みで読み取れるようにする。\n- 章冒頭や節の導入では、これから例で扱う内容に関係しない過剰な詳細を詰め込まない。\n- 例の節の中でも、**その節の問い・帰結に関係しない**過剰な詳細だけを omit する。議論に必要な具体は残す。省略の典型は、エージェント報告の装飾的精度（時刻、HTTP ステータス、カバレッジ率など）や、後で参照しない固有名詞。\n\n## 視点と語り\n\n- 例示では、結果の羅列や受動態（「特定され、判明した」）ではなく、行為者を主語にした動作の連なり（「リポジトリを調査して特定し、見つけてくれた」）で書く。\n- 「入社2年目のエンジニアが」のような架空の人物設定を無意味に冠しない。\n- 論証の中で読者を「あなた」と呼ばず、役割名（「開発者」「読者」）で書く。二人称の呼びかけは、場面への導入（「〜としよう」）や章・本の結びなど、限られた要所にとどめる。\n- 対象を指す語は具体的に選ぶ。「AI」「ツール」のような広い語でぼかさない。\n- 章や節で定式化・術語（K、契約、不変条件など）を導入したら、以後はその語で通す。「文脈」「ツール」「AI」のような曖昧語に後退しない（定式化する前の導入語として「文脈」などを使うのはよい）。\n- 術語・訳語は、その分野で慣用されている語を選ぶ（プッシュ通知は「配送」ではなく「配信」、など）。意味の近い漢語を一般語の感覚で充てない。\n- 人物そのものに言及するときは原綴りで書く（Lehman、Bainbridge）。ただし、歴史上の人物や、人名を冠した概念を定着名で紹介するときは、日本語で通用しているカタカナの通称を使う。\n- 術語の響きを持つ語を、術語でない場面に流用しない（システムから人間までの連なりを「経路」と呼ぶ、など）。「届くまでの流れ」「あいだに何があるか」のように普通の言い方で書く。\n- イ形容詞の終止に「です」を続けた文（「難しいです」「多いです」）を書かない。これは文体の規則ではなく、文の流れの破綻の兆候である。イ形容詞を裸で言い切る必要が生じるのは、その文が前後から孤立しているからであり、流れている文章なら「〜は難しく、…」と文が続くか、「〜でしょう」「〜である」で受けられる。出現したら文末だけ取り繕わず、前後の流れごと書き直す。ナ形容詞の「〜です」（「重要です」）は対象外。\n\n## 演出の抑制\n\n演出の規範は全面禁止ではなく、節度の規範である。修辞は、それが効果を生む箇所でのみ使う。\n\n- 溜め（「ここには〜が潜んでいる」）や修辞疑問で導出を演出するのは、緊張が議論に効く要所に限る。説明で足りる箇所では、そのまま述べる。\n- 短い決め台詞を独立した段落にして緊張を作る演出を多用しない。段落内の短い体言止め（「ここまでわずか数十秒。」など）は、場面の山場に限り使ってよい。\n- 本文中の太字強調を多用しない。誤読を防ぐ否定や節の帰結など、論理の要所に限り、一節に一、二箇所まで使ってよい（導入部でも可）。それ以外は文の順序と構造で際立たせる。\n- 「〜してはならない」という命令調の断定より、「〜するわけにはいかない」のような、作業者の判断として書く形を選ぶ。\n- 転回点を過剰に劇的にしない。事実を述べる一文で足りる場合が多い。議論の山場にかぎり、感嘆符つきの短い一文程度は許容する。\n- 帰結の列挙によって事故や危険を煽らない。\n- 「重要なのは〜である」のような前置きで主張を予告しない。主張をそのまま書く。ただし、主張の様式を宣言する前置き（「標語として言い換えれば」など）は使ってよい。\n- 「AではなくBだった」という対句の決め台詞を多用しない。軽い補足や評価は括弧書きで添えてよい。\n- 慣用表現をひねった言い回し（「知識を体に入れる」など）や、指す内容が一意に決まらない比喩（「報告の外側に世界が広がっている」など）を使わない。平易な動詞でそのまま言う（「身につく」「気付く機会が減る」）。\n\n## LLM っぽい表現の禁止\n\nLLM が大量生成する、中身のない型に誘惑されない。書き上げたら、この節で点検する。\n本書の術語（本質的複雑さ、回収、判断の配置など）を議論に使うのはよい。空虚な装飾として使うのが問題である。\n\n次のような言い回しは、論点を増やさず「ちゃんと書いている感」だけを付ける LLM 口調である。使わない。\n\n- **予告と総括**：「重要なのは〜である」「本章では〜を扱う／探求する」「ここでは〜について見ていく」「まとめると」「要するに」（直前の言い換えだけのとき）、「〜に他ならない」\n- **正面から系**：「正面から扱う」「正面から回収する」「正面から見る／書く／立てる」——中身の代わりに姿勢だけを宣言する\n- **空虚な形容**：「不可欠」「核心的」「鍵となる」「根本的な」（主張の中身を説明せず強調だけする）、「多角的」「包括的」「総合的」（何をどう見たかを書かない）\n- **空虚な動詞**：「掘り下げる」「深掘りする」「言語化する」（何をどう書いたかを示さず終わる）、「触れる」「言及する」（一段落で済ませるだけ）\n- **接続の型**：「〜において」「〜という側面から」「〜の観点から」（新情報なし）、「さらに」「また」「加えて」の連打\n- **弱い緩和と称賛**：「〜と言えるだろう」「〜かもしれない」（根拠なく主張を弱める場合だけ。推量・仮定・読者の疑念・作中人物の認識なら残す）、「非常に」「極めて」「大いに」（中身のない強調）\n\n悪い例：「本章では、〇〇の理論を正面から扱う」「この前提を、ここで正面から回収する」「多角的に分析すると、重要なのは〜である」。\n良い例：「本章では、〇〇の理論を扱う」「ここで、この前提を回収する」「評価の核心は、正しさを誰が知っているかにある」。\n\n## 翻訳調の比喩と擬人化の禁止\n\nLLM は、日本語として存在しない言い回しを、次の三つの経路で生成する。\n前節の空句と違い、書き手（LLM）に比喩や演出の意識がないまま混入するので、比喩を使ったつもりのない文も含めて点検する。\n\n- **英語慣用句の直訳**：英語の技術文では carry \u002F open \u002F expose \u002F live \u002F land などの比喩的用法が慣用句として定着しており、比喩として意識されない。これを日本語の対応語に直訳すると、日本語では慣用化していないため、字義どおりに読める奇妙な生きた比喩になる。\n  - 悪い例：「ベクトルが選好を運ぶ」（carry）。良い例：「選好がベクトルとして表現される」「ベクトルに反映される」。\n  - 悪い例：「この問いは開かれている」（open question）。良い例：「この問いにはまだ答えが出ていない」「未解決である」。\n  - 悪い例：「推敲の軸が露出する」（expose）。良い例：「推敲の軸が線形に取り出せる」。\n  - 悪い例：「この情報は残差ストリームに住んでいる」（live in）。良い例：「残差ストリームに含まれる」。\n- **無生物主語構文の直輸入**：英語では無生物主語の他動詞文が普通だが、そのまま日本語にすると、モデル、データ、ベクトル、損失といった抽象物が意思を持って振る舞う擬人化になる。日本語では、人か処理を主体に戻すか、「〜から分かる」「〜に含まれる」の形に言い直す。\n  - 悪い例：「モデルは文体を知っている」。良い例：「モデルの出力には文体の一貫性がある」など、確認できる事実として書く。\n  - 悪い例：「データが語るのは〜である」。良い例：「データから分かるのは〜である」。\n- **研究者の話し言葉の混入**：機械学習の口頭議論で流通する動詞（「効く」「刺さる」「筋がいい」など）は、話し言葉としては通じるが、書き言葉の技術文書では俗語である。効果や見込みの内容を具体的に書く。\n  - 悪い例：「規範スキルが効く」。良い例：「規範スキルを与えると生成が選好に近づく」。\n  - 悪い例：「この手法は筋がいい」。良い例：「この手法は〜という理由で有望である」。\n\n判定の目安は二段である。\nまず、その述語を初めて見る読者が字義どおりの動作（運ぶ、開く、住む）を想像しうるなら、翻訳調の比喩を疑う。\n次に、動作の主体と対象を具体語で言い直せるか試す。\n言い直せるなら、その言い直しをそのまま書く。\n言い直せないなら、その文は指す内容が特定できていないので、主張として成立していない。削るか、内容を確定させてから書き直す。\n\n## 冗長の排除\n\n無駄な文章をなるべく残さない。\n\n- 同じ主張を言い換えて繰り返さない。一つの主張は一度だけ書く。題材が直前と同じでも、その文が加えている命題が違えば繰り返しではない。列挙の各項が同じ論理的地位であることを示す枠語の反復や、定義の直後に適用条件や限定を足す文も、主張の繰り返しではない。\n- 隣接する節が同じことを別の角度で述べているなら、役割が重複している。片方に吸収して一つの節にまとめる。\n- 場面を描写した直後に、その内容を要約し直さない。意味づけの一文（「このような作業は、ほぼ完全に任せられる」など）だけを置く。\n- 同じ論理的役割を持つ並列の事実は、文を分けて重ねず一文にまとめる。その事実群の論理的地位は文頭の語で示す（「当然、経理部の月次処理も顧客の支払いも〜」）。\n- 冗長さは文字数や文数で判定しない。短文化と一文化は、動機、対象、操作、その同一性、因果、条件が順読みで明示されたまま保てる場合に限る。これらを読者の推論に委ねる圧縮はせず、必要な反復と長さを残す。\n- 接続や評価のためだけの文（「それ自体はよいことである」など）を置かない。\n- 想像上の読者との問答（問いを立てて一語で答える形など）を修辞として使わない。主張はそのまま述べる。読者の反応を演じて応答する形（「〜と感じたかもしれない。そのとおりである」）も同様に避け、譲歩は地の文で簡潔に行う（「もちろん、処置そのものは開発者が決める問題ではない」）。\n- 読者が抱きそうな発想を、メタな枠取り（「ここまでの話には自然な続きがある」「〜という発想である」）で紹介しない。その発想自体を直接書く。読者の疑問なら疑問文のまま書いてよい（「その保守も任せればよいのではないだろうか」）。\n- 「本書もそれを否定しない」のような、著者の立場の弁明や断りを書かない。事実の記述（「〜に書かせる場合が多い」）だけを置く。\n- 文脈を最短で読み手と共有できる文章にする。導出を一歩ずつ展開しなくても伝わるなら、構造に名前を与えて言い切る。\n- 本文でまだ導入していない概念や文書名を、先回りして持ち出さない。\n- ためらいのある弱い述語（「有効な対策であり」など）で済ませない。本文内の根拠で確定していることは強く具体的に言い切る（「活用において必須であり」など）。ただし、不確実性・可能性・仮定・読者の疑念を表すための弱い述語は保持する。語調を整えるための意図的な緩和（「必須だと言ってもいい」など）は許す。\n- 文章のリズムを作るための接続表現（「しかし一方で」など）は、冗長と見なさない。\n\n## 見出しの付け方\n\n見出しは内容を特定できる具体的なものにする。その節が答える問い、または扱う対象を指す句にする。\n\n- 作業の手順だけを述べる見出し（「例に戻す」「〜を読み直す」など）や、情報量のない見出しにしない。その節が答える問い、または扱う対象を見出しにする。\n- 見出しを、節の結論を言い切る「セリフ」にしない。見出しの時点で読者がオチを知る状態を避ける。\n- 節で扱っている対象を指す名詞句でもよい。\n- 見出しが疑問形か断定形かは問わない。問うのは、扱う対象や読者の持つ問いを指しているかである。\n- 疑問形か、対象を指す名詞句かは、本文のトーンに合うほうを選ぶ。\n\n## 読者への誠実さ\n\n- 例が作為的に見えうる場合、それを隠さない。読者の疑念を先回りして認め、現実に十分あり得ることの根拠を短く添える。\n- その根拠は、著者の断定（「十分あり得る状況だ」）ではなく、読者自身の経験に訴える一般的事実や通説に求める（「この症状は珍しくないだろう」「〜という言い方もよく耳にする」）。\n- 確認していないことを、確認したかのように滑らかに書かない。\n","# 日本語技術文書の文章規範\n\n日本語で技術的な原稿（書籍の章、記事、解説文）を書く・推敲するときは、以下の規範に従う。\n\n## 段落と論証の構成\n\nパラグラフライティングを基本とする。段落は論証の一歩であり、読者は段落単位で論理を追えなければならない。\n\n- 一つの段落には一つのトピックだけを置く。場面の進行（調査、報告、検証、評価）が複数混ざった長い段落は、一歩ずつの段落に分割する。\n- 段落の最初の文を読めば、その段落が何の話かわかるようにする。\n- 段落の先頭では、前の段落との論理関係を接続表現で明示する（「であれば」「実際」「しかし」「この例自体からも」）。\n- 論証は一方向に進める。結論を出してから反論を処理し、結論を言い直す構成にしない。反論と疑念の処理を終えてから、結論を一度だけ置く。\n- 例への弁明（作為的に見える、への先回りなど）は、場面の山場の直後に挟んで流れを切らない。次の節の冒頭でまとめて処理する。\n- 読者が立てそうな誤った解釈は、明示的に否定してから本当の理由を述べる（「その理由は『〜だから』ではない。〜だからだ」）。\n- 「AではなくB」と否定するときは、否定の根拠を一文添える。反実仮想（「もしAなら、〜だっただろう」）が使えることが多い。\n- 同じ概念を二つの対象で対比定義するときは、両文の述部を同じ型にする。既出の説明の回収は文頭の枠に置き、定義そのものを「〜だと説明した」に埋め込まない。特徴の句は「」で切り出し、対比の接続を明示する。第二極について続ける属性は、主語を改めて名乗らず継承する。\n- 譲歩（「確かに〜」）では、事実の確認にとどめる。あとで訂正する内容を著者の声で因果として断定すると、自己矛盾になる。表面的な診断を一度認めたいときは、読者や通説の声に帰属させる（「〜と要約できてしまうかもしれない」）。\n- 山場で効かせたい情報（数値、固有の事実）は、その手前の段落で先出ししない。\n- 何かを否定・限定するときは、否定する命題そのものを「」で正確に書き出す（「明文化されていればすべてを任せられる」を意味しない、など）。「何もかもが解決するわけではない」のような漠然とした否定で済ませない。\n- 「後の章で扱う」のような前方参照は、論証が一段落した位置（段落末・節末）に置く。論証の途中に挟んで流れを切らない。\n\n## 論証の厳密さ\n\n文章の論理にツッコミどころを残さない。書き上げたら、読み手の反論を先回りして次の点を点検する。\n\n- 推量・可能性・読者の疑念・反実仮想として書かれている文を、機械的に断定へ変えない。\n  「かもしれない」「だろう」「ようだ」「らしい」は、根拠なく主張を弱めている場合だけ削る。\n  事実未確認の可能性、作中人物の認識、ログからの推定、読者が抱きそうな疑念、反実仮想を表す場合は、その不確実性を保つ。\n  断定に直せるのは、本文内の根拠によって命題が確定している場合に限る。\n  悪い例：「提示し続けているかもしれない」を「提示し続けている」に変える。\n  良い例：「提示し続けている可能性がある」のように、不確実性を残して文を整える。\n- 異なるものを「同じ」とまとめない。区別すべき対象（別々の決定、別々の原因、種類の違う問題）を一括りの言葉でくくらない。悪い例：相互依存する三つの未決事項を「同じ決定を別々に下していた」と書く。良い例：「どれも別々の決定であり、しかも互いに依存している」と腑分けする。\n- 複数の要因がある事象を、単一の原因に還元しない。例が複数種類の問題を含むなら、それぞれを切り分け、どの道具がどれを説明するのかを対応づける。悪い例：契約の不在と情報隠蔽の失敗が混ざった事故を、丸ごと「情報隠蔽の問題」と説明する。\n- 章・節をまたいで、同じ概念の扱いを一致させる。ある節で「人間が決める」と分類したものを、別の節で「チームで合意する」と書かない。分類・定義・用語の地位は全体で揃える。\n- 因果を主張するときは、その機構（なぜそうなるのか）を一文で示す。「AだとBになる」とだけ書いて理由を省略しない。悪い例：「手順で分けると変更が全体に波及する」。良い例：「各工程がデータを受け渡すための表現を共有してしまい、その表現を変えると全体に波及する」。\n- 検出・保証・解決を「必ず」できるかのように書かない。条件付きで正確に述べる（「〜しやすい」「〜できることが多い」「〜が成り立つときに限り」）。\n- 主張は、挙げた例が実際にその全体を支えているかを確認する。例が主張の一部しか支えないなら、主張の範囲を例に合わせて狭める。\n- 「次節で扱う」と前方に逃がした論点は、本当にそこで回収されることを確認する。回収しない伏線を張らない。\n- 譲歩や限定（「ただし」「とはいえ」）を置いたら、その後で必ず論を進める。逆接で終えて宙吊りにしない。\n- 節の中心となる語は、その節以前に定義・対象範囲を述べてから使う。定義せず使い始めない。\n- 複数の概念を一つの上位語にまとめるときは、命名の直前に、それらが同じものに帰着すると\n  一文で述べる。腑分けの逆の操作にも橋を架ける。\n\n## 読み手の負荷の管理\n\n読者の記憶と注意は有限の資源として扱う。\n\n- 読者が順読みで保持する情報は、一度に一段だけ増やす。箇所を削ったら残った言及を辿り、この文書のほかで使われなくなった主題は落とす。直前までの文の上に一段で足りる許可や読み方は直接書く。\n- 後で参照する必要のない固有名（ファイル名、関数名、識別子）を出さない。「仕様書」「金額計算のユーティリティ」のような一般的な言い方で済ませる。\n- 抽象的な言い回しの指す内容が文脈から一意に決まらないときは、可能なときは丸括弧による同格挿入でその場で特定し、できるだけ読者に前を読み返させない。\n- 概念を初めて示す文では、読者が順に読んだだけで、まずその概念が何であるか（データ構造、手順、制約などの種類や地位）を読み取れる順序にする。その概念を既に知っている読者にだけ自然な性質・仕組み・制約を、種類の同定より前に置かない。前置すると、未習の読者は文を読み終えた時点で逆戻りしなければ核となる情報を見逃すか、理解が滞る。\n- 新しい例や場面を追加して、読者が保持すべき文脈が増えるときは、前の例と何が違うのか、なぜもう一つ必要なのかを前置きして納得感を与える。\n- 同一節内に図、表、コードなど複数の提示があるとき、各媒体が担う説明（配置の見え方、数値、手順など）を分けて書く。媒体間で型やデータを揃える必要はなく、別例として並べてよい。指示語（「この2つ」「上記の例」）は、どの媒体のどの例を指すか文脈だけで一意に決まるように置く。一つの媒体で確認した性質を、別の媒体の例にもそのまま当てはめない。二方式を「Aの代わりにB」と対比するときも、やめる側と採る側の語順を置換関係と一致させ、後に書く側が採用される方式であることを順読みで読み取れるようにする。\n- 章冒頭や節の導入では、これから例で扱う内容に関係しない過剰な詳細を詰め込まない。\n- 例の節の中でも、**その節の問い・帰結に関係しない**過剰な詳細だけを omit する。議論に必要な具体は残す。省略の典型は、エージェント報告の装飾的精度（時刻、HTTP ステータス、カバレッジ率など）や、後で参照しない固有名詞。\n\n## 視点と語り\n\n- 例示では、結果の羅列や受動態（「特定され、判明した」）ではなく、行為者を主語にした動作の連なり（「リポジトリを調査して特定し、見つけてくれた」）で書く。\n- 「入社2年目のエンジニアが」のような架空の人物設定を無意味に冠しない。\n- 論証の中で読者を「あなた」と呼ばず、役割名（「開発者」「読者」）で書く。二人称の呼びかけは、場面への導入（「〜としよう」）や章・本の結びなど、限られた要所にとどめる。\n- 対象を指す語は具体的に選ぶ。「AI」「ツール」のような広い語でぼかさない。\n- 章や節で定式化・術語（K、契約、不変条件など）を導入したら、以後はその語で通す。「文脈」「ツール」「AI」のような曖昧語に後退しない（定式化する前の導入語として「文脈」などを使うのはよい）。\n- 術語・訳語は、その分野で慣用されている語を選ぶ（プッシュ通知は「配送」ではなく「配信」、など）。意味の近い漢語を一般語の感覚で充てない。\n- 人物そのものに言及するときは原綴りで書く（Lehman、Bainbridge）。ただし、歴史上の人物や、人名を冠した概念を定着名で紹介するときは、日本語で通用しているカタカナの通称を使う。\n- 術語の響きを持つ語を、術語でない場面に流用しない（システムから人間までの連なりを「経路」と呼ぶ、など）。「届くまでの流れ」「あいだに何があるか」のように普通の言い方で書く。\n- イ形容詞の終止に「です」を続けた文（「難しいです」「多いです」）を書かない。これは文体の規則ではなく、文の流れの破綻の兆候である。イ形容詞を裸で言い切る必要が生じるのは、その文が前後から孤立しているからであり、流れている文章なら「〜は難しく、…」と文が続くか、「〜でしょう」「〜である」で受けられる。出現したら文末だけ取り繕わず、前後の流れごと書き直す。ナ形容詞の「〜です」（「重要です」）は対象外。\n\n## 演出の抑制\n\n演出の規範は全面禁止ではなく、節度の規範である。修辞は、それが効果を生む箇所でのみ使う。\n\n- 溜め（「ここには〜が潜んでいる」）や修辞疑問で導出を演出するのは、緊張が議論に効く要所に限る。説明で足りる箇所では、そのまま述べる。\n- 短い決め台詞を独立した段落にして緊張を作る演出を多用しない。段落内の短い体言止め（「ここまでわずか数十秒。」など）は、場面の山場に限り使ってよい。\n- 本文中の太字強調を多用しない。誤読を防ぐ否定や節の帰結など、論理の要所に限り、一節に一、二箇所まで使ってよい（導入部でも可）。それ以外は文の順序と構造で際立たせる。\n- 「〜してはならない」という命令調の断定より、「〜するわけにはいかない」のような、作業者の判断として書く形を選ぶ。\n- 転回点を過剰に劇的にしない。事実を述べる一文で足りる場合が多い。議論の山場にかぎり、感嘆符つきの短い一文程度は許容する。\n- 帰結の列挙によって事故や危険を煽らない。\n- 「重要なのは〜である」のような前置きで主張を予告しない。主張をそのまま書く。ただし、主張の様式を宣言する前置き（「標語として言い換えれば」など）は使ってよい。\n- 「AではなくBだった」という対句の決め台詞を多用しない。軽い補足や評価は括弧書きで添えてよい。\n- 慣用表現をひねった言い回し（「知識を体に入れる」など）や、指す内容が一意に決まらない比喩（「報告の外側に世界が広がっている」など）を使わない。平易な動詞でそのまま言う（「身につく」「気付く機会が減る」）。\n\n## LLM っぽい表現の禁止\n\nLLM が大量生成する、中身のない型に誘惑されない。書き上げたら、この節で点検する。\n本書の術語（本質的複雑さ、回収、判断の配置など）を議論に使うのはよい。空虚な装飾として使うのが問題である。\n\n次のような言い回しは、論点を増やさず「ちゃんと書いている感」だけを付ける LLM 口調である。使わない。\n\n- **予告と総括**：「重要なのは〜である」「本章では〜を扱う／探求する」「ここでは〜について見ていく」「まとめると」「要するに」（直前の言い換えだけのとき）、「〜に他ならない」\n- **正面から系**：「正面から扱う」「正面から回収する」「正面から見る／書く／立てる」——中身の代わりに姿勢だけを宣言する\n- **空虚な形容**：「不可欠」「核心的」「鍵となる」「根本的な」（主張の中身を説明せず強調だけする）、「多角的」「包括的」「総合的」（何をどう見たかを書かない）\n- **空虚な動詞**：「掘り下げる」「深掘りする」「言語化する」（何をどう書いたかを示さず終わる）、「触れる」「言及する」（一段落で済ませるだけ）\n- **接続の型**：「〜において」「〜という側面から」「〜の観点から」（新情報なし）、「さらに」「また」「加えて」の連打\n- **弱い緩和と称賛**：「〜と言えるだろう」「〜かもしれない」（根拠なく主張を弱める場合だけ。推量・仮定・読者の疑念・作中人物の認識なら残す）、「非常に」「極めて」「大いに」（中身のない強調）\n\n悪い例：「本章では、〇〇の理論を正面から扱う」「この前提を、ここで正面から回収する」「多角的に分析すると、重要なのは〜である」。\n良い例：「本章では、〇〇の理論を扱う」「ここで、この前提を回収する」「評価の核心は、正しさを誰が知っているかにある」。\n\n## 翻訳調の比喩と擬人化の禁止\n\nLLM は、日本語として存在しない言い回しを、次の三つの経路で生成する。\n前節の空句と違い、書き手（LLM）に比喩や演出の意識がないまま混入するので、比喩を使ったつもりのない文も含めて点検する。\n\n- **英語慣用句の直訳**：英語の技術文では carry \u002F open \u002F expose \u002F live \u002F land などの比喩的用法が慣用句として定着しており、比喩として意識されない。これを日本語の対応語に直訳すると、日本語では慣用化していないため、字義どおりに読める奇妙な生きた比喩になる。\n  - 悪い例：「ベクトルが選好を運ぶ」（carry）。良い例：「選好がベクトルとして表現される」「ベクトルに反映される」。\n  - 悪い例：「この問いは開かれている」（open question）。良い例：「この問いにはまだ答えが出ていない」「未解決である」。\n  - 悪い例：「推敲の軸が露出する」（expose）。良い例：「推敲の軸が線形に取り出せる」。\n  - 悪い例：「この情報は残差ストリームに住んでいる」（live in）。良い例：「残差ストリームに含まれる」。\n- **無生物主語構文の直輸入**：英語では無生物主語の他動詞文が普通だが、そのまま日本語にすると、モデル、データ、ベクトル、損失といった抽象物が意思を持って振る舞う擬人化になる。日本語では、人か処理を主体に戻すか、「〜から分かる」「〜に含まれる」の形に言い直す。\n  - 悪い例：「モデルは文体を知っている」。良い例：「モデルの出力には文体の一貫性がある」など、確認できる事実として書く。\n  - 悪い例：「データが語るのは〜である」。良い例：「データから分かるのは〜である」。\n- **研究者の話し言葉の混入**：機械学習の口頭議論で流通する動詞（「効く」「刺さる」「筋がいい」など）は、話し言葉としては通じるが、書き言葉の技術文書では俗語である。効果や見込みの内容を具体的に書く。\n  - 悪い例：「規範スキルが効く」。良い例：「規範スキルを与えると生成が選好に近づく」。\n  - 悪い例：「この手法は筋がいい」。良い例：「この手法は〜という理由で有望である」。\n\n判定の目安は二段である。\nまず、その述語を初めて見る読者が字義どおりの動作（運ぶ、開く、住む）を想像しうるなら、翻訳調の比喩を疑う。\n次に、動作の主体と対象を具体語で言い直せるか試す。\n言い直せるなら、その言い直しをそのまま書く。\n言い直せないなら、その文は指す内容が特定できていないので、主張として成立していない。削るか、内容を確定させてから書き直す。\n\n## 冗長の排除\n\n無駄な文章をなるべく残さない。\n\n- 同じ主張を言い換えて繰り返さない。一つの主張は一度だけ書く。題材が直前と同じでも、その文が加えている命題が違えば繰り返しではない。列挙の各項が同じ論理的地位であることを示す枠語の反復や、定義の直後に適用条件や限定を足す文も、主張の繰り返しではない。\n- 隣接する節が同じことを別の角度で述べているなら、役割が重複している。片方に吸収して一つの節にまとめる。\n- 場面を描写した直後に、その内容を要約し直さない。意味づけの一文（「このような作業は、ほぼ完全に任せられる」など）だけを置く。\n- 同じ論理的役割を持つ並列の事実は、文を分けて重ねず一文にまとめる。その事実群の論理的地位は文頭の語で示す（「当然、経理部の月次処理も顧客の支払いも〜」）。\n- 冗長さは文字数や文数で判定しない。短文化と一文化は、動機、対象、操作、その同一性、因果、条件が順読みで明示されたまま保てる場合に限る。これらを読者の推論に委ねる圧縮はせず、必要な反復と長さを残す。\n- 接続や評価のためだけの文（「それ自体はよいことである」など）を置かない。\n- 想像上の読者との問答（問いを立てて一語で答える形など）を修辞として使わない。主張はそのまま述べる。読者の反応を演じて応答する形（「〜と感じたかもしれない。そのとおりである」）も同様に避け、譲歩は地の文で簡潔に行う（「もちろん、処置そのものは開発者が決める問題ではない」）。\n- 読者が抱きそうな発想を、メタな枠取り（「ここまでの話には自然な続きがある」「〜という発想である」）で紹介しない。その発想自体を直接書く。読者の疑問なら疑問文のまま書いてよい（「その保守も任せればよいのではないだろうか」）。\n- 「本書もそれを否定しない」のような、著者の立場の弁明や断りを書かない。事実の記述（「〜に書かせる場合が多い」）だけを置く。\n- 文脈を最短で読み手と共有できる文章にする。導出を一歩ずつ展開しなくても伝わるなら、構造に名前を与えて言い切る。\n- 本文でまだ導入していない概念や文書名を、先回りして持ち出さない。\n- ためらいのある弱い述語（「有効な対策であり」など）で済ませない。本文内の根拠で確定していることは強く具体的に言い切る（「活用において必須であり」など）。ただし、不確実性・可能性・仮定・読者の疑念を表すための弱い述語は保持する。語調を整えるための意図的な緩和（「必須だと言ってもいい」など）は許す。\n- 文章のリズムを作るための接続表現（「しかし一方で」など）は、冗長と見なさない。\n\n## 見出しの付け方\n\n見出しは内容を特定できる具体的なものにする。その節が答える問い、または扱う対象を指す句にする。\n\n- 作業の手順だけを述べる見出し（「例に戻す」「〜を読み直す」など）や、情報量のない見出しにしない。その節が答える問い、または扱う対象を見出しにする。\n- 見出しを、節の結論を言い切る「セリフ」にしない。見出しの時点で読者がオチを知る状態を避ける。\n- 節で扱っている対象を指す名詞句でもよい。\n- 見出しが疑問形か断定形かは問わない。問うのは、扱う対象や読者の持つ問いを指しているかである。\n- 疑問形か、対象を指す名詞句かは、本文のトーンに合うほうを選ぶ。\n\n## 読者への誠実さ\n\n- 例が作為的に見えうる場合、それを隠さない。読者の疑念を先回りして認め、現実に十分あり得ることの根拠を短く添える。\n- その根拠は、著者の断定（「十分あり得る状況だ」）ではなく、読者自身の経験に訴える一般的事実や通説に求める（「この症状は珍しくないだろう」「〜という言い方もよく耳にする」）。\n- 確認していないことを、確認したかのように滑らかに書かない。\n",{"name":33,"license":34,"description":35},"japanese-tech-writing","Unlicense（https:\u002F\u002Fgist.github.com\u002Fk16shikano\u002F67625f2a7d96e3bbdfae8d571a936063）","日本語の技術文書・書籍原稿の文章規範。段落と論証の構成（パラグラフライティング）、論証の厳密さ（ツッコミどころの除去）、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、翻訳調の比喩と擬人化の禁止（「運ぶ」「効く」「開かれた問い」など）、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、または推敲・リライトするときに使用する。","main","e3bd571a552fccb7992acf5ea2c345daaf1fabe4","packages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Ffailing-examples\u002FSK008\u002Finvalid-directory-name\u002Fskills\u002Fbad_name",0,"https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint","https:\u002F\u002Fgithub.com\u002Fbitflight-devops","Public repositories of DevOps tools, scripts, integrations, and templates","2026-11-09 14:16:32",{"source":8,"skillName":33,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add bitflight-devops\u002Fskilllint --skill japanese-tech-writing",{"tool":50,"command":51},"bunx","bunx skills add bitflight-devops\u002Fskilllint --skill japanese-tech-writing",{"tool":53,"command":54},"pnpm","pnpm dlx skills add bitflight-devops\u002Fskilllint --skill japanese-tech-writing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Ffailing-examples\u002FSK008\u002Finvalid-directory-name\u002Fskills\u002Fbad_name\u002FSKILL.md",true,[58,64,70,73],{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"assets\u002F.gitkeep","ASSET","资产文件",1,"https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Ffailing-examples\u002FSK008\u002Finvalid-directory-name\u002Fskills\u002Fbad_name\u002Fassets\u002F.gitkeep",{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"eval_queries.json","REFERENCE","参考文档",16,"https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Ffailing-examples\u002FSK008\u002Finvalid-directory-name\u002Fskills\u002Fbad_name\u002Feval_queries.json",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":62,"sourceHtmlUrl":72},"references\u002F.gitkeep","https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Ffailing-examples\u002FSK008\u002Finvalid-directory-name\u002Fskills\u002Fbad_name\u002Freferences\u002F.gitkeep",{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":62,"sourceHtmlUrl":77},"scripts\u002F.gitkeep","SCRIPT","脚本","https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Ffailing-examples\u002FSK008\u002Finvalid-directory-name\u002Fskills\u002Fbad_name\u002Fscripts\u002F.gitkeep",[79,92,116,134,144,157],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":28},"01M6CSQYQKKT3AP6J6NTT1RYJG","fixable-skill","Exercise grouped Action fix findings.","https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Faction\u002Fskills\u002Ffixable-skill\u002FSKILL.md",[],[86,87,88,89,90,91],"fixable skill","action","exercise","fix findings","fix","read",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":28},"01M6CSQWBMT9000HH2A7KR1TCC","skilllint","Use the skilllint CLI to validate, explain, and fix agent plugins, skills, agents, commands, and platform files. Use when asked to lint agent artifacts, investigate a skilllint rule ID, or verify a plugin before commit.","https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fplugins\u002Fagentskills-skilllint\u002Fskills\u002Fskilllint\u002FSKILL.md",[],[94,99,100,101,102,103,104,105,106,107,108,90,24,109,110,111,112,113,114,115,27],"explain","cli","commit","validate","plugin","lint","artifacts","plugins","verify","investigate","files","commands","platform","id","rule","path","agent plugins",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":127,"publishedAt":28},"01M6CSQTRYRZN792TK6FV6PDAA","my-skill","Use this skill when you need to verify valid name pattern compliance.","https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Fpassing-examples\u002FFM010\u002Fvalid-name-pattern\u002Fskills\u002Fmy-skill\u002FSKILL.md",[122],{"categoryNo":123,"categoryName":124,"taxonomyType":125,"taxonomyTypeDesc":126},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[128,129,130,27,21,131,132,107,24,133],"my","my skill","you","valid","compliance","pattern",{"skillNo":135,"name":118,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":28},"01M6CSQSAR0FC01CBKBXSTYQCD","Use this skill when you need to verify quoted descriptions with colons: example.","https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Fpassing-examples\u002FFM009\u002Fquoted-description\u002Fskills\u002Fmy-skill\u002FSKILL.md",[139],{"categoryNo":123,"categoryName":124,"taxonomyType":125,"taxonomyTypeDesc":126},[128,129,107,24,141,142,130,143,27],"example","with","quoted",{"skillNo":145,"name":118,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":28},"01M6CSQQK9TV19JTYPV242XR1P","Use this skill when you need to verify CSV string format for tools.","https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Fpassing-examples\u002FFM007\u002Ftools-as-csv-string\u002Fskills\u002Fmy-skill\u002FSKILL.md",[149],{"categoryNo":123,"categoryName":124,"taxonomyType":125,"taxonomyTypeDesc":126},[128,129,130,151,152,107,153,154,91,24,155,156,27],"csv","Tools","format","grep","STRING","for",{"skillNo":158,"name":118,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":163,"publishedAt":28},"01M6CSQP4X044W2FZXDMVGWHPM","Use this skill when you need to verify valid enum field values.","https:\u002F\u002Fgithub.com\u002Fbitflight-devops\u002Fskilllint\u002Fblob\u002Fmain\u002Fpackages\u002Fskilllint\u002Ftests\u002Ffixtures\u002Fproviders\u002Fagentskills\u002Fpassing-examples\u002FFM006\u002Fvalid-context-value\u002Fskills\u002Fmy-skill\u002FSKILL.md",[162],{"categoryNo":123,"categoryName":124,"taxonomyType":125,"taxonomyTypeDesc":126},[129,128,131,107,24,130,164,165,27],"values","fork"]