Github Dev Standard Free

SKILL.md

---
name: "github-dev-standard-free"
description: "个人开发者项目开发标准流程，含 9 步开发流程与基础验收清单。"
license: Proprietary
allowed-tools: read exec
compatibility: "Requires LLM with tool-use capability"
metadata:
  displayName: "项目开发标准免费版"
  version: "1.0.0"
  summary: "个人开发者项目开发标准流程，含 9 步开发流程与基础验收清单。"
  tags:
    - "开发工具"
    - "开发规范"
    - "代码质量"
    - "项目管理"
  source: "SkillHub"
  converted_at: "2026-07-22T17:58:36"
---

# 项目开发标准（免费版）

## 概述

本工具为独立开发者提供结构化的项目开发标准流程，解决开发中常见的过度修改、无验证、夹带重构等问题。通过 9 步开发流程、8 条编码纪律、4 层验证机制和 15 项验收清单，帮助开发者建立"先定义问题、再定义改法、再写代码、再做验证、最后才发布"的工程习惯。免费版聚焦个人开发场景，提供开箱即用的流程模板与检查清单。

## 核心能力

| 能力模块 | 描述 | 解决的问题 |
| --- | --- | --- |
| 9 步开发流程 | 从需求到发布的完整流程 | 流程缺失导致返工 |
| 8 条编码纪律 | 约束修改范围与行为 | 过度修改、夹带重构 |
| 4 层验证 | 语法→导入→样例→测试 | 无验证直接发布 |
| 15 项验收清单 | 交付前的多维度检查 | 质量标准不统一 |
**技术实现要点**：核心能力基于`input_params`参数与`output_format`配置实现,支持创建/查询/修改/删除等操作模式,通过`config_options`进行运行时配置。

### 核心功能执行
用`input_params`参数进行配置。

**输入**: 用户提供核心功能执行所需的指令和必要参数。
**处理**: 按照skill规范执行核心功能执行操作,遵循单一意图原则。
**输出**: 返回核心功能执行的执行结果,包含操作状态和输出数据。
- 执行此能力时使用`input_params`参数,支持创建/查询/导出操作

### 参数配置与调用
用`config_options`参数进行配置。

**输入**: 用户提供参数配置与调用所需的指令和必要参数。
**处理**: 按照skill规范执行参数配置与调用操作,遵循单一意图原则。
**输出**: 返回参数配置与调用的执行结果,包含操作状态和输出数据。
- 执行此能力时使用`config_options`参数,支持修改/重置/导入操作

### 结果处理与输出
用`output_format`参数进行配置。

**输入**: 用户提供结果处理与输出所需的指令和必要参数。
**处理**: 按照skill规范执行结果处理与输出操作,遵循单一意图原则。
**输出**: 返回结果处理与输出的执行结果,包含操作状态和输出数据。
- 执行此能力时使用`output_format`参数,支持导出/保存/转换操作
**能力覆盖范围**：本skill的核心能力覆盖以下场景关键词：个人开发者项目开、发标准流程、步开发流程与基础、面向独立开发者的、项目开发标准化工、通过结构化流程约、束代码质量、读需求、写任务卡、条编码纪律防止过、层基础验证、项验收清单确保交、付质量等。这些关键词对应description中声明的使用场景,均已在上述能力点中提供对应的操作支持。

## 使用场景

### 场景一：缺陷修复标准化

开发者收到一个缺陷报告，需要按标准流程修复。

```text
用户：收到一个支付金额计算错误的缺陷，帮我按标准流程修复

助手：按 9 步流程执行

1. 读 issue：理解缺陷描述，明确"支付金额多算了一分钱"
2. 写任务卡：
   - 目标：修复支付金额计算精度问题
   - 不修改：支付流程逻辑、UI 交互
   - 基线版本：当前 main 分支
3. 列改动点：
   - src/utils/calc.js 的 toFloat 函数
   - 仅修改浮点转整数逻辑
4. 编码：局部替换，不重写整个文件
5. 本地验证：
   node -c src/utils/calc.js          # 语法检查
   node -e "require('./src/utils/calc.js')"  # 导入检查
   node test-calc-fix.js              # 样例验证
   npm test                           # 回归测试
6. 看 diff：确认改动量在 15 行以内
7. 写发布说明：明确修复内容和影响范围
8. 提交并发布
```

### 场景二：功能开发流程管控

开发者需要新增一个用户注册功能，需要控制改动范围。

