github-profile-authority-page

GitHub プロフィール権威性ページのスキル

目的

GitHub プロフィールを、開発者向けのランディングページに変えます。

優れたプロフィールページでは、次のことが伝わる必要があります。

1. この人は誰ですか？
2. どのような課題を解決しますか？
3. 最初に何を見ればよいですか？
4. どのような実績がありますか？
5. 今、何に取り組んでいますか？
6. 詳しい情報を読んだり、連絡したりするにはどこを見ればよいですか？

すべてを列挙することが目的ではありません。最も強い根拠を厳選して示すことが目的です。

使用するタイミング

ユーザーが次のことを依頼した場合に、このスキルを使用します。

• GitHub プロフィールの README を再設計する
• GitHub プロフィールの信頼性や印象、プロらしさを高める
• ピン留めするリポジトリを選ぶ
• プロジェクト、記事、実績、公開成果を紹介する
• GitHub の見せ方を LinkedIn、ポートフォリオ、ブログ、履歴書、求職活動に合わせる
• 多数のプロジェクトから「Start Here」セクションをまとめる
• 権威性を伝えつつ、傲慢な印象を避ける

最初にプロフィールの全体像を確認する

次を確認します。

• USERNAME/USERNAME リポジトリ
• プロフィールの README.md
• ピン留めされたリポジトリ
• 公開リポジトリとその説明
• プロフィールの自己紹介、ウェブサイト、所在地、所属組織、ソーシャルリンク
• ブログやポートフォリオへのリンク
• 最近の公開アクティビティ
• README のバッジ、統計カード、画像
• 記事一覧や RSS で生成されたブログセクションがある場合は、その内容
• プロフィールで、非公開の勤務先の成果、個人の住所、秘密情報、誤解を招く主張が公開されていないか

GitHub のメタデータを自動で読み取れない場合は、手動確認用のチェックリストを出力します。

プロフィール戦略

プロフィール README の役割は、リポジトリ README とは異なります。

リポジトリ README は、単一のプロジェクトを紹介します。 プロフィール README は、複数のプロジェクトに共通する一貫したパターンを紹介します。

プロフィールを、すべてのリポジトリを詰め込む場所にしてはいけません。対象を絞り、信頼できる強みを示す必要があります。

命名とエコシステムへの依存関係

ピン留めするリポジトリを選ぶときやプロフィールを書き換えるときは、リポジトリ名を確認します。

ピン留めされたプロジェクトの名前が弱い、境界が不明確、またはエコシステム内での位置づけに一貫性がない場合は、github-repo-product-naming を使用します。

一貫した命名体系は、プロフィールの質を高めます。たとえば、次のようになります。

ProofStack   -> public-safe career proof
AgentDesk    -> agent-ready workstation setup
SystemSmith  -> engineering methods for code, agents, and architecture

これは、次のような汎用的なリポジトリ名をピン留めするよりも効果的です。

proofstack
agentdesk
systemsmith

プロフィールではプロダクト名を示し、サブタイトルで具体的な用途を説明します。

優れたプロフィールのパターンを分析する

優れた技術プロフィールでは、次のようなブロックがよく使われます。

1. 最初の画面で強みを明確にする

一般的な形式：

# Hi, I'm <Name>

📍 <location or remote context> | <current role/wedge> | <credible anchor>

I build <category of things> for <audience/problem>. Right now I’m focused on <current focus>.

良い例：

# Hi, I'm Arthur

Junior Data Engineer building practical cloud/data workflows and agentic automation tools.

I use Python, AWS, Databricks, and browser automation to turn recurring high-friction workflows into small, reusable systems.

弱い例：

# Hi there 👋

I'm passionate about technology and always learning new things.

2. 長いリストの前に「Start Here」を置く

## Start Here を使って、訪問者におすすめの項目を 3〜6 件示します。

各項目は 1 行にまとめます。

- **[Project](link)** — concrete outcome or reason to inspect it.

より良い例：

- **[SystemSmith](link)** — reusable engineering methods for code, agents, docs, security, reviews, and architecture.

避けたい例：

- **[engineering-methods](link)** — my cool engineering docs.

3. プロジェクトのポートフォリオを分類する

「Start Here」の後で、テーマごとにプロジェクトをまとめます。

カテゴリの例：

• エージェント型 AI とブラウザー自動化
• データエンジニアリングとクラウドワークフロー
• 開発者の生産性向上
• 個人の業務管理システム
• ML／研究実装
• 執筆と事例研究

終わりのないリストは避けます。

4. 根拠を段階的に示す

公開しても問題のない、最も強い実績を示します。

根拠の例：

• 公開可能な場合は現在の職務
• 公開しているリポジトリ
• 記事や事例研究
• オープンソースへの貢献
• 学位論文や研究プロジェクト
• コンテスト
• デモ
• 公開プロジェクトの指標
• 講演やメディア掲載
• 関連する場合は資格

非公開の勤務先の指標、内部コード、非公開の顧客データ、機密プロジェクトの詳細は決して含めないでください。

5. 現在注力していること

短いセクションを使います。

## Current Focus

