Content
75%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is a well-structured, terse overview with concrete commands, a clear credential-lifecycle workflow including failure handling, and a single well-signaled external reference. It is held back from top marks by placeholder-filled commands, the absence of an explicit validation checkpoint in the lifecycle, and an unverifiable external reference with no bundle files present.
Suggestions
Add an explicit verification step in the Credential lifecycle (e.g., after exchanging the code, verify the token can fetch the calendar list before marking the credential valid) to push workflow clarity toward 5.
Replace placeholder arguments in the Common tasks table with a concrete minimal example for at least one flow so commands are copy-paste ready.
Either provide the referenced `docs/providers.md` as a bundle file under references/ or inline a minimal provider-interface contract so the "Writing a new provider" section is self-contained.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is lean and assumes Claude's competence (terse bullets like "OAuth; read freeBusy + write events", no explanations of what OAuth/CalDAV are); the Microsoft Teams paragraph is slightly more verbose, though its rationale (tenant and scope choices) earns its place, keeping it just below a 5. | 4 / 5 |
Actionability | Concrete commands and signatures are provided throughout (`connect-calendar --kind google_calendar --redirectUri ...`, `set-default-conferencing-app --credentialId <zoom-cred>`, `aggregateBusy({...})`, `completeVideoOAuth()`), and the Common tasks table maps intent to commands, but several use placeholders and the provider interface is deferred to `docs/providers.md`, leaving minor gaps. | 4 / 5 |
Workflow Clarity | The Credential lifecycle is a clear 5-step numbered sequence with an error-recovery feedback loop (token expiry -> refresh -> on failure set `invalid: true` and re-connect), but it lacks an explicit verify-connection checkpoint before persisting credentials, so it stops at 4. | 4 / 5 |
Progressive Disclosure | Sections are well-organized and the detailed provider interface is externalized via a clearly signaled one-level reference ("See `docs/providers.md` for the full interface."); however no bundle files exist to verify that reference, and the fairly detailed inline Microsoft Teams setup could arguably live in its own file, so it is not a clean 5. | 4 / 5 |
Total | 16 / 20 Passed |