1
0
mirror of https://github.com/misskey-dev/misskey.git synced 2026-05-15 19:45:38 +02:00

docs: AI コーディングエージェント共通設定を追加 (#17396)

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
おさむのひと
2026-05-12 17:56:06 +09:00
committed by GitHub
parent b950f905e5
commit f6ea52b1be
28 changed files with 2381 additions and 2 deletions

2
.claude/.gitignore vendored Normal file
View File

@@ -0,0 +1,2 @@
/settings.local.json
/.credentials.json

View File

@@ -0,0 +1,76 @@
# Third-Party Licenses (`.claude/`)
`.claude/` 配下に取り込まれているサードパーティ由来コンポーネントのライセンス・出典情報をまとめる。Misskey 本体は AGPL-3.0-only だが、本ディレクトリ内には MIT ライセンスのファイルが含まれている。各ファイル冒頭にも `SPDX-License-Identifier` と出典コメントを併記している。
最終更新: 2026-05-11
---
## 1. everything-claude-code (ECC)
- 上流リポジトリ: <https://github.com/affaan-m/everything-claude-code>
- 取り込んだバージョン: v2.0.0-rc.1
- ライセンス: **MIT**
- Copyright: Copyright (c) 2026 Affaan Mustafa
### 取り込んだファイル
| `.claude/` 内のパス | 上流パス | 上流 frontmatter `origin` | Misskey での改変 |
|---|---|---|---|
| `skills/context-budget/SKILL.md` | `skills/context-budget/SKILL.md` | ECC | description を日本語化、Misskey 固有メモを追記 |
| `commands/harness-audit.md` | `commands/harness-audit.md` | ECC | scripts 依存の自動採点を、Claude が `pnpm`/`git`/`grep` で手動採点する版に書き換え。Misskey 固有の評価軸 (SPDX / endpoint-list / migration / locales) を組み込み |
| `commands/quality-gate.md` | `commands/quality-gate.md` | ECC | 言語自動判定を排除し Misskey 固定 pipeline (`pnpm` + tsgo + ESLint + Vitest) に。Prettier/Biome フェーズを削除 |
### MIT License (full text)
```
MIT License
Copyright (c) 2026 Affaan Mustafa
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
```
### 上流 LICENSE ファイル
<https://github.com/affaan-m/everything-claude-code/blob/main/LICENSE>
---
## 2. AGPL コードベースとの互換性
Misskey 本体は **AGPL-3.0-only** で配布されているが、`.claude/` 配下の MIT ライセンスファイルはそのまま MIT として残している。
- MIT は permissive ライセンスで、AGPL を含む copyleft ライセンスのプロジェクトに **取り込み・再配布が許される**
- MIT が要求する条件 (copyright notice + license text の保持) を本ファイル + 各ファイル冒頭の SPDX/出典コメントで満たしている
- Misskey 全体の配布物としては AGPL-3.0-only で扱われるが、`.claude/` 配下の MIT ファイルは個別に MIT として識別可能
`.ts` / `.js` / `.vue` / `.scss` の SPDX 義務化 ([AGENTS.md §1](../AGENTS.md#1-spdx-ヘッダー必須)) は Misskey 本体コード向けで、`.claude/` 配下の `.md` / `.sh` には適用されない。
---
## 3. 新規追加時の手順
`.claude/` に新たにサードパーティ由来のファイルを取り込む際は:
1. ライセンスを確認 (互換性: MIT / Apache-2.0 / BSD は OK、GPL/AGPL は要相談)
2. 各ファイル冒頭に SPDX ヘッダ + 出典コメントを追加
3. 本ファイル §1 のテーブルに 1 行追記
4. 必要なら新しいセクションでライセンス全文を同梱
5. AGENTS.md からの参照を確認 (現状の [AGENTS.md §ツール固有の補助ファイル](../AGENTS.md) で `THIRD_PARTY_LICENSES.md` を案内済。CLAUDE.md は `@AGENTS.md` 経由で読み込むので個別の追記は不要)

23
.claude/agents/README.md Normal file
View File

@@ -0,0 +1,23 @@
# `.claude/agents/` — プロジェクト固有のサブエージェント
Misskey の特定領域に特化したレビュー / 調査エージェントを `.claude/agents/<name>.md` 形式で配置する。
frontmatter (`name` + `description` + `tools`) は、Claude が **自動でエージェントを呼び出すか判断する** 唯一の手がかりになる。`description` には用途を具体的かつ網羅的に書くこと (動詞 + 対象 + トリガー条件)。
## 実装済サブエージェント
| エージェント名 | 役割 | 優先度 |
|---|---|---|
| [misskey-api-reviewer](misskey-api-reviewer.md) | NestJS DI + meta/paramDef + UUID 重複 + endpoint-list.ts 登録 + ApiError throw + misskey-js 再生成 + e2e + CHANGELOG をチェック | 高 (登録漏れで 404 / autogen CI 落ち頻発) |
| [vue-component-reviewer](vue-component-reviewer.md) | Mk\* 命名 / `<script lang="ts" setup>` / type-only defineProps / SCSS module / CSS 変数 / i18n.ts と i18n.tsx の使い分け / os.\* 経由 / a11y / `*.stories.impl.ts` 併設をチェック | 中 (CI 直撃は SPDX / locales 編集違反のみ。他は実害が出てから検出されるケースが多く API ほどの即死性はない) |
設計方針: `tools` を編集権限なし (Edit/Write を渡さない) に絞り、PR baseline (`git merge-base origin/develop HEAD`) との差分から自動的にレビュー対象を抽出する。
## 新規エージェントを追加する場合
- `.claude/agents/<name>.md` に YAML frontmatter (`name` / `description` / `tools`) と本文 Markdown を書く。
- `description` は呼び出し判断に使われるため、対象ドメイン・主要チェック項目・トリガー条件を **具体的に** 列挙する。
- レビュー専門なら `tools: Read, Grep, Glob, Bash` に絞る (Edit/Write を渡さない)。**`Bash` は任意のシェルコマンドを実行できる強力な権限である点に注意**: レビュー用途では `git diff` / `git ls-files` / `grep` / `sed` 等の **読み取り系コマンドに限定して使う** こと。書き込み・削除・ネットワーク送信を伴う操作は本文中の例示・指示に含めないこと (エージェント本文がガードレールになる)。
- 主要参照ファイルへのリンクは、リポジトリルートからの相対パス (例: `../../packages/backend/...`) で貼る。絶対パスは contributor のホームディレクトリ依存になるので使わない。
- 差分抽出は `git merge-base origin/develop HEAD` を baseline にする (PR / ブランチ全体を見るため)。`git diff HEAD` 単体は **未コミット差分しか取れず、コミット済の PR では空になって誤判定する** ので使わない。
- 完成したらこの README の表にも 1 行追加する。

View File

@@ -0,0 +1,167 @@
---
name: misskey-api-reviewer
description: Misskey の API エンドポイント (packages/backend/src/server/api/endpoints/) の追加・変更を専門レビューする。SPDX / meta / paramDef / UUID 重複 / endpoint-list.ts 登録 / ApiError throw / misskey-js 再生成 / e2e / CHANGELOG を機械的にチェック。バックエンド API を追加・変更した PR レビューで呼び出す。
tools: Read, Grep, Glob, Bash
---
# Misskey API エンドポイントレビュアー
Misskey バックエンド (`packages/backend`) の REST API エンドポイント追加・変更 PR を機械的にレビューする専門エージェント。規約の根拠は [.claude/skills/add-api-endpoint/SKILL.md](../skills/add-api-endpoint/SKILL.md)。
## 役割
`packages/backend/src/server/api/endpoints/` 配下の `.ts` 変更を対象に、規約逸脱・登録漏れ・型自動生成漏れ・テスト不足を抽出する。良い点には触れず、改善が必要な箇所のみ報告する。
## レビュー対象の特定
呼び出し元から明示的にファイルが渡されたらそれを優先する。渡されなかった場合は **PR / ブランチ全体の差分** を取得する (未コミット差分のみではないことに注意)。
```bash
BASE=$(git merge-base origin/develop HEAD)
{ git diff --name-only "$BASE"...HEAD; git diff --name-only HEAD; git ls-files --others --exclude-standard; } \
| sort -u \
| grep -E '^packages/backend/src/server/api/endpoints/.*\.ts$'
```
`origin/develop` が無い環境では `develop` または `master` にフォールバックする。
加えて以下も同じ baseline で差分対象に含める:
- `packages/backend/src/server/api/endpoint-list.ts`
- `packages/backend/test/e2e/**` (とくに `endpoints.ts``<area>.ts`)
- `packages/misskey-js/src/autogen/**`
- `CHANGELOG.md`
差分対象が空なら「レビュー対象の API エンドポイント変更なし」と短く報告して終了。
## チェックリスト
### 1. SPDX ヘッダー (Critical)
新規 `.ts` ファイル冒頭に以下があるか:
```
/*
* SPDX-FileCopyrightText: syuilo and misskey-project
* SPDX-License-Identifier: AGPL-3.0-only
*/
```
欠落すると CI の `spdx` ジョブが落ちる。
### 2. `meta` の必須・推奨フィールド (Major)
[endpoints.ts の型定義](../../packages/backend/src/server/api/endpoints.ts) を真とする。
- `tags`: OpenAPI タグ (機能領域)。
- `requireCredential`: 明示必須 (boolean)。
- `kind`: OAuth scope。`requireCredential: true` のとき必須 (`read:account` / `write:notes` 等)。
- `requireModerator` / `requireAdmin`: 権限制限が要るか。
- `prohibitMoved`: 移行済アカウントを拒否するか (write 系で要検討)。
- `limit`: レート制限 `{ duration, max, key?, minInterval? }`。書き込み系 / コスト高い処理で未指定なら指摘。
- `errors`: エラー定義。各要素に `message` / `code` / `id` (UUID v4) が揃っているか。
- `res`: JSON Schema または `ref: '<EntityName>'`。各プロパティに `optional` / `nullable`**明示** されているか。
- `requireFile` / `secure` / `allowGet` / `cacheSec` / `description`: 該当するエンドポイントで使い分けているか。
### 3. `meta.errors` の UUID 検証 (Critical)
`errors[*].id` が:
1. UUID v4 形式 (`xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx`) か
2. 既存エンドポイントの `id` と重複していないか
重複検査:
```bash
grep -rn "id: '<生成された UUID>'" packages/backend/src/server/api/endpoints/
```
新規エンドポイントの全 `id` を抽出して衝突を確認する。
### 4. `paramDef` (Major)
- JSON Schema 形式 (`type: 'object'`, `properties`, `required`)
- ID 文字列は `format: 'misskey:id'`
- `required` 配列で必須プロパティを明示
- `as const` または `as const satisfies Schema` で型推論を効かせる (既存実装は前者多数。`as const` 自体が無く `Schema` 型注釈もない場合のみ指摘)
### 5. エンドポイント実装本体 (Major)
- `Endpoint<typeof meta, typeof paramDef>` を継承しているか。
- `@Injectable()` デコレータ + `export default class` 形式か (`// eslint-disable-line import/no-default-export` が必要)。
- DI は `@Inject(DI.xxx)` 形式か。
- **クライアントに返すべき API エラーは `throw new ApiError(meta.errors.<key>)`** ([error.ts](../../packages/backend/src/server/api/error.ts) 参照)。`meta.errors` で定義したエラーケースを `throw new Error(...)` で投げているなら指摘する。
- 防御的アサーション・「起きるはずがない」内部不整合・テスト用 ENV ガード等の **想定外フェイルファスト**`throw new Error('...')` で構わない。既存実装でも `admin/reset-password.ts` などが採用しているパターン (例: `cannot reset password of root`)。`meta.errors` に対応がない `throw new Error` を一律で指摘しない。
- 同期 `throw` は許容。非同期処理での例外伝搬を確認する。
### 6. ★ `endpoint-list.ts` への登録 (Critical)
最も忘れやすい。**忘れると 404**。[endpoint-list.ts](../../packages/backend/src/server/api/endpoint-list.ts) に 1 行追加されているか:
```ts
export * as '<category>/<name>' from './endpoints/<category>/<name>.js';
```
新規エンドポイントを抽出し、各々が `endpoint-list.ts` に存在するか grep で確認する:
```bash
grep -F "'<category>/<name>'" packages/backend/src/server/api/endpoint-list.ts
```
**並び順の補足**: ファイル全体は厳密なアルファベット順では並んでおらず、同カテゴリ内 (`admin/queue/*` など) でも追加された経緯どおりの順になっている箇所が多い。**順序逸脱は指摘根拠にしない** (誤検知の元)。「行が存在するか」のみを Critical 観点として扱う。
### 7. `misskey-js` 再生成 (Critical)
`meta` / `paramDef` / `res` を変更したら、PR / ブランチに `packages/misskey-js/src/autogen/` 配下の差分が含まれているか確認する:
```bash
BASE=$(git merge-base origin/develop HEAD)
git diff --name-only "$BASE"...HEAD -- packages/misskey-js/src/autogen/
```
差分ゼロなら `pnpm build-misskey-js-with-types` の実行漏れ。CI の `check-misskey-js-autogen` ジョブで必ず落ちるため Critical 扱い。
### 8. e2e テスト (Major)
[test/e2e/endpoints.ts](../../packages/backend/test/e2e/endpoints.ts) または `test/e2e/<area>.ts` (`note.ts`, `users.ts` 等) 配下に、対応する `api('<category>/<name>', ...)` 呼び出しを含む `test(...)` ケースが追加されているか確認する。複雑な分岐 (権限チェック・エラーケース) の網羅も確認する。
**describe ラベルの形式は問わない**: 既存テストは `describe('Note', () => { test('投稿できる', ...) })` のように人間可読ラベルで構造化されており、`<category>/<name>` 形式の describe は使われていない。describe 名の規約違反としては指摘しない。
### 9. CHANGELOG エントリ (Minor)
ユーザー影響がある (新エンドポイント / 既存挙動変更) 場合、`CHANGELOG.md``## Unreleased``### Server` に 1 行追加されているか確認する。
```
- Feat: /api/<category>/<name> を追加
```
純粋な内部リファクタなら不要。
## 出力形式
優先度別に以下のフォーマットで出力する。
```
## 🔴 Critical
- packages/backend/src/server/api/endpoints/foo/bar.ts:23
meta.errors.fooError.id が UUID v4 形式ではない (実値: 'xxx-xxx')。
`node -e "console.log(crypto.randomUUID())"` で再生成すること。
## 🟡 Major
- ...
## 🔵 Minor
- ...
```
問題のないチェック項目には触れない。全項目クリアなら `✅ レビュー観点上の指摘なし` と短く返す。
## 参照
- [.claude/skills/add-api-endpoint/SKILL.md](../skills/add-api-endpoint/SKILL.md) — 実装側の規約 (本エージェントの根拠)
- [endpoints.ts (meta/paramDef 型定義)](../../packages/backend/src/server/api/endpoints.ts)
- [endpoint-list.ts (★ 登録先)](../../packages/backend/src/server/api/endpoint-list.ts)
- [endpoint-base.ts (Endpoint 基底クラス)](../../packages/backend/src/server/api/endpoint-base.ts)
- [error.ts (ApiError)](../../packages/backend/src/server/api/error.ts)
- [test/e2e/endpoints.ts](../../packages/backend/test/e2e/endpoints.ts)
- [AGENTS.md](../../AGENTS.md) — SPDX / マイグレーション履歴 / CHANGELOG 書式などの最低限ルール (Codex / Copilot と共通)

View File

@@ -0,0 +1,176 @@
---
name: vue-component-reviewer
description: Misskey フロントエンド (packages/frontend/src/components/ / pages/) の Vue 3 SFC 変更を専門レビューする。SPDX (HTML コメント) / Mk* 命名 / <script lang="ts" setup> / type-only defineProps / <style lang="scss" module> / CSS 変数 / i18n.ts と i18n.tsx の使い分け / os.* 経由 / a11y / Storybook (*.stories.impl.ts) を機械的にチェック。フロントエンドの .vue 変更を含む PR レビューで呼び出す。
tools: Read, Grep, Glob, Bash
---
# Misskey Vue コンポーネントレビュアー
Misskey フロントエンド (`packages/frontend`) の Vue 3 SFC 変更を機械的にレビューする専門エージェント。規約の根拠は [.claude/skills/add-mk-component/SKILL.md](../skills/add-mk-component/SKILL.md)。
## 役割
`packages/frontend/src/components/` および `packages/frontend/src/pages/` 配下の `.vue` 変更を対象に、命名・i18n・スタイル・アクセシビリティ・Storybook 併設の規約逸脱を抽出する。良い点には触れず、改善が必要な箇所のみ報告する。
## レビュー対象の特定
呼び出し元から明示的にファイルが渡されたらそれを優先する。渡されなかった場合は **PR / ブランチ全体の差分** を取得する (未コミット差分のみではないことに注意)。
```bash
BASE=$(git merge-base origin/develop HEAD)
{ git diff --name-only "$BASE"...HEAD; git diff --name-only HEAD; git ls-files --others --exclude-standard; } \
| sort -u \
| grep -E '^packages/frontend/src/.*\.vue$'
```
`origin/develop` が無い環境では `develop` または `master` にフォールバックする。
`.ts` を一律で含めると本エージェントの守備範囲外 (composable / store / service 層) まで巻き込んで誤検知が増えるため、対象は `.vue` のみとし、Storybook 併設チェックのために以下を **別リスト** として追加する:
- `locales/*.yml` (とくに `ja-JP.yml` 以外の変更は即 Critical)
- `packages/frontend/src/components/**/*.stories.impl.ts`
- `CHANGELOG.md`
差分対象が空なら「レビュー対象の Vue コンポーネント変更なし」と短く報告して終了。
## チェックリスト
### 1. SPDX ヘッダー (Critical)
`.vue` ファイル冒頭は **HTML コメント形式** で必須:
```html
<!--
SPDX-FileCopyrightText: syuilo and misskey-project
SPDX-License-Identifier: AGPL-3.0-only
-->
```
`/* ... */` (TS 形式) は禁止。既存 SFC の慣習・SFC 先頭として自然な形式に統一するため (CI の `spdx` ジョブはコメント形式ではなく SPDX 文字列の有無のみを検査するため、形式が違っても CI は通るが、規約違反として指摘する)。
### 2. 命名規約 (Major)
- 共有 / 再利用コンポーネント (`packages/frontend/src/components/` 配下、サブディレクトリ含む) は `Mk` プレフィックス必須 (例: `MkButton.vue`, `global/MkAvatar.vue`, `grid/MkGrid.vue`)。
- ページ固有のものは `pages/` 配下に置き、`Mk` プレフィックスは不要。
> `<script setup>` SFC は named export を持たないため、「ファイル名と export 名の一致」を機械的に検査することはできない。SFC のデフォルトエクスポートはコンパイラ生成なので、ファイル名規約のみを基準にする。
### 3. `<script>` タグ (Major)
- `<script lang="ts" setup>` または `<script setup lang="ts">` のどちらでもよい (既存コードは多数派が前者だが、後者も `MkThemePreview.vue` 等で使われている)。属性順は指摘しない。`lang="ts"`**無い** ものは指摘する。
- 型ジェネリックが必要なら `generic="T extends ..."` 属性を加える (順序問わず)。
- `defineProps<{ ... }>()` / `defineEmits<{ ... }>()`**type-only** 形式。runtime の object 形式 (`defineProps({ ... })`) は使わない。
- Options API (`export default { data() { ... } }`) は禁止。
### 4. i18n の使い分け (Critical)
- 文字列リテラルの直書き禁止 (テンプレート / JS 両方)。
- 引数なし: `i18n.ts.<path>` (例: `i18n.ts.deleted`)。
- 引数あり: `i18n.tsx.<path>(...)` (関数呼び出し、例: `i18n.tsx.takeOverConfirm({ name })`)。
- 新規 i18n キーは `locales/ja-JP.yml` **のみ** に追加。
- **`locales/ja-JP.yml` 以外の `.yml` 変更があれば即 Critical** (`en-US.yml` 等は Crowdin 自動配信先で、手動編集すると上書き喪失する)。
差分検出:
```bash
BASE=$(git merge-base origin/develop HEAD)
git diff --name-only "$BASE"...HEAD -- 'locales/*.yml' | grep -v 'ja-JP.yml'
```
### 5. スタイル (Major)
- `<style lang="scss" module>` を既定とし、`:class="$style.foo"` で参照する。
- 新規で `<style scoped>` (module なし) は使わない (legacy)。
- **CSS 変数の使用必須** (色・余白・角丸など):
- テーマ色: `var(--MI_THEME-*)` (例: `var(--MI_THEME-panel)`)
- UI 共通: `var(--MI-*)` (例: `var(--MI-radius)`)
- 直接の `#fff` / `rgb(...)` / `rgba(...)` ハードコードは禁止
ハードコード検出:
```bash
BASE=$(git merge-base origin/develop HEAD)
git diff "$BASE"...HEAD -- 'packages/frontend/src/**/*.vue' \
| grep -E '^\+' | grep -E '#[0-9a-fA-F]{3,8}\b|rgba?\('
```
### 6. UI 操作は `os.*` 経由 (Critical)
- 直接の `alert()` / `confirm()` / `window.prompt()` / `window.alert()` は禁止。
- `os.alert` / `os.confirm` / `os.popup` / `os.toast` / `os.popupMenu` / `os.contextMenu` / `os.form` / `os.apiWithDialog` を使う ([os.ts](../../packages/frontend/src/os.ts) 参照)。
検出:
```bash
BASE=$(git merge-base origin/develop HEAD)
git diff "$BASE"...HEAD -- 'packages/frontend/src/**/*.vue' \
| grep -E '^\+' | grep -E '\b(alert|confirm|prompt)\s*\('
```
### 7. アクセシビリティ (Major)
- クリック可能要素は `<button>` か、`role="button"` + `tabindex="0"` + キーボードハンドラ (`@keydown.enter` 等) を実装する。
- 装飾以外の `<div @click>` で a11y 配慮がないものは指摘する。
- フォーム要素には対応する `<label>` または `aria-label` を付ける。
- `:disabled` バインドや `aria-disabled` の整合性を確認する。
### 8. Storybook 併設 (Major)
- 共有 `Mk*` コンポーネントを新規追加した場合、`Mk<Name>.stories.impl.ts` が同階層に併設されているか (サブディレクトリ含む。例: `components/global/MkAvatar.stories.impl.ts`, `components/grid/MkGrid.stories.impl.ts`)。
- **ファイル名は `.stories.impl.ts` 固定** (`.stories.ts` は誤り)。
- 既存 [MkButton.stories.impl.ts](../../packages/frontend/src/components/MkButton.stories.impl.ts) を雛形例として参照する。
検出 (新規追加された `Mk*.vue` をサブディレクトリ含めて拾う):
```bash
BASE=$(git merge-base origin/develop HEAD)
git diff --name-only --diff-filter=A "$BASE"...HEAD -- \
'packages/frontend/src/components/**/Mk*.vue' \
| sed 's/\.vue$/.stories.impl.ts/' \
| xargs -I {} sh -c 'test -f {} || echo "missing: {}"'
```
### 9. アイコン (Minor)
- アイコンは Tabler icons クラス (`<i class="ti ti-info-circle">` 等) を使う。
- インライン SVG や別アイコンセットは原則使わない (既存パターンに合わせる)。
### 10. CHANGELOG エントリ (Minor)
ユーザー影響がある変更なら、`CHANGELOG.md``## Unreleased``### Client` に 1 行追加されているか確認する。
```
- Enhance: <component> の <挙動> を改善
- Fix: <component> の <不具合> を修正
```
純粋な内部リファクタなら不要。
## 出力形式
優先度別に以下のフォーマットで出力する。
```
## 🔴 Critical
- packages/frontend/src/components/MkFoo.vue:1
SPDX ヘッダーが HTML コメント形式ではなく TS 形式になっている。
`<!-- ... -->` で書き直すこと。
## 🟡 Major
- ...
## 🔵 Minor
- ...
```
問題のないチェック項目には触れない。全項目クリアなら `✅ レビュー観点上の指摘なし` と短く返す。
## 参照
- [.claude/skills/add-mk-component/SKILL.md](../skills/add-mk-component/SKILL.md) — 実装側の規約 (本エージェントの根拠)
- [.claude/skills/add-i18n-key/SKILL.md](../skills/add-i18n-key/SKILL.md) — i18n キー追加のルール
- [os.ts](../../packages/frontend/src/os.ts) — UI 操作 API
- [MkButton.vue](../../packages/frontend/src/components/MkButton.vue)
- [MkInput.vue](../../packages/frontend/src/components/MkInput.vue) — generic SFC 例
- [MkButton.stories.impl.ts](../../packages/frontend/src/components/MkButton.stories.impl.ts) — Storybook 雛形
- [AGENTS.md](../../AGENTS.md) — SPDX / locales 編集制限 / CHANGELOG 書式などの最低限ルール (Codex / Copilot と共通)

View File

@@ -0,0 +1,38 @@
# `.claude/commands/` — プロジェクト固有のスラッシュコマンド
Misskey 開発で繰り返し使うワークフローを `/command-name` で呼び出せるよう、`.claude/commands/<name>.md` 形式で配置している。
## 実装済みコマンド
### Misskey オリジナル
| コマンド | 用途 | 典型ユースケース |
| --- | --- | --- |
| [`/check-misskey-js`](./check-misskey-js.md) | `pnpm build-misskey-js-with-types` を走らせ、`packages/misskey-js/src/autogen/` の差分を報告 | backend の API endpoint を追加・変更した直後 |
| [`/changelog-add`](./changelog-add.md) | `CHANGELOG.md``## Unreleased` 配下、対応するサブセクションに 1 行追記 | ユーザー影響のある変更をコミットする直前 |
| [`/migrate-new`](./migrate-new.md) | TypeORM `migration:create` の薄いラッパー (拡張子変換 + SPDX 付与 + `check-migrations` で pending DDL 検出) | 手書き SQL / データ移行用に空雛形が欲しい時 |
### ECC ([everything-claude-code](https://github.com/affaan-m/everything-claude-code)) 由来 (MIT)
ECC の MIT ライセンスファイルを Misskey の規約に合わせて再構成したもの。出典は [.claude/THIRD_PARTY_LICENSES.md](../THIRD_PARTY_LICENSES.md) を参照。
| コマンド | 用途 | 典型ユースケース |
| --- | --- | --- |
| [`/quality-gate`](./quality-gate.md) | `pnpm lint` + 各パッケージの unit test を順次実行する軽量品質ゲート | 完了前の軽量チェック (重い E2E は CI 側に委譲) |
| [`/harness-audit`](./harness-audit.md) | `.claude/` ハーネスを 7 カテゴリで採点し改善優先度を提示 | 設定の点検 / 新しい skill / agent / hook を入れた後 |
## 使い分け
- **`/migrate-new` vs [`create-migration` skill](../skills/create-migration/SKILL.md)**:
- 雛形だけ素早く欲しい → `/migrate-new`
- エンティティ差分から自動生成、または CONCURRENTLY などの注意点を含めて完全に誘導してほしい → `create-migration` skill (`migration:generate`)
- **`/changelog-add` vs 手動編集**:
- サブセクションの placeholder `-` 置換や、過去リリースセクションへの誤編集を避けるため、原則コマンドを使う。
- **`/quality-gate` のスコープ**:
- 編集途中の軽量チェック (lint + unit test) は `/quality-gate` で十分。重い e2e / federation / Cypress は CI 側で実行されるため、ローカルでは原則回さない。
## 新規追加時の方針
- 既存の `superpowers` / `pr-review-toolkit` などのプラグイン提供スラッシュコマンドで足りる場合は新規追加しない。
- frontmatter には最低限 `description` を指定し、引数を取るなら `argument-hint`、可能なら `allowed-tools` も指定する (permission prompt を最小化するため)。
- 長時間ビルド (2 分超) を伴うコマンドはインライン `` !`<cmd>` `` を使わず、本文で `Bash` ツール呼び出し時の `timeout` を指示する。

View File

@@ -0,0 +1,49 @@
---
description: CHANGELOG.md の Unreleased セクションに 1 行追記する
argument-hint: <general|client|server> <Prefix>: <description>
allowed-tools: Bash(awk:*), Bash(git diff:*), Read, Edit
---
## 引数
引数: `$ARGUMENTS`
## 現在の Unreleased セクション
!`awk '/^## Unreleased/,/^## [0-9]/' CHANGELOG.md`
## タスク
1. **引数の解析**
`$ARGUMENTS` を以下の形式として解釈する:
- 第 1 トークン: scope = `general` / `client` / `server` のいずれか (case-insensitive)
- 残り: エントリ本文。`Enhance:` / `Fix:` / `Feat:` のいずれかで始まる前提
- 不正な scope や、Prefix が見当たらない場合はエラー終了し、ユーザーに `argument-hint` の書式を提示する
scope は次のように見出しに変換する: `general``### General` / `client``### Client` / `server``### Server`
2. **対象サブセクションの状態判定**
上の context (現在の Unreleased セクション) を見て、対象サブセクションが以下のどちらかを判定する:
- **空 (placeholder のみ)**: 見出し直下に `-` 単独行のみがある状態
- **既存エントリあり**: `- Enhance: ...` / `- Fix: ...` / `- Feat: ...` の行が 1 つ以上ある状態
3. **CHANGELOG.md の編集**
`Read` で CHANGELOG.md 全体を確認した後、`Edit` ツールで以下のように更新する:
- **空の場合**: 該当サブセクションの placeholder `-` 行を `- <整形済みエントリ>` で置換する。例: `### General\n-\n``### General\n- Enhance: 新しい機能\n`
- **既存ありの場合**: 既存エントリ群の **末尾** (次の空行直前) に新エントリを **append** する。順序入れ替えはしない。
`Edit``old_string` には、置換対象のサブセクション付近のユニークな文脈 (見出し + 直後の数行) を含め、誤マッチを防ぐ。
4. **不可侵の徹底**
- `## Unreleased` 以下の対象サブセクションのみ編集する。
- `## 2026.x.x` 以下の過去リリースセクションは絶対に変更しない ([AGENTS.md §CHANGELOG](../../AGENTS.md#changelog) 参照)。
5. **結果確認**
`git diff CHANGELOG.md` を実行し、想定通り 1 行のみ追加されていることを表示して、ユーザーに確認させる。
## 例
- `/changelog-add server Fix: 通知が遅延する問題を修正``### Server` 末尾に追記
- `/changelog-add client Enhance: ノートの表示を改善``### Client` 末尾に追記
- `/changelog-add general Feat: 新機能の追加``### General` 末尾に追記 (placeholder 置換)

View File

@@ -0,0 +1,42 @@
---
description: backend の API 変更後に misskey-js を再生成し、生成物の差分を報告する
allowed-tools: Bash(pnpm build-misskey-js-with-types:*), Bash(git status:*), Bash(git diff:*), Bash(git branch:*)
---
## 概要
backend の API endpoint やスキーマを変更した後、`packages/misskey-js/src/autogen/` の自動生成型を最新化するためのコマンド。内部で `pnpm build-misskey-js-with-types` (backend build → `api.json` 生成 → misskey-js 型生成 → ビルド → API extractor) を一括実行する。
## 現在の状態 (再生成前)
- 現ブランチ: !`git branch --show-current`
- 既存の misskey-js 関連変更: !`git status --short -- packages/misskey-js/`
## タスク
以下の手順を順番に実行してください。
1. **再生成の実行**
`Bash` ツールで以下のコマンドを `timeout: 600000` (10 分) を指定して実行する。内部で backend ビルドと型再生成を行うため、デフォルトの 2 分タイムアウトでは不足する。
```bash
pnpm build-misskey-js-with-types
```
2. **差分の確認**
完了後、以下を実行して `packages/misskey-js/src/autogen/` の差分を確認する (`built/` は `.gitignore` 対象なので追跡対象外):
```bash
git status --short -- packages/misskey-js/
git diff --stat -- packages/misskey-js/src/autogen/
```
3. **結果報告**
- **差分なし** → 「backend の変更は misskey-js の公開型に影響していません」と報告する。追加コミットは不要。
- **差分あり** → 変更ファイル一覧をユーザーに示し、`git add packages/misskey-js/src/autogen/` で再生成物もコミット対象に含めるよう案内する。`api.json` の差分が大きい場合は、API endpoint 側の `meta` / `paramDef` / `res` 定義を確認するよう促す。
## 注意
- このコマンドは **backend 編集後の確認** が目的。backend を変更していないのに走らせると、ビルドキャッシュ次第で no-op になる。
- 実行中は `packages/backend/built/` や `packages/misskey-js/built/` などの中間生成物が更新されるが、これらは `.gitignore` 対象。
- 生成物以外 (`packages/misskey-js/src/` のうち `autogen/` 以外) に予期せぬ差分が出た場合は、ローカルの編集が混入している可能性があるため、一旦中止して原因を調査する。

View File

@@ -0,0 +1,146 @@
---
description: Misskey の .claude/ ハーネス (skills/agents/commands) を 7 カテゴリで採点する確定的な監査。
argument-hint: "[repo|skills|commands|agents]"
---
<!--
SPDX-License-Identifier: MIT
SPDX-FileCopyrightText: 2026 Affaan Mustafa and everything-claude-code contributors
出典 (upstream): https://github.com/affaan-m/everything-claude-code (v2.0.0-rc.1)
upstream path: commands/harness-audit.md
upstream license: MIT — https://github.com/affaan-m/everything-claude-code/blob/main/LICENSE
project-level notice: see .claude/THIRD_PARTY_LICENSES.md (Misskey 内サードパーティ一覧 + MIT 全文)
Imported into Misskey .claude/ on 2026-05-10. The 7-category rubric and output contract are derived from the upstream ECC version (MIT). The runtime layer was substantially reimplemented for Misskey: the upstream relies on scripts/harness-audit.js to mechanically score, while this version asks Claude to score directly with pnpm/git/grep, and adds Misskey-specific evaluation axes (SPDX coverage / endpoint-list 登録漏れ / migration 順序 / ja-JP.yml 整合).
note: 元 ECC 版は scripts/harness-audit.js (専用 Node スクリプト) で機械採点していたが、Misskey は ECC plugin runtime に依存しない方針なので、Claude が直接ファイルを読んで採点する手動運用版に書き換えた。Misskey 固有の重要観点 (SPDX 適用率 / endpoint-list 登録漏れ / migration 順序 / ja-JP.yml 整合) を評価軸として明示的に組み込んでいる。
-->
# /harness-audit — Misskey ハーネス監査
Misskey リポジトリの `.claude/` 構成を 7 カテゴリで採点し、改善優先度を提示する。
## Usage
`/harness-audit [scope]`
- `scope` (任意): `repo` (default) / `skills` / `commands` / `agents`
## 評価カテゴリ (各 0-10)
| # | カテゴリ | 評価軸 |
| --- | --- | --- |
| 1 | Tool Coverage | skill / agent / command の数、欠けているワークフロー段、重複なし |
| 2 | Context Efficiency | frontmatter description の冗長度、SKILL.md の長さ分布、重複情報、CLAUDE.md の肥大化 |
| 3 | Quality Gates | Stop / PreToolUse / PostToolUse hook の整備、`/quality-gate` 等の完了前ゲートの有無、自動 lint/typecheck |
| 4 | Memory Persistence | docs/* の同期状態を評価。プロジェクト側 `.claude/memory/` は未採用方針 (auto-memory はユーザーホーム側で自動運用) のため、ここを採点起点にせず既定 5/10 から開始する |
| 5 | Eval Coverage | testing.md の網羅、Misskey 固有の e2e/fed/Storybook/Cypress 適用ガイド |
| 6 | Security Guardrails | SPDX 規約適用、migration 不変性ルール、ja-JP.yml 限定編集ルール、secrets 検出 |
| 7 | Cost Efficiency | enabledPlugins の重複・過剰、context-budget の整備、MCP 過剰登録なし |
## Misskey 固有の確認項目 (採点根拠コマンド)
採点時に以下を実コマンドで確認する。各項目の **属するカテゴリ** は項目内に明記する (#1-#3 は Security Guardrails、#4 は Tool Coverage、#5 は Quality Gates):
```bash
# 1. [Security Guardrails] SPDX 適用率 (新規ファイル想定の汎用チェック)
# - node_modules を prune で除外
# - packages/misskey-js は MIT サブパッケージなので AGPL ヘッダーを持たない (AGENTS.md §1) → 除外
# - built/ なども除外
# 候補にはなお *.config.{ts,js} / *eslint* / *.d.ts のような CI 上 SPDX 対象外
# (.github/workflows/check-spdx-license-id.yml の exclude 参照) も混ざるため、
# 上位に出たファイルが「新規追加した実コード」かどうかは目視判定する。
find packages \
\( -type d \( -name node_modules -o -name built -o -name dist -o -path 'packages/misskey-js' \) -prune \) \
-o -type f \( -name '*.ts' -o -name '*.js' -o -name '*.vue' -o -name '*.scss' \) -print \
| xargs -r grep -L 'SPDX-License-Identifier: AGPL-3.0-only' | head -20
# → 上位に新規実コードが無ければ満点
# 2. [Security Guardrails] ja-JP.yml 以外の locales が直近で手動編集されていないか
# --pretty=format: でコミットヘッダ行を抑止し、ファイル名行のみを残してから grep する。
# Crowdin の自動同期 commit でも他言語 yml は更新されるため、出力が 0 行になることは少ない。
# 出力があった場合は、author / commit message を確認し Crowdin 由来か手動編集かを判定する:
# git log --since='30 days ago' --pretty=format:'%h %an %s' -- locales/<file>.yml
git log --since='30 days ago' --pretty=format: --name-only -- 'locales/*.yml' \
| grep -v '^$' | grep -v 'ja-JP.yml' | sort -u
# → 出力が無い、または全て Crowdin 由来 commit なら満点
# 3. [Security Guardrails] migration の pending DDL 検査 (TypeORM schema builder)
pnpm --filter backend check-migrations
# → 0 errors (= "All migrations are clean.") なら満点
# 4. [Tool Coverage] endpoint-list.ts 登録漏れ (新規 endpoint がリストにない場合)
# endpoints/ は再帰構造 (notes/create.ts, admin/announcements/create.ts 等) で 400+ ファイルあるため、
# endpoint-list.ts も `export * as '<category>/<name>' from './endpoints/<category>/<name>.js';` 形式で
# 1 ファイル 1 行登録される。両者の行数を「再帰 .ts 数」と「export * as 行数」で比較する。
# e2e / 単体テストは endpoint ではないので *.test.ts を除外する。
endpoint_files=$(find packages/backend/src/server/api/endpoints -type f -name '*.ts' ! -name '*.test.ts' | wc -l)
list_entries=$(grep -cE "^export \* as " packages/backend/src/server/api/endpoint-list.ts)
echo "endpoints (recursive): $endpoint_files / endpoint-list.ts entries: $list_entries"
# 差分が 0 なら満点。差分が出たら、登録漏れの具体特定:
comm -23 \
<(find packages/backend/src/server/api/endpoints -type f -name '*.ts' ! -name '*.test.ts' \
| sed -E 's|.*/endpoints/||;s|\.ts$||' | sort -u) \
<(grep -oE "^export \* as '[^']+'" packages/backend/src/server/api/endpoint-list.ts \
| sed -E "s/^export \* as '([^']+)'/\1/" | sort -u)
# 出力された行が登録漏れの endpoint。0 行なら満点。
# 5. [Quality Gates] console.log の混入
grep -rn 'console\.\(log\|debug\)' packages/backend/src packages/frontend/src 2>/dev/null \
| grep -v 'node_modules\|test\|.spec\.\|.test\.' | wc -l
# → 0 が理想
```
## 出力契約
以下を返す:
1. `overall_score` / `max_score` (repo は 70 点満点)
2. カテゴリごとのスコア + 具体的な根拠
3. 失敗チェック項目と該当ファイルパス
4. Top 3 改善アクション
5. 次に適用を推奨する skill / 手順
## サンプル出力
```text
Harness Audit (repo): 55/70
Tool Coverage: 9/10 (skills 5, agents 2, commands 5 — 偏りなし)
Context Efficiency: 8/10 (description 平均 3-5 行、肥大なし)
Quality Gates: 5/10 (Stop hook 共有設定に未登録 / `/quality-gate` あり)
Memory Persistence: 5/10 (プロジェクト側 memory/ 未採用方針 = 既定値)
Eval Coverage: 7/10 (testing.md 網羅、Storybook 一部抜け)
Security Guardrails: 10/10 (SPDX 100%, locales OK, migrations clean)
Cost Efficiency: 8/10 (context-budget 導入済 / MCP 0)
Failed Checks:
- packages/frontend/src/.../X.vue で SPDX 欠落 (Security Guardrails)
- console.log が backend に 3 件 (Quality Gates)
- 共有 Stop hook なし (Quality Gates) — 各 contributor が `.claude/settings.local.json` で opt-in する方針なら減点しなくて良い
Top 3 Actions:
1) [Security Guardrails] SPDX 欠落 1 ファイルを修正:
packages/frontend/src/.../X.vue
2) [Quality Gates] backend の console.log 3 件を logger に置換。
git grep "console\.log" packages/backend/src
3) [Cost Efficiency] enabledPlugins から未使用のものを外す。
.claude/docs/plugins.md と照合。
Suggested next skills to apply:
- /quality-gate で完了前に lint + unit test を回す
- context-budget で plugin 由来の overhead を確認
```
## 採点の信頼性
- 確定的: 同じ commit / 同じ `.claude/` 構成なら同じスコア
- ヒューリスティクス: 「description の冗長度」のような主観項目は同一基準で機械的に判定
- スクリプト不要: `pnpm``git``grep`/`find` 等の標準ツールのみ
## 参考: ECC オリジナルとの差分
- ECC 版は `node scripts/harness-audit.js` を直叩きする運用で、ECC リポジトリ全体に閉じた採点だった。
- Misskey 版は **Misskey の規約 (SPDX/migration/locales/endpoint-list)** を Security 採点に組み込み、`pnpm` ベースの実コマンドで根拠を取る方式に再設計。
- 結果として ECC への依存はゼロ。

View File

@@ -0,0 +1,81 @@
---
description: TypeORM migration の空雛形を生成する。スキーマ差分から自動生成したい時は create-migration skill を使うこと
argument-hint: <PascalCaseName>
allowed-tools: Bash(pnpm:*), Bash(ls:*), Bash(test:*), Bash(head:*), Read, Edit
---
## 引数
引数: `$ARGUMENTS`
## タスク
1. **PascalCaseName の検証**
`$ARGUMENTS``^[A-Z][A-Za-z0-9]+$` に一致するか確認する。一致しない場合はエラー終了し、`AddFooBar` / `BirthdayIndex` のような形式を案内する。
2. **既存ファイルの存在確認**
```bash
ls packages/backend/migration/*$ARGUMENTS.{js,ts} 2>/dev/null
```
既に同名 (タイムスタンプ違い) のファイルが存在する場合、上書きせずユーザーに別名を促す。
3. **TypeORM 公式 CLI で空雛形を生成 (`-o --esm` 必須)**
`create-migration` skill の方針に従い、`Date.now()` を手書きするのではなく TypeORM CLI を使う。`-o --esm` で **最初から JS(ESM) を生成** させ、後続の `.ts → .js` 変換や `import { MigrationInterface }` 削除といった TS 固有構文の除去を不要にする (`-o --esm` を付けないと `.ts` + CommonJS / `implements MigrationInterface` 付きで生成され、Misskey の `ormconfig.js` (`migration/*.js` のみロード) と既存 migration スタイルに合わない):
```bash
pnpm --filter backend exec typeorm migration:create -o --esm migration/$ARGUMENTS
```
出力: `packages/backend/migration/<UnixMs>-<PascalCaseName>.js`
4. **生成ファイルパスの取得**
後続ステップで使うパスを変数に受ける (`<ms>` を手書きしない):
```bash
dst=$(ls -t packages/backend/migration/*$ARGUMENTS.js | head -1)
```
以降のステップでは `$dst` を編集対象として扱う。完成後の典型的な形は次のようになる (参考: [packages/backend/migration/1767169026317-birthday-index.js](../../packages/backend/migration/1767169026317-birthday-index.js)):
```js
export class <PascalCaseName><ms> {
name = '<PascalCaseName><ms>'
async up(queryRunner) {
}
async down(queryRunner) {
}
}
```
5. **SPDX ヘッダーの追加**
`Edit` ツールで、ファイル冒頭に以下を挿入する。CI の `spdx` ジョブが失敗するため必須:
```js
/*
* SPDX-FileCopyrightText: syuilo and misskey-project
* SPDX-License-Identifier: AGPL-3.0-only
*/
```
6. **migration の pending DDL 検査**
```bash
pnpm --filter backend check-migrations
```
TypeORM schema builder で pending DDL を検出する検査 ([scripts/check_migrations_clean.js](../../packages/backend/scripts/check_migrations_clean.js))。空雛形を作っただけの段階ではエンティティ差分との不整合が残る場合があるため、`up`/`down` を埋めた後にも再実行して 0 件になるか確認する。
7. **結果報告**
- 生成ファイルパスを示す。
- `up()` / `down()` の中身が空であることを伝え、SQL を書く必要があると案内する。
- `down()` を空のまま放置すると本番ロールバック時に詰むため、必ず `up` の完全な巻き戻しを実装するよう促す。
- 詳細な手順 (`migration:generate` を使うべきケース、CONCURRENTLY などの注意点) は `create-migration` skill を参照するよう案内する。
## 注意
- このコマンドは **空雛形を素早く出して手書きする** 用途。エンティティ (`packages/backend/src/models/*.ts`) を変更した差分から SQL を自動生成したい場合は、このコマンドではなく `create-migration` skill 経由で `migration:generate` を使うこと。
- マージ済み migration ファイルは絶対に編集しない ([AGENTS.md §3](../../AGENTS.md#3-マージ済み-migration-を絶対に編集しない))。

View File

@@ -0,0 +1,122 @@
---
description: Misskey の lint / typecheck / 高速テストを順に実行して品質ゲートを通すコマンド。完了前の軽量検証用。
argument-hint: "[repo|backend|frontend|<path/to/file.ts>]"
---
<!--
SPDX-License-Identifier: MIT
SPDX-FileCopyrightText: 2026 Affaan Mustafa and everything-claude-code contributors
出典 (upstream): https://github.com/affaan-m/everything-claude-code (v2.0.0-rc.1)
upstream path: commands/quality-gate.md
upstream license: MIT — https://github.com/affaan-m/everything-claude-code/blob/main/LICENSE
project-level notice: see .claude/THIRD_PARTY_LICENSES.md (Misskey 内サードパーティ一覧 + MIT 全文)
Imported into Misskey .claude/ on 2026-05-10. Pipeline 概念 (lint → typecheck → test) は upstream ECC 版から借用 (MIT)。実コマンド層は Misskey の pnpm + tsgo + ESLint + Vitest に固定し、formatter (Prettier/Biome) フェーズは削除した。
note: 元 ECC 版は言語自動判定 + format/lint/type のジェネリック版だったが、Misskey 専用に pnpm + tsgo + ESLint + Vitest の組み合わせに固定。重い test:e2e / test:fed は含まない (CI 側で実行される)。
-->
# /quality-gate — Misskey 軽量品質ゲート
`/quality-gate [scope]`
完了前の **軽量** 品質チェック。重い E2E / 連合テスト (test:e2e / test:fed / Cypress) は CI 側で実行されるため、本コマンドには含めない。
## Scope
- `repo` (default) — 全パッケージ
- `backend``packages/backend` のみ
- `frontend``packages/frontend` のみ
- `path/to/file.ts` — 単一ファイルへの ESLint --fix のみ
## Pipeline
### Repo scope (全部)
各パッケージの `lint` スクリプト実体は `pnpm typecheck && pnpm eslint` ([packages/backend/package.json](../../packages/backend/package.json), [packages/frontend/package.json](../../packages/frontend/package.json)) で、ルートの `pnpm lint``pnpm --no-bail -r lint` (= 全パッケージで lint を `--no-bail` で実行)。**typecheck は lint に含まれている**ため、通常はこの 2 コマンドで十分:
```bash
# 1. Lint (= typecheck + ESLint、全パッケージ。--no-bail で最初の失敗で止まらず全結果を集める)
pnpm lint
# 2. Unit test (高速、e2e は含まない)
pnpm --filter backend test
pnpm --filter frontend test
```
#### 詳細を分けて見たい時のみ (optional)
lint がまとめて失敗していて typecheck の結果だけ単独で見たい場合は、以下を個別に回す。**通常は不要** (lint の出力を読めば足りる):
```bash
pnpm --filter backend typecheck # tsgo 単体
pnpm --filter frontend typecheck # vue-tsc 単体 (Vue SFC の型を見るため)
```
### Backend scope
`pnpm --filter backend lint` は内部で `pnpm typecheck && pnpm eslint` を実行する ([packages/backend/package.json](../../packages/backend/package.json)) ので、`lint` を回せば typecheck も終わる。軽量ゲートでは typecheck の二重実行を避けるため `lint` + `test` のみ:
```bash
pnpm --filter backend lint
pnpm --filter backend test
```
`tsgo` の出力を単独で見たい時のみ optional で `pnpm --filter backend typecheck` を別途回す。
### Frontend scope
`pnpm --filter frontend lint` も内部で `pnpm typecheck && pnpm eslint` を実行する ([packages/frontend/package.json](../../packages/frontend/package.json)) ため、軽量ゲートでは Backend 同様に `lint` + `test` のみ:
```bash
pnpm --filter frontend lint
pnpm --filter frontend test
```
`vue-tsc` の出力を単独で見たい時のみ optional で `pnpm --filter frontend typecheck` を別途回す。
### Single file scope
```bash
pnpm exec eslint --fix <path>
```
## Output
実行したフェーズの pass/fail と件数を集計する。標準パイプラインは `pnpm lint` (typecheck 内包) と unit test のみなので、デフォルトの出力は以下のようになる:
```text
Quality Gate (repo):
Lint: PASS (0 errors, 2 warnings)
Backend ut: PASS (412/412)
Frontend ut: PASS (87/87)
→ 完了前の軽量チェック OK。重い e2e / 連合テストは CI 側で実行される。
```
`#### 詳細を分けて見たい時のみ (optional)` で個別 typecheck (`pnpm --filter backend typecheck` / `pnpm --filter frontend typecheck`) も回した場合のみ、その結果を追加行として表示する:
```text
Quality Gate (repo):
Lint: PASS (0 errors, 2 warnings)
Backend tc: PASS (0 errors) # optional 実行時のみ
Frontend tc: PASS (0 errors) # optional 実行時のみ
Backend ut: PASS (412/412)
Frontend ut: PASS (87/87)
```
失敗時は最初に落ちたフェーズで停止して詳細を見せる。
## 関連 skill / コマンド
- `/check-misskey-js` コマンド — API 変更時の misskey-js 再生成
- [AGENTS.md §必須コマンド](../../AGENTS.md#必須コマンド) — pnpm コマンド一覧の正典
## 元 ECC 版との差分
- ジェネリックな言語自動判定を排除し、Misskey 固定 pipeline に。
- formatter フェーズなし (Misskey は ESLint --fix のみ採用)。
- e2e / federation / Cypress は重いため除外し CI 側に委譲。

18
.claude/docs/README.md Normal file
View File

@@ -0,0 +1,18 @@
# Misskey Claude Code 補助ドキュメント
ルート `CLAUDE.md` には書かれていないが、開発時に参照すると便利な情報を分野別にまとめている。**Claude は必要になったタイミングで該当ファイルを Read すれば良い** (auto-load しない)。
## 索引
| ファイル | いつ読むか |
|---|---|
| [architecture.md](./architecture.md) | パッケージ構成・ビルド構造を把握したい時 / 新パッケージを跨ぐ変更を計画する時 |
| [backend.md](./backend.md) | `packages/backend` を編集する時 (NestJS / TypeORM / API endpoint / migration) |
| [frontend.md](./frontend.md) | `packages/frontend` を編集する時 (Vue 3 / Mk* / i18n / SCSS Modules / `os.ts`) |
| [testing.md](./testing.md) | テストを書く・走らせる時 (Vitest 構成、Cypress、Storybook) |
| [plugins.md](./plugins.md) | 有効化済の Claude Code プラグインの用途を確認したい時 |
## 補足: ルール vs ドキュメント
- 事故直結ルール (SPDX / locales / migration) と必須コマンド・CHANGELOG 書式は、リポジトリルートの [AGENTS.md](../../AGENTS.md) に集約されている。Claude Code は CLAUDE.md からの `@AGENTS.md` で常時コンテキストに乗せる。Codex / Copilot も同じファイルを読む。
- `.claude/docs/*.md` (このディレクトリ) は **オンデマンド参照**。Claude が「知っておいた方が良いが常に持つ必要はない」内容をここに置く。

View File

@@ -0,0 +1,47 @@
# アーキテクチャ概要
## モノレポ構成 (pnpm workspaces)
pnpm workspace の正は [pnpm-workspace.yaml](../../pnpm-workspace.yaml) で、以下 11 パッケージと、`packages/misskey-js` 内の sub-workspace `packages/misskey-js/generator` (型生成用の内部ジェネレータ。直接編集しない) で構成される。`package.json``workspaces` 配列も併記しているが、実体は pnpm-workspace.yaml が読まれる:
| パッケージ | 役割 |
|---|---|
| `packages/backend` | NestJS 11 + Fastify 5 + TypeORM 0.3 (PostgreSQL) + Redis。HTTP/WebSocket/ActivityPub サーバー本体。 |
| `packages/frontend` | Vue 3.5 + Vite。Web クライアント本体。 |
| `packages/frontend-embed` | 埋め込み専用ビュー (ノート単体プレビュー等)。 |
| `packages/frontend-shared` | frontend と frontend-embed で共有するユーティリティ・コンポーネント。 |
| `packages/frontend-builder` | フロントエンドビルド支援 (Vite plugin など)。 |
| `packages/sw` | Service Worker。 |
| `packages/misskey-js` | JS/TS クライアント SDK (MIT サブパッケージ)。`src/autogen/` 配下のみ backend の OpenAPI から `pnpm build-misskey-js-with-types` で自動生成され、それ以外 (`src/index.ts` / `src/api.ts` 等) は手書き保守する。autogen 配下を直接編集しないこと。 |
| `packages/misskey-reversi` | 内蔵リバーシゲームのロジック。 |
| `packages/misskey-bubble-game` | 内蔵バブルゲームのロジック。 |
| `packages/i18n` | locales 読み込み/型生成のサポート。 |
| `packages/icons-subsetter` | アイコンのサブセット化ツール。 |
その他に `packages/shared` (workspaces には含まれないが共有ファイル置き場) もある。
## 重要な依存関係
```
frontend ── misskey-js (auto-generated) ── backend (OpenAPI)
└── frontend-embed, sw も依存
```
- backend の API (meta / paramDef / response) を変更したら **必ず** `pnpm build-misskey-js-with-types` を実行し、misskey-js の生成物を更新する。忘れると CI の `check-misskey-js-autogen` ジョブが落ちる。
## ビルドツール
- **Backend**: `rolldown` (Rust 製・Rollup 互換 API のバンドラ) でバンドル。型チェックは `tsgo` (TypeScript native preview)。
- **Frontend**: Vite。型チェックは `vue-tsc`
- **Lint**: ESLint 9 (Flat Config) + `@misskey-dev/eslint-plugin`
## 国際化
- `locales/` 直下に 40 言語の YAML (ja-JP.yml + 他 39 言語)。
- **`ja-JP.yml` のみ手動編集可** (Crowdin 経由で他言語へ自動配信)。
- フロントエンドからの参照は引数なしか引数ありかで使い分ける。詳細は [frontend.md](./frontend.md#国際化-i18n)。
## ライセンス
リポジトリ本体は AGPL-3.0-only。**AGPL-3.0-only 管轄かつ SPDX CI 対象ディレクトリ** の新規 `.ts` / `.js` / `.cjs` / `.mjs` / `.vue` / `.scss` / `.html` ファイルには冒頭に SPDX ヘッダー必須。`packages/misskey-js` は MIT サブパッケージなので AGPL ヘッダーを一律に付けない。条件と除外の詳細は [AGENTS.md §1](../../AGENTS.md#1-spdx-ヘッダー必須) 参照。

124
.claude/docs/backend.md Normal file
View File

@@ -0,0 +1,124 @@
# Backend (`packages/backend`) 規約
NestJS 11 + Fastify 5 + TypeORM 0.3 (PostgreSQL) + Redis。
## アーキテクチャ
- **DI コンテナ**: NestJS の `@Injectable()` サービス + Repository (TypeORM) パターン。
- **DI トークン**: `@/di-symbols.js``DI` から `@Inject(DI.xxx)` で注入。
- **ビルド**: `rolldown -c``built/` にバンドル。型チェックは `tsgo`
## API エンドポイント
### 配置
`packages/backend/src/server/api/endpoints/<category>/<name>.ts` (一部はトップ直下)。
### 三点セット (`endpoints/ping.ts` 参照)
各エンドポイントファイルは以下の 3 つを export する:
```ts
export const meta = {
tags: ['<tag>'],
requireCredential: true, // または false (必ず明示)
requireModerator: false, // 必要なら true
kind: 'read:account', // OAuth scope
res: {
type: 'object',
optional: false, nullable: false,
properties: { /* ... */ },
},
errors: {
sampleError: {
message: 'Sample error message.',
code: 'SAMPLE_ERROR',
id: 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx', // UUID v4 (`x`=hex, `y`=8/9/a/b)。`crypto.randomUUID()` で生成し、他エンドポイントと重複させない
},
},
} as const;
export const paramDef = {
type: 'object',
properties: { /* JSON Schema */ },
required: [],
} as const;
@Injectable()
export default class extends Endpoint<typeof meta, typeof paramDef> { // eslint-disable-line import/no-default-export
constructor(
// @Inject(DI.xxx) private xxxRepository: XxxRepository,
) {
super(meta, paramDef, async (ps, me) => {
// 実装。エラーは throw new ApiError(meta.errors.xxx);
});
}
}
```
### 注意点
- **公開 API エラーとしてクライアントに返したいものは `throw new ApiError(meta.errors.<key>)` を使う**。`meta.errors` に列挙して `ApiError` でラップしないと misskey-js 側の型に出ず、レスポンスも 500 になる。
- 一方で **想定外の例外 (DB 不整合 / 下層サービスの bug 等) は握り潰さず再 throw する**。既存 endpoint も「期待される業務エラーは `ApiError` に変換し、それ以外は `throw err;` で再 throw」の二段構え (例: [`endpoints/i/pin.ts`](../../packages/backend/src/server/api/endpoints/i/pin.ts) の `catch` 節)。生 `throw` を全面禁止すると未知例外が 200 で潰れて debug 困難になる。
- `meta.errors.<key>.id`**UUID** 形式。新規追加時は他エンドポイントと重複しないよう確認する。
- `requireCredential``true` / `false` を必ず明示する。
- 新規エンドポイント追加後は **`pnpm build-misskey-js-with-types`** を実行する (`misskey-js` の自動生成ファイルを更新)。
### ルート登録
エンドポイントは **glob 自動収集されない**。新規ファイルを `endpoints/<category>/<name>.ts` に置いただけでは API ルーティングに乗らず、404 になる。`packages/backend/src/server/api/endpoint-list.ts` にアルファベット順で 1 行追加するのが必須:
```ts
export * as '<category>/<name>' from './endpoints/<category>/<name>.js';
```
`EndpointsModule.ts` がこのファイルの全エクスポートを `Object.entries()` で反復し、NestJS の provider (`provide: 'ep:<path>'`) を生成する。詳細は [.claude/skills/add-api-endpoint/SKILL.md](../skills/add-api-endpoint/SKILL.md) のステップ 4 を参照。
## モデル / Repository
- エンティティ: `packages/backend/src/models/<Name>.ts` (`@Entity` + `@Column`)。
- DI 経由で注入される Repository を経由してアクセス。
## Migration
詳細手順 (手書き方式 = AGENTS.md §3 と整合):
> エンティティ差分からの自動生成や `CREATE INDEX CONCURRENTLY` 等のオプションを使いたい場合は [.claude/skills/create-migration/SKILL.md](../skills/create-migration/SKILL.md) の TypeORM CLI 手順を使う。手書き / CLI どちらでも `check-migrations` (pending DDL 検出) さえ通せば等価。
1. **タイムスタンプ取得**: `node -e "console.log(Date.now())"`
2. **ファイル名**: `packages/backend/migration/{timestamp}-{PascalCaseName}.js` (拡張子は `.js`)
3. **雛形**:
```js
/*
* SPDX-FileCopyrightText: syuilo and misskey-project
* SPDX-License-Identifier: AGPL-3.0-only
*/
export class PascalCaseName1234567890123 {
name = 'PascalCaseName1234567890123'
async up(queryRunner) {
// 前進マイグレーション
}
async down(queryRunner) {
// up を完全に巻き戻す
}
}
```
4. **検証**:
- `pnpm --filter backend check-migrations` (TypeORM schema builder で pending DDL を検出する。エンティティと migration の不一致が残っているとここで非ゼロ終了する。実体は [scripts/check_migrations_clean.js](../../packages/backend/scripts/check_migrations_clean.js))
- `pnpm migrate` (ローカル DB に適用)
- `pnpm revert` (ロールバック確認)
5. **エンティティとの整合性**: 関連する `src/models/*.ts` の `@Column` / `@Entity` も同時に更新する。
> マージ済み migration の編集は **絶対禁止** ([AGENTS.md §3](../../AGENTS.md#3-マージ済み-migration-を絶対に編集しない))。
## テスト
- Unit: `pnpm --filter backend test` (`vitest.config.unit.ts`)
- E2E: `pnpm --filter backend test:e2e` (`vitest.config.e2e.ts`)
- Federation: `pnpm --filter backend test:fed` (`vitest.config.fed.ts`)
- 配置: `packages/backend/test/` 配下。

76
.claude/docs/frontend.md Normal file
View File

@@ -0,0 +1,76 @@
# Frontend (`packages/frontend`) 規約
Vue 3.5 + Vite + Storybook + Cypress E2E。
## コンポーネント命名
- 共有 / 再利用コンポーネントは **`Mk` プレフィックス** (例: `MkButton.vue`, `MkInput.vue`, `MkAbuseReport.vue`)。
- ページ単位のものは `packages/frontend/src/pages/` 配下に置く。
## SFC スタイル
Composition API + `<script setup lang="ts">` を基本とする (Options API は新規導入しない)。型宣言や module スコープのユーティリティを置きたい時は、setup ブロックと**併用**する形で追加の `<script lang="ts">` ブロックを置いて構わない (例: [`MkInput.vue`](../../packages/frontend/src/components/MkInput.vue) は `SupportedTypes` 型を別ブロックで宣言してから setup を書いている)。SCSS は **CSS Modules** で書き、`<style lang="scss" module>` を使う:
```vue
<!--
SPDX-FileCopyrightText: syuilo and misskey-project
SPDX-License-Identifier: AGPL-3.0-only
-->
<template>
<div :class="$style.root">
<!-- ... -->
</div>
</template>
<script setup lang="ts">
import { ref } from 'vue';
// ...
</script>
<style lang="scss" module>
.root {
/* ... */
}
</style>
```
## 国際化 (i18n)
- 文字列リテラルを直書きしない。
- 引数なし: `i18n.ts.<path>` で参照する (例: `i18n.ts.deleted`)。
- 引数あり: `i18n.tsx.<path>(...)` で関数呼び出しする (例: `i18n.tsx.takeOverConfirm({ name })`)。
- 新規キーは **`locales/ja-JP.yml` のみ** に追加する (他言語は Crowdin で自動配信)。
- `i18n``packages/frontend/src/i18n.ts` (または共有モジュール) から import する。
## モーダル / 通知
- `os.ts` (`packages/frontend/src/os.ts`) 経由で呼ぶ。
- `os.alert(...)` / `os.confirm(...)` / `os.popup(...)` / `os.success(...)` など。
- ブラウザ標準の `window.alert()` / `window.confirm()`**直接呼ばない**
## アクセシビリティ (PR レビューで指摘されやすい点)
- クリックハンドラを付けるなら `<button>` を使うか、`role="button"` + `tabindex` を付ける。
- フォーム要素には `<label>` または `aria-label` を付ける。
- キーボード操作可能であること。
## Storybook
新規共有コンポーネントには `<ComponentName>.stories.impl.ts` を併設するのが慣習 (`MkButton.stories.impl.ts` 等の例多数)。
```bash
pnpm --filter frontend storybook-dev # localhost:6006
```
## ビルド・開発
- 開発: `pnpm dev` (ルート) で backend + frontend が watch で立ち上がる。
- ビルド: `pnpm --filter frontend build`
- 型チェック: `pnpm --filter frontend typecheck` (vue-tsc)
- ESLint: `pnpm --filter frontend eslint`
## テスト
- Unit (Vitest): `pnpm --filter frontend test`
- Cypress E2E: `pnpm e2e` (ルートから; `start-server-and-test` で起動)

28
.claude/docs/plugins.md Normal file
View File

@@ -0,0 +1,28 @@
# 有効化済 Claude Code プラグイン
`.claude/settings.json` で 14 プラグインが有効化されている。それぞれの典型的な利用シーンを 1 行で示す。
| プラグイン | 用途 |
| --- | --- |
| `frontend-design` | UI コンポーネント / ページの設計・デザイン作業 (Vue 3 編集に有効) |
| `superpowers` | TDD・debugging・brainstorming・planning 等のメタスキル群 |
| `context7` | OSS ドキュメントの取得 (Vue 3, NestJS, TypeORM, Vitest 等) — 訓練データの古さを補う |
| `code-review` | コードレビュー (`/code-review`) |
| `code-simplifier` | コード整理 (`code-simplifier:code-simplifier` サブエージェント経由) |
| `github` | GitHub PR / Issue 操作 (gh ベースだが補助コマンドあり) |
| `skill-creator` | 新スキルの作成・改善・評価 |
| `feature-dev` | 機能開発ガイド (`/feature-dev:feature-dev` / 内部に `code-architect` / `code-explorer` / `code-reviewer` サブエージェント) |
| `claude-md-management` | CLAUDE.md の作成・改善 (`/claude-md-management:revise-claude-md` / `claude-md-improver` エージェント) |
| `typescript-lsp` | TypeScript LSP 連携 (型情報を活用) |
| `security-guidance` | セキュリティレビュー (`/security-review`) |
| `pr-review-toolkit` | PR レビュー一式。サブエージェント: `code-reviewer` / `code-simplifier` / `comment-analyzer` / `pr-test-analyzer` / `silent-failure-hunter` / `type-design-analyzer` |
| `claude-code-setup` | Claude Code 自動化セットアップ提案 |
| `playwright` | ブラウザ自動操作 (フロントエンド動作確認時に有用) |
## 使い分けの指針
- **API 関連の調査**: `context7` で対象ライブラリのドキュメントを取得 → 編集。
- **PR 作成前**: `pr-review-toolkit` の各エージェント (code-reviewer / silent-failure-hunter 等) を並列で走らせる。
- **新機能の設計**: `feature-dev` → brainstorming → 実装の流れ。
- **UI 確認**: `playwright``pnpm dev` の画面を直接操作。
- **将来追加検討**: PostgreSQL MCP — TypeORM + 342 migration の調査効率化。read-only ロールで登録し、接続先 (`misskey` DB) と権限分離に注意する。

69
.claude/docs/testing.md Normal file
View File

@@ -0,0 +1,69 @@
# テスト構成
## Backend 全般の前提: `.config/test.yml`
backend のテストスクリプト (`test` / `test:e2e` / `test:fed`) はすべて内部で `cross-env NODE_ENV=test pnpm compile-config` を実行し、`.config/test.yml` を読み込む ([packages/backend/package.json](../../packages/backend/package.json), [packages/backend/scripts/compile_config.js](../../packages/backend/scripts/compile_config.js))。**未作成だとテスト自体が起動しない。**
未作成なら以下を 1 回だけ手動コピーする (どちらでも可):
```bash
ncp .github/misskey/test.yml .config/test.yml
# または
cp .github/misskey/test.yml .config/test.yml
```
補足:
- ルートの `pnpm start:test` (Cypress 用にテストサーバーを起動するコマンド) を使う経路では実行時に `ncp` で自動コピーされる ([package.json](../../package.json))。それ以外で backend テストを直接走らせる時は上記の手動コピーが必要。
- すでに `.config/test.yml` があれば各テストスクリプトの内部 `compile-config` で十分なので、追加で `pnpm --filter backend compile-config` を叩く必要はない。
- `pnpm start:test` は backend e2e テスト (`pnpm --filter backend test:e2e`) の前提ではない (ポート競合の元になるため使わないこと)。
## Backend (Vitest 4, 3 設定)
| 種別 | 設定ファイル | 実行コマンド |
| --- | --- | --- |
| Unit | `packages/backend/vitest.config.unit.ts` | `pnpm --filter backend test` |
| E2E (HTTP / DB) | `packages/backend/vitest.config.e2e.ts` | `pnpm --filter backend test:e2e` |
| Federation | `packages/backend/vitest.config.fed.ts` | `pnpm --filter backend test:fed` |
- 配置: `packages/backend/test/`
- 事前準備は [§Backend 全般の前提: `.config/test.yml`](#backend-全般の前提-configtestyml) を参照。
- カバレッジ: `pnpm --filter backend test-and-coverage`
## Frontend (Vitest)
```bash
pnpm --filter frontend test # 1 回実行
pnpm --filter frontend test-and-coverage # カバレッジ付き
```
- 主な配置: `packages/frontend/test/*.test.ts` (例: `i18n.test.ts`, `theme.test.ts`, `is-birthday.test.ts`)。
- ビルドツール周りなど対象コードと隣接させた方が分かりやすいテストは、コードと同じディレクトリに `*.test.ts` として置く (例: [`packages/frontend/lib/rollup-plugin-unwind-css-module-class-name.test.ts`](../../packages/frontend/lib/rollup-plugin-unwind-css-module-class-name.test.ts))。
- 共有コンポーネント (`MkX.vue`) のユニットテストは現状少なく、`*.spec.ts` / `__tests__/` 形式は採用していない (Storybook + Cypress でカバー)。
## E2E (Cypress)
ルートから実行する:
```bash
pnpm e2e # start:test サーバーを立てて Cypress run
pnpm cy:open # 対話的に開く
```
- 設定: ルート `cypress.config.ts`。テスト本体は `cypress/` 配下。
## Storybook (frontend)
```bash
pnpm --filter frontend storybook-dev # http://localhost:6006
pnpm --filter frontend build-storybook # 静的ビルド
```
- 各コンポーネント横に `*.stories.impl.ts` を併設する慣習 (例: `MkButton.stories.impl.ts`)。
- Chromatic (`pnpm --filter frontend chromatic`) で視覚回帰チェック。
## ローカル DB / Redis (テスト・開発共通)
```bash
docker compose -f compose.local-db.yml up -d
```

18
.claude/settings.json Normal file
View File

@@ -0,0 +1,18 @@
{
"enabledPlugins": {
"frontend-design@claude-plugins-official": true,
"superpowers@claude-plugins-official": true,
"context7@claude-plugins-official": true,
"code-review@claude-plugins-official": true,
"code-simplifier@claude-plugins-official": true,
"github@claude-plugins-official": true,
"skill-creator@claude-plugins-official": true,
"feature-dev@claude-plugins-official": true,
"claude-md-management@claude-plugins-official": true,
"typescript-lsp@claude-plugins-official": true,
"security-guidance@claude-plugins-official": true,
"pr-review-toolkit@claude-plugins-official": true,
"claude-code-setup@claude-plugins-official": true,
"playwright@claude-plugins-official": true
}
}

33
.claude/skills/README.md Normal file
View File

@@ -0,0 +1,33 @@
# `.claude/skills/` — プロジェクト固有のカスタムスキル
Misskey 固有の繰り返しタスクを Claude にスムーズに実行させるための **カスタムスキル**`.claude/skills/<name>/SKILL.md` 形式で配置する。
frontmatter (`name` + `description`) は、Claude が **自動でスキルを呼び出すか判断する** 唯一の手がかりになる。`description` には用途を具体的かつ網羅的に書く (動詞 + 対象 + トリガー条件)。
## 実装済スキル
### Misskey 固有 (本リポジトリ向け書き起こし)
| スキル名 | 役割 | 優先度 |
| --- | --- | --- |
| [create-migration](create-migration/SKILL.md) | TypeORM CLI (`migration:generate` / `migration:create`) でマイグレーションを生成し、SPDX / up-down / `check-migrations` まで誘導 | 高 (342 既存 / 規約厳しい) |
| [add-api-endpoint](add-api-endpoint/SKILL.md) | NestJS DI + meta/paramDef 規約で API エンドポイント追加。`endpoint-list.ts` 登録と `misskey-js` 再生成を含む | 高 |
| [add-i18n-key](add-i18n-key/SKILL.md) | `locales/ja-JP.yml` のみ編集する補助。型は `packages/i18n` が自動再生成 | 中 |
| [add-mk-component](add-mk-component/SKILL.md) | `Mk*` 命名 + SPDX (HTML) + SCSS module + `*.stories.impl.ts` 併設の Vue コンポーネントを一括スキャフォールド | 中 |
### ECC (everything-claude-code) 由来 — MIT セレクトインポート
[.claude/THIRD_PARTY_LICENSES.md](../THIRD_PARTY_LICENSES.md) §1 に出典・改変メモ・MIT 全文を集約。
| スキル名 | 役割 | 優先度 |
| --- | --- | --- |
| [context-budget](context-budget/SKILL.md) | agents / skills / MCP / CLAUDE.md の token overhead を見える化し、肥大コンポーネントを検出 | 中 |
設計方針: `create-migration` は手動の `Date.now()` 命名ではなく TypeORM 公式 CLI (`migration:generate` / `migration:create`) を採用。Storybook ファイル名は `*.stories.impl.ts` 規約に準拠する。
## 新規スキルを追加する場合
- `.claude/skills/<name>/SKILL.md` に YAML frontmatter (`name` + `description`) と本文 Markdown を書く。
- `disable-model-invocation: true` は付けない (auto-invoke させたいため)。
- 主要参照ファイルへのリンクは、リポジトリルートからの相対パス (例: `../../packages/backend/...`) で貼る。絶対パスは contributor のホームディレクトリ依存になるので使わない。
- 完成したらこの README の表にも 1 行追加する。

View File

@@ -0,0 +1,253 @@
---
name: add-api-endpoint
description: Misskey の REST API エンドポイント (/api/<category>/<name>) を NestJS DI + meta/paramDef 規約で追加する。バックエンドに新しい API ルートを足す時に必ず使う。endpoint-list.ts への手動登録、e2e テスト、misskey-js 再生成、CHANGELOG までの一連の手順を含む。
---
# Misskey API エンドポイント追加スキル
`packages/backend/src/server/api/endpoints/<category>/<name>.ts` に新規エンドポイントを追加するためのワークフロー。**手順 4 (endpoint-list.ts 登録) を忘れると 404 になる** 点に最大の注意を払う。
## 最重要事実 (見落とすと壊れる)
1. エンドポイントは **glob 自動収集されない**。[packages/backend/src/server/api/endpoint-list.ts](../../../packages/backend/src/server/api/endpoint-list.ts) への 1 行追加が必須。
2. `meta` / `paramDef` を変えたら **misskey-js の再生成が必須**`pnpm build-misskey-js-with-types` を忘れると CI の `check-misskey-js-autogen` で必ず落ちる。
3. `meta.errors` の各 `id`**UUID**。重複させない (既存全 UUID と衝突確認)。
## ステップ 1: ファイル配置と SPDX
`packages/backend/src/server/api/endpoints/<category>/<name>.ts` に新規作成する。`<category>` は機能領域 (例: `notes`, `users`, `admin/announcements`)。
冒頭に SPDX ヘッダーを必ず付ける:
```ts
/*
* SPDX-FileCopyrightText: syuilo and misskey-project
* SPDX-License-Identifier: AGPL-3.0-only
*/
```
## ステップ 2: 最小テンプレート (シンプル read 系)
[endpoints/ping.ts](../../../packages/backend/src/server/api/endpoints/ping.ts) をベースに書く。認証不要・パラメータなし・小さなレスポンスの例:
```ts
/*
* SPDX-FileCopyrightText: syuilo and misskey-project
* SPDX-License-Identifier: AGPL-3.0-only
*/
import { Injectable } from '@nestjs/common';
import { Endpoint } from '@/server/api/endpoint-base.js';
export const meta = {
tags: ['<tag>'],
requireCredential: false,
res: {
type: 'object',
optional: false, nullable: false,
properties: {
// ...
},
},
} as const;
export const paramDef = {
type: 'object',
properties: {},
required: [],
} as const;
@Injectable()
export default class extends Endpoint<typeof meta, typeof paramDef> { // eslint-disable-line import/no-default-export
constructor(
) {
super(meta, paramDef, async (ps, me) => {
// 実装
});
}
}
```
## ステップ 3: 認証付き / DI / errors を含むテンプレート
[endpoints/notes/create.ts](../../../packages/backend/src/server/api/endpoints/notes/create.ts) を参照する。要点:
```ts
import { Inject, Injectable } from '@nestjs/common';
import { Endpoint } from '@/server/api/endpoint-base.js';
import { ApiError } from '@/server/api/error.js';
import { DI } from '@/di-symbols.js';
// import ms from 'ms'; // limit.duration に ms('1hour') 等を渡すとき (default import)
export const meta = {
tags: ['notes'],
requireCredential: true, // 認証必須なら true
prohibitMoved: false, // moved user を拒否するか
kind: 'write:notes', // OAuth scope (requireCredential 時に必須)
limit: {
duration: 3600000, // ms('1hour')
max: 300,
},
errors: {
noSuchNote: {
message: 'No such note.',
code: 'NO_SUCH_NOTE',
id: 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx', // ★ UUID v4 を必ず生成 (`x`=hex, `y`=8/9/a/b)。下の「UUID 生成」を参照
},
},
res: {
type: 'object',
optional: false, nullable: false,
ref: 'Note', // packed entity に揃える場合
},
} as const;
export const paramDef = {
type: 'object',
properties: {
noteId: { type: 'string', format: 'misskey:id' },
},
required: ['noteId'],
} as const;
@Injectable()
export default class extends Endpoint<typeof meta, typeof paramDef> { // eslint-disable-line import/no-default-export
constructor(
@Inject(DI.notesRepository)
private notesRepository: NotesRepository,
) {
super(meta, paramDef, async (ps, me) => {
const note = await this.notesRepository.findOneBy({ id: ps.noteId });
if (note == null) throw new ApiError(meta.errors.noSuchNote);
// 実装
});
}
}
```
### meta フィールド早見表
| フィールド | 用途 |
|---|---|
| `tags` | OpenAPI タグ (機能領域) |
| `requireCredential` | 認証必須か |
| `requireModerator` / `requireAdmin` | 権限制限 |
| `prohibitMoved` | アカウント移行済ユーザーを拒否 |
| `kind` | OAuth scope (`read:notes` / `write:notes` 等)。`requireCredential: true` 時必須 |
| `limit` | レート制限 (`{ duration, max, key?, minInterval? }`) |
| `errors` | エラー定義。各要素に `message` / `code` / `id` (UUID v4) 必須 |
| `res` | JSON Schema or `ref: '<EntityName>'` (packed entity 参照) |
| `requireFile` | ファイルアップロード必須 |
| `secure` | secure cookie 必要 |
| `allowGet` | GET メソッド許可 |
| `cacheSec` | レスポンスキャッシュ秒数 |
| `description` | OpenAPI 説明 |
詳細は [endpoints.ts](../../../packages/backend/src/server/api/endpoints.ts) の型定義 (lines 11-125) を参照。
### paramDef の特殊フォーマット
JSON Schema (AJV) ベースだが、Misskey 拡張を使える:
- `format: 'misskey:id'` — ID 文字列バリデーション
- `allOf` / `anyOf` / `oneOf` — 複合条件
- `default` — デフォルト値
詳細は [endpoint-base.ts](../../../packages/backend/src/server/api/endpoint-base.ts) を参照。
### エラー throw
**「公開 API エラーとして API クライアントに返したいもの」は必ず `throw new ApiError(meta.errors.<key>)` を使う**。`meta.errors` に列挙した上で `ApiError` でラップしないと、misskey-js 側の型情報に出ず、レスポンスも 500 になる。第 2 引数で追加情報を渡せる:
```ts
throw new ApiError(meta.errors.invalidParam, { reason: 'too short' });
```
一方で、**想定外の例外 (DB 不整合 / 下層サービスの bug など) を握り潰すために `try/catch``ApiError` に変換するのは避ける**。既存 endpoint も「期待される業務エラーは `ApiError` に変換し、それ以外は `throw err;` で再 throw する」という二段構えになっている。`packages/backend/src/server/api/endpoints/notes/create.ts``catch` 節 (末尾の `throw err;`) を参照。生の `throw` を全面禁止すると未知例外も 200 で潰れて debug が困難になるので、このバランスを保つ。
詳細は [error.ts](../../../packages/backend/src/server/api/error.ts) の `ApiError` クラスを参照。
### UUID 生成
```bash
node -e "console.log(crypto.randomUUID())"
```
その UUID が他のエンドポイントの `id` と衝突していないか必ず確認:
```bash
grep -r "id: '<生成した UUID>'" packages/backend/src/server/api/endpoints/
```
## ステップ 4: ★必須 — endpoint-list.ts に登録
[packages/backend/src/server/api/endpoint-list.ts](../../../packages/backend/src/server/api/endpoint-list.ts) の同カテゴリ末尾に 1 行追加する(既存の並びを崩さない):
```ts
export * as '<category>/<name>' from './endpoints/<category>/<name>.js';
```
ファイル冒頭のコメント (`When you add new endpoint, you should add it to this file.`) の通り、このリストが API ルーティングの単一の真実。**忘れると 404**。
`EndpointsModule.ts` がこのファイルの全エクスポートを `Object.entries()` で反復し、NestJS provider (`provide: 'ep:<path>'`) を生成する。
## ステップ 5: e2e テスト追加
[packages/backend/test/e2e/endpoints.ts](../../../packages/backend/test/e2e/endpoints.ts) に対応する `describe` / `test` を追加する。`api()` ヘルパーで叩く:
```ts
describe('<category>/<name>', () => {
test('正常系', async () => {
const res = await api('<category>/<name>', { /* params */ }, alice);
assert.strictEqual(res.status, 200);
});
});
```
実行: `pnpm --filter backend test:e2e`
## ステップ 6: misskey-js 再生成 (★必須)
`meta` / `paramDef` / `res` を変えたら必ず実行する:
```bash
pnpm build-misskey-js-with-types
```
これで以下が更新される:
- `packages/backend/built/api.json` (OpenAPI spec)
- `packages/misskey-js/generator/api.json`
- `packages/misskey-js/src/autogen/*.ts` (TypeScript 型)
PR に `packages/misskey-js/src/autogen/` 配下の差分が含まれていないと、CI の `check-misskey-js-autogen` で落ちる。
## ステップ 7: Lint と typecheck
```bash
pnpm --filter backend lint
```
(typecheck = `tsgo --noEmit` / ESLint = `eslint`)
## ステップ 8: CHANGELOG
ユーザー影響がある (新機能 / 既存挙動変更) なら、`CHANGELOG.md``## Unreleased``### Server` に 1 行追加する ([AGENTS.md §CHANGELOG](../../../AGENTS.md#changelog) 参照):
```
- Feat: /api/<category>/<name> を追加
```
純粋なリファクタや内部用なら不要。
## 参照ファイル
- [endpoints.ts (meta/paramDef 型定義)](../../../packages/backend/src/server/api/endpoints.ts)
- [endpoint-base.ts (Endpoint 基底クラス)](../../../packages/backend/src/server/api/endpoint-base.ts)
- [endpoint-list.ts (★ ここに登録)](../../../packages/backend/src/server/api/endpoint-list.ts)
- [error.ts (ApiError)](../../../packages/backend/src/server/api/error.ts)
- [endpoints/ping.ts (最小例)](../../../packages/backend/src/server/api/endpoints/ping.ts)
- [endpoints/notes/create.ts (DI + errors の典型)](../../../packages/backend/src/server/api/endpoints/notes/create.ts)
- [test/e2e/endpoints.ts (テスト例)](../../../packages/backend/test/e2e/endpoints.ts)
- [scripts/generate_api_json.js (misskey-js 生成元)](../../../packages/backend/scripts/generate_api_json.js)

View File

@@ -0,0 +1,115 @@
---
name: add-i18n-key
description: Misskey の i18n キーを追加・修正する。locales/ja-JP.yml のみ編集可能で、他言語ファイル (en-US.yml 等 39 言語) は Crowdin の自動配信先のため絶対に触らない。型は packages/i18n が ja-JP.yml から自動再生成する。frontend からは i18n.ts.<key> または i18n.tsx.<key>(...) で参照する。
---
# Misskey i18n キー追加スキル
UI 文言の追加・変更を行う際の規約。**手動編集して良いのは `locales/ja-JP.yml` のみ。**
## 大前提 (絶対 NG)
- **`locales/<lang>.yml` (ja-JP.yml 以外) の編集は禁止**。これらは Crowdin の自動配信先で、手動編集すると次の同期で上書き喪失する ([locales/README.md](../../../locales/README.md), [crowdin.yml](../../../crowdin.yml))。
- 文字列リテラルを SFC に直書きしない (`<span>こんにちは</span>` 等)。必ず `i18n.ts.<key>` を経由する。
- 既存キーの破壊的リネームは Crowdin 翻訳資産も道連れになるので慎重に。追加・改名併用 (新キー追加 → 移行 → 旧キー削除) を検討する。
## ステップ 1: ja-JP.yml にキーを追加
[locales/ja-JP.yml](../../../locales/ja-JP.yml) を編集する。YAML の階層構造を維持し、関連するセクションに配置する:
```yaml
# トップレベル単純キー
save: "保存"
# ネストしたカテゴリ (アンダースコア接頭辞は内部カテゴリ)
_settings:
general: "全般"
appearance: "外観"
# パラメータ付き (ICU MessageFormat 互換)
greeting: "こんにちは、{name}さん"
```
### 命名のお作法
- 単純キー: lowerCamelCase (例: `saveChanges`, `confirmDelete`)。
- カテゴリ: アンダースコア接頭辞 (例: `_settings`, `_abuseUserReport`)。
- 既存セクション内に置く場合はアルファベット順を維持する (新セクション全体を末尾に追加するのは可)。
## ステップ 2: 型定義の自動再生成
`packages/i18n/build.ts``ja-JP.yml` を解析し、TypeScript インターフェースを [packages/i18n/src/autogen/locale.ts](../../../packages/i18n/src/autogen/locale.ts) に出力する。
### 自動 (推奨)
`pnpm dev` 実行中なら、`packages/i18n` の watch スクリプトが yml の変更を検知して自動再生成する。
### 手動
```bash
pnpm --filter i18n generate
```
実体は `tsx scripts/generateLocaleInterface.ts`
### 失敗パターン
これを実行せずに frontend 側で `i18n.ts.<newKey>` を参照すると、`Locale` インターフェースに追加されていないため、typecheck で「Property '<newKey>' does not exist on type 'Locale'」というエラーになる。`pnpm --filter frontend lint` で発覚する。
## ステップ 3: frontend での参照
```ts
import { i18n } from '@/i18n.js';
```
| 用途 | 書き方 |
|---|---|
| 単純文字列 | `i18n.ts.save` |
| ネスト | `i18n.ts._settings.general` |
| パラメータ付き | `i18n.tsx.greeting({ name: userName })` |
| Vue テンプレート内 | `{{ i18n.ts.save }}` / `{{ i18n.tsx.greeting({ name }) }}` |
`i18n.ts` は型付き文字列、`i18n.tsx` は MessageFormat 関数。
## ステップ 4: 検証
```bash
# i18n パッケージの型再生成 + typecheck
pnpm --filter i18n lint
# frontend で新キー参照箇所の型チェック
pnpm --filter frontend lint
```
## 例: 「ノートを削除しますか?」確認ダイアログを追加する
1. `locales/ja-JP.yml`:
```yaml
_notes:
deleteConfirm: "このノートを削除しますか?"
```
2. `pnpm --filter i18n generate` (または `pnpm dev` で watch 中)
3. SFC:
```vue
<script setup lang="ts">
import { i18n } from '@/i18n.js';
import * as os from '@/os.js';
async function onDelete() {
const { canceled } = await os.confirm({
type: 'warning',
text: i18n.ts._notes.deleteConfirm,
});
if (canceled) return;
// 削除処理
}
</script>
```
## 参照ファイル
- [locales/README.md (★ 編集ポリシー根拠)](../../../locales/README.md)
- [locales/ja-JP.yml](../../../locales/ja-JP.yml)
- [packages/i18n/build.ts](../../../packages/i18n/build.ts)
- [packages/i18n/src/autogen/locale.ts (生成物)](../../../packages/i18n/src/autogen/locale.ts)
- [packages/frontend/src/i18n.ts](../../../packages/frontend/src/i18n.ts)

View File

@@ -0,0 +1,174 @@
---
name: add-mk-component
description: Misskey フロントエンドの新規 Vue 3 コンポーネントを追加する。Mk* 命名 / SPDX (HTML コメント) / <script setup lang="ts"> / <style lang="scss" module> / *.stories.impl.ts 併設の規約をまとめて適用する。新しい共有 UI コンポーネントを packages/frontend/src/components/ に作る時に使う。
---
# Misskey Vue コンポーネント追加スキル
`packages/frontend/src/components/` に新しい共有コンポーネントを追加するための規約。
## 大前提
- 共有 / 再利用コンポーネントは **必ず `Mk` プレフィックス** (例: `MkButton`, `MkInput`)。ページ固有部品など `Mk` プレフィックスでないものは原則 `pages/` 側に置く。
- 新規では `<style lang="scss" module>` (CSS Modules) を既定とする。古い `scoped` 形式が混在しているが、新規では使わない。
- 文字列リテラルの直書きは禁止。文言は必ず `i18n.ts.<key>` 経由で参照する (新キーは `add-i18n-key` スキルを参照)。
- `alert()` / `confirm()` / `window.prompt()` は使わない。`os.alert` / `os.confirm` / `os.popup` などを使う。
## ステップ 1: ファイル配置
`packages/frontend/src/components/Mk<Name>.vue` に新規作成する。
ストーリーが必要 (= ほぼ常に必要) なら、同階層に `Mk<Name>.stories.impl.ts` も作る。Storybook の規約は `*.stories.impl.ts` であって、`*.stories.ts` ではない。
## ステップ 2: SPDX ヘッダー (HTML コメント形式)
`.vue` ファイル冒頭に必須:
```html
<!--
SPDX-FileCopyrightText: syuilo and misskey-project
SPDX-License-Identifier: AGPL-3.0-only
-->
```
`/* ... */` (TS / JS 形式) ではなく **HTML コメント** で書くこと。既存の `.vue` ファイルがすべて HTML コメント形式を使っており、SFC の先頭として自然な形式に統一するため (CI の `spdx` ジョブはコメント形式ではなく SPDX 文字列の有無のみを検査する)。
## ステップ 3: 最小テンプレート
[MkInfo.vue](../../../packages/frontend/src/components/MkInfo.vue) をベースにする (シンプルな表示コンポーネント):
```vue
<!--
SPDX-FileCopyrightText: syuilo and misskey-project
SPDX-License-Identifier: AGPL-3.0-only
-->
<template>
<div :class="$style.root">
<slot></slot>
</div>
</template>
<script lang="ts" setup>
const props = defineProps<{
variant?: 'primary' | 'secondary';
}>();
const emit = defineEmits<{
(ev: 'click'): void;
}>();
</script>
<style lang="scss" module>
.root {
padding: 12px 14px;
border-radius: var(--MI-radius);
background: var(--MI_THEME-panel);
}
</style>
```
### 規約ポイント
| 項目 | 規約 |
|---|---|
| `<script>` | `<script lang="ts" setup>`。型パラメータが必要なら `generic="T extends ..."` を付ける ([MkInput.vue 参照](../../../packages/frontend/src/components/MkInput.vue)) |
| `defineProps` / `defineEmits` | **type-only** (`<{ ... }>`) 形式。runtime の object 形式は使わない |
| `<style>` | `lang="scss" module` を既定。クラス参照は `:class="$style.foo"` |
| CSS 変数 | `var(--MI_THEME-...)` (テーマ) / `var(--MI-radius)` (UI 共通) — ハードコードしない |
| アイコン | Tabler icons のクラス (`<i class="ti ti-info-circle">`) を使う |
## ステップ 4: i18n と os の利用
```vue
<script lang="ts" setup>
import { i18n } from '@/i18n.js';
import * as os from '@/os.js';
async function onClick() {
const { canceled } = await os.confirm({
type: 'warning',
text: i18n.ts._notes.deleteConfirm,
});
if (canceled) return;
os.toast(i18n.ts.deleted);
}
</script>
```
### `os` の主なヘルパー (詳細は [os.ts](../../../packages/frontend/src/os.ts))
| 関数 | 用途 |
|---|---|
| `os.alert({ type, title?, text })` | 単方向アラート |
| `os.confirm({ type, title, text })` | yes/no 確認 (`{ canceled }` を返す) |
| `os.toast(message)` | 一時通知 |
| `os.popup(component, props, handlers)` | 任意コンポーネントの非同期ポップアップ |
| `os.popupMenu(items, anchor?)` | コンテキストメニュー |
| `os.form(title, fields)` | フォームダイアログ |
| `os.apiWithDialog(endpoint, data)` | API 呼出し + エラー時ダイアログ表示 |
## ステップ 5: Storybook ストーリー併設
[MkButton.stories.impl.ts](../../../packages/frontend/src/components/MkButton.stories.impl.ts) を雛形として参考にする。`.stories.impl.ts``packages/frontend/src/` 配下の `.ts` ファイルなので [AGENTS.md §1 SPDX ヘッダー必須](../../../AGENTS.md#1-spdx-ヘッダー必須) の対象であり、冒頭に SPDX ヘッダーを必ず付ける (HTML コメント形式ではなく `/* */` 形式)。形式 (以下の `MkXxx` は実際のコンポーネント名に置換する):
```ts
/*
* SPDX-FileCopyrightText: syuilo and misskey-project
* SPDX-License-Identifier: AGPL-3.0-only
*/
/* eslint-disable @typescript-eslint/explicit-function-return-type */
/* eslint-disable import/no-default-export */
import type { StoryObj } from '@storybook/vue3';
import MkXxx from './MkXxx.vue';
export const Default = {
render(args) {
return {
components: { MkXxx },
setup() {
return { args };
},
template: '<MkXxx v-bind="args">slot content</MkXxx>',
};
},
args: {
variant: 'primary',
},
parameters: {
layout: 'centered',
},
} satisfies StoryObj<typeof MkXxx>;
```
`Vue` SFC は default export なので、`import MkXxx from './MkXxx.vue';` のように名前付き import ではなく default import で書く。実行確認は `pnpm --filter frontend storybook-dev`
## ステップ 6: Lint と typecheck
```bash
pnpm --filter frontend lint
```
(typecheck = vue-tsc 等、ESLint = `@misskey-dev/eslint-plugin` 含む)
ESLint --fix をピンポイントで:
```bash
pnpm exec eslint --fix packages/frontend/src/components/Mk<Name>.vue
```
## ステップ 7: 既存コンポーネントとの整合性確認
- 似た用途の既存 `Mk*` コンポーネントを参考に、スタイルやプロップ命名を揃える。
- `_button` / `_panel` / `_selectable` などの **共通 utility class** (グローバルスタイルにある) を活用できるか確認する。
- 大きな機能なら、Storybook stories で各バリエーションを網羅する。
## 参照ファイル
- [MkInfo.vue (シンプル例)](../../../packages/frontend/src/components/MkInfo.vue)
- [MkButton.vue (汎用ボタン例)](../../../packages/frontend/src/components/MkButton.vue)
- [MkInput.vue (generics + 多機能例)](../../../packages/frontend/src/components/MkInput.vue)
- [MkButton.stories.impl.ts (Storybook 雛形)](../../../packages/frontend/src/components/MkButton.stories.impl.ts)
- [packages/frontend/src/os.ts](../../../packages/frontend/src/os.ts)
- [packages/frontend/src/i18n.ts](../../../packages/frontend/src/i18n.ts)

View File

@@ -0,0 +1,148 @@
---
name: context-budget
description: Claude Code セッションのコンテキスト窓消費を agents/skills/MCP/rules/CLAUDE.md ごとに見える化し、肥大化と冗長コンポーネントを検出して節約候補を提示する。"コンテキスト消費を見せて"、"context budget"、"context audit"、"トークン内訳"、"これ以上 MCP 入る?" 等の発話で起動する。
---
<!--
SPDX-License-Identifier: MIT
SPDX-FileCopyrightText: 2026 Affaan Mustafa and everything-claude-code contributors
出典 (upstream): https://github.com/affaan-m/everything-claude-code (v2.0.0-rc.1)
upstream path: skills/context-budget/SKILL.md
upstream origin frontmatter: ECC
upstream license: MIT — https://github.com/affaan-m/everything-claude-code/blob/main/LICENSE
project-level notice: see .claude/THIRD_PARTY_LICENSES.md (Misskey 内サードパーティ一覧 + MIT 全文)
Imported into Misskey .claude/ on 2026-05-10 as a standalone copy (no dependency on the ECC plugin runtime). description was rewritten in Japanese and a "Misskey 固有メモ" section was appended; body content remains MIT-licensed.
note: Misskey の skills/agents 数は少ないので、MCP / CLAUDE.md / プラグイン由来の overhead が支配的になりやすい点に留意。
-->
# Context Budget
セッション内に読み込まれるコンポーネント (agents / skills / rules / MCP servers / CLAUDE.md) の token overhead を分析し、空き context を回復する具体策を提示する。
## 使う場面
- セッションが重い・出力品質が落ちてきた感覚がある
- 直近で skills / agents / MCP server を多数追加した
- 残りの context headroom を知りたい
- 追加コンポーネントを入れる前に空きを確認したい
- 「context-budget」「token 内訳」等のキーワードでユーザーが明示的に要請した時 (Misskey リポジトリにはこの名前のスラッシュコマンドは登録していない — 本 skill は名前 / description マッチで auto-invoke される想定。実装済の slash command 一覧は [.claude/commands/](../../commands/) を参照)
## 仕組み
### Phase 1: Inventory
各コンポーネントを走査して token を推定する。
**Agents** (`.claude/agents/*.md`)
- 行数とトークン数 (`words × 1.3`) を計算
- frontmatter `description` の長さを抽出
- フラグ: 200 行超 (重い)、description 30 word 超 (frontmatter 肥大)
**Skills** (`.claude/skills/*/SKILL.md`)
- SKILL.md ごとに token を計算
- フラグ: 400 行超
- `.agents/skills/` 等の重複コピーは除外
**Rules** (リポジトリルートの `AGENTS.md` + `.claude/` から `@-import` されるファイル)
- ファイル単位で token 計算
- フラグ: 100 行超
- 同一言語モジュール内の内容重複を検出
**MCP Servers** (`.mcp.json` または有効 MCP 設定)
- server 数と総 tool 数
- schema overhead をツールあたり ~500 token で見積もる
- フラグ: 20 tool 超のサーバー、`gh` / `git` / `npm` 等の CLI を単純ラップしただけのサーバー
**CLAUDE.md** (project + user-level)
- ファイルごとに token を計算
- フラグ: 合計 300 行超
### Phase 2: Classify
| バケット | 判定基準 | 行動 |
|--------------------|-------------------------------------------------------------|-----------------------------------|
| **Always needed** | CLAUDE.md から参照されている / 有効コマンドの裏 / 現プロジェクトと一致 | 維持 |
| **Sometimes needed** | ドメイン依存 (例: 言語パターン)、CLAUDE.md 参照なし | オンデマンド有効化を検討 |
| **Rarely needed** | コマンド参照なし、内容重複、明確な用途なし | 削除または lazy-load |
### Phase 3: Detect Issues
- **Bloated agent description** — frontmatter description が 30 word 超だと、Task ツール起動のたびに毎回ロードされる
- **Heavy agents** — 200 行超は Task ツールの context を毎回膨らませる
- **Redundant components** — agent ロジックを重複する skill、CLAUDE.md と重複する rule
- **MCP over-subscription** — 10 server 超、または CLI 代用可能なサーバー
- **CLAUDE.md bloat** — 冗長説明、古いセクション、rule に移すべき指示
### Phase 4: Report
```
Context Budget Report
═══════════════════════════════════════
Total estimated overhead: ~XX,XXX tokens
Context model: <現在モデル名> (<window>K window) ← 例: Claude Opus 4.7 (1M), Claude Sonnet (200K)
Effective available context: ~XXX,XXX tokens (XX%)
Component Breakdown:
┌─────────────────┬────────┬───────────┐
│ Component │ Count │ Tokens │
├─────────────────┼────────┼───────────┤
│ Agents │ N │ ~X,XXX │
│ Skills │ N │ ~X,XXX │
│ Rules │ N │ ~X,XXX │
│ MCP tools │ N │ ~XX,XXX │
│ CLAUDE.md │ N │ ~X,XXX │
└─────────────────┴────────┴───────────┘
WARNING: Issues Found (N):
[token 節約量の降順]
Top 3 Optimizations:
1. [action] → save ~X,XXX tokens
2. [action] → save ~X,XXX tokens
3. [action] → save ~X,XXX tokens
Potential savings: ~XX,XXX tokens (XX% of current overhead)
```
verbose mode ではさらにファイルごとの token 内訳、最重ファイルの行単位ブレークダウン、重複行の対比、MCP tool 一覧 + tool ごとの schema サイズ推定を出す。
## 例
**基本監査**
```
User: コンテキスト消費を見せて
Skill: 16 agents (12,400 tokens), 28 skills (6,200), 87 MCP tools (43,500), 2 CLAUDE.md (1,200)
Flags: 重い agent 3 個、CLI 代用可能な MCP 3 個
Top saving: MCP 3 個削除 → -27,500 tokens (overhead の 47% 削減)
```
**Verbose**
```
User: トークン内訳をファイル単位で
Skill: 上記レポートに加えて、planner.md (213 lines, 1,840 tokens) のような
per-file 行内訳、MCP tool ごとのサイズ、rule の重複行を side-by-side で表示
```
**追加前チェック**
```
User: MCP server を 5 個追加したいが、空きある?
Skill: 現状 33% → 5 server (≈ 50 tools) 追加で +25,000 tokens → 45% に到達
推奨: CLI 代用可能な server 2 個を先に外して 40% 以下を維持
```
## ベストプラクティス
- **トークン推定**: prose は `words × 1.3`、code 主体は `chars / 4`
- **MCP は最大のレバー**: tool あたり ~500 token、30-tool server ひとつで全 skill より大きい
- **agent description は常時ロード**: 呼ばれない agent でも description は毎 Task 投入
- **verbose は debug 用**: 普段は使わない
- **変更後は監査**: agent/skill/MCP 追加直後に走らせて creep を早期発見
## Misskey 固有メモ
- Misskey は MCP server をプロジェクトで明示登録していないため (`.mcp.json` 不在)、現状 overhead の支配項は CLAUDE.md と公式プラグイン群の skills / agents description である。
- ECC プラグインがユーザースコープで `installed_plugins.json` に存在するため、プロジェクトで `enabledPlugins` に追加していなくても system reminder に 200+ skill が現れる。これらは description が短いので個別 overhead は小さいが、合計値の確認に本 skill を使う。

View File

@@ -0,0 +1,156 @@
---
name: create-migration
description: Misskey の TypeORM マイグレーションを公式 CLI (migration:generate / migration:create) で正しく生成し、SPDX ヘッダー付与・up/down 整合・check-migrations 確認まで誘導する。エンティティのスキーマ変更を含むあらゆる DB 変更、または手書き SQL によるデータ移行が必要な時に使用する。
---
# Misskey マイグレーション作成スキル
`packages/backend/migration/` に新規 TypeORM マイグレーションを追加するためのワークフロー。
## 大前提 (絶対 NG)
- **既にマージ済み (develop / master) のマイグレーションファイルを編集しない** ([AGENTS.md §3](../../../AGENTS.md#3-マージ済み-migration-を絶対に編集しない))。本番履歴の改変は深刻なデータ不整合を引き起こす。スキーマ変更は **常に新しいタイムスタンプで新規ファイル** を作る。
- ファイル名のタイムスタンプ部分を後から書き換えない (順序が壊れる)。
> 作り方は AGENTS.md §3 の「`Date.now()` で UNIX ms を取得 → `{ms}-{PascalName}.js` を手書き」が最低ライン。エンティティ差分から自動生成したい (= TypeORM の `migration:generate` を使う) 場合は本 skill の手順に従う。**どちらでも構わない**が、エンティティ変更を伴う時は CLI 経由のほうが取り漏れが減るので推奨。
## ステップ 1: どちらの方式を使うか決める
| 状況 | 方式 |
|---|---|
| エンティティ (`packages/backend/src/models/*.ts`) を `@Column` / `@Index` / `@Entity` 等で先に変更し、差分から自動生成したい | `typeorm migration:generate` (本 skill の手順) |
| 手書き SQL / データ移行 / `CREATE INDEX CONCURRENTLY` など、エンティティ差分では表現できない変更 | `typeorm migration:create` で空雛形を作るか、`migrate-new` command で手書き雛形を作る |
| 列追加 1 本のような小規模変更で、既存ファイルをコピーした方が速い | AGENTS.md §3 の手順 (`Date.now()` + 手書き) でよい |
迷ったら **まずエンティティを変更 → `migration:generate`** が原則。既存 342 ファイルのほぼすべてが `queryRunner.query(\`SQL...\`)` の raw SQL なので、CLI 出力でも手書きでもスタイルは揃う。
## ステップ 2: CLI 実行
ルートディレクトリから以下を実行する。`<PascalName>` は変更内容を表す PascalCase (例: `AddBirthdayIndex`, `AddCategoryToAvatarDecorations`)。
### 2-A. エンティティ差分から生成
[CONTRIBUTING.md §Migration作成方法](../../../CONTRIBUTING.md#migration作成方法) に記載の基本形:
```bash
# packages/backend ディレクトリで実行する場合 (CONTRIBUTING.md 記載形式)
pnpm dlx typeorm migration:generate -d ormconfig.js -o --esm <PascalName>
```
**リポジトリルートから実行する場合** (AI が使う推奨形式。`pnpm --filter backend exec` を使うと backend の TypeORM バージョンと一致するため確実):
```bash
pnpm --filter backend exec typeorm migration:generate -d ormconfig.js -o --esm migration/<PascalName>
```
> **`--esm` について**: `-o` / `--outputJs` は「TS ではなく JS を出力する」オプション、`--esm` は「ESM 形式 (`export class ...`) で出力する」オプション。Misskey の既存 migration はすべて ESM JS であるため **両方が必須**。`--esm` を省略すると CommonJS 形式の JS が生成されスタイルが揃わない。
事前準備:
- `pnpm build-pre` を実行して `built/meta.json` を生成する (`loadConfig()` が `built/meta.json` を必須とするため。`pnpm build` 済みであれば不要)。
- `.config/default.yml` が存在すること (なければ `.config/example.yml` を参考に作成する)。
- `pnpm --filter backend compile-config` を実行して `built/.config.json` を生成する (`ormconfig.js` が `loadConfig()` 経由で必須とする。未実行だと "Compiled configuration file not found." エラーになる)。
- `pnpm --filter backend build` でエンティティを最新ビルド (CLI は `built/` を読む)。
- ローカル DB を起動する (`docker compose -f compose.local-db.yml up -d`)。
### 2-B. 空の手書きマイグレーション
```bash
pnpm --filter backend exec typeorm migration:create -o --esm migration/<PascalName>
```
ローカル DB の起動とビルドは不要。空の `up` / `down` だけが生成される。
> `-o --esm` を **必ず付ける**。これが無いと `<UnixMs>-<PascalName>.ts` (CommonJS / TS 出力) が生成されるが、Misskey の `ormconfig.js` は `migration/*.js` だけを読み、既存の他 migration も全て `export class ... { async up(queryRunner) {...} }` の ESM JS 形式なので、後で手作業で `.ts → .js` リネーム + `import { MigrationInterface }` 削除 + `class ... implements MigrationInterface` 削除をしないと走らない。`-o --esm` を付ければそのまま `.js` ESM で出るので、後処理は SPDX ヘッダー付与 (ステップ 3) だけで済む。
## ステップ 3: SPDX ヘッダー付与
CLI 出力には SPDX ヘッダーが含まれない。**必ず冒頭に追加する** (CI の `spdx` ジョブが失敗するため)。
```js
/*
* SPDX-FileCopyrightText: syuilo and misskey-project
* SPDX-License-Identifier: AGPL-3.0-only
*/
```
## ステップ 4: up / down の整合確認
- `up()` の各ステートメントに対し、`down()` で完全に巻き戻せること。
- 列追加 (`ADD COLUMN`) ↔ 列削除 (`DROP COLUMN`)、テーブル作成 ↔ テーブル削除、
FK 追加 ↔ FK 削除、インデックス作成 ↔ インデックス削除 を必ずペアで書く。
- `down()` を空のまま残さない。本番ロールバック時に詰む。
### インデックス追加時の注意 (CREATE INDEX CONCURRENTLY)
大規模テーブルへの `CREATE INDEX` は本番で長時間ロックする恐れがある。`CONCURRENTLY` で発行するときは **migration 側にも対応が必要**: PostgreSQL は `CREATE INDEX CONCURRENTLY` を transaction 内で実行できないため、migration class に以下を仕込んで TypeORM に「この migration は transaction を張らない」と指示する。
参照実装: [packages/backend/migration/1745378064470-composite-note-index.js](../../../packages/backend/migration/1745378064470-composite-note-index.js)。
```js
const isConcurrentIndexMigrationEnabled = process.env.MISSKEY_MIGRATION_CREATE_INDEX_CONCURRENTLY === '1';
export class CompositeNoteIndex1745378064470 {
name = 'CompositeNoteIndex1745378064470';
transaction = isConcurrentIndexMigrationEnabled ? false : undefined;
async up(queryRunner) {
const concurrently = isConcurrentIndexMigrationEnabled;
if (concurrently) {
// CREATE INDEX CONCURRENTLY ...
} else {
// CREATE INDEX ...
}
}
async down(queryRunner) {
// 同様に環境変数で分岐
}
}
```
要点:
- **`transaction = isConcurrentIndexMigrationEnabled ? false : undefined;`** が必須。これがないと `CREATE INDEX CONCURRENTLY` が transaction 内で実行されて `ERROR: CREATE INDEX CONCURRENTLY cannot run inside a transaction block` で失敗する。
- 環境変数 `MISSKEY_MIGRATION_CREATE_INDEX_CONCURRENTLY=1` がデフォルト OFF。OFF のときは普通の `CREATE INDEX` (transaction 内) で動く必要がある。`up`/`down` 双方を環境変数で分岐させる。
- `ormconfig.js` の `migrationsTransactionMode` は **環境変数で切り替わる**: `MISSKEY_MIGRATION_CREATE_INDEX_CONCURRENTLY=1` のときだけ `'each'` (各 migration が個別 transaction)、未設定時は `'all'` (全 migration を 1 つの transaction でラップ) ([ormconfig.js:19](../../../packages/backend/ormconfig.js#L19))。普段は `'all'` 前提なので、CONCURRENTLY を使う migration を書く時だけこのフラグの存在を意識すれば良い。
### 関連エンティティとの一致
`migration:generate` を使った場合、エンティティ側の `@Column` / `@Entity` 修正と DB スキーマが食い違うとビルド全体がズレる。生成後に該当エンティティと SQL の対応を目視確認すること。
## ステップ 5: 検証
ルートから実行:
```bash
# 未反映の差分が無いか (新規 migration が生成すべき DDL を取り逃していないか)
pnpm --filter backend check-migrations
# ローカル DB に適用
pnpm migrate
# ロールバック (down が壊れていないか)
pnpm revert
# 再適用 (順方向にもう一度通す)
pnpm migrate
```
`check-migrations` の実体は [scripts/check_migrations_clean.js](../../../packages/backend/scripts/check_migrations_clean.js)。TypeORM の `dataSource.driver.createSchemaBuilder().log()` で pending DDL を取得し、`upQueries` / `downQueries` のいずれかが残っていれば非ゼロ終了する。**順序検査ではなく**「エンティティと migration が同期しているか」の検査。
## ステップ 6: 既存ファイル参照テンプレ
新規ファイルを書くときは、変更パターンが近い既存ファイルを **必ずひとつ開いて並べて書く**。スタイルが激しくズレた PR は差し戻されやすい。
| パターン | 参照ファイル |
|---|---|
| インデックス追加 + 関数定義 | [packages/backend/migration/1767169026317-birthday-index.js](../../../packages/backend/migration/1767169026317-birthday-index.js) |
| 列追加のみ | [packages/backend/migration/1766652173085-add-category-to-avatar-decorations.js](../../../packages/backend/migration/1766652173085-add-category-to-avatar-decorations.js) |
| テーブル新規作成 + FK | [packages/backend/migration/1761569941833-add-channel-muting.js](../../../packages/backend/migration/1761569941833-add-channel-muting.js) |
クラス命名規則は **PascalCase 名 + 13 桁タイムスタンプ** (例: `class BirthdayIndex1767169026317`)。`name` プロパティもクラス名と同一文字列にする。
## ステップ 7: CHANGELOG (ユーザー影響がある場合)
スキーマ変更がユーザーに見える挙動を生む場合のみ、`CHANGELOG.md` の `## Unreleased` → `### Server` または `### General` に 1 行追加する ([AGENTS.md §CHANGELOG](../../../AGENTS.md#changelog) 参照)。内部リファクタや純粋なインデックス追加は不要。

