协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
miro-local-dev-loop【开发与工程】Build repository-side scaffolding for a repeatable Miro development loop with isolated apps, fixture boards, contract tests, cleanup, and explicit operator commands. Use when developing Miro integrations locally. Trigger with "start Miro dev loop".
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
name: miro-local-dev-loop description: "Build repository-side scaffolding for a repeatable Miro development loop with isolated apps, fixture boards, contract tests, cleanup, and explicit operator commands. Use when developing Miro integrations locally. Trigger with "start Miro dev loop"." argument-hint: "[feature] [test-board-id]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.9.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags:
Shorten feedback cycles without turning a real collaboration board into a test fixture. Separate configuration, deterministic fixtures, and destructive cleanup; use the evidence produced here to make the next decision explicit and reviewable.
Use Read, Glob, and Grep to inspect the repository, configuration names, adapters, tests, and evidence. Use WebFetch only for current official Miro documentation. Use Write or Edit after confirming the requested mode, target environment, tenant, board, and approval boundary. These declared tools do not call authenticated Miro APIs or deployment CLIs; implement client, configuration, and test changes, then return exact operator commands or an approval-gated handoff for live execution.
For REST work, use OAuth 2.0 Authorization Code with the narrowest Miro scopes. Bind each encrypted token record to its user, application, authorized team, and granted scopes. Never print access tokens, refresh tokens, client secrets, authorization codes, or board content.
Do not expose a local callback publicly, install an app to another team, or delete unmarked board content without explicit approval. Pause when the responsible owner or exact target is uncertain.
Return environment guards, fixture IDs as hashes, test results, observed contract drift, cleanup count, and leftovers. State what was not inspected or changed so the receipt cannot overclaim coverage.
| Condition | Response |
|---|---|
| Production identifier detected | Abort before making any request. |
| Fixture create partially fails | Stop, inventory confirmed creations, and clean only those IDs. |
| Asynchronous state is not visible | Retry a bounded read with jitter; do not duplicate the write. |
| Cleanup ownership is uncertain | Leave the item and flag it for a board owner. |
The example is a redacted operator receipt; identifiers are hashes or bounded labels, not board content or credentials.
app=dev; board=test-only; fixtures-created=3; contract-tests=8/8; fixtures-removed=3; production-ids=0