Skill.md検索

要件定義から実装まで一本道で進める — MUSUBI仕様駆動開発フローに従うことで、要件→設計→タスク→実装→検証の各段階が整理され、迷わず進められます。 仕様変更を体系的に管理 — Delta Specを使い、変更内容の初期化・検証・適用・アーカイブを自動化でき、変更漏れを防げます。 プロジェクトメモリを一元管理 — steering/ディレクトリで製品・技術・構造・規約情報を整理し、チーム全体がいつでも参照できます。 ギャップ検出で仕様漏れを自動発見 — musubi-gapsコマンドで仕様と実装のズレを検出し、品質を担保します。 フェーズ計画を視覚的に管理 — plans/に計画を配置し、プロジェクト全体の進捗を一目で把握できます。 プロジェクトマネージャー — 仕様から実装の進捗を一貫して追跡し、チーム全体の状態を可視化したい方。 新機能開発を担当するエンジニア — 要件が明確でない状態から、仕様書を作りながら実装を進めたい方。 既存仕様の変更対応が多い人 — 機能追加や仕様変更時に、どの設計書・タスク・コードが影響を受けるかを把握したい方。 チームのオンボーディング担当者 — 新メンバーに仕様体系やプロジェクト構造を迅速に理解させたい方。 MUSUBI仕様駆動開発は、steering/（プロジェクトメモリ：product, tech, structure, constitution）、storage/specs/（要件定義）、storage/design/（設計）、storage/tasks/（タスク）、storage/changes/（仕様変更Delta Spec）、plans/（フェーズ計画）のディレクトリ構造で運用されます。正規フローは：(1)/sdd-requirementsで要件定義、(2)/sdd-designで設計、(3)/sdd-tasksでタスク作成、(4)/sdd-implementでテスト先行実装、(5)/sdd-validateで規約適合確認、(6)jj git pushで提出。仕様変更はmusubi-change init CHANGE-NNNで初期化、validateで検証、実装後applyで適用、archiveでアーカイブします。ギャップ検出はmusubi-gaps detect --verboseとmusubi-gaps coverageで実行。steering/features/は使用禁止です。

著者のペルソナに沿った文体をチェック：記事が55歳の個人事業主プログラマというキャラクターから逸脱していないか確認し、「AI驚き屋」ではなく淡々とした語り口に統一します。 テキスト分析ツール（Linter）で文法・表記をチェック：npx textlint コマンドを実行し、日本語の文法や冗長表現などの機械的な指摘をすべて修正。言葉遣いの不自然さを客観的に検出します。 トーンと文体の一貫性を確保：「ですます調」で統一し、AIっぽい「あなたは」「いるんです」といった表現や先回り感のある文を削除。個人の学習体験として自然に読める記事に仕上げます。 太字や構成を最適化：本当に強調すべき技術用語だけに太字を絞り、冗長な前置きを削って読者を引き込む文章構成に改善します。 Zennで技術記事を連載している個人ブロガー：記事の読みやすさや個性をプロフェッショナルなレベルに高めたい人。 自分の経験を「教える」のではなく「共有したい」ブロガー：押し付けがましくない、自然な語り口で記事を磨きたい人。 複数の記事を管理していて文体の統一に悩む著者：キャラクター設定に沿った一貫した文風を保ちたい人。 初稿は書いたが、言葉遣いや表現が自然かどうか不安な人：客観的なフィードバックで記事の完成度を上げたい人。 Zenn技術記事の校正スキルは、55歳の個人事業主プログラマという著者ペルソナ（新技術にはすぐ手を出すが煽りではなく淡々、Web系は広く浅い、ベテランの落ち着き、OSSへのリスペクト、自分のシステムの限界も認める）に基づいて記事内容をチェックします。校正重点項目は①トーン（「ですます調」統一、先回り感のない表現、AIっぽさ回避、自然な主語、淡々とした事実述べ）②冗長性（前置き削除、不要な説明削除、「調べてみると」の簡潔化）③太字の適切な使用（重要用語・本質的違い・表対比は可、ラベルや普通の名詞は不可）④記事の構成（個人の学習体験順で展開、「人に勧める」ではなく「判断を共有」）です。必須で npx textlint "記事パス" を実行してtextlint-jaの指摘をすべて修正し、防衛的表現や不要な感想を削除。実体験を入れて読者共感を促し、最後に再度Linterで検証します。

テキスト分析ツール（Linter）で文法と表記をチェック：npx textlint コマンドを実行し、日本語の文法、表記ゆれ、冗長表現、助詞の不自然さなどを機械的に指摘。すべての指摘を修正することで品質を担保します。 ドキュメント全体の文体を「ですます調」で統一：「だ・である調」を排除し、一貫した敬体で記述。読み手にやさしく、プロフェッショナルな印象のドキュメントに。 AIっぽさや不自然な表現を排除：「あなたが」「〜いるんです」といった砕けすぎた表現や、押し付けがましい断定を削除。淡々と事実を述べた自然な日本語に改善します。 太字や構成を最適化：本当に強調すべき技術用語だけに絞り、冗長な前置きや不要な感想文を削って、伝わる構成に整備します。 GitHub等でREADMEやドキュメントを公開している開発者：ドキュメントの質を高め、ユーザーの読みやすさを向上させたい人。 技術仕様書や設定ガイドを社内で共有する人：文体を統一し、誰が読んでも分かりやすいドキュメントを作りたい人。 複数人で執筆したドキュメントの表現を統一したい：チーム内の文体のゆらぎを修正し、統一感を持たせたい人。 初稿は完成したが、言葉遣いや流れが自然か不安な人：客観的な校正で、プロフェッショナルなドキュメントに仕上げたい人。 日本語Markdownドキュメントの校正スキルは、README・技術ドキュメント・ガイドなどを対象に、①トーン（「ですます調」統一、AIっぽさ回避、不自然な主語の繰り返し削除、感情表現の抑制、押し付けがましい断定の回避、仰々しい表現の排除）②冗長性（冗長な前置き削除、不要な説明削除、簡潔化）③太字（重要用語初出・本質的違い・表対比のみ、ラベルや普通の名詞は除外）④文書構成（不要な感想削除、防衛的表現回避、事実を簡潔に述べる）⑤Linter指摘対応（textlint-jaの指摘をすべて修正、「述語+コロン」パターンのAI直訳表現を避ける、markdownlintの構文問題も修正）をチェック。必須で校正前後に npx textlint "ファイルパス" を実行し、エラー0を目指します。Edit toolで修正を一度にすべて反映させます。