Adobe Layered Failure Isolation

Overview

Isolate complex Adobe failures across DNS/TLS, auth, entitlement, schema, async state, storage, Runtime, and downstream layers without leaking credentials or content. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Troubleshooting proceeds from sanitized wire facts and known control boundaries. Decoding a bearer token locally is not authoritative proof of entitlement and raw verbose traces are unsafe defaults; use token response metadata, Console assignments, and request/job IDs. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Collect aliases, scope/profile names, expiry class, last rotation/use evidence, and correlation IDs. Never expose token payloads, Authorization, signed URLs, prompts, documents, images, or event bodies.

Instructions

1. Freeze speculative retries and capture one redacted failure envelope, topology, time window, and expected contract.
2. Check DNS/TLS/egress and service status without sending customer data or credentials to unapproved tools.
3. Verify credential type, organization/project/workspace, entitlement, scopes, profiles, host, method, version, and schema.
4. Trace submission, returned status URL, polling, terminal state, storage access, webhook/activation, and downstream acknowledgement.
5. Compare a synthetic control and the failing path one layer at a time while preserving request/job/activation IDs.
6. State the isolated layer, falsified hypotheses, minimal remediation, verification, and Adobe escalation evidence.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Incident/data/security owners approve production diagnostics. Any token introspection, content sample, external support upload, replay, cancellation, or deletion needs explicit approval.

Error Handling

• Do not paste a token into an online decoder.
• Do not run curl -v with secrets into shared logs.
• Do not create new jobs while the original completion state is unknown.

Output

Return the layer map, redacted evidence, hypotheses/te…

Adobe Architecture Variant Decision

Overview

Choose among direct service integration, Adobe App Builder, and a dedicated queued worker using evidence about ownership, latency, scale, storage, events, and operations. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Direct integration minimizes platform layers, App Builder offers Adobe-native Runtime/workspaces/events, and dedicated workers maximize queue/storage portability. None removes the need for auth, entitlement, async lifecycle, data custody, observability, and rollback. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Score how each variant binds S2S/user credentials, organization/project/workspace, product profiles, secret storage, and deployment authority.

Instructions

1. Capture workload operations, data owners, latency/throughput, budgets, team skills, compliance, RTO/RPO, and portability needs.
2. Model direct server-side adapters, App Builder Runtime, and dedicated queued workers against the same service contracts.
3. Compare auth/entitlement, async jobs, storage custody, events, limits, observability, failure isolation, deployment, and lock-in.
4. Prototype the riskiest seam with synthetic data and measure rather than inventing latency or scale claims.
5. Threat-model each variant and name compensating controls, operational owners, exit cost, and rollback.
6. Issue a dated decision with rejected options, evidence, conditions, review triggers, and migration seam.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Architecture, security, data, budget, and operations owners approve the decision. A prototype does not authorize production data, spend, deploy, or destructive actions.

Error Handling

• Reject browser-side client-secret designs.
• Reject App Builder claims that assume Runtime namespace auth for current deploys.
• Reject direct synchronous handlers for unbounded async work.

Output

Return decision drivers, comparison matrix, prototype evidence, threats, selected variant, conditions, exit plan, an…

Adobe Contract-Safe CI

Overview

Build deterministic CI gates for Adobe adapters without giving fork jobs credentials or spending against live creative/document APIs. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Pull requests can prove routes, headers, schemas, polling, redaction, EOL bans, errors, and retries offline. Live tests require a protected trusted branch, non-production project/workspace, synthetic fixtures, strict budget, and explicit mutation/cleanup boundaries. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Fork and untrusted PR jobs receive no secrets. Protected lanes use environment-scoped credentials and record aliases only; secret canaries gate artifacts and logs.

Instructions

1. Map CI trust boundaries, service adapters, fixtures, secret sources, deploy workflows, and fork behavior.
2. Add offline request/response contracts for auth, async URLs, PDF assets, webhooks, errors, throttling, and EOL endpoints.
3. Separate untrusted PR jobs from protected credentialed smoke and deploy jobs.
4. Use synthetic inputs, transaction/generation ceilings, serialized jobs, and deterministic cleanup in any live lane.
5. Gate on secret scans, obsolete-route scans, negative cases, generated-file checks, and immutable artifact identity.
6. Treat skipped trusted tests as unknown and retain redacted receipts plus cleanup evidence.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Repository and sandbox owners approve trusted live lanes; security approves secret access; product and budget owners approve any upload, generation, write, deploy, or deletion.

Error Handling

• A 429 is not an acceptable successful assertion.
• Never auto-update fixtures from live customer data.
• Fail if a fork can request a secret-bearing environment.

Output

Return the trust matrix, fixtures, gates, commands, live boundary, secret evidence, cleanup, and owners. Mark assumptions, observed environment behavior, owners, evidence dates, and unresolved gaps explicitly.

Examples

Adobe Response-Led Error Triage

Overview

Classify Adobe failures from redacted response evidence and select the smallest bounded recovery. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

HTTP status, product error code, request/job/activation identity, credential type, organization, entitlement, request validity, retry headers, and service state are separate evidence. There is no safe universal mapping from one status to one fix. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Record only credential aliases, scopes, profiles, and expiry class. A 403 may be organization, entitlement, product-profile, policy, or resource authority; do not solve it by blind privilege expansion.

Instructions

1. Capture one sanitized request/response envelope, operation, environment, timestamp, and correlation identifiers.
2. Classify transport, authentication, authorization/entitlement, validation/policy, throttling, conflict, async-state, or vendor-service failure.
3. Compare host, method, version, schema, organization/project/workspace, scopes, profiles, and data ownership with current docs.
4. Apply the smallest class-specific correction and preserve the original evidence.
5. Retry only transient and idempotent work within Retry-After and strict attempt/time budgets.
6. Verify with the least consequential reproduction and package unresolved cases for Adobe support.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Scope/profile/credential changes require security and organization-owner approval. Prompt, document, asset, event registration, deploy, or retry changes require their respective owners.

