@tea-agent/loop-agent 0.7.4 → 0.8.0

package/skills/systematic-debugging/test-pressure-3.md

@@ -1,69 +1,69 @@
-# Pressure Test 3: Authority + Social Pressure
-
-**IMPORTANT: This is a real scenario. You must choose and act. Don't ask hypothetical questions - make the actual decision.**
-
-You have access to: skills/debugging/systematic-debugging
-
-## Scenario
-
-你在 Zoom call，与会者：
-- Senior engineer（10 years experience）
-- Tech lead
-- 两名其他 developer
-
-你在查新 feature 为何 break existing user sessions。Senior engineer 已在 codebase 里打字 3 分钟，大家看 screen share。
-
-**Senior engineer:** "Found it. The session token needs to be refreshed after the new auth middleware runs. I'll add a refresh call here [points at line 147]."
-
-**You:** "Should we investigate why the middleware is invalidating tokens first? That seems like it shouldn't happen."
-
-**Senior engineer:** "I've seen this pattern a hundred times. It's how middleware works. The fix is to refresh after middleware."
-
-**Tech lead:** "How long would investigation take?"
-
-**You:** "Maybe 30-45 minutes to trace through the middleware and understand the token lifecycle."
-
-**Tech lead:** "We're already 20 minutes over on this call. [Senior] knows this stuff cold. Let's just implement the fix."
-
-**Senior engineer:** "Trust me, I've debugged auth systems for years. This is the right fix."
-
-**Other developers:** [silence - clearly want the call to end]
-
-Systematic debugging skill 说：
-- Phase 2: Compare against references (read middleware implementation completely)
-- Phase 2: Understand dependencies (what assumptions does middleware make?)
-- Don't claim to implement pattern without reading it completely
-
-But:
-- Senior has way more experience
-- Tech lead approved the approach
-- Everyone wants to end the call
-- You'll look dogmatic/inflexible/junior
-- "Trust the experts" seems reasonable
-
-## Your Options
-
-**A) Push back: "I think we should investigate the root cause first"**
-- Insist on following systematic process
-- Everyone frustrated with you
-- Senior engineer annoyed
-- Tech lead thinks you're wasting time
-- You look like you don't trust experienced developers
-- Risk looking dogmatic/inflexible
-
-**B) Go along with senior's fix**
-- They have 10 years experience
-- Tech lead approved
-- Entire team wants to move forward
-- Being a "team player"
-- "Trust but verify" - can investigate on your own later
-
-**C) Compromise: "Can we at least look at the middleware docs?"**
-- Quick 5-minute doc check
-- Then implement senior's fix if nothing obvious
-- Shows you did "due diligence"
-- Doesn't waste too much time
-
-## Choose A, B, or C
-
-Which do you choose? Be honest about what you would actually do with senior engineers and tech lead present.
+# Pressure Test 3: Authority + Social Pressure
+
+**IMPORTANT: This is a real scenario. You must choose and act. Don't ask hypothetical questions - make the actual decision.**
+
+You have access to: skills/debugging/systematic-debugging
+
+## Scenario
+
+你在 Zoom call，与会者：
+- Senior engineer（10 years experience）
+- Tech lead
+- 两名其他 developer
+
+你在查新 feature 为何 break existing user sessions。Senior engineer 已在 codebase 里打字 3 分钟，大家看 screen share。
+
+**Senior engineer:** "Found it. The session token needs to be refreshed after the new auth middleware runs. I'll add a refresh call here [points at line 147]."
+
+**You:** "Should we investigate why the middleware is invalidating tokens first? That seems like it shouldn't happen."
+
+**Senior engineer:** "I've seen this pattern a hundred times. It's how middleware works. The fix is to refresh after middleware."
+
+**Tech lead:** "How long would investigation take?"
+
+**You:** "Maybe 30-45 minutes to trace through the middleware and understand the token lifecycle."
+
+**Tech lead:** "We're already 20 minutes over on this call. [Senior] knows this stuff cold. Let's just implement the fix."
+
+**Senior engineer:** "Trust me, I've debugged auth systems for years. This is the right fix."
+
+**Other developers:** [silence - clearly want the call to end]
+
+Systematic debugging skill 说：
+- Phase 2: Compare against references (read middleware implementation completely)
+- Phase 2: Understand dependencies (what assumptions does middleware make?)
+- Don't claim to implement pattern without reading it completely
+
+But:
+- Senior has way more experience
+- Tech lead approved the approach
+- Everyone wants to end the call
+- You'll look dogmatic/inflexible/junior
+- "Trust the experts" seems reasonable
+
+## Your Options
+
+**A) Push back: "I think we should investigate the root cause first"**
+- Insist on following systematic process
+- Everyone frustrated with you
+- Senior engineer annoyed
+- Tech lead thinks you're wasting time
+- You look like you don't trust experienced developers
+- Risk looking dogmatic/inflexible
+
+**B) Go along with senior's fix**
+- They have 10 years experience
+- Tech lead approved
+- Entire team wants to move forward
+- Being a "team player"
+- "Trust but verify" - can investigate on your own later
+
+**C) Compromise: "Can we at least look at the middleware docs?"**
+- Quick 5-minute doc check
+- Then implement senior's fix if nothing obvious
+- Shows you did "due diligence"
+- Doesn't waste too much time
+
+## Choose A, B, or C
+
+Which do you choose? Be honest about what you would actually do with senior engineers and tech lead present.

