mcpField
L
linear-usage

linear-usage

github.com/fcakyon生産性1.2k37 回インストール今日更新
リポジトリ

linear-usage について

Linear と課題管理に関する実践ガイドです。課題の記述、ラベルと優先度、サイクル計画、トリアージを扱い、記述やプロジェクト運用を統一したいチーム向けです。

主な機能

  1. 01課題タイトルと説明の指針
  2. 02バグと機能要望のテンプレート
  3. 03ラベルと優先度の推奨事項
  4. 04サイクルとプロジェクト計画の実践
  5. 05トリアージと課題終了の手順
  6. 06GitHub 連携とワークフロー例

活用シーン

  1. 01再現可能なバグ報告の作成
  2. 02機能要望の受け入れ条件の定義
  3. 03チームのバックログの計画とトリアージ
  4. 04プルリクエストと Linear の課題の連携

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/fcakyon/claude-codex-settings --skill linear-usage

インストール後、Claude Code で/linear-usageを入力して読み込まれたか確認します。

詳細

Linear と課題管理のベストプラクティス

課題の記述ガイドライン

わかりやすいタイトル

問題または結果を説明するタイトルを付けます。

  • 良い例：「モバイル版 Safari でユーザーがパスワードをリセットできない」
  • 悪い例：「パスワードのバグ」
  • 良い例：「ユーザーレポートを CSV にエクスポートする機能を追加」
  • 悪い例：「エクスポート機能」
効果的な説明

次の内容を含めます。

  1. 背景： なぜこれが重要なのか
  2. 現在の動作： 現在どのようなことが起きているか（バグの場合）
  3. 期待する動作： どのように動作すべきか
  4. 再現手順： バグの場合
  5. 受け入れ条件： 完了の定義
テンプレート

バグ報告：

## Description
Brief description of the issue.

## Steps to Reproduce
1. Step one
2. Step two
3. Issue occurs

## Expected Behavior
What should happen.

## Actual Behavior
What happens instead.

## Environment
- Browser/OS
- User type

機能リクエスト：

## Problem Statement
What problem does this solve?

## Proposed Solution
High-level approach.

## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2

ラベルの分類体系

推奨ラベル

種類ラベル：

  • bug - 正常に動作していないもの
  • feature - 新しい機能
  • improvement - 既存機能の改善
  • chore - メンテナンス、リファクタリング

領域ラベル：

  • frontend、backend、api、mobile
  • または機能領域別：auth、payments、onboarding

ステータスラベル（ワークフローの状態を使用しない場合）：

  • needs-triage、blocked、needs-design
ラベル運用のベストプラクティス
  • ラベル数を管理しやすい範囲（合計15～25個）に保ちます
  • 一貫した命名規則を使用します
  • カテゴリーごとに色分けします
  • 四半期ごとに見直し、不要なラベルを整理します

優先度と見積もり

優先度レベル
  • 緊急（P0）： 本番環境の停止、セキュリティの問題
  • 高（P1）： 主要機能の障害、重要な期限
  • 中（P2）： 重要だが緊急ではないもの
  • 低（P3）： あれば便利なもの、小規模な改善
見積もりのヒント
  • 時間ではなく、相対的な規模（ポイント）を使用します
  • 所要時間ではなく、複雑さを見積もります
  • テストとレビューの時間を含めます
  • スコープが大きく変わった場合は再見積もりします

サイクル／スプリント計画

サイクル運用のベストプラクティス
  • 期間： 通常1～2週間
  • キャパシティ： 割り込みに備えて70～80％を計画します
  • 持ち越し： 項目が完了しなかった理由を確認します
  • 振り返り： サイクル終了時に簡単なレビューを行います
計画プロセス
  1. バックログの優先度を確認します
  2. 課題をサイクルに取り込みます
  3. 大きな項目（5ポイント超）を分割します
  4. 担当者を割り当てます
  5. 依存関係とブロッカーを特定します

プロジェクトの編成

プロジェクトとイニシアチブの違い

プロジェクト： 対象が明確で期間が定められた作業（1～3か月）

  • 通常は単一のチームが担当します
  • 明確な成果物があります
  • 例：「モバイルアプリ v2 のリリース」

イニシアチブ： 戦略的なテーマ

  • 複数のプロジェクトにまたがる場合があります
  • より長期的な目標です
  • 例：「プラットフォームの信頼性」
ロードマップのヒント
  • ロードマップ項目は大まかな内容に留めます
  • ステータスを定期的に更新します
  • 詳細な課題やプロジェクトにリンクします
  • ステークホルダーと共有します

トリアージのワークフロー

トリアージプロセス
  1. 新しい課題を毎日確認します
  2. 不足している情報を追加します（ラベル、優先度）
  3. 適切なチーム／担当者に割り当てます
  4. 関連する課題をリンクします
  5. 無効な場合はバックログに移動するか、クローズします
課題のクローズ

明確な理由を添えてクローズします。

  • 完了： 作業が完了しました
  • 重複： 元の課題にリンクします
  • 対応しない： 理由を説明します
  • 無効： 情報不足、再現できない

GitHub 連携

PR と課題のリンク
  • PR のタイトルまたは説明に Linear の課題 ID を記載します
  • Linear が自動的にリンクし、ステータスを更新します
  • 自動リンクできるように、課題 ID を含めたブランチ名を使用します
ワークフローの自動化
  • PR を開く → 課題が「進行中」に移動します
  • PR をマージする → 課題が「完了」に移動します
  • Linear の設定で構成します

コメント

Markdown 対応