Error Handling

• Never infer a 24-hour token lifetime unless the actual token response proves it.
• Never accept 429 as a successful CI test.
• Do not dump raw HTTP traces containing Authorization or signed URLs.

Output

Return the evidence envelope, fault class, ruled-out causes, minimal action, retry decision, verification, and escalation packet. Mark assumptions, observed environment be…

Firefly Controlled Async Generation

Overview

Run a current Adobe Firefly image generation job with prompt approval, response-led polling, artifact custody, and cancellation. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Current Firefly asynchronous operations return jobId, statusUrl, and cancelUrl. Follow those returned URLs rather than inventing a jobs route. Model/API versions and supported input-storage domains are mutable; recheck usage notes for the selected operation. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Acquire OAuth Server-to-Server credentials only after enterprise entitlement and product assignment are proven. Send x-api-key and bearer headers server-side; never expose them to a browser or job record.

Instructions

1. Record the approved business purpose, prompt, model/operation, dimensions, quantity, budget, and content owner.
2. Read the current API and usage notes; validate endpoint version, request schema, supported signed-URL hosts, and content rules.
3. Create a redacted idempotency record and submit one bounded asynchronous job.
4. Persist jobId plus returned statusUrl and cancelUrl, then poll with jitter and strict elapsed-time limits.
5. On success, validate media type and size, transfer the artifact to approved storage, and preserve provenance/content-credential metadata.
6. On failure or timeout, classify the vendor response, cancel when approved, reconcile spend, and expire temporary access.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Require creative and budget approval before submission. External storage, personal/regulated content, bulk generation, cancellation, publication, and deletion each require the named owner.

Error Handling

• Never retry a policy or validation rejection by silently rewriting the prompt.
• After ambiguous submission, reconcile by idempotency evidence before resubmitting.
• Stop if a returned URL leaves the documented allowlist or includes a secret in logs.

Output

Return prompt and policy receipt, …

PDF Services Controlled Document Job

Overview

Execute an Adobe PDF Services operation through explicit asset custody, asynchronous status, output verification, and cleanup. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

The REST lifecycle is authenticate, supply a supported signed URL or create an asset and upload to its pre-signed URI, create an async job, follow the Location/status contract, retrieve output, and delete Adobe-hosted assets when no longer needed. Limits vary by operation. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Use server-side service credentials and bind assets to the same credential or approved signed URL. Signed URLs are bearer capabilities and must be redacted, narrowly scoped, and short-lived.

Instructions

1. Classify the input, operation, page/file constraints, output, retention, transaction budget, and owners.
2. Choose customer-managed signed URLs or Adobe-hosted assets and document the custody boundary.
3. Validate media type, size, protection state, operation contract, and current limits before upload.
4. Create the job once, retain the returned status location, and poll within an attempt and elapsed-time budget.
5. Download or receive output into approved storage, verify type/hash/expected structure, and acknowledge downstream custody.
6. Delete approved Adobe-hosted assets promptly and reconcile transaction, failure, retention, and deletion evidence.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Require data-owner and budget approval before upload or job creation. Decryption, external transfer, output retention, and asset deletion require explicit authorized owners.

Error Handling

• Do not retry a disqualified or malformed document unchanged.
• Do not log input/output content, credentials, or signed URLs.
• Treat an ambiguous job result as reconciliation work, not permission to duplicate a transaction.

Output

Return classification, storage decision, asset/job ledger, status evidence, verified output, transaction class, de…

Adobe Workload Cost and Waste Review

Overview

Reduce Adobe integration spend using contract, invoice, usage, queue, storage, and retry evidence instead of invented per-call prices. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Firefly entitlements and generative usage, PDF Services document transactions, and application compute/storage/egress are distinct cost classes. Pricing and plan limits are mutable; use the account contract, live usage surface, and dated first-party pages. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Collect aggregated aliases, operation classes, outcomes, retries, bytes, and durations. Prompts, assets, documents, users, tokens, and signed URLs are not cost telemetry.

Instructions

1. Define billing window, account/contract owner, services, operations, workload units, and non-negotiable quality objectives.
2. Reconcile invoice/contract and service usage with submitted jobs, terminal outcomes, retries, duplicates, and storage/compute costs.
3. Find duplicate submissions, failed transactions, oversized inputs, stale outputs, excessive polling, and unused environments.
4. Model idempotency, caching-by-approved-hash, batching where documented, input sizing, queue admission, and retention changes.
5. Canary one control and measure quality, latency, 429s, usage units, and downstream impact.
6. Adopt only verified savings with budget alerts, anomaly ownership, rollback, and a dated pricing assumption register.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Budget and workload owners approve spend controls; data owner approves hashing/caching/retention; product owner approves quality or freshness changes.

Error Handling

• Do not publish fixed prices or universal free-tier assumptions in workflow logic.
• Do not cache policy-sensitive prompts or customer outputs without approval.
• Do not lower cost by bypassing entitlements or multiplying credentials.

Output

Return reconciled baseline, waste map, dated assumptions, control options, canary ev…

Adobe Data Custody and Privacy Review

Overview

Analyze and enforce classification, minimization, signed-URL custody, retention, deletion, content provenance, and privacy-request boundaries for Adobe workflows. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Adobe services have distinct custody contracts. PDF Services can use supported customer-storage signed URLs and can delete Adobe-hosted assets through the Assets endpoint. Firefly inputs/outputs and Content Credentials require product-specific review. Privacy Service is a separate Experience Platform API with its own authorization contract. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Treat tokens and signed URLs as secrets and prompts, images, PDFs, extracted text, event bodies, and identifiers as classified content. Do not send data to a service merely because auth succeeds.

Instructions