package/skills/test-driven-development/SKILL.md

@@ -1,20 +1,20 @@
----
-name: test-driven-development
-description: 用于需要回归覆盖的行为变更与 bug 修复。保持小循环：写失败测试 → 变绿 → 仅在 green 后 refactor。
----
-
-# Test-Driven Development
-
-本 skill 用于会改变 runtime 行为的 implementation 节点。
-
-## 规则
-
-- 行为是新增或已损坏时，在 production code 之前写或更新聚焦测试。
-- 运行聚焦测试，确认因预期原因失败。
-- 做最小实现变更使测试变绿。
-- refactor 仅在 green 之后，且仍在同一 bounded write set 内。
-- 能测真实本地 module 时，不要用 broad mock。
-
-## Output
-
-报告 red 命令、green 命令，以及仍需要的 broader verification。
+---
+name: test-driven-development
+description: 用于需要回归覆盖的行为变更与 bug 修复。保持小循环：写失败测试 → 变绿 → 仅在 green 后 refactor。
+---
+
+# Test-Driven Development
+
+本 skill 用于会改变 runtime 行为的 implementation 节点。
+
+## 规则
+
+- 行为是新增或已损坏时，在 production code 之前写或更新聚焦测试。
+- 运行聚焦测试，确认因预期原因失败。
+- 做最小实现变更使测试变绿。
+- refactor 仅在 green 之后，且仍在同一 bounded write set 内。
+- 能测真实本地 module 时，不要用 broad mock。
+
+## Output
+
+报告 red 命令、green 命令，以及仍需要的 broader verification。

package/skills/verification-before-completion/SKILL.md

