rw-check-compatibility

Par runwayml · skills

Analyser le codebase d'un utilisateur pour vérifier qu'il peut utiliser l'API publique de Runway (prérequis côté serveur)

npx skills add https://github.com/runwayml/skills --skill rw-check-compatibility

Vérifier la Compatibilité

Analysez le projet de l'utilisateur pour déterminer s'il est compatible avec l'API publique de Runway.

Pourquoi C'est Important

L'API publique de Runway nécessite une invocation côté serveur. La clé API ne doit jamais être exposée dans le code côté client. Les projets purement frontend (HTML/JS statique, SPAs côté client sans backend) ne peuvent pas appeler l'API de manière sécurisée.

Étapes d'Analyse

Étape 1 : Identifier le Type de Projet

Cherchez ces fichiers à la racine du projet pour déterminer la pile technologique :

Fichier Indique
package.json Projet Node.js
requirements.txt, pyproject.toml, Pipfile, setup.py Projet Python
go.mod Projet Go
Cargo.toml Projet Rust
pom.xml, build.gradle Projet Java/Kotlin
Gemfile Projet Ruby
composer.json Projet PHP

Si aucun de ces fichiers n'existe, marquez le projet comme inconnu et demandez à l'utilisateur quel langage/runtime il utilise.

Étape 2 : Vérifier la Capacité Côté Serveur

Cherchez les indicateurs d'un serveur/backend :

Projets Node.js — vérifiez les dépendances de package.json pour :

  • express, fastify, koa, hapi, nest, hono → framework serveur HTTP
  • next → Next.js (a des routes API — compatible)
  • nuxt → Nuxt.js (a des routes serveur — compatible)
  • remix → Remix (a des loaders/actions — compatible)
  • @sveltejs/kit → SvelteKit (a des routes serveur — compatible)
  • astro → Astro (a des endpoints API si SSR activé)

Projets Python — vérifiez :

  • flask, django, fastapi, starlette, tornado, aiohttp, sanic → framework serveur web
  • streamlit, gradio → peuvent faire des appels côté serveur

Signaux d'alerte (frontend uniquement) :

  • package.json avec seulement react, vue, svelte, angular et AUCUN framework serveur
  • vite.config.ts ou webpack.config.js sans configuration serveur/SSR
  • Générateurs de site statique sans routes serveur (ex. Gatsby simple, Eleventy simple)
  • index.html comme seul point d'entrée avec balises <script> inline

Étape 3 : Vérifier les Installations Existantes du SDK Runway

Cherchez les installations existantes du SDK Runway :

Node.js :

  • Vérifiez package.json pour @runwayml/sdk
  • Cherchez import RunwayML ou require('@runwayml/sdk') dans les fichiers source

Python :

  • Vérifiez requirements.txt / pyproject.toml pour runwayml
  • Cherchez from runwayml import RunwayML ou import runwayml dans les fichiers source

Étape 4 : Vérifier la Version du Runtime

Node.js : Doit être version 18 ou supérieure (node --version) Python : Doit être version 3.8 ou supérieure (python3 --version)

Étape 5 : Vérifier le Support des Variables d'Environnement

Cherchez un fichier .env, .env.example, .env.local, ou une configuration dotenv :

  • Node.js : dotenv dans les dépendances, ou support natif des variables d'environnement du framework (Next.js, etc.)
  • Python : python-dotenv dans les dépendances, ou support natif du framework

Format du Rapport

Après l'analyse, fournissez un rapport clair :

## Rapport de Compatibilité API Runway

**Type de projet :** [Node.js / Python / etc.]
**Capable côté serveur :** [Oui / Non / Partiel]
**Version du runtime :** [version] — [Compatible / Nécessite une mise à jour]
**SDK Runway installé :** [Oui / Non]
**Support des variables d'environnement :** [Oui / Non / Configuration nécessaire]

### Verdict : [COMPATIBLE / NÉCESSITE DES MODIFICATIONS / INCOMPATIBLE]

[Si COMPATIBLE]
Votre projet est prêt pour l'intégration de l'API Runway. Procédez à la configuration de la clé API.

[Si NÉCESSITE DES MODIFICATIONS]
Votre projet a besoin des modifications suivantes :
1. [Lister les modifications spécifiques nécessaires]

[Si INCOMPATIBLE]
Votre projet est frontend uniquement et ne peut pas appeler l'API Runway de manière sécurisée. Options :
1. **Ajouter un backend** — Ajoutez un serveur Express/FastAPI ou utilisez un framework avec routes serveur (Next.js, SvelteKit, etc.)
2. **Utiliser une fonction serverless** — Ajoutez des routes API via Vercel Functions, AWS Lambda, Cloudflare Workers, etc.
3. **Créer un backend séparé** — Créez un proxy API léger que votre frontend appelle

Remarques Importantes

  • Ne suggérez jamais d'intégrer la clé API dans le code côté client. C'est un risque de sécurité.
  • Si le projet utilise Next.js, Remix, SvelteKit, Nuxt, ou Astro avec SSR, il EST compatible — les gestionnaires de routes côté serveur peuvent appeler l'API.
  • Les plateformes serverless (Vercel, Netlify, AWS Lambda, Cloudflare Workers) sont compatibles.
  • Les apps Docker/conteneurisées sont compatibles si elles exécutent un processus serveur.

Après la Vérification de Compatibilité

Si le projet est compatible, suggérez à l'utilisateur de procéder avec +rw-setup-api-key pour configurer ses identifiants API.

Skills similaires