How We Automated Web Production Project Management with Claude Code: Building GitHub × Google Chat Integration in One Day

Introduction

I'm Suzuki, an engineer with 10 years of experience, currently serving as a technical manager at GleamHub Inc.

Our company undertakes multiple web production projects in parallel. Gratefully, the number of projects has been increasing, but what kept troubling us was the cost and operational overhead of project management.

Tool history — Notion → Google Workspace → GitHub

At first, we managed projects using Notion and JIRA. Functionally, they left nothing to be desired, but as projects multiplied, the tool costs became impossible to ignore. For a small web production team, a recurring fixed cost of tens of thousands of yen each month just for management tools was heavy.

That was when Google Workspace caught our attention. We use Google Workspace as the foundation for our business operations, consolidating email, Calendar, Drive, and Chat all in one place. We wondered: couldn't we run project management on this platform we were already paying for?

We actually created a task management sheet in Google Sheets and built a simple dashboard using AppSheet. Honestly, though, it didn't feel right. Sheets tended to require manual data entry and updates, and while AppSheet offered flexibility, its UI wasn't specialized for project management. In the end, we couldn't escape "management for the sake of management."

The real challenge: Cross-project management of contractor members

Even more critical than tool selection was managing contractor members across multiple projects.

We often bring in designers and coders on a contractor basis, but we lacked a way to see at a glance which project tasks members working across multiple engagements held and what was currently in progress. As a result, we sometimes inadvertently overworked them without realizing it.

In short, whether we spent money on tools or not, we were unable to accurately grasp member workload — that was our biggest challenge.

The solution: GitHub Projects × Google Chat × Claude Code

What we ultimately arrived at was GitHub Projects. We were already using GitHub for development, so the additional cost was zero. Projects v2's board features are on par with Notion and JIRA, and using an Organization Project lets us manage issues across all projects on a single screen. Meanwhile, daily communication remains right where it was in Google Chat.

We built this integration foundation connecting GitHub Projects and Google Chat in one day using Claude Code. In this article, we share the complete picture and how we actually created it.

---

What we built: Overall system overview

What we built is a project management system that integrates GitHub Projects and Google Chat.

The key point is that while repositories and issues are separated by project, all project issues are consolidated onto one screen via a GitHub Organization Project. This makes it immediately clear at a glance that, for example, "Person A has design work for Project X and coding for Project Y, both currently in progress."

GitHub Organization Project（全案件を横断して一覧表示）
    │
    ├── 案件A リポジトリ ─── Issues ──┐
    ├── 案件B リポジトリ ─── Issues ──┼── 自動追加（GitHub Actions）
    └── 案件C リポジトリ ─── Issues ──┘

Google Chat（クライアントとのやりとり）
    │
    ├── Chat Bot（GAS）
    │     /create → GitHub Issue 作成
    │     /close  → Issue クローズ
    │     /status → 進捗一覧表示
    │
    ├── 自動通知（GitHub Actions）
    │     Issue 作成・完了時に Chat へ通知
    │
    └── Bot 投稿
          WBS 展開・日報生成の結果を Chat に投稿

Here are the six main features:

1. Unified management via Organization Project — Issues across all projects are aggregated on a single board. Grasp workload through a cross-cutting view of assignee × project
2. Automated project setup — Just provide the project name to create repositories, labels, Projects, and notification workflows all at once. Issues are automatically added to the Org Project
3. Chat bot — Typing /create デザインカンプ作成 @伊藤 in Google Chat automatically creates a GitHub issue
4. Automated notifications — Real-time notifications to Google Chat upon issue creation and completion
5. WBS rollout — Bulk-convert a Markdown WBS into GitHub issues (turning 15 tasks into issues with a single command)
6. Daily report generation — Automatically aggregate the day's changes across GitHub issues to generate reports

---

What are Claude Code "agents"?

Claude Code features the ability to define custom agents tailored to specific workflows. Simply placing a Markdown file in .claude/agents/ enables an AI assistant dedicated to that task.

This time, we defined three agents.

.claude/agents/
├── project-setup.md     # 案件セットアップ
├── report-generator.md  # 日報生成
└── space-migrator.md    # 既存スペース移行

For instance, this is all it takes to define the project setup agent.

---
name: project-setup
description: 新規案件のセットアップを実行するエージェント
tools:
  - Bash
  - Read
  - Write
---

# 案件セットアップエージェント

新規Web制作案件の GitHub 環境を構築する。

## 実行手順

1. 案件名を受け取る
2. `agents/setup/create_project.py` を実行し、以下を自動化:
   - GitHub リポジトリ作成
   - 標準ラベル作成
   - GitHub Projects (v2) 作成
   - `config/space_project_map.json` に対応情報を追加