```text
用户：要新增用户注册功能，怎么按标准流程来

助手：
1. 读需求：用户注册功能，包含邮箱注册和手机号注册
2. 写任务卡：
   - 目标：实现用户注册 API
   - 范围：仅后端 API，不含前端页面
   - 不修改：现有登录逻辑
3. 确定基线：基于 main 分支创建 feature/register
4. 列改动点：
   - 新增 src/controllers/register.js
   - 修改 src/routes/index.js（仅添加路由）
   - 新增 src/validators/register.js
5. 编码：先复制相似代码结构，再局部修改
6. 验证：
   npm run lint       # 代码规范
   npm test           # 单元测试
   npm run test:e2e   # 集成测试
7. 检查 diff：确认没有夹带重构
8. 发布说明：列出新增 API 和参数说明
```

### 场景三：提交前自查

开发者完成编码后，提交前进行质量自查。

```bash
# 执行 15 项验收清单自查

# A. 需求一致性
echo "A1. 能用一句话说清这次修复的目标？ [y/n]"
echo "A2. 知道这次不打算修的内容有哪些？ [y/n]"
echo "A3. 代码改动与需求描述一致？ [y/n]"

# B. 技术正确性
echo "B1. 基于正确版本开始修改？ [y/n]"
echo "B2. 没有重写整个文件？ [y/n]"
echo "B3. 数据结构变化已同步所有引用？ [y/n]"
echo "B4. 新逻辑不会破坏旧逻辑？ [y/n]"

# C. 测试验证
python3 -m py_compile scripts/xxx.py        # C1. 语法检查
python3 -c "from scripts.xxx import ClassName"  # C2. 导入检查
python3 test_fix.py                          # C3. 样例验证
python3 -m pytest tests/                     # C4. 回归测试

# D. 发布质量
git diff --stat   # D1. 确认 diff 大小与任务规模匹配
```

## 不适用场景

以下场景项目开发标准免费版不适合处理：

- 无明确技术栈的模糊需求
- 纯架构设计决策
- 运维部署管理

## 触发条件

需要代码生成、编程辅助、调试测试、开发部署时使用。不适用于非本工具能力范围的需求。

## 快速开始

### 9 步开发流程

```text
1. 读 issue → 2. 写任务卡 → 3. 确定基线
     ↓
4. 列改动点 → 5. 编码 → 6. 本地验证
     ↓
7. 看 diff → 8. 写发布说明 → 9. 复盘
```

### 8 条编码纪律

| 序号 | 纪律 | 说明 |
| --- | --- | --- |
| 1 | 先复制旧代码，再局部替换 | 避免重写整个文件 |
| 2 | 改函数前，先通读输入/输出/副作用 | 理解后再修改 |
| 3 | 涉及数据结构变化时，先搜所有使用点 | 避免遗漏引用 |
| 4 | 不要同时改逻辑和风格 | 保持改动单一 |
| 5 | 不要在缺陷修复里做重构 | 分离关注点 |
| 6 | 不要修改未被需求要求的行为 | 控制影响范围 |
| 7 | 不要在验证前说"修好了" | 先验证再结论 |
| 8 | 不要让 release note 超前于实际代码 | 文档与代码同步 |

### 4 层验证

```bash
# 第一层：语法检查
python3 -m py_compile scripts/xxx.py
# 或
node -c src/xxx.js

# 第二层：导入检查
python3 -c "from scripts.xxx import ClassName"
# 或
node -e "require('./src/xxx.js')"

# 第三层：最小样例验证
python3 test_fix.py
# 或
node test-fix.js

# 第四层：回归测试
python3 -m pytest tests/
# 或
npm test
```

## 示例

### 任务卡模板

```markdown
## 任务卡

**目标**：一句话描述本次修复/开发目标
**基线版本**：基于哪个分支/提交开始
**改动范围**：
- 修改文件列表
- 新增文件列表

**不修改的内容**：
- 明确列出不在本次范围内的内容

**验证方式**：
- 语法检查命令
- 测试命令
```

### 15 项验收清单

**A. 需求一致性（3 项）**

| 编号 | 检查项 |
| --- | --- |
| A1 | 能用一句话说清这次修复的目标 |
| A2 | 知道这次"不打算修"的内容有哪些 |
| A3 | 代码改动与需求描述一致 |

**B. 技术正确性（4 项）**

| 编号 | 检查项 |
| --- | --- |
| B1 | 基于正确版本开始修改 |
| B2 | 没有重写整个文件 |
| B3 | 数据结构变化已同步所有引用点 |
| B4 | 新逻辑不会破坏旧逻辑 |

**C. 测试验证（4 项）**

