SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsgo-backend-dev-workflow

go-backend-dev-workflow

Coding & development

View repository

Updated 10-15 20:05

About this skill

Standard development workflow

Mainly applicable to two scenarios:

  1. Existing requirements analysis results or development plan: Use existing documents as input, automatically complete the full closed loop of coding → testing → review → regression
  2. Minimal feature or bugfix: No complex requirements or planning documents needed, start directly based on session context communication, skipping the parts of document planning that do not apply

When to use

  • The user says "develop according to the standard workflow" / "run the full workflow" / "start developing this feature"
  • Requirements analysis (/go-backend-requirement-analysis) or technical design (/go-backend-technical-design) has been completed, entering the implementation phase
  • Minimal feature or bugfix, no formal design document needed, use the session description directly to drive development

How to invoke

/go-backend-dev-workflow [docs/feature-dir]
  • Provide a directory name: use that directory as the feature document directory
  • Do not provide a directory name: under docs/ , automatically create a subdirectory based on the feature name

Phase 1: Document directory planning

Step 1: Ensure tasks/todo.md exists (execute unconditionally, must not be skipped in any scenario)

Do not make any prior judgment, execute directly:

mkdir -p {project_root}/tasks
[ -f {project_root}/tasks/todo.md ] || printf '# Todo\n\n## 参考文档\n\n' > {project_root}/tasks/todo.md
grep -q '^## 参考文档' {project_root}/tasks/todo.md || printf '\n## 参考文档\n\n' >> {project_root}/tasks/todo.md

After execution is complete,tasks/todo.md must exist and must contain the ## 参考文档 subsection.

Step 2: Determine the feature document directory

If a directory name was provided at invocation:

First distinguish whether the directory is under the project root:

