implement-with-remote-feedback

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implement with Feedback

带反馈的实现工作流

A disciplined, git-centric implementation workflow. Remote git logs are the primary way others monitor your work.

一套规范的、以Git为核心的实现工作流。远程Git日志是他人监控你工作进展的主要方式。

Workflow

工作流

Phase 1: Pre-flight Checks

阶段1：预检检查

Verify clean checkout. Run
```
git status
```
. If there are ANY uncommitted changes (staged, unstaged, or untracked non-ignored files), STOP and tell the user:
"Working tree is not clean. Please commit or stash your changes before starting." Do NOT proceed until the checkout is clean.
Verify we are on main/master. If not, warn the user and ask whether to continue from the current branch or switch to main first.
Pull latest. Run
```
git pull
```
to ensure we're up to date.

验证干净的检出状态。运行
```
git status
```
。如果存在任何未提交的更改（已暂存、未暂存或未被忽略的未跟踪文件），立即停止并告知用户：
"工作区未处于干净状态。请先提交或暂存您的更改再开始。" 在检出状态干净前，请勿继续。
验证当前分支为main/master。如果不是，提醒用户并询问是从当前分支继续还是先切换到main分支。
拉取最新代码。运行
```
git pull
```
确保本地代码与远程同步。

Phase 2: Branch Creation

阶段2：分支创建

Determine branch type from arguments or context. Valid prefixes:
- ```
feature/
```
  — new functionality
- ```
bugfix/
```
  — fixing a defect
- ```
spike/
```
  — exploratory / research / prototype
- ```
refactor/
```
  — restructuring without behavior change
- ```
docs/
```
  — documentation only
- ```
chore/
```
  — maintenance, deps, tooling
Create and push the branch.
```
git checkout -b <branch-type>/<short-description>
git push -u origin <branch-type>/<short-description>
```
If
```
$ARGUMENTS
```
is provided, use it as the branch name directly (e.g.
```
/implement-with-feedback feature/add-auth
```
). Otherwise, ask the user what kind of work this is and derive a branch name.

根据参数或上下文确定分支类型。有效的分支前缀：
- ```
feature/
```
  — 新功能开发
- ```
bugfix/
```
  — 缺陷修复
- ```
spike/
```
  — 探索性/研究性工作/原型开发
- ```
refactor/
```
  — 代码重构（不改变功能）
- ```
docs/
```
  — 仅更新文档
- ```
chore/
```
  — 维护工作、依赖更新、工具配置

创建并推送分支。

git checkout -b <branch-type>/<short-description>
git push -u origin <branch-type>/<short-description>

如果提供了

$ARGUMENTS

，直接将其用作分支名称（例如

/implement-with-feedback feature/add-auth

）。否则，询问用户本次工作的类型并生成分支名称。

Phase 3: WIP Progress File

阶段3：WIP进度文件

Create
docs/plans/plan_<branch-name>_implimentation.md
(replacing
```
/
```
with
```
-
```
in the filename). This file tracks the plan, progress, decisions, and blockers in real time.

Initial content:

markdown

# WIP: <Branch Name>

**Branch:** `<branch-type>/<description>`
**Started:** <date>
**Status:** In Progress

## Plan

<If a plan file was provided as $1, summarize it here and link to it. Otherwise, work with the user to define the plan.>

### Tasks

- [ ] Task 1
- [ ] Task 2
- ...

## Progress Log

### <timestamp>
- Started work. Branch created from `main` at `<commit-sha>`.

## Decisions & Notes

<Record architectural decisions, trade-offs, and anything useful for reviewers.>

## Blockers

<None currently.>

## Commits
<githash> - Oneline changelog/commit note

Commit and push the WIP file immediately:

git add docs/wip/<filename>.md
git commit -m "wip: start <branch-name> — init progress tracker"
git push

创建
docs/plans/plan_<branch-name>_implimentation.md
文件（文件名中的
```
/
```
替换为
```
-
```
）。该文件用于实时跟踪计划、进度、决策和阻塞问题。

初始内容：

markdown

# WIP: <Branch Name>

**Branch:** `<branch-type>/<description>`
**Started:** <date>
**Status:** In Progress

## Plan

<如果$1提供了计划文件，在此处总结内容并链接到该文件。否则，与用户协作定义计划。>

### Tasks