| 编号 | 检查项 |
| --- | --- |
| C1 | 语法检查通过 |
| C2 | 导入检查通过 |
| C3 | 最小样例验证通过 |
| C4 | 回归测试通过 |

**D. 发布质量（4 项）**

| 编号 | 检查项 |
| --- | --- |
| D1 | diff 大小与任务规模匹配 |
| D2 | release note 与实际代码一致 |
| D3 | 版本号、文档、注释已同步 |
| D4 | 可以指出这次改动的风险点 |

## 最佳实践

1. **先写任务卡再编码**：明确目标和范围后再动手

2. **改动量与任务匹配**：缺陷修复控制在 15 行以内
   ```bash
   git diff --stat
   ```

3. **分离逻辑与风格**：不要在同一提交中混合

4. **验证先于结论**：所有"修好了"必须有验证证据

5. **diff 审查**：提交前务必检查改动内容
   ```bash
   git diff
   git diff --staged
   ```

6. **使用工具验证**：工具验证比人工更可靠
   ```bash
   grep -r "oldFunctionName" src/  # 搜索所有使用点
   ```

## 常见问题

### Q1：改动量总是超标怎么办？

```text
可能原因：
1. 需求理解不清晰，范围蔓延
2. 顺手做了重构
3. 基线版本不对

解决方案：
1. 重新写任务卡，明确"不修改"的边界
2. 将重构拆分为独立提交
3. 确认基线版本后再开始
```

### Q2：如何避免夹带重构？

```text
1. 编码前列出所有改动点
2. 编码时只做列出的改动
3. 提交前用 git diff 逐行审查
4. 发现夹带的改动，撤销或拆分到独立提交
```

### Q3：没有测试用例怎么验证？

```bash
# 最小验证：语法 + 导入
python3 -m py_compile your_script.py
python3 -c "import your_module"

# 手动样例验证
python3 -c "
from your_module import your_function
result = your_function(test_input)
assert result == expected, f'Expected {expected}, got {result}'
print('验证通过')
"
```

### Q4：多文件修改如何确保同步？

```bash
# 搜索所有使用点
grep -r "OldClassName" src/
grep -r "old_function_name" src/

# 确认所有引用都已更新
grep -r "NewClassName" src/
```

### Q5：release note 怎么写？

```markdown
## v1.2.1

### 修复
- 修复支付金额计算精度丢失问题（calc.js）
- 修复登录页面在 Safari 下的样式错位（login.css）

### 说明
- 本次改动 12 行，涉及 2 个文件
- 已通过语法检查和回归测试
```

### Q6：如何控制 AI 辅助编码的改动量？

```text
1. 明确告诉 AI：只修改指定文件的指定函数
2. 提供任务卡作为上下文
3. 要求 AI 输出 diff 而非完整文件
4. 逐行审查 AI 生成的代码
5. 拒绝任何超出范围的"优化建议"
```

## 依赖说明

### 运行环境
- **Agent 平台**: 支持读取 SKILL.md 的任意 AI Agent（Claude Code / Cursor / Codex / Gemini CLI 等）
- **操作系统**: Windows / macOS / Linux

### 依赖详情

| 依赖项 | 类型 | 是否必需 | 获取方式 |
|:-------|:-----|:---------|:---------|
| Python | 运行时 | 可选 | python.org 下载 |
| Node.js | 运行时 | 可选 | nodejs.org 下载 |
| Git | 命令行工具 | 推荐 | 系统包管理器安装 |
| LLM API | API | 必需 | 由 Agent 内置 LLM 提供 |

### API Key 配置
- 本工具为纯 Markdown 指令驱动，无需额外 API Key
- 如需操作 GitHub Issue，需要配置 GitHub CLI 令牌

### 可用性分类
- **分类**: MD+EXEC（Markdown 指令 + 命令行执行）
- **说明**: 通过自然语言指令驱动 Agent 执行开发流程，验证步骤需要命令行执行能力

## 错误处理


| 错误场景 | 原因 | 处理方式 |
|---------|------|---------|
| 配置错误 | 参数缺失或格式错误 | 检查依赖说明中的配置要求 |
| 运行时错误 | 运行环境不满足 | 确认运行环境符合依赖说明 |
| 网络错误 | 连接超时或不可达 | 执行ping命令测试网络连通性,检查防火墙和代理设置连接后执行ping命令测试网络连通性,检查防火墙和代理设置连接后重新执行命令，参考国内替代方案 |

## 已知限制

- 需LLM支持,无LLM环境不可用
- 复杂业务场景建议结合人工经验判断
- 执行效率受模型能力与网络环境影响
- 当前为免费版本,如需完整功能请升级到付费版获取全部能力