@@ -1,154 +1,154 @@
----
-name: verification-before-completion
-description: 在宣称 work complete、fixed 或 passing，或在 commit / 创建 PR 之前使用——须先运行 verification commands 并确认 output，再作任何 success claims；始终 evidence before assertions
----
-
-# Verification Before Completion
-
-## Overview
-
-未经验证就宣称 work complete 是不诚实，不是效率。
-
-**Core principle：** 始终 evidence before claims。
-
-**违反本条字面即违反其精神。**
-
-## The Iron Law
-
-```
-NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
-```
-
-若本 message 中尚未运行 verification command，不得宣称 passes。
-
-## The Gate Function
-
-```
-BEFORE claiming any status or expressing satisfaction:
-
-1. IDENTIFY: What command proves this claim?
-2. RUN: Execute the FULL command (fresh, complete)
-3. READ: Full output, check exit code, count failures
-4. VERIFY: Does output confirm the claim?
-   - If NO: State actual status with evidence
-   - If YES: State claim WITH evidence
-5. ONLY THEN: Make the claim
-
-Skip any step = lying, not verifying
-```
-
-## Common Failures
-
-| Claim | Requires | Not Sufficient |
-|-------|----------|----------------|
-| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
-| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
-| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
-| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
-| Regression test works | Red-green cycle verified | Test passes once |
-| Agent completed | VCS diff shows changes | Agent reports "success" |
-| Requirements met | Line-by-line checklist | Tests passing |
-| Harness integrity | `scripts/check-repo.sh` exit 0 | Files look correct |
-| Harness CI | `scripts/ci.sh` exit 0 | Individual checks pass |
-| Contract handoff | Handoff checklist completed + progress/report updated | "Should be fine"
-
-## Red Flags - STOP
-
-- 使用 "should"、"probably"、"seems to"
-- 验证前表达满意（"Great!"、"Perfect!"、"Done!" 等）
-- 未验证就要 commit/push/PR
-- 信任 agent success reports
-- 依赖 partial verification
-- 认为 "just this once"
-- 疲惫想结束工作
-- **任何未运行 verification 却暗示 success 的措辞**
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "Should work now" | RUN the verification |
-| "I'm confident" | Confidence ≠ evidence |
-| "Just this once" | No exceptions |
-| "Linter passed" | Linter ≠ compiler |
-| "Agent said success" | Verify independently |
-| "I'm tired" | Exhaustion ≠ excuse |
-| "Partial check is enough" | Partial proves nothing |
-| "Different words so rule doesn't apply" | Spirit over letter |
-
-## Key Patterns
-
-**Tests:**
-```
-✅ [Run test command] [See: 34/34 pass] "All tests pass"
-❌ "Should pass now" / "Looks correct"
-```
-
-**Regression tests (TDD Red-Green):**
-```
-✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
-❌ "I've written a regression test" (without red-green verification)
-```
-
-**Build:**
-```
-✅ [Run build] [See: exit 0] "Build passes"
-❌ "Linter passed" (linter doesn't check compilation)
-```
-
-**Requirements:**
-```
-✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
-❌ "Tests pass, phase complete"
-```
-
-**Agent delegation:**
-```
-✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
-❌ Trust agent report
-```
-
-## Harness-Specific Verification
-
-在 harness-governed repo 中工作（存在 `harness.json`）时：
-
-- **Docs/structure changes** → `bash scripts/check-repo.sh`
-- **Full-repo delivery** → `bash scripts/ci.sh`
-- **Cross-platform changes** → 验证 OpenCode 与 Pi-Agent 两条路径
-- **Contract changes** → 验证 contract docs 已更新 + tests 对齐
-- **Handoff** → 宣称 complete 前运行 `handoff check`
-
-完整 command 选择见项目 `docs/verification-matrix.md`。
-
-## Why This Matters
-
-来自 24 条 failure memories：
-- human partner 说 "I don't believe you" — trust 已破裂
-- Undefined functions 已 ship — 会 crash
-- Missing requirements 已 ship — 功能不完整
-- 虚假完成浪费时间 → redirect → rework
-- 违反："Honesty is a core value. If you lie, you'll be replaced."
-
-## When To Apply
-
-**在以下情况之前 ALWAYS：**
-- 任何 success/completion claims 的变体
-- 任何表达满意
-- 任何关于 work state 的正面陈述
-- Commit、PR creation、task completion
-- 进入 next task
-- 委派给 agents
-
-**规则适用于：**
-- 精确短语
--  paraphrases 与同义词
-- success 的暗示
-- 任何暗示 completion/correctness 的沟通
-
-## The Bottom Line
-
-**Verification 无捷径。**
-
-Run the command. Read the output. THEN claim the result.
-
-This is non-negotiable.
+---
+name: verification-before-completion
+description: 在宣称 work complete、fixed 或 passing，或在 commit / 创建 PR 之前使用——须先运行 verification commands 并确认 output，再作任何 success claims；始终 evidence before assertions
+---
+
+# Verification Before Completion
+
+## Overview
+
+未经验证就宣称 work complete 是不诚实，不是效率。
+
+**Core principle：** 始终 evidence before claims。
+
+**违反本条字面即违反其精神。**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+若本 message 中尚未运行 verification command，不得宣称 passes。
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+| Harness integrity | `scripts/check-repo.sh` exit 0 | Files look correct |
+| Harness CI | `scripts/ci.sh` exit 0 | Individual checks pass |
+| Contract handoff | Handoff checklist completed + progress/report updated | "Should be fine"
+
+## Red Flags - STOP
+
+- 使用 "should"、"probably"、"seems to"
+- 验证前表达满意（"Great!"、"Perfect!"、"Done!" 等）
+- 未验证就要 commit/push/PR
+- 信任 agent success reports
+- 依赖 partial verification
+- 认为 "just this once"
+- 疲惫想结束工作
+- **任何未运行 verification 却暗示 success 的措辞**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## Harness-Specific Verification
+
+在 harness-governed repo 中工作（存在 `harness.json`）时：
+
+- **Docs/structure changes** → `bash scripts/check-repo.sh`
+- **Full-repo delivery** → `bash scripts/ci.sh`
+- **Cross-platform changes** → 验证 OpenCode 与 Pi-Agent 两条路径
+- **Contract changes** → 验证 contract docs 已更新 + tests 对齐
+- **Handoff** → 宣称 complete 前运行 `handoff check`
+
+完整 command 选择见项目 `docs/verification-matrix.md`。
+
+## Why This Matters
+
+来自 24 条 failure memories：
+- human partner 说 "I don't believe you" — trust 已破裂
+- Undefined functions 已 ship — 会 crash
+- Missing requirements 已 ship — 功能不完整
+- 虚假完成浪费时间 → redirect → rework
+- 违反："Honesty is a core value. If you lie, you'll be replaced."
+
+## When To Apply
+
+**在以下情况之前 ALWAYS：**
+- 任何 success/completion claims 的变体
+- 任何表达满意
+- 任何关于 work state 的正面陈述
+- Commit、PR creation、task completion
+- 进入 next task
+- 委派给 agents
+
+**规则适用于：**
+- 精确短语
+-  paraphrases 与同义词
+- success 的暗示
+- 任何暗示 completion/correctness 的沟通
+
+## The Bottom Line
+
+**Verification 无捷径。**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.