1. Map every input, derived field, prompt, artifact, event, log, storage hop, recipient, jurisdiction, purpose, and owner.
2. Minimize fields/content and select customer-managed storage or Adobe assets from current service/security evidence.
3. Set signed-URL scope/expiry, encryption, access, provenance, retention, deletion, and legal-hold controls.
4. Validate content-policy and Content Credentials behavior from live product outcomes without inventing regex screening guarantees.
5. Separate ordinary application deletion from regulated Privacy Service requests and identify responsible controllers/processors.
6. Test redaction, access, expiry, deletion, legal hold, provenance preservation, and incident escalation.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Data, privacy, security, and product owners approve processing and destinations. Upload, external transfer, retention change, Privacy Service submission, or deletion requires explicit authority.

Error Handling

• Do not publish universal 24-hour retention claims across Adobe products.
• Do not pre-screen prompts with unsupported claims that override Adobe's actual decision.
• D…

Adobe Redacted Diagnostic Bundle

Overview

Assemble a minimal, reproducible Adobe diagnostic bundle with default-deny collection and verifiable redaction. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Useful evidence is version, configuration-key presence, service/operation, environment aliases, timestamps, status/error class, request/job/activation identifiers, retry history, and a synthetic reproduction. Tokens, secrets, signed URLs, prompts, images, documents, event bodies, and customer identifiers are excluded by default. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Use one-way fingerprints only when correlation is necessary. Never call the IMS token endpoint merely to populate a support archive.

Instructions

1. Define incident window, service, operation, data classification, recipients, retention, and custodian.
2. Create an allowlist manifest before collection and enumerate explicitly forbidden fields and file classes.
3. Collect dependency locks, deployment revision, sanitized configuration keys, status/error evidence, and correlation IDs.
4. Reproduce with a synthetic fixture or read-only check and record expected versus observed behavior.
5. Run secret, URL, PII, document/image, prompt, and identifier canaries across every output.
6. Hash the bundle, record redactions and gaps, transfer through an approved channel, and schedule deletion.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Incident and data owners approve collection; security approves external disclosure. Any broader trace, content sample, or retention extension requires a fresh explicit approval.

Error Handling

• Abort if an Authorization header, token, client secret, refresh token, signed URL, or customer content survives.
• Do not execute speculative network probes against production.
• Quarantine a bundle whose audience or deletion owner is unknown.

Output

Return a minimal archive, allowlist manifest, hashes, redaction scan, reproduction, custody log, expiry, and deletion owner. Mar…

Adobe Integration Deployment

Overview

Deploy an Adobe-backed service or App Builder application with isolated environments, immutable artifacts, canaries, observability, and rollback. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

AIO CLI v11 and later require Adobe IMS authentication for App Builder deploys: interactive aio login locally or OAuth Server-to-Server in CI. Runtime namespace auth is not a current deploy mechanism. Stage and Production workspaces are isolated. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Bind deploy credentials and product credentials to the target environment. app.config.yaml is reviewed source; .env and .aio are local state and must not be committed.

Instructions

1. Verify the artifact digest, dependency locks, configuration schema, tests, migration, and rollback artifact.
2. Resolve organization, project, workspace, service credentials, product profiles, storage, and event registrations.
3. Confirm the AIO CLI/auth path or external platform identity and fail closed on environment mismatch.
4. Deploy dark, verify configuration and logs, then run one approved read-only or synthetic smoke path.
5. Canary bounded traffic while watching auth, 429, jobs, queue age, spend, activations, and content-safe errors.
6. Promote or roll back from declared thresholds and preserve deployment, activity-log, cleanup, and owner receipts.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Release owner approves production deployment; security approves credentials; data/budget owners approve live product calls; webhook or asset deletion needs separate approval.

Error Handling

• Stop if the selected workspace differs from the review target.
• Do not commit .env or .aio.
• Rollback if artifact, auth, entitlement, storage, or observability evidence is missing.

Output

Return artifact and environment identity, auth path, preflight, smoke/canary metrics, decision, rollback, cleanup, and owners. Mark assumptions, observed environment behavior, owners, evid…

Adobe Enterprise Access Governance

Overview

Govern Adobe Developer Console roles, product profiles, technical accounts, User Management API automation, and periodic access review. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Developer Console project access, API scopes, product entitlement, product-profile assignment, and resource ownership are distinct. User Management API manages enterprise users/groups/entitlements under its own authorization; it is not a generic fix for application API access. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Use named admin/automation identities with least privilege, environment binding, approver separation, rotation, and review dates. Technical-account access is constrained by assigned product profiles.

Instructions

1. Inventory organizations, directories, admins, developers, projects, credentials, users/groups, products, profiles, and automation.
2. Build a role-to-operation matrix and calculate effective access across Console roles, scopes, profiles, and resources.
3. Identify orphaned credentials, broad profiles, stale users, shared admins, and cross-environment grants.
4. Design joiner/mover/leaver and service-account changes with approval, idempotency, reconciliation, and rollback.
5. Canary UMAPI changes on a synthetic group where authorized and compare intended versus effective access.
6. Schedule recertification, exception expiry, secret rotation, audit export, and emergency revocation.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Organization, product, identity, and security owners approve grants and revocations. Bulk membership/profile changes and credential deletion require explicit execution approval.

Error Handling

• Do not equate an OAuth scope with product entitlement.
• Do not use UMAPI against an unverified organization.
• Quarantine drift rather than auto-removing critical access without an approved rollback.

Output

Return organization/access inventory, effective-access matrix, findings, approved cha…

Adobe Minimal Access Proof

Overview

Prove one Adobe API connection with a current, read-only or synthetic operation and a content-safe receipt. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

The smallest useful proof is product-specific: token acquisition alone does not demonstrate API entitlement. Prefer a documented read or a synthetic asynchronous job whose artifact can be safely deleted; do not use retired Photoshop v1, /sensei/cutout, or Lightroom Firefly Services endpoints. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Use a dedicated non-production credential or consenting test user and record only aliases, scope names, product profiles, response status, and request identifiers.

Instructions

