tktcorporation

コードを変更する実装作業（機能追加、バグ修正、リファクタリング、テスト追加）を始めるときに使うスキル。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼のほか、 方針合意後に「進めて」「お任せ」「どんどんやって」と任された場合にも使う。 調査・質問回答・レビューだけで完結するタスクや、方針が未決で相談段階のものには使わない。

ユーザーの発言内容だけを忠実にドキュメント化するスキル。PRD・仕様書・企画書・ 提案書など構造化ドキュメントの作成時に使う。AIが「言ってないことを勝手に補足する」 問題を防ぐためのもの。以下のような場面で必ず発動すること: "PRDを書いて", "企画書を作って", "仕様書をまとめて", "ドキュメントにして", "草案を書いて", "叩き台を作って", "提案書を書いて", "聞いた内容をまとめて", "話した内容を文書化して", "言ったことだけ書いて", "勝手に足さないで" またユーザーの口頭説明や会話からドキュメントを起こす場面でも積極的に使うこと。

npm (pnpm) / Cargo の依存パッケージをバージョンアップするスキル。 サプライチェーン攻撃 (Shai-Hulud 系 worm) のリスクを抑えつつ、脆弱性のある パッケージを優先的に潰し、override (pnpm.overrides / [patch.crates-io]) という 負債をなるべく増やさない / 既存の override を外せないか検討する、までを 1 セットで回す。 以下の依頼で使う: 「依存を上げて」「パッケージを更新して」「バージョンアップして」「audit を潰して」 「脆弱性のあるパッケージを直して」「dependabot の PR を見て」「override を整理して」 「outdated を解消して」。 個別 1 パッケージの bump でも、まずこのワークフローを通して安全性と override 負債を確認する。

PR が「その文脈を知らない初見のレビュアー（別チーム／入社直後）」に通じるかを点検したいときに使う。初見が詰まる原因は2つ。①意味が取れない（issue/PR にしか登場しない呼び名「Phase-2」「軸B」、PR に含まれない参照、未定義の略語、暗黙の前提「前回の議論どおり」等）と、②頭に入ってこない（一文が長い・主述が遠い・名詞化・回りくどい述語・結論が後ろ＝可読性）。語は分かるのに文がまどろっこしいときも対象。社内で定着しコードに実体がある用語（grep で定義に辿れる社内サービス名等）は対象外。トリガー例:「初見でレビューできる？」「PRのジャーゴンを消して」「文がまどろっこしい」「スッと頭に入らない」「onboarding した人が分かる？」。

Research-driven UI design decision-making. Use when facing UI/UX design choices, information layout challenges, or needing to decide how to display complex data. Triggers: (1) UI design decisions with multiple valid approaches, (2) information overload or layout consolidation needs, (3) "how should we display X?" or "how do other products handle Y?" questions, (4) progress indicators, steppers, navigation, form design decisions, (5) when the user says the design feels "broken", "too much", or "messy", (6) when uncertain about the best way to organize or present information in UI

UIコンポーネントやページを実装する際に、AI特有の「ジェネリック感」を排除し、プロのUIデザイナーが設計したような品質を実現するスキル。 UIの実装、コンポーネント作成、画面構築、フロントエンド開発、ページデザインを依頼されたとき、 または「UIを作って」「画面を実装して」「コンポーネントを作って」「フォームを作って」「ダッシュボードを作って」 といったリクエストで必ず使うこと。既存の frontend-design スキルと併用可能だが、 こちらは「参照ベースの実装」と「AI感の排除」に特化している。 ボタン1つでも画面全体でも、UI実装が絡むなら使うべき。

修正・バグ修正・リファクタリングの依頼時に、末端パッチではなく上流での根本解決を優先するスキル。 「これ直して」「バグがある」「修正して」「ここがおかしい」「リファクタリングして」「設計を見直して」 「場当たり的じゃなくちゃんと直して」「根本から直して」といった依頼で使う。 コード修正の依頼全般で使うこと。単純な typo 修正や1行の変更でも、周辺に根本的な問題が潜んでいないか 確認するために一度このスキルのワークフローを通す価値がある。