- Building agentic automation tools for browser-heavy workflows.
- Improving data/cloud engineering workflows with small CLIs and repeatable pipelines.
- Writing case studies about turning messy work into reusable systems.

6. 執筆セクション

記事がある場合は追加します。技術面での信頼性を示すうえでは、リポジトリ数よりも、プロジェクトに関する判断を説明する文章のほうが役立つことがよくあります。

## Writing

- **[How I cleared 100 tickets in 2 days](link)** — workflow design, automation, and operational leverage.
- **[Article title](link)** — one-line reason to read.

7. 連絡先セクション

コンパクトなリンク一覧やバッジを使います。

## Connect

[Website](...) · [LinkedIn](...) · [Blog](...) · [Email](mailto:...)

自宅の住所や個人の電話番号は公開しないでください。

推奨するプロフィール README の構成

次の構成を標準として使用します。

# Hi, I'm <Name>

<One-line role/wedge.>

<2-3 sentence positioning paragraph: what you build, for whom, with what stack, and why.>

<p align="left">
  <a href="...">Website</a> ·
  <a href="...">LinkedIn</a> ·
  <a href="...">Blog</a>
</p>

## Start Here

- **[Project 1](...)** — outcome-oriented one-liner.
- **[Project 2](...)** — outcome-oriented one-liner.
- **[Article / case study](...)** — why it matters.

## Current Focus

- ...
- ...
- ...

## Projects

### Agentic AI & Automation

- **[Repo](...)** — what it does and why it matters.

### Data Engineering & Cloud

- **[Repo](...)** — what it does and why it matters.

### Developer Productivity

- **[Repo](...)** — what it does and why it matters.

## Writing

- **[Article](...)** — one-line takeaway.

## Background

- <Public-safe credibility anchor>
- <Relevant education/thesis/competition/open-source contribution>
- <Tools/stack, if useful>

## Connect

...

ピン留めリポジトリの戦略

GitHub では最大 6 件の項目をピン留めできます。いずれも質が高い場合に限り、6 件すべてを使いましょう。

おすすめの組み合わせ：

1. 現在の最も優れた代表プロジェクト
2. プロフェッショナルな技術スタックを示す最も優れたプロジェクト
3. 自動化／開発ツールの最も優れたプロジェクト
4. 最も優れた執筆・ポートフォリオのリポジトリ、またはウェブサイト
5. 今も関連性がある場合は、以前の研究／論文／ML リポジトリのうち最も優れたもの
6. 現在のストーリーを補強する場合に限り、実験的なリポジトリを 1 件

ピン留めしないもの：

• 空のリポジトリ
• 学習記録として明示されていない、放置されたおもちゃのようなアプリ
• 非公開に見えるリポジトリ名
• README がないリポジトリ
• About の説明が曖昧なリポジトリ
• 似たようなリポジトリが多数ある場合

ピン留めしたリポジトリは、Start Here セクションと一致させましょう。

プロジェクトの一文紹介のテンプレート

次のいずれかを使いましょう。

成果を示すテンプレート

<Repo> — helps <audience> achieve <outcome> by <mechanism>.

課題から解決策へ導くテンプレート

<Repo> — turns <messy recurring problem> into <repeatable workflow/system>.

ケーススタディのテンプレート

<Repo> — case study in <skill>, showing <specific technical judgment>.

学習記録のテンプレート

<Repo> — implementation of <paper/system> to understand <concept>; archived as a learning project.

GitHub プロフィールのメタデータ確認リスト

プロフィール README の表示

プロフィール README が表示される条件：

• GitHub ユーザー名と同じ名前の公開リポジトリがある
• そのリポジトリのルートに空ではない README.md がある

プロフィールのピン留め

リポジトリ／gist を最大 6 件選びましょう。

プロフィールの自己紹介

推奨の長さ：1 文。

テンプレート：

<Data/cloud/AI engineer> building <specific kind of tools> for <specific kind of workflows>.

例：

Junior Data Engineer building practical automation systems for data, cloud, and agentic workflows.

ウェブサイト

最も強力な URL を 1 つ使いましょう：

• ポートフォリオ
• ブログ
• 現在の代表プロジェクト
• 他により適した選択肢がない場合のみ、リンク集ページ

リポジトリの説明

ピン留めするすべてのリポジトリに About の説明が必要です。「コードが含まれています」ではなく、成果を中心に説明しましょう。

トピック

ピン留めするすべてのリポジトリに、関連するトピックを設定しましょう。

機械的な監査チェック

最初の画面のチェック

• 最初の 7 行以内に名前がある。
• 最初の 10 行以内に役割／専門領域がある。
• 最初の 15 行以内に、どのような問題を解決するのかが説明されている。
• 上部付近に公開リンクが少なくとも 1 つある。
• ありきたりな「テクノロジーに情熱を注いでいます」という表現が残っていない。

キュレーションのチェック

• 長いプロジェクト一覧より前に ## Start Here がある。
• Start Here の項目数が 3～6 件である。
• Start Here の各項目に、リンクと成果を中心とした一文紹介がある。
• プロジェクトのセクションがテーマごとにまとめられている。
• 理由がない限り、各セクションの項目数が 8 件を超えていない。