1. Resolve the exact Adobe organization, project, workspace, credential type, and service.
2. Read the current product quickstart and identify the least consequential documented proof.
3. Validate endpoint host, method, request schema, scopes, entitlement, and storage requirements offline.
4. Run exactly one bounded proof and capture redacted response and correlation evidence.
5. Verify the expected allow case and one safe denied or invalid fixture without broadening access.
6. Delete approved temporary assets and issue a pass, fail, or entitlement-blocked result.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Require the sandbox and data owners before a live call. Image/document generation, upload, spend, or asset deletion needs explicit approval even in a test environment.

Error Handling

• Stop if the service is absent from Developer Console.
• Do not treat a 401, 403, or policy rejection as a reason to guess new scopes.
• Never use production customer files as a hello-world fixture.

Output

Return the selected proof, current documentation, auth/entitlement aliases, request receipt, negative result, cleanup evidence, and decision. Mark assumptions, observed environment behavior, owners, evidence dates, and unresolved gaps explicitly.

Examples

…

Adobe Integration Incident Command

Overview

Triage, contain, recover, and review Adobe auth, product, async-job, event, storage, spend, or App Builder incidents with evidence. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Vendor status, local deployment, credentials/entitlement, request validity, queues, storage, and downstream systems are separate failure domains. Containment preserves evidence while stopping new harm; recovery never starts with blind retry or credential deletion. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

A suspected secret or signed-URL exposure is a security incident. Add/rotate/deploy/verify before approved old-secret deletion; invalidate exposed temporary access and preserve last-use evidence.

Instructions

1. Declare severity, commander, service/operation, environment, customer/data/spend impact, and incident clock.
2. Freeze risky deploys/replays and capture content-safe request/job/activation IDs, queue state, artifact revision, and vendor status.
3. Classify local, auth/entitlement, validation/policy, throttling, vendor, event-delivery, storage, or downstream failure.
4. Contain via queue pause, circuit, credential rotation, registration disablement, or traffic rollback according to owner authority.
5. Recover with one bounded synthetic canary, reconcile ambiguous jobs/events/assets, and restore traffic in stages.
6. Verify data/spend/cleanup, communicate status, preserve timeline, and assign corrective actions with evidence.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Commander coordinates; security authorizes secret response; product/data/budget owners authorize replay, generation, transfer, or deletion; release owner authorizes rollback/redeploy.

Error Handling

• Do not delete the only credential during containment.
• Do not replay unknown PDF/Firefly jobs without reconciliation.
• Do not declare recovery from endpoint health alone.

Output

Return severity, timeline, evidence, fault domain, containment, recovery tests, rec…

Adobe Authentication and Entitlement Intake

Overview

Select and prove the correct Adobe authentication model, entitlement, product profile, and secret lifecycle before integration work. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

OAuth Server-to-Server uses client credentials for application- or organization-owned data. User Authentication uses authorization code, explicit user consent, and optional offline access for user-owned data. Service Account JWT is deprecated and is never a valid new-work fallback. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Keep client secrets and refresh tokens in an approved server-side secret store. Product profiles constrain organization data; scopes and a valid token do not prove entitlement by themselves.

Instructions

1. Classify the API, data owner, organization, environment, and whether a user must consent.
2. Confirm the service is visible in the selected Developer Console organization and identify its license and admin owner.
3. Choose OAuth Server-to-Server or User Authentication from the ownership contract; reject JWT configuration.
4. Select only required scopes and product profiles and record requested versus granted authority.
5. Acquire a token through an established OAuth library and run one read-only, product-specific proof.
6. Document expiry, refresh, revocation, rotation, break-glass, and owner-transfer procedures.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Require the organization or user owner for consent and product-profile assignment. Security approves production secret storage and rotation. Deleting a credential or old secret requires explicit approval after replacement evidence.

Error Handling

• A token without product entitlement is not ready.
• Do not broaden scopes to cure a product-profile denial.
• Never print, decode, commit, or transmit a live token or secret.

Output

Return the ownership decision, auth flow, scope/profile matrix, entitlement proof, redacted token test, lifecycle runbook, …

Adobe Integration Pitfall Review

Overview

Detect current high-risk Adobe integration traps before they become production incidents. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

High-risk traps include Service Account JWT, confusing S2S with user auth, missing entitlements/profiles, secrets in clients, retired Photoshop v1 and Lightroom Firefly Services, reconstructed async URLs, leaked signed URLs, fixed limits, unverified events, and wrong App Builder workspace. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Review effective authority and secret flow before code style. A valid token, installed SDK, or successful deploy does not prove product entitlement or correct data ownership.

Instructions

1. Read manifests, locks, config, adapters, routes, workflows, logs, dashboards, tests, and runbooks.
2. Glob and Grep for JWT, /sensei/cutout, Lightroom Firefly Services, client-side secrets, fixed quotas, and hardcoded job routes.
3. Trace auth ownership, product profiles, versions, signed URLs, async states, retries, events, workspaces, and cleanup.
4. Classify each finding as obsolete, unsafe, brittle, undocumented, environment-specific, or stale evidence.
5. Propose the smallest compatible correction with tests, canary, rollback, and named owner.
6. Edit only approved repository artifacts, rerun gates, and record unresolved external dependencies.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Read-only review needs no mutation authority. Credential/profile changes, production calls, deploys, replays, registration changes, and deletion require separate explicit approval.

Error Handling

• Do not replace one remembered constant with another.
• Do not infer a product from a similarly named Adobe API.
• Do not auto-fix secrets without coordinated rotation and revocation.

Output

Return findings with file/line evidence, current sources, severity, correction, test, owner, and unresolved risks. Mark assumptions, observed environment behavior, owners, evidence dates, and …

Adobe Capacity and Load Envelope

Overview

Derive a safe Adobe workload envelope from synthetic load, queue/backpressure behavior, current service constraints, spend, and output correctness. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Capacity is service-, operation-, entitlement-, and contract-specific. Measure arrival rate, queue age, concurrency, vendor time, 429/5xx, retries, terminal completion, storage transfer, cost units, and correctness. Do not publish guessed universal throughput. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Use dedicated sandbox credentials, synthetic non-sensitive inputs, environment assertions, and a hard kill switch. Credential sharding to evade limits is forbidden.