シナリオの「魅力」と「読者体験」を検証するセルフレビュースキル。 lintが捕捉する構造的問題（会話比率、ナレーション連続等）の上位レイヤーとして、 「読者が自然に読めるか」「引き込まれるか」「疑問を持たないか」を検査する。 「レビューして」「セルフレビュー」「品質チェック」「読者視点で確認して」 「唐突感がないか見て」「魅力的か確認して」といった依頼で発動。 シナリオ執筆後のセルフレビューフェーズで必ず使うこと。

キャラクターが読者に愛されるかどうかを検証するスキル。 「このキャラ好きになれない」「なんか不快」「魅力が見えない」「読者が離れそう」 という問題を事前に防ぐ。シナリオ執筆・レビュー時に適用すること。 「キャラの魅力を上げて」「好感度が足りない」「読者がつくか不安」 「キャラが不快」「もっと愛されるキャラにして」で発動。 scenario-writingスキルと併用する。会話の内容がスキル、構造がハーネス。

ADVゲーム「月灯り」のシナリオテキストを執筆・改善するためのスキル。 自然な会話、環境描写、感情表現、ペーシングに関する包括的なガイドライン。 「シナリオを書いて」「テキストを改善して」「会話を自然にして」「シーンを追加して」 「ストーリーを書いて」「台詞を直して」「場面を膨らませて」といった依頼で発動。 唐突さを排除し、読者が行間を読める余白のあるテキストを目指す。

ハーネスエンジニアリングの原則に基づき、エージェントのミスを構造的に防止するスキル。 「同じミスを二度としない」ためのフィードバックループを回す。 ミスを発見した時、リンタールール追加、知識タイムライン更新、hookの改善など 決定的な検証レイヤーを強化する作業で使う。 「ハーネスを改善して」「リンタールールを追加して」「知識タイムラインを更新して」 「hookを追加して」「検証を自動化して」「同じミスが起きないようにして」で発動。 シナリオの整合性問題を修正した後にも自動的に適用すること。

シナリオの論理的整合性・因果関係・物理的矛盾を防ぐためのスキル。 「なぜこの人は今ここにいる？」「なぜこの行動をとった？」「前の場面と矛盾していないか？」 といった違和感を事前に潰す。シナリオ執筆・修正時に必ず適用すること。 scenario-writing（テキスト表現）、narrative-design（構造設計）の下位で機能する 「物理法則レイヤー」のスキル。

物語の前提・キャラクター導入・関係性構築を体系的に設計するスキル。 「設定が不自然」「キャラの登場が唐突」「関係性が浅い」「もっと読みたくならない」 「キャラに深みがない」「前提に違和感がある」「動機が弱い」といった問題に対処する。 シナリオの構造設計、キャラクター設計、プロット設計の段階で使うこと。 scenario-writing スキル（テキスト表現レベル）の上位に位置する構造設計スキル。

ソーシャルゲーム・カフェ経営ゲームのシステム設計を改善・拡張するためのスキル。 ゲームメカニクスの追加・変更、バランス調整、新システムの提案時に使う。 「システムを改善して」「深みを出して」「バランスを調整して」「新しい仕組みを追加して」 「エンゲージメントを上げたい」「リテンションを改善したい」といった依頼で発動。 搾取的でなくプレイヤーを尊重する設計哲学に基づく。