- [ ] Task 1
- [ ] Task 2
- ...

## Progress Log

### <timestamp>
- Started work. Branch created from `main` at `<commit-sha>`.

## Decisions & Notes

<记录架构决策、权衡方案以及对评审者有用的所有信息。>

## Blockers

<None currently.>

## Commits
<githash> - Oneline changelog/commit note

立即提交并推送WIP文件：

git add docs/wip/<filename>.md
git commit -m "wip: start <branch-name> — init progress tracker"
git push

Phase 4: Implementation Loop

阶段4：实现循环

For each piece of work:

Update the WIP file FIRST — mark the current task
```
[x]
```
or add a progress log entry with a timestamp.
Do the work — write code, update docs, run tests, etc.

Commit early, commit often. Each commit should be a logical, small unit of work. Use descriptive commit messages:

feat: add auth middleware for API routes

```
fix: handle null response from scanner
```

wip: partial implementation of results table

```
docs: update scanner authoring guide
```
```
test: add normalizer tests for ffuf
```

refactor: extract fingerprint logic to shared util

Push after EVERY commit. No exceptions. This is the monitoring channel.

git add <specific-files>
git commit -m "<type>: <description>"
git push

Update the WIP file with progress, decisions, or blockers after each meaningful step. Commit and push the WIP update too.
If blocked or unsure, update the WIP Blockers section, commit, push, then ask the user.

对于每一项工作：

首先更新WIP文件 — 将当前任务标记为
```
[x]
```
或添加带时间戳的进度日志条目。
开展工作 — 编写代码、更新文档、运行测试等。

尽早提交、频繁提交。每次提交应是一个逻辑独立的小单元工作。使用描述性的提交信息：

feat: add auth middleware for API routes

```
fix: handle null response from scanner
```

wip: partial implementation of results table

```
docs: update scanner authoring guide
```
```
test: add normalizer tests for ffuf
```

refactor: extract fingerprint logic to shared util

每次提交后立即推送。无例外。这是监控渠道。

git add <specific-files>
git commit -m "<type>: <description>"
git push

更新WIP文件，记录进度、决策或阻塞问题。提交并推送上WIP文件的更新。
如果遇到阻塞或不确定的情况，更新WIP文件中的阻塞问题部分，提交并推送，然后询问用户。

Phase 5: Completion

阶段5：完成阶段

Update the WIP file:
- Set
```
**Status:**
```
  to
```
Complete
```
- Ensure all tasks are checked off
- Add a final progress log entry
Final commit and push.
Inform the user the branch is ready for review / PR creation. Offer to create the PR.

更新WIP文件：
- 将
```
**Status:**
```
  设置为
```
Complete
```
- 确保所有任务都已勾选完成
- 添加最终的进度日志条目
最终提交并推送。
告知用户分支已准备好进行评审/创建PR。可主动提出创建PR。

Rules

规则

NEVER force push. History is sacred in this workflow.
NEVER amend pushed commits. Make a new commit instead.
NEVER skip pushing. Every commit must be pushed immediately.
Commit messages must be meaningful. No "wip" without context — use "wip: partial auth middleware" not just "wip".
The WIP file is a living document. Update it continuously. It should tell the full story of the implementation to anyone reading the git log.
Keep commits small and focused. One logical change per commit. If you touch 5 files for 3 different reasons, that's 3 commits.

绝对禁止强制推送。在此工作流中，提交历史是不可侵犯的。
绝对禁止修改已推送的提交。应创建新的提交替代。
绝对禁止跳过推送步骤。每一次提交都必须立即推送。
提交信息必须有意义。不能仅使用“wip”而无上下文 — 应使用“wip: partial auth middleware”而非仅“wip”。
WIP文件是动态文档。持续更新它。任何查看Git日志的人都应能通过它了解实现的完整过程。
保持提交小巧且聚焦。每次提交对应一个逻辑变更。如果因3个不同原因修改了5个文件，应拆分为3个提交。

Monitoring

监控

Others can monitor progress via:

bash

git log --oneline origin/<branch-name>
git diff main..origin/<branch-name>
cat docs/wip/<branch-name>.md   # on the remote branch

他人可通过以下方式监控进度：

bash

git log --oneline origin/<branch-name>
git diff main..origin/<branch-name>
cat docs/wip/<branch-name>.md   # on the remote branch