3. 結果を報告する

With this, simply telling Claude Code to "set up a project named 'ThemeX Corporate Site'" completes the GitHub environment configuration. A task that takes 10 to 15 minutes manually is done in seconds.

Furthermore, issues in the newly created project repository are automatically added to the Organization Project via GitHub Actions. There is no need to configure each project individually; Claude Code handles everything, including workflows, during setup.

---

Implementation process: 8 steps in one day

For this system, we handed design specifications prepared in advance to Claude Code and implemented it incrementally across 8 steps.

Here is our actual commit history.

592220e fix: Chat 通知を curl 方式に変更
7456d4f feat: WBS 展開スクリプト実装（Step 8）
92040c2 feat: 既存スペース移行スクリプト実装（Step 7）
b2d92ae feat: Chat API クライアント・GAS Bot・通知連携・日報生成を実装（Step 3〜6）
6ef13ec feat: 初期構築（環境整備 + GitHub API クライアント実装）

At each step, we cycled through "dry-run → operation verification → approval → actual execution." To ensure Claude Code never modifies the production environment arbitrarily, we explicitly stated safety rules in CLAUDE.md.

## 安全ルール

- `.env` と `credentials/` を絶対にコミットしない
- 破壊的 API 操作（リポジトリ削除等）は実装しない
- 本番デプロイ・費用が発生する API・公開投稿は人間の承認を必須とする

---

Technical highlights

Differentiating GitHub REST API and GraphQL

Operating GitHub Projects v2 requires the GraphQL API. While issues and repositories can be manipulated via the REST API, Projects v2 board management (adding items, updating statuses) can only be achieved via GraphQL.

This time, we integrated both into a single client class.

class GitHubClient:
    """GitHub API クライアント"""

    # REST API — Issue・リポジトリ操作
    def _rest(self, method: str, path: str, *, json: dict | None = None):
        url = f"{REST_BASE}{path}"
        resp = requests.request(method, url, headers=self.headers, json=json, timeout=30)
        resp.raise_for_status()
        return resp.json()

    # GraphQL API — Projects v2 操作
    def _graphql(self, query: str, variables: dict | None = None):
        resp = requests.post(GRAPHQL_URL, headers=self.headers, json={"query": query, "variables": variables}, timeout=30)
        data = resp.json()
        if "errors" in data:
            raise RuntimeError(f"GraphQL エラー: {data['errors']}")
        return data["data"]

Adding an issue to Projects v2 is accomplished with a GraphQL mutation like this.

def add_item_to_project(self, project_id: str, content_id: str) -> dict:
    mutation = """
    mutation($projectId: ID!, $contentId: ID!) {
        addProjectV2ItemById(input: { projectId: $projectId, contentId: $contentId }) {
            item { id }
        }
    }
    """
    data = self._graphql(mutation, {"projectId": project_id, "contentId": content_id})
    return data["addProjectV2ItemById"]["item"]

Note that using the GraphQL API requires adding the project scope to the Personal Access Token. Initially, a missing scope triggered a INSUFFICIENT_SCOPES error, but Claude Code read the error message and proposed the command to add the scope (gh auth refresh -s project).

Two authentication modes of the Google Chat API

The Google Chat API offers two modes: User delegation mode and App mode.

class ChatClient:
    def _get_user_service(self):
        """ユーザー委任モード（管理ユーザーとしてスペース一覧・メッセージ取得）"""
        creds = service_account.Credentials.from_service_account_file(
            str(self._sa_file), scopes=CHAT_SCOPES
        )
        creds = creds.with_subject(self._delegated_user)  # ← ユーザーに成り代わる
        return build("chat", "v1", credentials=creds)

    def _get_app_service(self):
        """App モード（Bot 自身としてメッセージ投稿）"""
        creds = service_account.Credentials.from_service_account_file(
            str(self._sa_file), scopes=CHAT_SCOPES
        )
        # with_subject なし → Bot として動作
        return build("chat", "v1", credentials=creds)

It is a simple design switched solely by the presence or absence of with_subject(), but many people likely stumble here without knowing this. Listing spaces and reading messages requires user authorization, whereas posting as a bot requires App authorization — this distinction is key.

Bulk conversion from WBS to GitHub issues

In web production, managing tasks based on a WBS (Work Breakdown Structure) is standard practice. This time, we made it possible to bulk-convert to GitHub issues simply by writing a WBS in Markdown format like this.

## フェーズ1: デザイン