「点と点を線にする」快感を軸にゲームデザインを設計・レビューするスキル。 人間の脳は「無関係に見えたAとBに関係性を見出した瞬間」に強い快感を得る。 伏線回収・知識アンロック・シナジー発見・隠れた関係性は全てこの派生。 「線（=AとBを結ぶ説明）はプレイヤー自身に引いてもらう設計」が核心で、 デザイナーは点を配置し、余白（=線にあたる部分）をあえて残す。 以下のような場面で使う: - 新しいゲームメカニクスを設計するとき - ストーリー・世界観・伏線を設計するとき - チュートリアル・知識提示・情報UIを設計するとき - ゲームの「面白さが弱い」「淡々としている」「アハ体験がない」と感じたとき - 既存のゲーム（cookie, factory, rpg, abyss, godfield, metropolis など）の面白さを強化する提案をするとき - 「点と線で考えて」「伏線として」「アンロックの設計」「アハ体験」といったキーワード

ゲームデザインを分析し、面白さを改善するための提案を行う。対象ゲームを指定するか、全ゲームを対象にできる。

方針合意後の実装を自律的に進め、テストを丁寧に書き、セルフレビューを徹底するスキル。 実装タスク全般で使うこと。機能追加、バグ修正、リファクタリング、テスト追加など、 コードを書く作業が発生したら必ずこのワークフローを通す。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼はもちろん、 ユーザーが方針を決めて「進めて」「お任せ」「どんどんやって」と言った場合にも使う。 確認を挟まず自律的に完成まで持っていくためのワークフロー。

ユーザーの発言内容だけを忠実にドキュメント化するスキル。PRD・仕様書・企画書・ 提案書など構造化ドキュメントの作成時に使う。AIが「言ってないことを勝手に補足する」 問題を防ぐためのもの。以下のような場面で必ず発動すること: "PRDを書いて", "企画書を作って", "仕様書をまとめて", "ドキュメントにして", "草案を書いて", "叩き台を作って", "提案書を書いて", "聞いた内容をまとめて", "話した内容を文書化して", "言ったことだけ書いて", "勝手に足さないで" またユーザーの口頭説明や会話からドキュメントを起こす場面でも積極的に使うこと。

npm (pnpm) / Cargo の依存パッケージをバージョンアップするスキル。 サプライチェーン攻撃 (Shai-Hulud 系 worm) のリスクを抑えつつ、脆弱性のある パッケージを優先的に潰し、override (pnpm.overrides / [patch.crates-io]) という 負債をなるべく増やさない / 既存の override を外せないか検討する、までを 1 セットで回す。 以下の依頼で使う: 「依存を上げて」「パッケージを更新して」「バージョンアップして」「audit を潰して」 「脆弱性のあるパッケージを直して」「dependabot の PR を見て」「override を整理して」 「outdated を解消して」。 個別 1 パッケージの bump でも、まずこのワークフローを通して安全性と override 負債を確認する。

コードを変更する実装作業（機能追加、バグ修正、リファクタリング、テスト追加）を始めるときに使うスキル。 「実装して」「作って」「追加して」「直して」「書いて」といった依頼のほか、 方針合意後に「進めて」「お任せ」「どんどんやって」と任された場合にも使う。 調査・質問回答・レビューだけで完結するタスクや、方針が未決で相談段階のものには使わない。

PR が「その文脈を知らない初見のレビュアー（別チーム／入社直後）」に通じるかを点検したいときに使う。初見が詰まる原因は2つ。①意味が取れない（issue/PR にしか登場しない呼び名「Phase-2」「軸B」、PR に含まれない参照、未定義の略語、暗黙の前提「前回の議論どおり」等）と、②頭に入ってこない（一文が長い・主述が遠い・名詞化・回りくどい述語・結論が後ろ＝可読性）。語は分かるのに文がまどろっこしいときも対象。社内で定着しコードに実体がある用語（grep で定義に辿れる社内サービス名等）は対象外。トリガー例:「初見でレビューできる？」「PRのジャーゴンを消して」「文がまどろっこしい」「スッと頭に入らない」「onboarding した人が分かる？」。

