implement-with-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>
```
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>
```
如果提供了
```
$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 the WIP file immediately:

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

创建
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"

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

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, 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

在每个重要步骤后更新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.
Inform the user the branch is ready for review / PR creation. Offer to merge, push, or create the PR.

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

Rules

规则

NEVER push. We're in a local only workflow.
NEVER amend pushed commits. Make a new commit instead.
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次提交。