View File

@@ -1,3 +1,54 @@
# Copilot Instructions for Misskey
- en-US.yml を編集しないでください。
このファイルは GitHub Copilot の repository-wide instructions として使われる。Copilot code review では `AGENTS.md` が読まれない環境があるため、レビューや軽微な実装判断に必要な規約はこのファイル単体で満たすこと。
このリポジトリは Misskey の pnpm workspace モノレポ。主要な実装は `packages/backend` (NestJS / TypeORM) と `packages/frontend` (Vue 3) にある。より詳しいガイドはリポジトリルートの `AGENTS.md` を参照してよいが、このファイルの要件を省略してそちらへの参照だけで済ませないこと。
## Always follow
- AGPL-3.0-only 管轄かつ SPDX CI 対象ディレクトリに新規 `.ts` / `.js` / `.cjs` / `.mjs` / `.scss` ファイルを追加する場合は、必ず次の SPDX ヘッダーを付ける。詳細な対象判定は `AGENTS.md``.github/workflows/check-spdx-license-id.yml` を参照すること。
```text
/*
* SPDX-FileCopyrightText: syuilo and misskey-project
* SPDX-License-Identifier: AGPL-3.0-only
*/
```
- AGPL-3.0-only 管轄かつ SPDX CI 対象ディレクトリに新規 `.vue` / `.html` ファイルを追加する場合は、必ず次の SPDX ヘッダーを付ける。
```text
<!--
SPDX-FileCopyrightText: syuilo and misskey-project
SPDX-License-Identifier: AGPL-3.0-only
-->
```
`packages/misskey-js` は MIT ライセンスのサブパッケージなので、この AGPL ヘッダーを一律に付けない。サブパッケージ固有の `package.json` / `LICENSE` / 既存ファイルのヘッダーに従う。
- `locales/` 配下の YAML は `ja-JP.yml` のみ手動編集してよい。他言語は Crowdin の自動配信先なので手動編集しないこと。
- `packages/backend/migration/{timestamp}-*.js` のうち、既にマージ済みの migration は絶対に編集しない。スキーマ変更が必要な場合は新しい timestamp で migration を追加し、`up()``down()` の両方を実装すること。
- ユーザー影響のある変更は `CHANGELOG.md``## Unreleased` 配下の `### General` / `### Client` / `### Server` のいずれかに 1 行追加する。内部リファクタのみなら不要。
- API 変更時は `pnpm build-misskey-js-with-types` の実行が必要になる。
## Validation
- 全体ビルド: `pnpm build`
- 全体 lint / typecheck: `pnpm lint`
- Backend unit test: `pnpm --filter backend test`
- Backend e2e test: `pnpm --filter backend test:e2e`
- Backend federation test: `pnpm --filter backend test:fed`
- Frontend test: `pnpm --filter frontend test`
- Migration 差分検査: `pnpm --filter backend check-migrations`
> **backend テスト (`test` / `test:e2e` / `test:fed`) 実行前に `.config/test.yml` が必要。** 未作成の場合は `ncp .github/misskey/test.yml .config/test.yml` (または `cp .github/misskey/test.yml .config/test.yml`) を実行してから走らせる。各テストスクリプトが内部で `cross-env NODE_ENV=test pnpm compile-config` を呼ぶため、コピー済みであれば追加の compile-config は不要。
変更範囲に応じて最も近いコマンドから優先して検証し、必要なら全体コマンドに広げること。
## Editing hints
- Backend の API / migration / TypeORM 変更は `packages/backend` を見る。
- Frontend の Vue コンポーネントやページ変更は `packages/frontend` を見る。
- `AGENTS.md` 内の相対リンクはリポジトリルート起点で解決する想定。
> `AGENTS.md` はより詳細な正典だが、Copilot code review ではこのファイルが主な入口になる。両方が読まれる環境では `AGENTS.md` を補助情報として使ってよい。