Instructions

1. Define workload shape, target volume, objectives, data/output checks, budget, ramp, abort thresholds, and cleanup.
2. Read current product constraints and measure a single-job baseline across all lifecycle stages.
3. Build an open/closed load model that drives the queue, not direct uncontrolled vendor floods.
4. Ramp one dimension at a time while recording concurrency, latency, 429s, failures, completions, spend, and artifacts.
5. Exercise backpressure, cancellation, unknown completion, vendor degradation, worker restart, and DLQ recovery.
6. Publish the conservative envelope, autoscaling/queue controls, emergency stop, capacity owner, and retest date.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Sandbox, vendor-account, data, budget, and operations owners approve tests. Bulk generation/transactions, cancellation, and artifact deletion require explicit execution approval.

Error Handling

• Never load-test production customer workflows.
• Abort on unexpected spend, content leakage, growing unknown jobs, or error threshold.
• Do not use identities or projects as rate-limit shards.

Output

Return assumptions, current constraints, load model, raw/result metrics, correctness evidence, safe envelope, aborts, cleanup, and retest owner. Mark assumptions,…

Adobe Isolated Development Loop

Overview

Build a repeatable local loop for Adobe adapters using synthetic contracts before any remote Runtime or product call. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

App Builder local modes differ: aio app dev runs actions locally and lacks activation records and some Runtime-only storage capabilities; aio app run uses remote Runtime actions with local UI. Offline fixtures must cover both product responses and those environment differences. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Use synthetic data and non-production aliases. Keep .env and .aio out of version control; pass configured values to actions rather than assuming local environment variables exist in deployed Runtime.

Instructions

1. Inventory the adapter, SDK locks, App Builder configuration, fixtures, and current local-mode assumptions.
2. Define typed request, response, async-status, error, throttling, and redaction contracts from current docs.
3. Create synthetic fixtures for success, additive fields, malformed data, 401/403, 429, 5xx, and ambiguous completion.
4. Run unit and contract tests with network access disabled and secret canaries enabled.
5. If App Builder is used, exercise aio app dev and a separately approved aio app run path where Runtime fidelity matters.
6. Record mode differences, cleanup remote test artifacts, and keep only sanitized deterministic fixtures.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Require sandbox-owner approval for remote Runtime or Adobe API calls and separate approval for uploads, generation, writes, or deletion.

Error Handling

• Fail if a production hostname, organization, credential, or asset enters a fixture.
• Do not snapshot signed URLs or document/image bytes into source control.
• Treat locally unsupported State or Files behavior as unknown until remote testing.

Output

Return the client seam, fixture manifest, commands, secret scan, local/remote matrix, cleanup, and remaining unknowns. Mark assumptions…

Adobe Platform Migration Program

Overview

Analyze and execute a multi-workload migration into or across Adobe services with contract evidence, dependency waves, dual-run reconciliation, cost controls, and rollback. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

A migration is a set of product-specific contracts, not an endpoint translation. Auth ownership, entitlement, async behavior, input/output fidelity, storage custody, content rules, limits, events, and operational tooling must each map from source to target. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Choose S2S or user auth per data owner, not migration convenience. Preserve source/target identity and access evidence and never copy secrets or production content into test fixtures.

Instructions

1. Inventory source workflows, volumes, identities, data classes, formats, SLAs, costs, dependencies, and retirement constraints.
2. Map each capability to current Adobe service/version or classify it as gap, redesign, or retire; exclude EOL products.
3. Define adapters, canonical data contracts, idempotency, provenance, reconciliation, storage, and rollback boundaries.
4. Build synthetic and sampled approved parity tests for outputs, metadata, ordering, policy, latency, and cost.
5. Migrate in dependency waves with shadow/dual-run only where duplicate actions and spend are controlled.
6. Reconcile every wave, cut over from explicit thresholds, archive receipts, and remove approved obsolete paths and credentials.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Program, identity, security, data, product, budget, and operations owners approve their waves. Live content movement, dual writes, cutover, and deletion require separate explicit approval.

Error Handling

• Do not claim parity from happy-path samples only.
• Do not map a retired Lightroom service to a different Lightroom API by name.
• Pause on count, content, provenance, authorization, or cost divergence.

Output

Return capability map, contracts, wave pla…

Adobe Multi-Environment Isolation

Overview

Separate Adobe development, stage, and production organizations/projects/workspaces, credentials, profiles, storage, events, budgets, and evidence. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

App Builder provides isolated workspaces such as Stage and Production within a project, while some risk boundaries require separate projects or credentials. Environment equivalence must be proven from configuration and entitlement, not assumed from names. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Each credential is bound to one declared environment and secret store. Product profiles, redirect URIs, event registrations, storage buckets, and consenting users are independently mapped.

Instructions

1. Inventory organizations, projects, workspaces, credentials, services, profiles, users, URLs, storage, events, and billing owners.
2. Define isolation requirements and choose workspace, project, or organization separation for each threat and operational boundary.
3. Create a typed environment manifest with aliases and secret references but no values.
4. Add fail-closed assertions for organization/project/workspace, endpoint hosts, storage, event recipient, and production fixture bans.
5. Compare environment capabilities and run synthetic parity tests without copying production data.
6. Document promotion, drift detection, emergency disablement, rotation, teardown, and ownership.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Security and organization admins approve environment/credential/profile creation; data and budget owners approve storage and live workloads; teardown and deletion require separate approval.

Error Handling

• Never infer environment from a branch name alone.
• Do not reuse production credentials or data in development.
• Treat entitlement differences as explicit drift, not a test inconvenience.

Output

Return the environment matrix, isolation rationale, typed manifest, parity results, promotion gate, drift con…

Adobe Content-Safe Observability

Overview

Instrument Adobe integrations with redacted structured logs, request/job/activation correlation, service-level indicators, alerts, and evidence retention. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

