miro-multi-env-setup

Design and implement repository-side isolation for Miro development, staging, and production apps, redirects, token references, teams, and boards with hard guards. Use when configuring multiple environments. Trigger with "miro multi-environment isolation".

Allowed Tools

ReadGlobGrepWebFetchWriteEdit

Provided by Plugin

miro-pack

Miro operator workflows for OAuth, boards, governance, migration, and resilient synchronization (24 skills; live actions remain approval-gated)

saas packs v1.9.0
View Plugin

Installation

This skill is included in the miro-pack plugin:

/plugin install miro-pack@claude-code-plugins-plus

Click to copy

Instructions

Miro Multi-Environment Isolation

Overview

Make environment confusion detectable before a request leaves the process; use the evidence produced here to make the next decision explicit and reviewable.

Prerequisites

  • Approved Miro application, tenant, and board scope
  • Current repository and deployment evidence
  • Named owner, success criteria, and rollback or recovery boundary

Tool Discipline

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.

Current Contract

  • Each app has independent identity, redirects, scopes, token mode, and installations.
  • Access-token context must match the intended tenant.
  • Production credentials never belong in local or preview environments.
  • Token-expiration mode can differ because it is fixed at app creation.

Authentication

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.

Instructions

  1. Build an environment matrix of app hash, redirects, token mode, scopes, team, boards, store, and owner.
  2. Fail startup on missing, duplicated, or inconsistent mappings.
  3. Resolve credentials only through each environment's approved server-side reference.
  4. Assert token context before enabling operations.
  5. Test that production identifiers cannot appear in lower-environment config.
  6. Exercise rotation, revocation, promotion, and rollback per environment.

Approval Boundaries

Creating/installing production apps, copying tokens, and changing production redirects/scopes require explicit owner approval. Pause when the responsible owner or exact target is uncertain.

Output

Return scope, observed contract, proposed or completed actions, verification evidence, approvals, residual risks, and next owner. State what was not inspected or changed so the receipt cannot overclaim coverage.

Error Handling

Condition Response
Tenant or board context mismatches Stop before mutation and quarantine the credential mapping.
Current docs contradict the implementation Treat the official current contract as a blocker and design an explicit migration.
A mutation result is ambiguous Reconcile state before retrying.
Required evidence is unavailable Return a blocked decision with the smallest safe next probe.

Examples

The example is a redacted operator receipt; identifiers are hashes or bounded labels, not board content or credentials.


envs=3; unique-apps=3/3; context=3/3; cross-env-tests=passed; drift=0

Resources

Ready to use miro-pack?