139
AGENTS.md Normal file
View File

@@ -0,0 +1,139 @@
# Misskey AI Agent Guide
このファイルは Misskey リポジトリで動く AI コーディングエージェント (Claude Code / OpenAI Codex / GitHub Copilot 等) が共通で参照する **最低限のルールと索引**。次の 3 経路から参照・読み込みされる:
- **Claude Code**: ルート `CLAUDE.md` から `@AGENTS.md` で取り込まれる
- **OpenAI Codex**: ルート `AGENTS.md` を直接読み込む
- **GitHub Copilot**: `.github/copilot-instructions.md` (本ファイルを参照しつつ、Copilot code review 向けに必須規約を再掲するファイル) 経由で参照する
人間 contributor 向けの一般規約 (Issue / PR の出し方、ActivityPub 拡張など) は [CONTRIBUTING.md](CONTRIBUTING.md) を参照。本ファイルは AI が **コードを書く・直す** 際に踏み外してはいけない事項に絞っている。
---
## 事故直結ルール (必ず守る)
違反すると CI 失敗または本番事故になる。順守すること。
### 1. SPDX ヘッダー必須
AGPL-3.0-only 管轄かつ SPDX CI 対象ディレクトリに新規 `.ts` / `.js` / `.cjs` / `.mjs` / `.vue` / `.scss` / `.html` ファイルを追加する場合、冒頭に以下を必ず付ける。欠落すると CI (`spdx` ジョブ) が失敗する。CI の対象判定は [.github/workflows/check-spdx-license-id.yml](.github/workflows/check-spdx-license-id.yml) の `directories` 配列を参照 (`*.config.{ts,js,cjs,mjs}``*eslint*` は除外)。
`packages/misskey-js` は MIT ライセンスのサブパッケージなので、この AGPL ヘッダーを一律に付けない。サブパッケージ固有の `package.json` / `LICENSE` / 既存ファイルのヘッダーに従う。
`.ts` / `.js` / `.cjs` / `.mjs` / `.scss`:
```text
/*
* SPDX-FileCopyrightText: syuilo and misskey-project
* SPDX-License-Identifier: AGPL-3.0-only
*/
```
`.vue` / `.html` (HTML コメント形式):
```text
<!--
SPDX-FileCopyrightText: syuilo and misskey-project
SPDX-License-Identifier: AGPL-3.0-only
-->
```
### 2. locales/*.yml は `ja-JP.yml` のみ編集可
`locales/` 配下の YAML は **`ja-JP.yml` のみ手動編集してよい**。他言語ファイル (`en-US.yml` 等) は Crowdin の自動配信先で、手動編集すると上書きで失われる。根拠: `locales/README.md` (ja-JP.yml 以外を手動編集しない運用) と `crowdin.yml` (`ja-JP.yml``locales/%locale%.yml` の同期設定)。
### 3. マージ済み migration を絶対に編集しない
`packages/backend/migration/{unixMs}-{PascalName}.js` のうち、既に `develop` / `master` にマージ済みのファイルは **絶対に変更しない**。本番環境で履歴改変が起きると深刻なデータ不整合を引き起こす。
スキーマ変更が必要な場合は **新しいタイムスタンプで新規ファイル** を作成する:
- ファイル名: `node -e "console.log(Date.now())"` で UNIX ms を取得し、`{ms}-<descriptive-name>.js` として置く。命名スタイルは既存履歴で混在しており (`1716129964060-ChannelIdDenormalizedForMiPoll.js` のような PascalCase、`1721666053703-fixDriveUrl.js` のような camelCase、`1672704136584-remove-latestStatus.js` のような kebab-case)、変更を表す単一の英語名であれば良い。クラス名側は PascalCase + 13 桁タイムスタンプ (`class FixDriveUrl1721666053703 { ... }`) を必ず守ること。
- `up()``down()` の両方を必ず実装する (`down``up` の完全な巻き戻し)。
- `pnpm --filter backend check-migrations` を通す。これは **TypeORM schema builder で pending DDL を検出する** 検査 ([packages/backend/scripts/check_migrations_clean.js](packages/backend/scripts/check_migrations_clean.js))。エンティティの `@Column` / `@Entity` 変更が migration に取り込まれていないとここで検出される。タイムスタンプの順序自体を直接検査するわけではない (順序が壊れた場合の失敗は別経路で出る)。
エンティティ差分から TypeORM CLI で自動生成したい / `CREATE INDEX CONCURRENTLY` 等のオプションを使いたい場合は [.claude/skills/create-migration/SKILL.md](.claude/skills/create-migration/SKILL.md) を参照。手書き / CLI どちらの方式でも上記 3 点 (履歴改変禁止 / `up`+`down` / `check-migrations`) が満たせれば良い。
---
## 必須コマンド
| 用途 | コマンド |
| --- | --- |
| 全体ビルド | `pnpm build` |
| 開発サーバー (backend + frontend watch) | `pnpm dev` |
| Lint (typecheck + eslint, 全パッケージ) | `pnpm lint` (= `pnpm --no-bail -r lint`。最初の失敗で止まらず全パッケージの結果を収集する) |
| Backend unit test (Vitest) | `pnpm --filter backend test` |
| Backend e2e test | `pnpm --filter backend test:e2e` |
| Backend federation test | `pnpm --filter backend test:fed` |
| Frontend test (Vitest) | `pnpm --filter frontend test` |
| Cypress E2E (要 `start:test`) | `pnpm e2e` |
| Storybook dev (frontend) | `pnpm --filter frontend storybook-dev` |
| Migration 適用 | `pnpm migrate` |
| Migration ロールバック | `pnpm revert` |
| Migration の pending DDL 検査 (エンティティ差分の取り込み漏れ検出) | `pnpm --filter backend check-migrations` |
| `misskey-js` 再生成 (API 変更後必須) | `pnpm build-misskey-js-with-types` |
> Backend の TypeScript 型チェックは `pnpm --filter backend typecheck` (tsgo)。
> 個別ファイルへの ESLint --fix は `pnpm exec eslint --fix <path>`。
> **backend テスト (`test` / `test:e2e` / `test:fed`) 実行前に `.config/test.yml` が必要** (未作成だとテスト自体が起動しない)。コピー手順と詳細は [.claude/docs/testing.md §Backend 全般の前提](.claude/docs/testing.md#backend-全般の前提-configtestyml) を参照。
---
## CHANGELOG
ユーザー影響のある変更 (機能追加・修正・改善) は `CHANGELOG.md` の冒頭 `## Unreleased` セクションに 1 行追加する。リファクタリング等の内部変更は不要。
### セクション構造
`## Unreleased` 配下に **3 つのサブセクション** が用意されている:
- `### General` — 共通 / 横断的な変更
- `### Client``packages/frontend`
- `### Server``packages/backend`
### エントリ書式
該当サブセクションに `- <Prefix>: <概要>` の形式で追加。Prefix は先頭大文字。
```text
- Enhance: ノートの詳細表示での公開範囲の表示を改善
- Fix: 通知が約10秒遅延する問題を修正
- Feat: 新機能の追加
```
### 触ってはいけない範囲
- `## Unreleased` **以外** のセクション (過去リリース) は変更しない。
- `## Unreleased` の見出しと 3 つの空サブセクション骨格自体は維持する (リリーススクリプトが期待する構造)。
> 参考: コミットメッセージ側は `enhance(frontend): ...` / `fix(backend): ...` の小文字 + スコープ形式 ([CONTRIBUTING.md](CONTRIBUTING.md) 参照)。CHANGELOG とは書式が異なる点に注意。
---
## オンデマンド参照 (必要時に Read すること)
以下は AI が **作業対象に応じて必要なときだけ** 開く詳細ドキュメント。常時コンテキストには載せない。
| 何をしたい時 | 参照先 |
| --- | --- |
| パッケージ構成・依存関係を把握したい | [.claude/docs/architecture.md](.claude/docs/architecture.md) |
| `packages/backend` を編集する (NestJS / TypeORM / migration / API endpoint) | [.claude/docs/backend.md](.claude/docs/backend.md) |
| `packages/frontend` を編集する (Vue 3 / Mk* / i18n / SCSS module / `os.ts`) | [.claude/docs/frontend.md](.claude/docs/frontend.md) |
| テストを書く・走らせる (Vitest / Cypress / Storybook) | [.claude/docs/testing.md](.claude/docs/testing.md) |
| 有効化済 Claude Code プラグインの用途を確認 | [.claude/docs/plugins.md](.claude/docs/plugins.md) |
---
## ツール固有の補助ファイル
`.claude/` 配下は Claude Code 固有の skills / agents / slash commands を集約している (Codex / Copilot は読み飛ばしてよい):
- `.claude/skills/` — 繰り返しタスク用の skill 定義 (例: `add-api-endpoint`, `create-migration`)
- `.claude/agents/` — 専門レビューエージェント (例: `misskey-api-reviewer`, `vue-component-reviewer`)
- `.claude/commands/` — Claude Code のスラッシュコマンド (例: `/check-misskey-js`, `/changelog-add`)
- `.claude/docs/` — オンデマンド参照ドキュメント (上記の表で示したもの。Codex / Copilot からも内容自体は読める)
- `.claude/settings.json` — Claude Code の有効プラグイン (`enabledPlugins`) のみを記載した共有設定。hook は意図的に登録しない (各 contributor が `.claude/settings.local.json` で opt-in する方針)
- `.claude/settings.local.json` — 個人ローカル設定 (`.gitignore` 済)
サードパーティ由来 (everything-claude-code 由来の MIT ライセンスファイル等) の出典は [.claude/THIRD_PARTY_LICENSES.md](.claude/THIRD_PARTY_LICENSES.md) を参照。

7
CLAUDE.md Normal file
View File

@@ -0,0 +1,7 @@
# Misskey Claude Code Guide
ルール本体は [AGENTS.md](AGENTS.md) (Codex / Copilot と共有する単一ソース)。本ファイルは Claude Code 用の薄いラッパーで、`@AGENTS.md` 構文で本体規約をセッション開始時にコンテキストへ展開する。
Claude Code 固有の補助 (skills / agents / slash commands / docs) は `.claude/` 配下にコミット済。個人ローカル設定は `.claude/settings.local.json` に、MCP 認証情報は `.claude/.credentials.json` に置く (いずれも `.gitignore` 済)。
@AGENTS.md

View File

@@ -575,11 +575,12 @@ enumの列挙の内容の削除は、その値をもつレコードを全て削
### Migration作成方法
packages/backendで:
```sh
pnpm dlx typeorm migration:generate -d ormconfig.js -o <migration name>
pnpm dlx typeorm migration:generate -d ormconfig.js -o --esm <migration name>
```
- 生成後、ファイルをmigration下に移してください
- 作成されたスクリプトは不必要な変更を含むため除去してください
- `-o` (`--outputJs`) で JS 形式、`--esm` で ESM 形式に生成する。Misskey の既存 migration はすべて ESM JS なので両方のオプションが必要
### コネクションには`markRaw`せよ
**Vueのコンポーネントのdataオプションとして**misskey.jsのコネクションを設定するとき、必ず`markRaw`でラップしてください。インスタンスが不必要にリアクティブ化されることで、misskey.js内の処理で不具合が発生するとともに、パフォーマンス上の問題にも繋がる。なお、Composition APIを使う場合はこの限りではない(リアクティブ化はマニュアルなため)。