setup

Setup TypeScript

TypeScript プロジェクトの初期セットアップを支援してください。 以下の条件に従い、品質を担保するために必要なセットアップを設計し、ユーザに確認・合意しながら進めてください。

要件

• TypeScript プロジェクトにおいて、形式的に担保可能な品質管理のセットアップを行いたい。
• 下記のものは提案に含め、ユーザの希望があればそちらを優先する

typecheck

• 型チェックを実行するコマンドを用意
  • bun run typecheck
• 最も厳しい tsconfig の定義

{
  "compilerOptions": {
    "strict": true,
    "allowUnusedLabels": false,
    "allowUnreachableCode": false,
    "exactOptionalPropertyTypes": true,
    "noFallthroughCasesInSwitch": true,
    "noImplicitOverride": true,
    "noImplicitReturns": true,
    "noPropertyAccessFromIndexSignature": true,
    "noUncheckedIndexedAccess": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,

    "isolatedModules": true,

    "checkJs": true,

    "esModuleInterop": true,
    "skipLibCheck": true
  },
}

test

• vitest などのテストフレームワークを導入する
• テストを実行するコマンドを用意

"scripts": {
  "test": "vitest"
}

lint

• 厳しめの ESLint 設定を定義
• チェックと修正を同時にできるコマンドを用意

"scripts": {
  "lint": "eslint . --fix"
}

format

• prettier のルールを定義
• チェックと修正を同時にできるコマンドを用意

"scripts": {
  "format": "prettier --write ."
}

MCP

• 必要であれば MCP を導入する
• .mcp.json を用意する

Claude Code Hooks

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "bun run typecheck"
          }
        ]
      }
    ]
  }
}

ci

• CI 設定を提案する
• 基本的に github actions を使う

進め方

1. 上記の要件を加味して、構成案をユーザに提案し、合意を取ること。

2. 合意が取れたら、セットアップ用のコマンド一覧を提示する。 bun を使っている場合の例:

   • bun run typecheck
   • bun run lint
   • bun run format
   • bun run test

3. 上記のコマンドを実行できるように実装を進める

• 必要なパッケージをインストール

• 設定ファイルを作成

  • tsconfig.json
  • .eslintrc.js
  • vitest.config.ts
  • .prettierrc
  • ci.yml

• etc.

• package.json の scripts にコマンドを追加 下記は例である。使用しているツールによってコマンドが異なる。

  "scripts": {
    "typecheck": "tsc --noEmit",
    "lint": "eslint . --ext .ts,.tsx --fix",
    "format": "prettier --write .",
    "test": "vitest",
    "check": "bun run typecheck && bun run lint && bun run format && bun run test"
  }
  

• 実行できることを確認する

4. もしユーザーが一部の設定をカスタマイズしたい場合は、その意図を確認し、最適な代替案を提案すること。

Fetch Rules

AI ルールリポジトリ (https://github.com/mrsekut/mrsekut-cc-marketplace/tree/main/rules) から当プロジェクトに適切なルールを取得し、CLAUDE.md を更新してください。

実行手順

Step 1: プロジェクト分析

以下を並行して分析し、プロジェクトタイプを特定してください：

• プロジェクト構成ファイル: package.json, Cargo.toml, pyproject.toml, go.mod, requirements.txt など
• 設定ファイル: tsconfig.json, .eslintrc, .prettierrc, webpack.config.js など
• エントリーポイント: main ファイル（index.js/ts, main.py, main.go など）
• ディレクトリ構造: src/, components/, tests/ などの構造から推測
• 既存の CLAUDE.md: 現在のルール状況の確認

Step 2: ルール取得

GitHub API を使用して利用可能なルールを確認し、プロジェクトタイプに応じて関連ルールを取得：

# 利用可能なルール一覧を取得
curl -s https://api.github.com/repos/mrsekut/mrsekut-cc-marketplace/tree/main/rules | jq -r '.[].name'

# プロジェクトタイプに基づいて関連するルールを並行取得
# 例: TypeScript React プロジェクトの場合
curl -s https://raw.githubusercontent.com/mrsekut/mrsekut-cc-marketplace/main/rules/typescript.md
curl -s https://raw.githubusercontent.com/mrsekut/mrsekut-cc-marketplace/main/rules/react.md
curl -s https://raw.githubusercontent.com/mrsekut/mrsekut-cc-marketplace/main/rules/coding.md
curl -s https://raw.githubusercontent.com/mrsekut/mrsekut-cc-marketplace/main/rules/git.md

Step 3: CLAUDE.md 更新

• 既存の CLAUDE.md をバックアップ（存在する場合）
• プロジェクト概要を含む構造化された CLAUDE.md を作成
• 取得したルールをプロジェクトの特性に合わせて統合

CLAUDE.md 構造テンプレート

# {Project Name} Project Rules

## Project Overview

- **Purpose**: {プロジェクトの目的}
- **Language**: {主要言語}
- **Framework/Runtime**: {フレームワーク・ランタイム}
- **Main Features**: {主要機能}

## Language-Specific Rules

{言語固有のルール}

## Framework-Specific Rules

{フレームワーク固有のルール（該当する場合）}

## General Coding Practices

{一般的なコーディングプラクティス}

## Git Practices

{Git 関連のプラクティス}

## Project-Specific Guidelines

{プロジェクト固有のガイドライン}

## Security Considerations

{セキュリティ考慮事項}

## Testing Strategy

{テスト戦略（該当する場合）}

重要な注意点

1. 自動プロジェクト判定

   • 複数の指標からプロジェクトタイプを総合的に判断
   • 不明な場合は基本ルール（coding.md, git.md）のみ適用

2. ルール重複の回避

   • 同じ内容のルールが複数ファイルにある場合は統合
   • プロジェクトに関係ないルールは除外

3. エラーハンドリング

   • GitHub API 制限やネットワークエラーの適切な処理
   • 既存 CLAUDE.md の保護（バックアップ作成）
   • ルールファイル取得失敗時の代替処理

4. カスタマイズ対応

   • プロジェクト固有の要件があれば Project-Specific Guidelines に追加
   • 既存ルールとの整合性を保つ

実行後の確認

• CLAUDE.md が適切に更新されているか
• プロジェクトタイプが正しく識別・反映されているか
• 必要なルールが含まれ、不要なルールが除外されているか
• ルールの重複や矛盾がないか
• プロジェクト固有の考慮事項が適切に追加されているか