@tea-agent/loop-agent 0.13.0-beta.0 → 0.13.0

package/skills/grill-with-docs/SKILL.md

@@ -1,88 +1,88 @@
----
-name: grill-with-docs
-description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
----
-
-<what-to-do>
-
-Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
-
-Ask the questions one at a time, waiting for feedback on each question before continuing.
-
-If a question can be answered by exploring the codebase, explore the codebase instead.
-
-</what-to-do>
-
-<supporting-info>
-
-## Domain awareness
-
-During codebase exploration, also look for existing documentation:
-
-### File structure
-
-Most repos have a single context:
-
-```
-/
-├── CONTEXT.md
-├── docs/
-│   └── adr/
-│       ├── 0001-event-sourced-orders.md
-│       └── 0002-postgres-for-write-model.md
-└── src/
-```
-
-If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
-
-```
-/
-├── CONTEXT-MAP.md
-├── docs/
-│   └── adr/                          ← system-wide decisions
-├── src/
-│   ├── ordering/
-│   │   ├── CONTEXT.md
-│   │   └── docs/adr/                 ← context-specific decisions
-│   └── billing/
-│       ├── CONTEXT.md
-│       └── docs/adr/
-```
-
-Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
-
-## During the session
-
-### Challenge against the glossary
-
-When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
-
-### Sharpen fuzzy language
-
-When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
-
-### Discuss concrete scenarios
-
-When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
-
-### Cross-reference with code
-
-When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
-
-### Update CONTEXT.md inline
-
-When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [context-format.md](./context-format.md).
-
-`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
-
-### Offer ADRs sparingly
-
-Only offer to create an ADR when all three are true:
-
-1. **Hard to reverse** — the cost of changing your mind later is meaningful
-2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
-3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
-
-If any of the three is missing, skip the ADR. Use the format in [adr-format.md](./adr-format.md).
-
-</supporting-info>
+---
+name: grill-with-docs
+description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
+---
+
+<what-to-do>
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.
+
+</what-to-do>
+
+<supporting-info>
+
+## Domain awareness
+
+During codebase exploration, also look for existing documentation:
+
+### File structure
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── ai_workspace/loop-agent/
+│   └── adr/
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── ai_workspace/loop-agent/
+│   └── adr/                          ← system-wide decisions
+├── src/
+│   ├── ordering/
+│   │   ├── CONTEXT.md
+│   │   └── ai_workspace/loop-agent/adr/                 ← context-specific decisions
+│   └── billing/
+│       ├── CONTEXT.md
+│       └── ai_workspace/loop-agent/adr/
+```
+
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `ai_workspace/loop-agent/adr/` exists, create it when the first ADR is needed.
+
+## During the session
+
+### Challenge against the glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+
+### Sharpen fuzzy language
+
+When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
+
+### Discuss concrete scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+
+### Cross-reference with code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
+
+### Update CONTEXT.md inline
+
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [context-format.md](./context-format.md).
+
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If any of the three is missing, skip the ADR. Use the format in [adr-format.md](./adr-format.md).
+
+</supporting-info>

package/skills/grill-with-docs/adr-format.md