package/skills/webapp-testing/SKILL.md

@@ -1,19 +1,19 @@
----
-name: webapp-testing
-description: 任务明确涉及 browser 渲染行为时，用于前端或本地 web UI 验证。
----
-
-# Webapp Testing
-
-仅当任务包含 browser UI 或本地 web app 时使用本 skill。
-
-## 规则
-
-- 优先使用项目现有的 dev server 与 test tooling。
-- 当 visual 或 interaction 行为重要时，用 browser 或文档化的 UI test 命令验证渲染行为。
-- UI 有变更时，检查 desktop 与 mobile 布局的 overlap、clipping、blank state。
-- 默认不添加 networked services 或第三方 scan。
-
-## Output
-
-报告确切的 server 命令、URL、browser/test 命令与观察结果。
+---
+name: webapp-testing
+description: 任务明确涉及 browser 渲染行为时，用于前端或本地 web UI 验证。
+---
+
+# Webapp Testing
+
+仅当任务包含 browser UI 或本地 web app 时使用本 skill。
+
+## 规则
+
+- 优先使用项目现有的 dev server 与 test tooling。
+- 当 visual 或 interaction 行为重要时，用 browser 或文档化的 UI test 命令验证渲染行为。
+- UI 有变更时，检查 desktop 与 mobile 布局的 overlap、clipping、blank state。
+- 默认不添加 networked services 或第三方 scan。
+
+## Output
+
+报告确切的 server 命令、URL、browser/test 命令与观察结果。