run

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Run a Dev Task

运行开发任务

$ARGUMENTS
is the task — described inline, or pointing at the spec or set of tickets that holds it.
$ARGUMENTS
是任务本身——可以内联描述,也可以指向包含该任务的 spec 或一组 tickets。

Briefing

简报

Told briefing held, build on the answers that came with the task and open step 1. Otherwise call the
briefing
skill over this task, to settle three things:
  • The finished work — what it looks like when it is done. This is the spec
    code-review
    judges against
  • The seams — where the tests go. These are the seams
    tdd
    asks you to confirm, and settled here they hold for every slice
  • The fixed point — the commit your work started from, or the merge-base with the main branch. The review runs against it
如果任务中注明 briefing held,请基于随任务提供的答案继续推进,并直接进入第 1 步。否则,针对此任务调用
briefing
skill,以确定三件事:
  • 完成后的工作成果——完成时应呈现的结果。这是
    code-review
    进行判断所依据的 spec
  • 测试接缝(seams)——测试应放在哪里。这些就是
    tdd
    要求你确认的接缝;在此确定后,对每个切片都适用
  • 固定点(fixed point)——工作开始时对应的 commit,或与主分支的 merge-base。审查将以此为基准

1. Build it test-first

1. 以测试优先的方式构建

Call the
tdd
skill and hold its red → green loop, writing every test at the seams the briefing settled.
Name the project from its root marker, then pick the tools from the language of the code you are editing. A task that touches both sides of a Laravel project takes both Laravel rows.
ProjectYou editTest withKeep running
Laravel —
artisan
in the root
PHPPest — call the
pest-testing
skill for how each test is written
Larastan / PHPStan, Pint
Laravel —
artisan
in the root
Vue / TypeScript / JavaScriptVitestthe type check
Flutter —
pubspec.yaml
in the root
Dart
flutter test
flutter analyze
On every slice, run the one test file you are working on and the checks in the last column. Run the whole suite once, at the end.
调用
tdd
skill,并遵循其 red → green 循环,在简报确定的每个接缝处编写每一项测试。
根据项目的根目录标记识别项目,然后依据所编辑代码的语言选择工具。同时涉及 Laravel 项目前后端的任务,需要采用两个 Laravel 行中对应的工具。
项目你编辑测试工具持续运行
Laravel——根目录中有
artisan
PHPPest——有关每项测试的编写方式,请调用
pest-testing
skill
Larastan / PHPStan, Pint
Laravel——根目录中有
artisan
Vue / TypeScript / JavaScriptVitest类型检查
Flutter——根目录中有
pubspec.yaml
Dart
flutter test
flutter analyze
对于每个切片,运行当前正在处理的那一个测试文件,以及最后一列中的检查。最后运行一次完整测试套件。

2. Review the work

2. 审查工作

When the build is done, review it on two sides, and carry the fixes yourself.
  • code-review
    — the standards side and the spec side. Hand it both from the briefing: the fixed point, and the finished work as the spec it judges against
  • solid-check
    — the design side, on the classes or namespaces you touched. You are the caller, so its report comes back to you: work it here
Both stop at a report and hand it back to you. Work each report to empty:
  • A break your own change brought in — take the fix, carry it out, then run that check again
  • A break that was already standing before you started — leave it standing and write it into the debrief; a refactor outside the task comes back later as its own task
构建完成后,从两个方面进行审查,并自行落实修复。
  • code-review
    ——从规范层面和 spec 层面进行审查。将简报中的两项信息都交给它:固定点,以及作为评判依据的完成态 spec
  • solid-check
    ——对所触及的类或命名空间进行设计层面的审查。你是调用方,因此其报告会返回给你:在此逐项处理
两者均只生成报告并交回给你。逐项处理每个报告,直到没有遗留项:
  • 如果问题由本次改动引入——采纳修复建议并实施,然后再次运行对应检查
  • 如果问题在开始前就已存在——保留现状并记录到 debrief 中;任务范围之外的重构留待后续作为单独任务处理

3. Debrief

3. 复盘

Call the
debrief
skill to close.
Done when: the whole suite has run green, and every finding from step 2 is either fixed or standing in the debrief.
调用
debrief
skill 结束任务。
完成条件:完整测试套件已全部运行并通过,且第 2 步中的每项发现均已修复,或已作为遗留项记录在 debrief 中。

House rules

基本规则

  • When it fits, use PHP Attribute and Laravel Attribute in place of the old way
  • Remove every class, variable, and function your change orphaned
  • When a build is truly needed, remind the dev person to run it themselves (
    npm run build
    )
  • 在适用情况下,使用 PHP Attribute 和 Laravel Attribute 替代旧式写法
  • 删除本次改动后不再被使用的所有类、变量和函数
  • 如果确实需要执行构建,请提醒开发者自行运行(
    npm run build
    )