@@ -1,47 +1,47 @@
-# ADR Format
-
-ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
-
-Create the `docs/adr/` directory lazily — only when the first ADR is needed.
-
-## Template
-
-```md
-# {Short title of the decision}
-
-{1-3 sentences: what's the context, what did we decide, and why.}
-```
-
-That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
-
-## Optional sections
-
-Only include these when they add genuine value. Most ADRs won't need them.
-
-- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
-- **Considered Options** — only when the rejected alternatives are worth remembering
-- **Consequences** — only when non-obvious downstream effects need to be called out
-
-## Numbering
-
-Scan `docs/adr/` for the highest existing number and increment by one.
-
-## When to offer an ADR
-
-All three of these must be true:
-
-1. **Hard to reverse** — the cost of changing your mind later is meaningful
-2. **Surprising without context** — a future reader will look at the code and wonder "why on earth did they do it this way?"
-3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
-
-If a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
-
-### What qualifies
-
-- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
-- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
-- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
-- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
-- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
-- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
-- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.
+# ADR Format
+
+ADRs live in `ai_workspace/loop-agent/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
+
+Create the `ai_workspace/loop-agent/adr/` directory lazily — only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what did we decide, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most ADRs won't need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
+- **Considered Options** — only when the rejected alternatives are worth remembering
+- **Consequences** — only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `ai_workspace/loop-agent/adr/` for the highest existing number and increment by one.
+
+## When to offer an ADR
+
+All three of these must be true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will look at the code and wonder "why on earth did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
+
+### What qualifies
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
+- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.

package/skills/grill-with-docs/context-format.md

@@ -1,60 +1,60 @@
-# CONTEXT.md Format
-
-## Structure
-
-```md
-# {Context Name}
-
-{One or two sentence description of what this context is and why it exists.}
-
-## Language
-
-**Order**:
-{A one or two sentence description of the term}
-_Avoid_: Purchase, transaction
-
-**Invoice**:
-A request for payment sent to a customer after delivery.
-_Avoid_: Bill, payment request
-
-**Customer**:
-A person or organization that places orders.
-_Avoid_: Client, buyer, account
-```
-
-## Rules
-
-- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
-- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
-- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
-- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
-
-## Single vs multi-context repos
-
-**Single context (most repos):** One `CONTEXT.md` at the repo root.
-
-**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
-
-```md
-# Context Map
-
-## Contexts
-
-- `src/ordering/CONTEXT.md` — receives and tracks customer orders
-- `src/billing/CONTEXT.md` — generates invoices and processes payments
-- `src/fulfillment/CONTEXT.md` — manages warehouse picking and shipping
-
-## Relationships
-
-- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
-- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
-- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
-```
-
-The skill infers which structure applies:
-
-- If `CONTEXT-MAP.md` exists, read it to find contexts
-- If only a root `CONTEXT.md` exists, single context
-- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
-
-When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.
+# CONTEXT.md Format
+
+## Structure
+
+```md
+# {Context Name}
+
+{One or two sentence description of what this context is and why it exists.}
+
+## Language
+
+**Order**:
+{A one or two sentence description of the term}
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organization that places orders.
+_Avoid_: Client, buyer, account
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
+- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
+- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
+- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
+
+## Single vs multi-context repos
+
+**Single context (most repos):** One `CONTEXT.md` at the repo root.
+
+**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+
+```md
+# Context Map
+
+## Contexts
+
+- `src/ordering/CONTEXT.md` — receives and tracks customer orders
+- `src/billing/CONTEXT.md` — generates invoices and processes payments
+- `src/fulfillment/CONTEXT.md` — manages warehouse picking and shipping
+
+## Relationships
+
+- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
+- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
+- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
+```
+
+The skill infers which structure applies:
+
+- If `CONTEXT-MAP.md` exists, read it to find contexts
+- If only a root `CONTEXT.md` exists, single context
+- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+
+When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.

package/skills/init-capability-evolution/SKILL.md