App Builder local, Runtime activation, CLI, and Console log surfaces differ. Successful activation persistence is mode-dependent; current Console application logs can provide broader visibility. Runtime log size and retention are bounded and mutable. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Log service, operation, environment aliases, request/job/activation IDs, state, status class, duration, retry, bytes, and usage class. Never log secrets, Authorization, signed URLs, prompts, document/image/event content, or direct identifiers.

Instructions

1. Define SLOs, telemetry consumers, data classification, retention, and incident evidence needs.
2. Inventory logs, metrics, traces, dashboards, activations, queue evidence, and current blind spots by execution mode.
3. Create a redacted correlation model from ingress through queue, Adobe request/job, storage, and downstream acknowledgement.
4. Measure availability, terminal success, queue age, vendor time, 429s, retries, unknown jobs, duplicates, and cleanup lag.
5. Add alerts tied to actionable runbooks, budget limits, credential/EOL dates, event disablement, and stale assets.
6. Run content/secret/URL canaries, failure drills, retention verification, and dashboard reconciliation.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Security and data owners approve telemetry fields and destinations; operations owns alerts and retention. Extra logging or external forwarding requires explicit approval.

Error Handling

• Do not enable production extra logging as a default workaround.
• Do not treat missing successful activations as zero traffic.
• Stop telemetry export if content or signed-URL canaries appear.

Output

Return telemetry schema, redaction rules, SLO/SLI definitions, da…

Adobe Measured Performance Tuning

Overview

Improve Adobe integration latency and throughput from measurements while preserving correctness, policy, and spend boundaries. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

No universal Adobe latency table is a production contract. Measure token reuse, queue wait, upload/download, submission, status polling, vendor processing, validation, and downstream work separately by service and operation. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Use content-free metrics and aliases. Token reuse must honor actual expiry response and revocation; cached signed URLs and customer outputs are not performance caches by default.

Instructions

1. Define objective, workload, input class, concurrency, cost ceiling, completeness, and measurement window.
2. Instrument queue, transport, vendor job, polling, storage transfer, validation, retry, and downstream spans.
3. Measure percentiles, 429s, failures, bytes, transactions/generations, and artifact correctness from a synthetic canary.
4. Test token reuse, connection reuse, right-sized inputs, bounded concurrency, adaptive polling, and safe deduplication independently.
5. Canary one change within current documented constraints and compare correctness plus spend, not latency alone.
6. Retain verified gains with rollback thresholds and remove instrumentation that captures sensitive content.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Workload, data, and budget owners approve load or generation tests. Do not increase credentials or identities to manufacture throughput.

Error Handling

• Delete invented benchmark tables.
• Do not parallelize past queue, spend, or service evidence.
• Roll back if output correctness, content provenance, throttling, or cost worsens.

Output

Return baseline spans, bottleneck attribution, experiments, before/after percentiles, correctness/spend proof, selected change, and rollback. Mark assumptions, observed environment behavior, owners, evidence dates, and u…

Adobe Policy and Execution Guardrails

Overview

Analyze and enforce repository, runtime, data, spend, endpoint, and approval guardrails without guessing secret formats or content-policy rules. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Guardrails derive from current service docs and local policy: approved auth flows, hosts/versions, scopes/profiles, schemas, storage domains, budgets, data classes, and approval boundaries. Secret prefixes and prompt regexes are not authoritative security or content-policy controls. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Use mature secret scanners plus entropy/context rules and provider revocation procedures. Runtime authorization evaluates credential binding, entitlement, resource, operation, and approval.

Instructions

1. Inventory all Adobe calls, credentials, endpoints, versions, payload classes, storage URLs, retries, jobs, events, and destructive operations.
2. Create allowlists for current hosts/versions/services and denylists for JWT, /sensei/cutout, and retired Lightroom Firefly Services.
3. Validate configuration/request/response schemas and redact tokens, signed URLs, prompts, and customer content.
4. Enforce data-purpose, owner, budget, concurrency, idempotency, and approval tokens before side effects.
5. Route Adobe policy outcomes to a human-readable denial path; never silently rewrite prompts or broaden scopes.
6. Test bypasses, stale docs, false positives, emergency disablement, exception expiry, and audit receipts.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Security/product/data/budget owners approve policy and exceptions. Generation, upload, deploy, webhook change, cancellation, replay, and deletion remain independently approved actions.

Error Handling

• Do not claim Adobe secrets always have a specific prefix.
• Do not claim local regexes predict Firefly policy decisions.
• Fail closed when endpoint/version or approval evidence is unknown.

Output

Return policy sources, allow/deny rules, enforce…

Adobe Production Readiness Decision

Overview

Issue an evidence-backed production decision across Adobe auth, entitlements, API versions, data custody, async reliability, spend, observability, and rollback. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

A launch is ready only when the deployed artifact and actual organization/project/workspace, credentials, product profiles, service versions, storage, queues, events, monitoring, support, and rollback are evidenced together. Passing a token call or happy path is insufficient. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Verify secret lifecycle, user consent if applicable, least privilege, entitlement, rotation, revocation, and environment isolation. JWT, Photoshop v1, and retired Lightroom Firefly Services references are launch blockers.

Instructions

1. Verify immutable artifact, dependencies, configuration, generated assets, tests, migrations, and rollback target.
2. Confirm organization/project/workspace, auth flow, scopes, profiles, entitlement, storage, and owner matrices.
3. Review every service version, async job, retry/idempotency, rate/spend, event authenticity, and EOL guard.
4. Review data classification, signed URLs, logs, retention, deletion, incident response, and vendor support custody.
5. Exercise canary, denial, 429, unknown status, rollback, reconciliation, and cleanup paths.
6. Issue GO, CONDITIONAL GO, or NO-GO with evidence, owners, expirations, and rollback authority.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Named release, security, data, budget, and operations owners approve their controls. Deploy, generation, upload, webhook replacement, secret deletion, and asset deletion remain separate actions.

Error Handling