Markdown ドキュメント (README, 設計書, .claude/rules/, docs/) や、コード内の 公開関数 JSDoc / docstring / 非自明ロジックへのコメントを書く・編集するときに 使うスキル。「半年後の読者が誤解しない文章」を成立させるためのチェックリスト。 以下の場面で必ず発動する: "ドキュメントを書いて", "README を更新して", "設計書を書いて", "コメントを足して", "JSDoc を書いて", "docstring を書いて", "ルールを追加して", "プランを書いて", "仕様をまとめて", ".claude/rules に追加", "docs/ に追加", "PR description を書いて" Markdown 文書 (.md / .mdx) や code comment の Edit/Write を行う前後に チェックリストを通す。

修正・バグ修正・リファクタリングの依頼を受けたとき、末端パッチではなく上流での根本解決を 「どう直すか」決めるまでを担うスキル（実装フェーズには踏み込まず、方針決定までを担う）。 「これ直して」「バグがある」「修正して」「ここがおかしい」「リファクタリングして」「設計を見直して」 「場当たり的じゃなくちゃんと直して」「根本から直して」「ゼロから設計し直すなら」といった依頼で使う。 コード修正の依頼で発動し、症状の奥に設計上の根本原因が無いかを一度診断する。 smell が無ければ局所修正で止め、smell があれば上流まで遡って直す方針を立てる。

PR・ブランチ差分を「ユーザー価値とプロダクト品質」の観点で、PdMとしてレビューするスキル。「PRをレビューして」「この変更でユーザーに何が起きる？」「ユーザーへの価値はどう変わる？」「イシューの意図に沿ってる？」「これマージして大丈夫？」「PdM目線で見て」「合否を判断して」といったリクエストで使う。codex review や code-review が行レベルのコード品質を見るのに対し、本スキルは「このPRをユーザーに出して良いか」を、価値の増減（プラス/マイナス）・イシューの意図との整合・想定外の変化の3点で評価し、PdMがパッと見で合否判断できる粒度にまとめる。

UIコンポーネントやページを実装する際に、AI特有の「ジェネリック感」を排除し、プロのUIデザイナーが設計したような品質を実現するスキル。 UIの実装、コンポーネント作成、画面構築、フロントエンド開発、ページデザインを依頼されたとき、 または「UIを作って」「画面を実装して」「コンポーネントを作って」「フォームを作って」「ダッシュボードを作って」 といったリクエストで必ず使うこと。既存の frontend-design スキルと併用可能だが、 こちらは「参照ベースの実装」と「AI感の排除」に特化している。 ボタン1つでも画面全体でも、UI実装が絡むなら使うべき。

修正・バグ修正・リファクタリングの依頼時に、末端パッチではなく上流での根本解決を優先するスキル。 「これ直して」「バグがある」「修正して」「ここがおかしい」「リファクタリングして」「設計を見直して」 「場当たり的じゃなくちゃんと直して」「根本から直して」といった依頼で使う。 コード修正の依頼全般で使うこと。単純な typo 修正や1行の変更でも、周辺に根本的な問題が潜んでいないか 確認するために一度このスキルのワークフローを通す価値がある。

Design and build high-quality, non-generic UI that doesn't look "AI-generated". Use whenever creating or restyling any interface, component, theme, or design system — especially when output looks generic, templated, or like default glassmorphism. Enforces explicit design intent, a real type/space/color system, genre-appropriate art direction, and tactile feedback.

Zenn (zenn.dev) の技術記事を、外部の人気記事の構成パターンを調査・分析した上で執筆するスキル。 記事の企画・構成・執筆・改善の全工程をカバーする。 「Zenn 記事書いて」「記事を書きたい」「ブログ書いて」「紹介記事を作って」「〇〇の記事を書いて」 「技術ブログを書きたい」「Zenn に投稿したい」「記事の構成を考えて」「記事をリライトして」 といった依頼で必ず使うこと。記事の一部修正やタイトル変更だけの場合は不要。

UI/UX design intelligence. 67 styles, 96 palettes, 57 font pairings, 25 charts, 13 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button, modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, flat design. Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing, hover, shadow, gradient. Integrations: shadcn/ui MCP for component search and examples.