[SomeoneToIgnore]

New API usage example (and comparison): https://github.com/cppalliance/runvil-classroom/compare/master...SomeoneToIgnore:runvil-classroom:kb/better-tool-declarations?expand=1

[coderabbitai]

Important

• Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 76e416ac-2fc9-4880-8c2e-73f2b3aec8d3

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The new behavior reaches plugin tools that opt into the typed Pack API.

The PR appears safe to merge, with a non-blocking documentation gap around shared tool state.

Findings

1.  Shared tool lifetime is undocumented ▶

Fix with agent prompt

### Issue 1
crates/runvil-plugin/src/tool.rs:41
`Tools` keeps each tool alive in the factory and shares that same object across every run. The new docs do not explain this, while the surrounding `Pack` docs describe per-run instances. Authors may therefore expect tool state to reset when a run ends.

Document that mutable tool state is shared across runs and that a tool's `Drop` does not run when a run ends. Authors who need per-run state should use their own `PackFactory`.

```suggestion
/// A [`PackFactory`] whose Pack offers each [`Tool`] added to it.
///
/// Every run shares the same tool objects, including their mutable state.
/// A tool's `Drop` does not run when a run ends. Use a custom
/// [`PackFactory`] when tools need per-run state.
```

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Adds Tool and Tools to let plugins declare typed arguments and outputs with less boilerplate.

• Rust tool types now build Packs with matching schemas and JSON results.

_{Reviews (1) · Last reviewed commit: "Simplify the tool declarations" · Reviewed by Greptile}

[greptile-apps]

Shared tool lifetime is undocumented

Tools keeps each tool alive in the factory and shares that same object across every run. The new docs do not explain this, while the surrounding Pack docs describe per-run instances. Authors may therefore expect tool state to reset when a run ends.

Document that mutable tool state is shared across runs and that a tool's Drop does not run when a run ends. Authors who need per-run state should use their own PackFactory.

Suggested change

	/// A [`PackFactory`] whose Pack offers each [`Tool`] added to it.
	/// A [`PackFactory`] whose Pack offers each [`Tool`] added to it.
	///
	/// Every run shares the same tool objects, including their mutable state.
	/// A tool's `Drop` does not run when a run ends. Use a custom
	/// [`PackFactory`] when tools need per-run state.

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/runvil-plugin/src/tool.rs
Line: 41

Comment:
**Shared tool lifetime is undocumented**

`Tools` keeps each tool alive in the factory and shares that same object across every run. The new docs do not explain this, while the surrounding `Pack` docs describe per-run instances. Authors may therefore expect tool state to reset when a run ends.

Document that mutable tool state is shared across runs and that a tool's `Drop` does not run when a run ends. Authors who need per-run state should use their own `PackFactory`.

```suggestion
/// A [`PackFactory`] whose Pack offers each [`Tool`] added to it.
///
/// Every run shares the same tool objects, including their mutable state.
/// A tool's `Drop` does not run when a run ends. Use a custom
/// [`PackFactory`] when tools need per-run state.
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!