arg_dir="{传入的目录参数}"
resolved=$(realpath "$arg_dir" 2>/dev/null || echo "$arg_dir")
project_abs=$(realpath {project_root})
case "$resolved" in
  "$project_abs"/*) echo "INSIDE:${resolved#$project_abs/}" ;;
  *)                echo "OUTSIDE:$resolved" ;;
esac
  • Output INSIDE:<rel> → use the path relative to the project root <rel>
  • Output OUTSIDE:<abs> → Use the absolute path as is, do not perform relpath conversion(applicable to scenarios where the user manages plan files with an external document repository)

Then normalize the converted path and the directory name already recorded in the ## 参考文档 subsection according to the same rules and compare them:

  • Consistent: Reuse the existing plan, continue to step 3
  • Inconsistent or the subsection is empty: Clear the ## 参考文档 subsection, regenerate according to the new directory name, continue to step 3

If no directory name was provided at invocation:

Based on the current feature name (extracted from the session context or the title of the requirements analysis/technical design document), under docs/ determine the subdirectory name, format:docs/{feature-name}。

Step 3: Scan the feature document directory and assign a value to each type of file

The following commands must be executed, must not be skipped or replaced with subjective judgment. The commands search independently for each type of file: for existing files take the most recently modified one, otherwise generate a new file name ({feature-name} is the feature abbreviation,{today} is today's date yyyy-mm-dd).

d="{resolved_dir}"
feat="{feature-name}"
today="{today}"

# 每类文件：有则取最新，无则生成新名
FILE_PLAN=$(ls -t "$d"/plan-*.md  2>/dev/null | head -1); [ -z "$FILE_PLAN" ] && FILE_PLAN="plan-${feat}-${today}.md"     || FILE_PLAN=$(basename "$FILE_PLAN")
FILE_ARCH=$(ls -t "$d"/arch-*.md  2>/dev/null | head -1); [ -z "$FILE_ARCH" ] && FILE_ARCH="arch-${feat}-${today}.md"     || FILE_ARCH=$(basename "$FILE_ARCH")
FILE_OPS_MD=$(ls -t "$d"/ops-*.md 2>/dev/null | head -1); [ -z "$FILE_OPS_MD" ] && FILE_OPS_MD="ops-${feat}-${today}.md" || FILE_OPS_MD=$(basename "$FILE_OPS_MD")
FILE_OPS_SH=$(ls -t "$d"/ops-*.sh 2>/dev/null | head -1); [ -z "$FILE_OPS_SH" ] && FILE_OPS_SH="ops-${feat}-${today}.sh" || FILE_OPS_SH=$(basename "$FILE_OPS_SH")
FILE_REPORT=$(ls -t "$d"/report-*.md 2>/dev/null | head -1); [ -z "$FILE_REPORT" ] && FILE_REPORT="report-${feat}-${today}.md" || FILE_REPORT=$(basename "$FILE_REPORT")
FILE_REVIEW=$(ls -t "$d"/review-*.md 2>/dev/null | head -1); [ -z "$FILE_REVIEW" ] && FILE_REVIEW="review-${feat}-${today}.md" || FILE_REVIEW=$(basename "$FILE_REVIEW")

echo "PLAN:     $FILE_PLAN"
echo "ARCH:     $FILE_ARCH"
echo "OPS_MD:   $FILE_OPS_MD"
echo "OPS_SH:   $FILE_OPS_SH"
echo "REPORT:   $FILE_REPORT"
echo "REVIEW:   $FILE_REVIEW"

The output is the final file name, use it directly in step 4, do not modify.

Step 4: Write the list into tasks/todo.md

Write the assignment results from step 3 into the tasks/todo.md subsection of ## 参考文档 (overwrite the existing content of that subsection), and use the actual output values of the step 3 commands for the file names:

## 参考文档

- 当前功能文档目录：{resolved_dir}
- 当前功能计划文档：{FILE_PLAN}
- 当前功能架构文档：{FILE_ARCH}
- 当前功能操作手册：{FILE_OPS_MD}
- 当前功能操作脚本：{FILE_OPS_SH}
- 当前功能测试记录文档：{FILE_REPORT}
- 当前功能评审记录文档：{FILE_REVIEW}

After writing, perform verification:

cat {project_root}/tasks/todo.md

After confirming the content of the ## 参考文档 subsection is correct, decide whether to execute step 5 based on the scenario.

Step 5: [Pause on first startup] Display the plan and wait for confirmation

Skip conditions (skip if any one is met, and go directly to Phase 2):

  • args contains resume-execution semantics such as "continue", "continue", "resume", etc.
  • the plan file path is explicitly specified in args (regarded as the plan already confirmed in the previous session)

When the skip conditions are not met, read the plan document (plan-*.md), filter the completed [x] tasks, and show the user:

tasks/todo.md 已更新 ✓

计划文件：{plan-file-name}
架构文档：{arch-file-name}（若存在）

待执行任务：
  - [ ] Task N: {task summary}
  - [ ] Task M: {task summary}
  ...

请输入 "执行" 确认开始实施，或告知调整意见。

Phase 2 can only be entered after receiving the user input "execute". Phase 2 directly executes the task list confirmed above, without rescanning.

Phase 2: Implement according to the design

Prerequisite action: read the path list from tasks/todo.md (business dependency, cannot be skipped)

Phase 2'sfirst mandatory action: from tasks/todo.md 's ## 参考文档 subsection, read the following paths and cache them as variables for this session. Every file-writing / script-running action in Phase 3/4/5/6/7 depends on these variables, and none can be missing:

awk '/^## 参考文档/{flag=1; next} /^## /{flag=0} flag' {project_root}/tasks/todo.md

Parse this subsection to obtain the following variables (if any line is missing, it is considered that Phase 1 was not completed):

Variable Meaning Used by which Phases
REF_DIR Current feature document directory Phase 3/4/5/6/7 concatenate file paths
REF_PLAN Plan document Basis for Phase 2 task-by-task implementation
REF_ARCH Architecture document (optional) Basis for Phase 2 implementation
REF_OPS_MD Operation manual Phase 3 append test cases
REF_OPS_SH Operation script Phase 5 run case by case, Phase 7 regression
REF_REPORT Test record document Phase 6/7 write execution records
REF_REVIEW Review record document Phase 4/6 write self-check and review results

Fallback rule：REF_DIR / REF_OPS_SH / REF_REPORT / REF_REVIEW If any cannot be parsed → immediately return to Phase 1 Step 1 and start over, and must not bypass it. Reason: Phase 4 self-check must write to REF_REVIEW, Phase 5 must run REF_OPS_SH, and Phase 7 must regress the same script—if the paths do not exist, no step after Phase 2 can be completed.

bugfix scenario(Phase 1 determines BUGFIX skip → tasks/todo.md also does not need to be produced): this prerequisite action is changed to "use session context anchors to record the review results and test verification content to be written", and the content stays directly in the session reply without being persisted to disk.

Implementation basis (by priority)

  1. There are requirement analysis or technical design results in the session: directly use the document content in the current session as the standard
  2. A document path is provided: read the plan document (plan-*.md) or architecture document (arch-*.md）
  3. Minimal feature or bugfix: based on the problem description and communication context in the session, no formal design document is needed

Scope confirmation for the minimal / bugfix path: before starting, confirm the scope of changes with the user in one sentence (e.g., "will modify function Y in file X, not involving other modules"), and start only after the user confirms.

Implementation principles

  • When there is a requirement mapping table (Req# → component), implement Req# by Req#, and after completion update the status in tasks/todo.md update status
  • Minimal features or bugfixes do not need a mapping table; implement directly according to the session description, minimizing the scope of changes
  • When encountering unreasonable factors that may render the product unusable, stop immediately and wait for manual confirmation, describe the specific problem and scope of impact, and do not make assumptions to bypass it on your own

Phase 3: Operation Manual and Script Supplementation

Whether to exempt new feature test cases (judge in order)

Execute the following command to determine whether this plan belongs to the "pure cleanup" scenario:

plan_file="$REF_PLAN"
total=$(grep -cE '^## Task' "$plan_file" 2>/dev/null || echo 0)
clean_only=$(grep -cE '^## Task.*(Delete|Remove|Clean|Cleanup|删除|移除|清理)' "$plan_file" 2>/dev/null || echo 0)
if [ "$total" -gt 0 ] && [ "$clean_only" -eq "$total" ]; then
  echo "CLEANUP_ONLY"
else
  echo "FEATURE_CHANGE"
fi
  • Output CLEANUP_ONLY(code deletion / configuration cleanup / pure refactoring, no new business behavior) → this Phase only write regression test cases(verify that existing functionality is still usable), do not write new feature test cases, and do not fabricate pseudo test cases
  • Output FEATURE_CHANGE → write new feature test cases + regression test cases according to the full process

Regardless of the scenario, it is necessary to, in REF_OPS_MD / REF_OPS_SH , retain at least one set of executable regression test cases — used in Phase 5 / Phase 7 to verify that the changes have not broken existing capabilities.

Write to the operation manual

The path shall be based on what is recorded in the tasks/todo.md reference document list (it may be an existing file or a newly created path). In that file,appendthe test cases for the new feature without overwriting existing content:

## 测试用例

### 正常路径

| TC# | 前置条件 | 操作 | 预期结果 |
|-----|---------|------|---------|

### 边界/异常路径

| TC# | 前置条件 | 操作 | 预期结果 |
|-----|---------|------|---------|

### 回归用例（历史功能）

| TC# | 覆盖场景 | 验证点 |
|-----|---------|-------|

Write to the operation script

The path is the same as above, based on the reference document list,appendnew test cases to the end of the existing script without overwriting existing functions:

  • Each test case corresponds to an independently executable function or command block
  • The script header includes environment variable descriptions and prerequisite dependency checks
  • Includes regression test cases covering the affected historical functionality paths

"Test cases already exist" does not exempt Phase 5 execution: if the script already has a suite with the same name or the same verification logic (written by the previous session), there is no need to append it again, but Phase 5 must still actually run the script in this session. "Test cases already written" ≠ "already executed".

Phase 4: Code Self-Review

Conduct a self-review of all files changed in this implementation, and record all findings in thereview record document（tasks/todo.md in the reference document list → the current feature review record document).

Self-review key points (general):

  • Logical correctness: boundary conditions, null/empty value checks, error handling
  • Concurrency safety: access control for shared state, lifecycle of asynchronous operations
  • Resource management: whether connections/files/handles are properly closed, whether timers/tasks can be canceled
  • Interface contract: whether it is consistent with the API specification in the design document
  • Test coverage: whether the newly added code has corresponding test cases

Review document structure:

# 评审记录

## 自查（Phase 4）

| # | 文件:行号 | 问题描述 | 严重级别 | 状态 |
|---|---------|---------|---------|------|
| 1 | pkg/foo/bar.go:42 | nil 未检查 | High | ✅ 已修复 |

Verify the issues found in the self-review one by one, and once confirmed to actually exist, fix them immediately and mark the status in the table.

Phase 5: Operation Script Execution

REF_REPORT Existing content does not mean this Phase has been executed: every time the skill is invoked, the script must actually be run in this session, and the execution result of this time must beappendedto REF_REPORT(it is recommended to include the execution date in the section title), and this Phase must not be skipped on the grounds that "the previous result is still valid" or "the report document is not empty".

Step Zero: Probe the current service status (must be executed, and must not be skipped based on assumptions)

Before doing any other operationsFirst confirm the health endpoint address from the ops manual, then actually probe it:

curl -s --max-time 3 {health_url} | grep -q '"ok"' && echo "SERVICE_UP" || echo "SERVICE_DOWN"
  • SERVICE_UP → The service is online,skip "Prerequisite: Service Startup" and go directly to "Execution Target: Must Run the Full Script"
  • SERVICE_DOWN → Enter the "Prerequisite: Service Startup" process below

It is forbidden to replace this probe with session impressions or subjective judgment: Claiming "the service is not running" without performing the health probe is considered Phase 5 incomplete and must be redone.

Prerequisite: Service Startup (executed only when the zeroth step outputs SERVICE_DOWN)

Determine the startup command, searching in the following priority order:

  1. ops manual（$REF_OPS_MD): search for Prerequisites、启动服务、start and other sections; if present, use them as the authority
  2. Project README / Makefile: when the ops manual has no instructions, search for README.md the startup command in, or Makefile the run、serve、start and other targets in
  3. Pure CLI project: if the project does not require starting a resident service (command-line tools, batch scripts, etc.),skip this section and execute the script directly
# 1. 后台启动服务（命令来自 ops 手册或 README/Makefile）
{启动命令} > /tmp/{project}-test.log 2>&1 &
SERVER_PID=$!

# 2. 等待服务就绪（最多 30 秒，按实际 health 地址调整）
for i in $(seq 1 30); do
  curl -s --max-time 2 {health_url} | grep -q '"ok"' && break
  sleep 1
done

# 3. 验证服务已就绪
curl -s --max-time 3 {health_url} | grep -q '"ok"' && echo "SERVER_UP" || echo "SERVER_START_FAILED"
  • SERVER_UP → Continue executing the script
  • SERVER_START_FAILED → Check the logs to troubleshoot the cause, and after fixing,must re-execute the complete Phase 5(restart from the zeroth step),forbiddento rerun only the suite that just failed

Execution Target: Must Run the Full Script

It is forbidden to run only the newly added suite. In Phase 3, new test cases were appended to the script; Phase 5 must run thefull script(without suite filter parameters), to cover both the new feature test cases and all regression paths:

# 正确：运行完整脚本
bash "$REF_DIR/$REF_OPS_SH"

# 错误：只跑新增 suite（禁止）
bash "$REF_DIR/$REF_OPS_SH" new_suite_only

# 错误：服务修复后只重跑失败的 suite（禁止）
bash "$REF_DIR/$REF_OPS_SH" health login account

Retry constraints after service repair: Regardless of the reason for interruption (service not started, timeout, environment anomaly), after repair the full script must be rerun; it is not permitted to only rerun the suites that were not run or failed before the interruption. "I have already verified N suites" cannot be used as a reason to skip the remaining suites.

If the script supports suite filtering and you really only want to run some suites, you must list in the test recordthe skipped suites and the reason for skipping, and explain whether the regression coverage is sufficient.

Execution Requirements

  • Run each test case one by one
  • Record the detailed execution process of each case in the reference document list'stest record document（tasks/todo.md → current feature test record document):
# 测试记录

## TC-{id}: {用例名称}

**执行命令：**
```bash
# 具体命令

Return result:

# 实际输出

Analysis: Briefly explain whether the result meets expectations; if there is an anomaly, explain the root cause Status: ✅ Passed / ❌ Failed (fixed)


- 对所有失败用例，逐一核实后修复真实存在的问题（区分测试脚本问题和代码问题）
- 修复后重新运行受影响的用例，直到全部通过

---

## Phase 6：专项审查

根据项目语言/技术栈选择对应的审查工具：

- **Go 项目**：调用 `/go-backend-reviewer` 进行专项审查
- **其他语言项目**：跳过本 Phase，或根据项目实际情况选用合适的审查手段

> 判断依据：项目根目录存在 `go.mod` 则为 Go 项目。

将所有反馈追加到参考文档清单中的**评审记录文档**：

```markdown
## 专项审查（Phase 6）

| # | 文件:行号 | 审查反馈 | 严重级别 | 状态 |
|---|---------|---------|---------|------|

Verify the review feedback one by one, confirm the genuinely existing issues, fix them, and mark the status in the table.

Phase 7: Regression Testing

After fixing the Phase 6 review issues, rerun the reference document list'sfull operation script（tasks/todo.md → current feature operation script), covering all regression test cases.

Same constraints as Phase 5: The full script must be run; it is not permitted to run only the newly added suite; when the service is unavailable, it must not be silently skipped and must be explicitly stated in the test record.

  • All passed: append "Regression test: ✅ All passed" to the end of the test record document in the reference document list
  • If there are failures: identify the root cause, fix it, and run regression again until all pass

Completion criteria

Features with requirements analysis / development plan:

  • tasks/todo.md The reference document section has been updated, and the path list has been confirmed
  • Code implementation covers all Req#
  • Operation manual and operation script have been written (ops- prefix)
  • The review document records all findings and fix statuses from self-check + special review
  • The test record document includes the execution process and conclusion for each test case
  • All regression tests passed

Minimal feature / bugfix:

  • Code changes are minimized, touching only the necessary parts
  • The review document (or session) records self-check findings and fix statuses
  • The test record includes the verification command, returned result, and analysis
  • All regression tests passed