编码技能发展报告
1 分•作者: juntz•3 个月前
博客：https://juntz-g1thub.github.io/#post=coding-skills-dev
代码库：https://github.com/juntz-g1thub/CodingSkills.git
背景
最近我一直在尝试“vibe coding”（一种编程方式）。我使用 OpenCode 作为我的开发工具。在开发 TUI（终端用户界面）程序时，AI 辅助的代码修改被证明非常困难——每一个小的 bug 修复都需要反复的手动测试，然后将结果反馈给代理非常麻烦。特别是对于 TUI 级别的反馈，我需要手动截图或输入提示。一度我几乎放弃了 AI 辅助开发。
受到这个问题的启发，我开始研究 MCP（多模态通信协议）工具。为了帮助代理更好地利用这些 MCP 工具，我开发了一套结合了一个或多个工具的技能。这些技能已经被打包并发布到 npm。
已发布的技能
1. agc-debug — TUI 程序调试工作流
解决的问题
在开发 TUI 程序时，AI 代码更改需要反复的手动测试。TUI 级别的反馈尤其痛苦——要么手动截图，要么输入提示，导致效率低下。
使用 tui-mcp MCP 服务器：
launch - 启动 TUI 程序
screenshot - 捕获 PNG 快照
snapshot - 捕获文本快照
send_keys/send_text - 发送键盘/文本输入
wait_for_text/wait_for_idle - 等待特定模式或终端空闲
resize - 调整终端大小以测试响应式布局
2. agc-explore — CodeGraph 优先的代码探索
解决的问题
当子代理探索代码时，它们经常会反复嵌套 grep/read 调用，导致效率低下。CodeGraph 一次调用就能返回 grep+read 多次迭代才能获得的结果。
3. agc-refactor — 复杂重构工作流
解决的问题
复杂的代码设计重构需要多分支推理、迭代验证和视觉快照比较。常规的重构常常让你怀疑“我做得对吗？”
架构
CodeGraph → Yggdrasil MCP（多分支推理 + 会话持久化）→ TUIdbug（视觉验证）
↓
Shell 脚本（状态管理）
↓
Git Worktree（按需隔离）
核心脚本
脚本用途
check-mcp-config.sh 检查并安装所需的 MCP 配置
refactor-state.sh 管理重构会话状态
screenshot-manager.sh 截图捕获、比较、归档
yggdrasil-helper.sh Yggdrasil 会话管理
依赖项
MCP 服务器：yggdrasil-mcp, tui-mcp, codegraph
子技能：using-git-worktrees, systematic-debugging
4. agc-docs — 项目文档标准
解决的问题
通用的文档标准不符合实际项目需求。每次编写文档时，你都必须纠结格式、命名和内容要求。
核心方法
不应用通用规则：
访谈用户以了解项目背景
生成项目特定的文档/DOC-SPEC.md
在整个开发生命周期中强制执行项目标准
初始化问卷
问题选项
项目类型：应用程序/库&SDK/基础设施/混合
团队规模：个人/小团队（2-10人）/中等/大团队（10+人）
文档类型：README, CHANGELOG, API, ADR, 用户指南...
特殊要求：命名约定、格式偏好、工具要求...
触发规则
以下操作会自动检查 DOC-SPEC：
创建/修改 docs/ 目录下的 .md 文件
创建/修改项目根目录下的 .md 文件
版本发布
PR 创建
模板库
安装
npm install @juntz/coding-skills
查看原文
BLOG: https://juntz-g1thub.github.io/#post=coding-skills-dev
REPO: https://github.com/juntz-g1thub/CodingSkills.git<p>Background
Recently I've been experimenting with vibe coding. I'm using OpenCode as my development tool. When developing TUI programs, AI-assisted code modification proved extremely difficult — every small bug fix required repeated manual testing, and feeding those results back to the agent was cumbersome. Especially for TUI-level feedback, I'd either take screenshots manually or type prompts. At one point, I nearly gave up on AI-assisted development.<p>Motivated by this, I started researching MCP tools. To help agents better utilize these MCP tools, I developed a set of skills combining one or more of them. These skills have been packaged and published to npm.<p>Released Skills
1. agc-debug — TUI Program Debugging Workflow
Problem Solved
When developing TUI (Terminal User Interface) programs, AI code changes require repeated manual testing. TUI-level feedback is particularly painful — either manual screenshots or typing prompts, resulting in low efficiency.<p>Using the tui-mcp MCP server:<p>launch - Start TUI program
screenshot - Capture PNG snapshot
snapshot - Capture text snapshot
send_keys/send_text - Send keyboard/text input
wait_for_text/wait_for_idle - Wait for pattern or terminal idle
resize - Resize terminal to test responsive layouts<p>2. agc-explore — CodeGraph-First Exploration
Problem Solved
When subagents explore code, they often nest grep/read calls repeatedly, resulting in low efficiency. CodeGraph can return in one call what would take dozens of grep+read iterations.<p>3. agc-refactor — Complex Refactoring Workflow
Problem Solved
Complex design refactoring requires multi-branch reasoning, iterative verification, and visual snapshot comparison. Regular refactoring often leaves you wondering "did I get this right?"<p>Architecture
CodeGraph → Yggdrasil MCP (multi-branch reasoning + session persistence) → TUIdbug (visual verification)
↓
Shell Scripts (state management)
↓
Git Worktree (on-demand isolation)
Core Scripts
Script Purpose
check-mcp-config.sh Check and install required MCP configurations
refactor-state.sh Manage refactor session state
screenshot-manager.sh Screenshot capture, comparison, archival
yggdrasil-helper.sh Yggdrasil session management
Dependencies
MCP servers: yggdrasil-mcp, tui-mcp, codegraph
Sub-skills: using-git-worktrees, systematic-debugging
4. agc-docs — Project Documentation Standards
Problem Solved
Generic documentation standards don't match actual project needs. Every time you write docs, you have to纠结 format, naming, and content requirements.<p>Core Approach
Instead of applying generic rules:<p>Interview user to understand project context
Generate project-specific docs/DOC-SPEC.md
Enforce project standards throughout development lifecycle
Initialization Questionnaire
Question Options
Project type Application / Library&SDK / Infrastructure / Mixed
Team size Solo / Small team (2-10) / Medium/Large team (10+)
Doc types README, CHANGELOG, API, ADR, User Guide...
Special requirements Naming conventions, formatting preferences, tool requirements...
Trigger Rules
The following operations automatically check DOC-SPEC:<p>Creating/modifying .md files in docs/
Creating/modifying project root .md files
Version releases
PR creation
Template Library<p># Install
npm install @juntz/coding-skills