• NO-GO on obsolete endpoints, missing entitlement, unbounded polling/retries, or unverified rollback.
• A skipped negative test remains an open condition.
• Do not waive content or signed-URL leakage as observability detail.

Output

Return the signed control matrix, evide…

Adobe Throttling and Backpressure

Overview

Implement service-specific Adobe admission control, Retry-After handling, bounded retries, and spend-aware queues. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Adobe limits differ by service, operation, entitlement, and contract. Recheck first-party limits at execution. A valid Retry-After response is authoritative; absence requires conservative capped exponential backoff with jitter, not a remembered universal rate. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Partition control by approved credential, organization, service, operation, and tenant without exposing tokens or multiplying credentials to evade policy.

Instructions

1. Inventory traffic, operations, concurrency, queues, retry chains, job durations, transactions, and downstream acknowledgements.
2. Read current service limits and capture observed 429 headers and error bodies from sanitized evidence.
3. Set conservative token buckets, concurrency, queue size, and spend ceilings below verified constraints.
4. Retry only classified transient, idempotent work; honor valid server delay and cap attempts plus elapsed time.
5. Quarantine ambiguous writes/jobs and propagate backpressure rather than recursively retrying.
6. Load-test with synthetic data, publish the safe envelope, and assign an emergency reduction switch.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Workload, budget, and sandbox owners approve load tests and capacity changes. Do not add organizations, users, keys, or projects to circumvent limits.

Error Handling

• Fixed pack-wide RPM tables are forbidden.
• Do not retry 401, 403, content-policy, validation, or terminal job failures blindly.
• Stop before the retry budget becomes a spend amplifier.

Output

Return cited current constraints, observed headers, control settings, retry matrix, queue policy, load curve, spend guard, and rollback. Mark assumptions, observed environment behavior, owners, evidence dates, and unresolved gaps explicitly.

Adobe Integration Reference Architecture

Overview

Define a production Adobe architecture spanning identity, service adapters, async workers, asset custody, I/O Events, App Builder, evidence, and recovery. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

The architecture separates control plane from data plane: identity/entitlement/configuration/deploy/approvals are control; prompts/documents/images/events/jobs are data. Each Adobe product has its own version, storage, error, limit, and lifecycle adapter. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Bind credential broker output to organization, project/workspace, service, scopes, product profiles, environment, and owner. User-owned data uses explicit user auth rather than silent S2S substitution.

Instructions

1. State business workflows, sources of truth, services, data classifications, consistency, budget, RTO, and RPO.
2. Map clients, auth broker, service adapters, queues, workers, asset storage, event ingress, evidence store, and destinations.
3. Define request, async-status, idempotency, retry, cancellation, signed-URL, output-verification, and cleanup contracts per service.
4. Define I/O Events authenticity/deduplication and App Builder workspace/deploy/log boundaries.
5. Threat-model credential theft, cross-environment access, forged events, URL leakage, replay, duplicate spend, and retired API use.
6. Choose canary stages, capacity envelope, observability, incident controls, reconciliation, and tested rollback.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Architecture, security, data, budget, product, and operations owners approve production. New services, scopes, storage destinations, event providers, writes, or destructive actions require explicit approval.

Error Handling

• Reject shared unbound credentials and generic one-client-for-everything designs.
• Reject synchronous waiting without cancellation/reconciliation.
• Reject architectures containing JWT, Photoshop v1, or retired Lightroom Firefly Services.

Adobe Async Reliability Controls

Overview

Analyze and design idempotency, bounded polling, per-service circuits, durable queues, DLQ/replay, degradation, and reconciliation for Adobe workloads. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Adobe services fail independently and async submission may succeed before the caller sees a response. Reliability is a state machine: planned, approved, submitted, acknowledged, running, terminal, artifact verified, downstream acknowledged, and cleaned. Unknown is not failed or safe to replay. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Idempotency records and job evidence use aliases and hashes, never tokens, signed URLs, or content. Credential failure and content/policy failure have different containment owners.

Instructions

1. Map operations, side effects, states, identifiers, retryability, time budgets, dependencies, and reconciliation sources.
2. Create per-service circuits and queues so one Adobe product does not exhaust all workers.
3. Persist submission intent before network call and bind returned job/status/cancel evidence atomically.
4. Poll returned status URLs with jitter, terminal-state validation, cancellation, and strict elapsed-time budget.
5. Route exhausted/unknown work to quarantine or DLQ; replay only after reconciliation and approval.
6. Exercise crashes, timeouts, 429/5xx, revocation, vendor outage, duplicate events, and recovery objectives.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Workload owner approves replay/degradation; budget owner approves resubmission; data owner approves artifact custody; security owns credential failures; cancellation/deletion require explicit approval.

Error Handling

• No fixed timeout table substitutes for measured objectives.
• Never retry unknown submissions blindly.
• Fallback output must be labeled and must not bypass policy or approval.

Output

Return state model, retry/idempotency matrix, circuit/queue design, reconciliation and replay runbooks, drills, SLOs…

Adobe Versioned Adapter Patterns

Overview

Create narrow, version-pinned Adobe SDK and REST adapters with typed contracts, redaction, bounded polling, and compatibility evidence. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

SDK package versions and REST product versions change independently. Keep auth, transport, schema validation, returned status URLs, request identifiers, storage custody, and retry classification behind service-specific interfaces. The retired Lightroom Firefly Services SDK is excluded. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Inject a credential provider; never let callers pass raw secrets. Bind every client to environment, organization/project, service, scopes, product profiles, and redaction policy.

Instructions

1. Inventory languages, package locks, direct REST calls, generated snippets, and target operations.
2. Pin supported SDK versions and trace every operation to its current REST documentation.
3. Define typed service adapters that preserve unknown fields and structured vendor error evidence.
4. Centralize token reuse, header construction, request IDs, timeouts, retry budgets, and signed-URL redaction.
5. Implement async polling by following returned status URLs with terminal-state and cancellation guards.
6. Run offline contracts plus one approved sandbox compatibility canary and publish the matrix.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Code owners approve adapter changes; security approves auth and URL handling. Any live write, generation, upload, cancellation, or deletion requires product-owner approval.