### トップページ
- [ ] ワイヤーフレーム作成 @伊藤 #期限2026-03-10
- [ ] デザインカンプ作成 @伊藤 #期限2026-03-15
- [ ] デザインレビュー・修正 @鈴木

### 下層ページ
- [ ] サービスページ デザイン @伊藤
- [ ] 会社概要ページ デザイン @伊藤

## フェーズ2: コーディング
...

The parser design is simple.

@dataclass
class WbsTask:
    title: str           # タスク名
    milestone: str = ""  # ## → マイルストーン
    section: str = ""    # ### → 工程
    assignees: list[str] = field(default_factory=list)  # @名前
    due_date: str = ""   # #期限YYYY-MM-DD

• ## heading → Milestone (phase)
• ### heading → Process (recorded in the issue body)
• - [ ] → Issue (task)
• @名前 → Assignee label
• #期限YYYY-MM-DD → Due date

Non-engineer directors can write in this format, and it also reads as a normal checklist. When we actually ran a test WBS (15 tasks), all issues were added to Projects and notifications were sent to Chat.

---

Insights gained from developing with Claude Code

"Agent capability" to resolve errors independently

Claude Code's strength lies not merely in writing code, but in executing a complete cycle to run, read errors, and correct them on its own.

During this development, various errors arose, such as missing GitHub API scopes, omissions in GAS deployment settings, and API call failures on empty repositories. Claude Code pinpointed the cause from the error messages for almost all of them, proposed fixes, and executed them.

For example, when adding a workflow file to a newly created repository, calling the API before repository initialization completed resulted in a 404 error. Claude Code responded to this by proactively adding retry logic.

CLAUDE.md becomes the "team rulebook"

The rules documented in CLAUDE.md (safety rules, coding standards, directory structure) serve as behavioral guidelines for Claude Code. This plays the same role as onboarding materials for human team members.

What is interesting is that CLAUDE.md itself evolves as you develop alongside Claude Code. Whenever a new module is added, structural descriptions are updated, and safety rules are augmented with insights gained from actual operations. It truly feels like the rules grow alongside the code.

Importance of the dry-run pattern

In scripts that call external APIs, we always implemented a dry-run mode. Instructing Claude Code to "verify with dry-run first" displays only the intended processing without actually calling the API.

# dry-run（Issue は作成しない）
uv run python agents/setup/expand_wbs.py --repo my-project --wbs wbs.md

# 実行（承認後）
uv run python agents/setup/expand_wbs.py --repo my-project --wbs wbs.md --execute

When letting an AI manipulate external resources, this "verify before execution" workflow felt essential.

---

Conclusion

After trial and error through Notion → Google Sheets → AppSheet, our project management finally settled on the combination of GitHub Projects × Google Chat × Claude Code.

Looking back, what we had overlooked in previous tool selections was not "tool features," but "operational automation." No matter how outstanding a tool is, if setup is manual, data entry is manual, and aggregation is manual, you ultimately cannot escape "management for the sake of management."

Claude Code is not merely an "AI that writes code," but a "partner that designs and builds the development process with you." It took just one day from handing over the design specifications to running an active, operational system. Differentiating REST and GraphQL for the GitHub API, designing authentication for the Google Chat API, implementing GAS bots, and integrating notifications via GitHub Actions — finishing this cross-domain development with one person + Claude Code was a major achievement.

And what had the greatest impact on me personally was cross-project unified management via Organization Projects. By consolidating issues across all projects onto one screen, we can now see at a glance what tasks contractor members hold across which projects and what is currently in progress. As a manager, making previously invisible workloads visible and preventing unwitting overwork has been a truly significant change.

What is more, whenever projects increase, simply leaving the setup to Claude Code automatically arranges everything, including workflow configuration. Even as projects grow to 10 or 20, management costs do not rise. We truly feel the power of an architecture that scales.

Cost-wise, monthly subscriptions for Notion or JIRA disappeared, and everything is fulfilled solely with GitHub and Google Workspace, which we already use. For a small web production team, acquiring a full-fledged project management foundation at zero additional cost is a substantial advantage.

Particularly in environments like contract web production teams where a small staff handles multiple projects, automating such management tasks directly boosts productivity. Eliminating "management for the sake of management" and creating an environment where we can focus on creative work — that, we believe, is the fundamental value of this automation.

---

The code examples in this article are based on actual projects, but project and client names have been altered.

---

Working toward operational efficiency powered by AI

At GleamHub Inc., we offer broad support including optimizing development processes using AI as introduced in this article, assisting with AI tool adoption, and designing development workflows.

Please feel free to contact us.

Contact us here → GleamHub Inc. Contact