In previous posts, I introduced the concept of Agent Skills and showed how to build an AI-driven development workflow with Claude Code + GitHub Copilot Review. As more products and teams embrace AI Agents, a clear architectural pattern is emerging: API + CLI + Skills. This isn’t a framework or protocol — it’s a pragmatic three-layer architecture that enables any product to become “agent-friendly” quickly.

在之前的文章中，我分別介紹了 Agent Skill 的概念以及如何用 Claude Code + GitHub Copilot Review 打造 AI 驅動的開發流程。隨著越來越多產品和團隊開始擁抱 AI Agent，一個清晰的架構模式正在浮現：API + CLI + Skills。這不是某個框架或協議，而是一種務實的三層架構，讓任何產品都能快速變得「對 Agent 友善」。

As a developer who maintains multiple open-source projects on GitHub, my daily work goes far beyond writing code. I also deal with a constant stream of issues, PR reviews, releases, and other tasks that are tedious but critical. As projects grow, this workload quickly exceeds what one person can handle efficiently.

Over the past few months, I’ve integrated Claude Code and GitHub Copilot Review into my daily development workflow, and the results have been remarkable — tasks that used to take half a day now often get done in 1-2 hours. This post shares my complete workflow and explains why I believe the developer’s own technical ability is the key to using AI tools effectively.

身為一個在 GitHub 上長期維護多個開源專案的開發者，我每天面對的不只是寫程式，還有大量的 Issue 處理、PR Review、版本發佈等瑣碎但重要的工作。隨著專案規模成長，這些工作量已經遠超一個人能高效處理的範圍。

過去一段時間，我開始將 Claude Code 和 GitHub Copilot Review 整合進我的日常開發流程，結果讓我非常驚艷——原本需要半天的工作，現在經常在 1-2 小時內就能完成。這篇文章將分享我的完整流程，以及為什麼我認為開發者本身的技術能力，才是善用 AI 工具的關鍵。

隨著 AI Agent 技術的快速發展，一個全新的概念正在改變軟體開發的工作方式：Agent Skill（代理技能）。如果你有使用過 Claude Code、Cursor 或其他 AI 輔助開發工具，可能已經接觸過類似的概念。本篇文章將深入介紹什麼是 Agent Skill，以及它如何對軟體產業帶來根本性的變化。

With the rapid evolution of AI Agent technology, a new concept is reshaping how software development works: Agent Skill. If you’ve used Claude Code, Cursor, or other AI-assisted development tools, you may have already encountered something similar. This article takes a deep dive into what Agent Skill is and how it brings fundamental changes to the software industry.

In 2025, I introduced MCP (Model Context Protocol) at the iThome Taiwan Cloud Summit. At that time, I mentioned that the official team has been continuously revising the authentication protocol to address complex authentication flows. The previous design involved DCR (Dynamic Client Registration), so as expected, on 2025/11/25, a new Authorization mechanism was released. This authentication mechanism is called “Client ID Metadata Documents, abbreviated as CIMD”.

When installing a Model Context Protocol (MCP) server, the most challenging part is often not the protocol itself, but how to establish trust between the client and server. If you’ve ever tried to connect an MCP client to an MCP server it has never encountered before, you’ve probably run into what’s known as the “registration wall”.

Pre-registering with every possible authorization server is simply not scalable, and while Dynamic Client Registration (DCR) helps, it lacks reliable mechanisms to verify client identity, making it vulnerable to phishing attacks. Beyond security concerns, DCR also creates operational overhead by generating an ever-growing number of duplicate client identities that need to be managed.

2025 年在 iThome 臺灣雲端大會介紹過 MCP (Model Context Protocol)，那時候就有提到在認證協議部分，官方其實一直都在改版解決複雜的認證流程，之前設計的 DCR (Dynamic Client Registration)，所以沒意外去年 2025/11/25 又推出一版 Authorization 機制，此認證機制取名叫『Client ID Metadata Documents 簡稱 CIMD』。

安裝 Model Context Protocol（MCP）伺服器時，最棘手的部分往往不是協議本身，而是如何讓客戶端與伺服器彼此建立信任。如果你曾嘗試讓一個 MCP 客戶端連線到一個從未接觸過的 MCP 伺服器，你大概遇過所謂的「註冊高牆（registration wall）」。

要預先在每一個可能的授權伺服器完成註冊根本無法擴展，而 Dynamic Client Registration（DCR）雖然有所幫助，但因為缺乏可靠的機制來驗證客戶端身份，所以容易遭受網路釣魚攻擊。除了安全性問題之外，DCR 還會造成營運負擔，因為它會產生越來越多需要管理的重複客戶端身份。

In the software development field, most people are no strangers to Git—the world’s most popular version control system and a foundational tool for modern collaborative development. And when we talk about Git, we can’t help but think of GitHub, the largest and most well-known open-source software platform today.

However, for many private companies or small to mid-sized teams, GitHub may not be an option due to security, cost, deployment strategies, or regulatory requirements. In such cases, what tools can serve as an internal Git repository platform? The most common choices include GitLab and Gitea, which is the focus of this article.

For some teams, Gitea might still be relatively unfamiliar. Simply put, Gitea is a lightweight, self-hosted Git platform written in Go, providing GitHub-like capabilities such as code hosting, permission management, Issues and Pull Requests, and CI/CD. You can find a more comprehensive explanation in the official documentation (Gitea Documentation). It’s cross-platform, easy to deploy, and low-maintenance, which is why it has been increasingly favored by small and medium-sized teams.

The main purpose of this article is to share why our team ultimately decided to migrate from Bitbucket Data Center to Gitea—and why we didn’t choose a more feature-rich but comparatively heavier open-source solution like GitLab.

相信在軟體開發領域，大家對 Git 應該都不陌生——這套全球最受歡迎的版本控制系統已成為現代協作開發的基礎工具。而提到 Git，就不得不想到目前全球最大且最知名的開源軟體平台 GitHub。

但在許多私人企業或中小型團隊中，如果因為安全性、成本、部署策略或法規需求等原因，而不能直接採用 GitHub，那麼有哪些工具可以作為企業內部的 Git 版本庫平台呢？最常見的選擇包含 GitLab 以及本篇將深入探討的 Gitea。

對部分團隊而言，Gitea 可能還相對陌生。簡單來說，Gitea 是一套以 Go 語言打造的極輕量、自架型 Git 平台，提供與 GitHub 類似的功能，例如程式碼託管、權限管理、Issue 與 Pull Request、CI/CD 等能力。 你也可以在官方文件中看到更完整說明（Gitea Documentation）。它跨平台、容易部署，且維護成本低，因此逐漸受到中小型團隊青睞。

本篇文章的主軸，就是要和大家分享： 為什麼我們團隊最終選擇從 Bitbucket Data Center 遷移到 Gitea？又為什麼沒有選擇 GitLab 這類功能更完整、但相對較為沉重的開源方案？