Error Handling

• Do not hardcode a remembered latest SDK or endpoint version.
• Do not reconstruct status URLs when the response returns one.
• Quarantine unknown terminal states and additive response shapes.

Output

Return dependency evidence, adapter interfaces, auth binding, schemas, fixtures, compatibility results, migration notes, and owner. Mark assumptions, observed environment behavior, owners, evidence d…

Adobe Integration Security Baseline

Overview

Establish least privilege, credential rotation, webhook authenticity, signed-URL custody, log minimization, and destructive-action controls. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Effective authority combines credential type, organization/project/workspace, scopes, product profiles, service entitlement, resource ownership, and operation. Event authenticity requires recipient and signature validation or mTLS; a syntactically valid JSON body is not trusted. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Store secrets server-side, redact signed URLs as bearer capabilities, rotate by overlap-and-verify, and delete the old secret only after last-use evidence proves cutover.

Instructions

1. Inventory credentials, users, scopes, profiles, projects, workspaces, webhooks, storage URLs, logs, and data flows.
2. Map effective read/write/generate/deploy/admin authority and remove stale or duplicate grants.
3. Add server-side secret storage, rotation alarms, host allowlists, request schemas, and structured redaction.
4. Validate webhook recipientclientid and digital signature/public-key host, or document the approved mTLS alternative.
5. Test credential theft, wrong organization, cross-environment swap, replay, forged key URL, and log canaries.
6. Assign recertification, rotation, incident, retention, deletion, and exception owners.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Security and organization owners approve credentials, scopes, product profiles, webhooks, and secret deletion. Data owners approve uploads, generated outputs, retention, sharing, and asset deletion.

Error Handling

• Never fetch a verification key from an arbitrary event-supplied host.
• Never rotate by deleting the only working secret first.
• Never log Authorization headers, refresh tokens, signed URLs, prompts, or document content.

Output

Return threat model, access matrix, rotation plan, webhook/storage controls, test evidence, findings, own…

Adobe End-of-Life and Contract Migration

Overview

Migrate Adobe integrations away from Service Account JWT, Photoshop v1, retired Lightroom Firefly Services, or drifting SDK/API contracts with canaries and rollback. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Service Account JWT is deprecated. Photoshop API v1 and the Firefly Services Lightroom API are already end-of-life; Remove Background uses Photoshop v2. Do not conflate the retired Lightroom service with separate Lightroom consumer APIs; confirm the dated retirement evidence in the reference map. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Preserve current and target credential, organization, scopes, profiles, and last-use evidence during auth migration. Old-secret or old-credential deletion is irreversible and happens only after verified cutover.

Instructions

1. Inventory JWT code/configuration, endpoint versions, Lightroom service calls, SDK locks, fixtures, dashboards, and runbooks.
2. Trace every behavior to current first-party docs and classify supported, deprecated, retired, undocumented, or environment-observed.
3. Define target OAuth, Photoshop v2, replacement/retirement, adapter, data, and rollback contracts.
4. Build parity fixtures and dual-run or shadow-read comparisons where they do not duplicate spend or writes.
5. Canary the target, verify outputs and observability, then cut traffic under declared thresholds.
6. Remove obsolete paths and approved credentials, scan for residue, and publish cutover plus rollback receipts.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Identity/security owners approve auth changes and deletions; product/data owners approve API replacement and live comparisons; release owner approves cutover and rollback.

Error Handling

• Do not leave JWT or v1 as a production fallback.
• Do not substitute a similarly named Lightroom API without contract proof.
• Roll back on output, authorization, storage, spend, or event drift.

Output

Return the inventory, evidence cl…

Adobe I/O Events Authentic Delivery

Overview

Implement Adobe I/O Events registration, challenge validation, authentic delivery, idempotent enqueue, replay operations, and disablement recovery. This workflow produces a reviewable artifact and evidence before any live side effect.

Prerequisites

• Current first-party Adobe documentation for every selected service, API version, auth flow, limit, and lifecycle.
• Named product, identity, security, data, budget, release, and operations owners appropriate to the scope.
• Synthetic or approved non-production fixtures with secret and content canaries.

Current Contract

Webhook endpoints are public HTTPS and must echo the GET challenge during registration. Event delivery is at least once and may duplicate or arrive out of order. Validate recipientclientid plus the digital signature/public key from a validated static.adobeioevents.com URL, or use an approved mTLS configuration. Recheck the dated evidence map before relying on mutable product behavior.

Authentication

Use an entitled Developer Console project and least-privilege credential for registration administration. Delivery handlers never receive or log management credentials.

Instructions

1. Resolve provider, event codes, organization/project/workspace, registration owner, endpoint, and data classification.
2. Validate the Registration API schema from current docs; do not copy a remembered payload or integration route.
3. Implement a narrow GET challenge response and POST size/type/schema checks before business processing.
4. Verify recipient client ID and signature/key allowlist or mTLS, then deduplicate on event identity before enqueue.
5. Acknowledge quickly; process asynchronously with ordering-aware state, retry budgets, DLQ, and replay controls.
6. Monitor retries and journal/recovery windows, manually re-enable disabled registrations, and reconcile gaps.

Tool Discipline

Use Read, Glob, and Grep to inspect current documentation, configuration, code, fixtures, and evidence. Use Write and Edit only for approved repository artifacts. Skill invocation alone does not authorize network access, credentials, Adobe content, consent, uploads, generation, spend, deployment, registration changes, replay, cancellation, or deletion.

Approval Boundaries

Security approves public ingress and authenticity method; product owner approves provider/events; operations approves replay. Registration replacement, re-enable, replay, or deletion requires explicit action approval.

Error Handling

• Reject arbitrary public-key hosts and recipient mismatches.
• Do not assume ordering or exactly-once delivery.
• Do not hide a disabled registration behind successful endpoint health.

Output

Return registration evidence, endpoint/authenticity…