命名のチェック

• ピン留めしたリポジトリ名が、製品名らしいか、意図が明確な説明的な名前である。
• 弱い名前には github-repo-product-naming のフラグが付けられている。
• 製品名とサブタイトルが一貫して使われている。
• プロフィールのプロジェクト群に、ひと目でわかるパターンがある。
• より適切な製品名がある場合、Start Here にわかりにくい内部フォルダー名を出していない。

信頼性のチェック

• 公開しても安全な、信頼性を示す要素が少なくとも 1 つある。
• 執筆記事がある場合は掲載されている。
• 現在の注力分野が明示されている。
• 主張が公開されている成果物、またはユーザー提供の事実によって裏付けられている。
• 雇用主の業務を、機密情報を含む形で説明していない。
• 実績を偽る数値、スター、受賞歴、所属、または本番環境での利用実績がない。

ピン留めしたリポジトリのチェック

• ピン留めの数が 6 件以下である。
• ピン留めしたリポジトリが Start Here のストーリーと一致している。
• ピン留めしたすべてのリポジトリに README がある。
• ピン留めしたすべてのリポジトリに役立つ About の説明がある。
• ピン留めしたすべてのリポジトリにトピックがある。
• 空または古いリポジトリは、アーカイブとして明示されている場合を除き、ピン留めされていない。

スタイルのチェック

• プロフィール全体を 30 秒以内で把握できる。
• 説明のないバッジが大量に並んでいない。
• GitHub の統計カードが多すぎない。
• ストーリーを補強する場合を除き、アニメーションで画面が煩雑になっていない。
• 自宅住所、電話番号、API キー、機密情報が写ったスクリーンショット、雇用主の機密情報がない。

出力形式

このスキルを適用する際は、以下を作成してください。

1. プロフィールの診断：現在のプロフィールが伝えている内容と、不足している内容。
2. ポジショニングの選択：提案する独自のアイデンティティ。
3. プロジェクトの命名／ピン留めに関する診断：
   • 弱いプロジェクト名
   • 提案する製品名
   • ピン留めするリポジトリの方針
4. プロフィール README：全面的な差し替え案または修正案。
5. ピン留めするリポジトリの計画：最大6件。順番と理由も示してください。
6. リポジトリのメタデータ更新：
   • ピン留めする各リポジトリの「About」の説明
   • ピン留めする各リポジトリのトピック
   • 該当する場合はホームページのURL
7. 執筆記事のセクション：選定したリンクと各記事の短い説明。
8. 安全性のための削除・伏せ字：省略または匿名化する情報。
9. 決定論的チェックリストの結果。

トーンのルール

以下を使用してください。

• 率直で、実践的かつ具体的な表現
• 控えめながらも自信のある表現
• 具体的な成果
• プロジェクトが実験的な場合は「公開ラボ」として位置付ける
• 古い学習用リポジトリは「学習アーカイブ」として位置付ける
• プロジェクト一覧の説明は短くまとめる

以下は避けてください。

• 謙遜を装った自慢の羅列
• 裏付けのない権威の主張
• 抽象的な情熱のアピール
• 絵文字の多用
• タスクを説明せずに「AI」を過剰に強調すること
• 非公開の勤務先情報を明かすこと
• 実験を本番用の製品として装うこと

Arthur 向けプロフィールの既定の方向性

Arthur Zakirov のプロフィールに取り組む場合、より新しい情報によって覆されない限り、以下を既定のストーリーとして使用してください。

# Hi, I'm Arthur

Junior Data Engineer building practical data/cloud workflows and agentic automation tools.

I work with Python, AWS, Databricks, and automation-heavy developer workflows. My public GitHub is a lab for turning recurring friction — apartment search, profile/resume workflows, research, personal operations, and developer tooling — into small, reusable systems.

推奨するセクションのテーマ：

• エージェント型 AI とブラウザー自動化
• データエンジニアリングとクラウドワークフロー
• 開発者の生産性
• 個人の業務システム
• ML／研究アーカイブ
• 執筆／事例研究

公開しても問題のない既定の一文：

This GitHub contains public personal projects and learning work. It does not represent private employer code.

優先するエコシステム名：

ProofStack   -> career proof and public-safe positioning
AgentDesk    -> machine and AI-agent workstation setup
SystemSmith  -> engineering methods for code, agents, and architecture

Arthur 向けのピン留めリポジトリ選定基準：

1. ProofStack、または現在のキャリア／プロフィール自動化リポジトリの中で最も優れたもの
2. AgentDesk、またはセットアップ／ワークステーション／エージェント環境リポジトリの中で最も優れたもの
3. SystemSmith、またはエンジニアリング手法を扱うリポジトリの中で最も優れたもの
4. 執筆／ブログ／ポートフォリオのリポジトリ
5. データ／クラウドエンジニアリングのリポジトリを1件
6. 十分に整っている場合は、専門性の深さを示すために、以前の ML／卒業論文／研究リポジトリを1件

「近日公開」と明記し、充実した README で裏付けられている場合を除き、内容のないプレースホルダーリポジトリはピン留めしないでください。