@@ -1,70 +1,70 @@
----
-name: init-capability-evolution
-description: 用于 loop-agent 本仓库的初始化能力演化审查，判断代码、skill、模板、包范围或 DAG 默认能力变化是否需要同步更新目标项目 init surface。
----
-
-# Init Capability Evolution
-
-本 skill 用于 loop-agent 本仓库。当变更可能影响 `loop-agent init` 初始化其他项目的能力时使用。
-
-## Goal
-
-让模型自行判断并维护初始化能力，而不是依赖人工记忆：
-
-- 新能力是否应该进入目标项目。
-- 新增/修改的 skill 是否应随 npm 包和 `init --profile full` 投影。
-- 目标项目的 `AGENTS.md`、README managed block、治理 docs、scripts 或 templates 是否需要更新。
-- `package.json files` 与 `docs/init-surface.manifest.json` 是否仍覆盖真实发布范围。
-- 是否需要目标项目 smoke、init doctor、docs audit 或 package dry-run 证据。
-
-## Trigger Tiers
-
-按 `docs/init-surface.manifest.json` 的 `evolutionReview.tiers` 判断成本：
-
-- `advisory`：只记录提示，不阻塞。
-- `surface-check`：运行 `bash scripts/check-init-surface.sh`；通过即可。
-- `model-review`：写一份简短 init evolution review，必要时修改 init surface、包范围、文档、skill 或测试。
-
-不要把小改动升级成重流程。只有当变化可能改变目标项目初始化体验、默认 DAG 行为、skill resolution、发布包边界或 init 生成物时，才进入 model-review。
-
-## Review Questions
-
-审查时逐条回答：
-
-1. 本次变更会改变目标项目执行 `loop-agent init --profile full --merge` 后得到的文件、规则或能力吗？
-2. 是否新增、删除或重命名了 `skills/**`，并且目标项目需要 repo-local 可审计副本？
-3. 是否改变了默认 DAG role skills、skill resolution、strict skill audit 或 task prompt 注入？
-4. 是否新增通用治理模板、script matrix、production readiness 或 operator recovery 文档，需要目标项目初始化后可见？
-5. `package.json files` 是否包含所有 npm 运行和初始化所需静态资料？
-6. `docs/init-surface.manifest.json` 是否更新了 package / init / exclude / trigger contract？
-7. 旧目标项目是否只需 advisory、需要手工复制新增文件，还是需要未来 `init audit/update` 迁移能力？
-
-## Output
-
-轻量审查可以只在 handoff 中说明。高影响审查应写入：
-
-```text
-docs/reports/YYYY-MM-DD-init-evolution-review.md
-```
-
-报告保持短小，包含：
-
-- changed surface
-- 可由 Git 解析的 Base 和 Head commit/ref；严格检查要求 Base 精确匹配所选 `--base`，Head 可以是运行时当前 `HEAD` 或它的一个可解析祖先提交。若 Head 是祖先，则 `reportHead..HEAD` 区间内一旦出现新的 `model-review` 高影响路径就会拒绝该报告；仅有 `advisory` 或 `surface-check` 变化不会让已完成的高影响审查失效。`working tree`、不可解析文字、无关历史报告都不能为其他变更范围放行严格检查。
-- decision: no init impact / surface check only / init update required
-- files updated
-- verification commands and results
-- residual risk
-
-## Required Verification
-
-按影响面选择最小命令：
-
-```bash
-bash scripts/check-init-surface.sh
-bash scripts/check-repo.sh
-npm test -- init-command dag-skills dag-validate-command
-npm pack --dry-run --ignore-scripts
-```
-
-如果没有新鲜验证证据，不要宣称 init evolution 已完成。
+---
+name: init-capability-evolution
+description: 用于 loop-agent 本仓库的初始化能力演化审查，判断代码、skill、模板、包范围或 DAG 默认能力变化是否需要同步更新目标项目 init surface。
+---
+
+# Init Capability Evolution
+
+本 skill 用于 loop-agent 本仓库。当变更可能影响 `loop-agent init` 初始化其他项目的能力时使用。
+
+## Goal
+
+让模型自行判断并维护初始化能力，而不是依赖人工记忆：
+
+- 新能力是否应该进入目标项目。
+- 新增/修改的 skill 是否应随 npm 包和 `init --profile full` 投影。
+- 目标项目的 `AGENTS.md`、README managed block、治理 docs、scripts 或 templates 是否需要更新。
+- `package.json files` 与 `ai_workspace/loop-agent/init-surface.manifest.json` 是否仍覆盖真实发布范围。
+- 是否需要目标项目 smoke、init doctor、docs audit 或 package dry-run 证据。
+
+## Trigger Tiers
+
+按 `ai_workspace/loop-agent/init-surface.manifest.json` 的 `evolutionReview.tiers` 判断成本：
+
+- `advisory`：只记录提示，不阻塞。
+- `surface-check`：运行 `bash scripts/check-init-surface.sh`；通过即可。
+- `model-review`：写一份简短 init evolution review，必要时修改 init surface、包范围、文档、skill 或测试。
+
+不要把小改动升级成重流程。只有当变化可能改变目标项目初始化体验、默认 DAG 行为、skill resolution、发布包边界或 init 生成物时，才进入 model-review。
+
+## Review Questions
+
+审查时逐条回答：
+
+1. 本次变更会改变目标项目执行 `loop-agent init --profile full --merge` 后得到的文件、规则或能力吗？
+2. 是否新增、删除或重命名了 `.agents/skills/**`，并且目标项目需要 repo-local 可审计副本？
+3. 是否改变了默认 DAG role skills、skill resolution、strict skill audit 或 task prompt 注入？
+4. 是否新增通用治理模板、script matrix、production readiness 或 operator recovery 文档，需要目标项目初始化后可见？
+5. `package.json files` 是否包含所有 npm 运行和初始化所需静态资料？
+6. `ai_workspace/loop-agent/init-surface.manifest.json` 是否更新了 package / init / exclude / trigger contract？
+7. 旧目标项目是否只需 advisory、需要手工复制新增文件，还是需要未来 `init audit/update` 迁移能力？
+
+## Output
+
+轻量审查可以只在 handoff 中说明。高影响审查应写入：
+
+```text
+ai_workspace/loop-agent/reports/YYYY-MM-DD-init-evolution-review.md
+```
+
+报告保持短小，包含：
+
+- changed surface
+- 可由 Git 解析的 Base 和 Head commit/ref；严格检查要求 Base 精确匹配所选 `--base`，Head 可以是运行时当前 `HEAD` 或它的一个可解析祖先提交。若 Head 是祖先，则 `reportHead..HEAD` 区间内一旦出现新的 `model-review` 高影响路径就会拒绝该报告；仅有 `advisory` 或 `surface-check` 变化不会让已完成的高影响审查失效。`working tree`、不可解析文字、无关历史报告都不能为其他变更范围放行严格检查。
+- decision: no init impact / surface check only / init update required
+- files updated
+- verification commands and results
+- residual risk
+
+## Required Verification
+
+按影响面选择最小命令：
+
+```bash
+bash scripts/check-init-surface.sh
+bash scripts/check-repo.sh
+npm test -- init-command dag-skills dag-validate-command
+npm pack --dry-run --ignore-scripts
+```
+
+如果没有新鲜验证证据，不要宣称 init evolution 已完成。