← Zurück zu Recruiting · Projektplanungspaket

Skill · Version 1.0.0

Einführung einer Integration planen

Macht aus einer technischen Empfehlung einen konkreten Integrationsplan mit lokalen Ansatzpunkten, Lebenszyklusgrenzen und sichtbarer Unsicherheit.

integration-architecture-adoption-plan

Agenten mit diesem Skill

Entdecke, wie der Skill hilft

Wann ist der Skill hilfreich?

Nutze ihn nach Eingrenzung von Bibliotheken oder Diensten und vor Bindung von Entwicklungsaufwand.

Wobei hilft er dir?

  • Bewertet Alternativen nach Eignung, Lizenz, Umfang und Wartung.
  • Benennt Hostmodule, Datenverträge und Grenzen der Fehlerübersetzung.
  • Plant Initialisierung, Abbruch, Freigabe und unsichere Aufwandsspannen.

Das könntest du fragen

Plane eine Suchbibliothek mit konkreten Adaptergrenzen und späteren Ablösekosten. Baue einen minimalen Suchadapter für eine echte Abfrage. Zeige Fehlerübersetzung und Abbruch und beschreibe den späteren Datenexport aus der Bibliothek.

Ausführliche Dokumentation

Hier findest du die ursprüngliche Anleitung, Beispiele und Prüfschritte des Skills in ihrer Originalsprache.

Details…Weniger anzeigen

Integration Architecture & Adoption Plan

Research must culminate in an actionable architecture decision and a concrete integration blueprint tailored to the host codebase.

The Five Canonical Adoption Modes

Evaluate finalists and recommend one explicit path:

  1. Use As-Is (Direct Dependency): The library is small, well-maintained, license-compatible, and fits our runtime and types cleanly.
  2. Integrate Behind an Adapter / Seam (Feathers & Hohpe): The library solves a complex core problem (e.g., parser, protocol engine, layout solver), but we wrap it behind a narrow domain interface so its types, errors, and upgrade churn never leak across our codebase.
  3. Vendor / Adapt a Permitted Subset: We only need 100 lines of a 20,000-line permissive (MIT/Apache-2.0/BSD) package; copy or adapt the minimal module with full license/copyright attribution and unit tests.
  4. Build a Scoped In-House Solution: External candidates are over-engineered, poorly maintained, or mismatched; implement a focused internal module informed by the best patterns observed during research.
  5. Reject / Defer: The capability is unnecessary or unviable right now.

Workflow

  1. Lead with the ranked recommendation:
    • State the recommended option first, followed by a structured comparison matrix of finalists across consistent criteria (fit, mechanism, footprint, license, maintenance, integration effort, key risks).
  2. Map exact host-codebase touchpoints:
    • Name the exact files, modules, schemas, and configuration surfaces in our project where the integration will live:
      • Boundary & data flow: Input/output types, serialization boundaries, and error translation into domain errors.
      • Lifecycle & resource control: Initialization, timeouts, cancellation (AbortSignal), memory cleanup, and concurrency limits.
      • Rollback & replaceability: How the integration can be feature-flagged, tested in isolation, or swapped out later.
  3. Provide uncertainty-aware effort estimates and next steps:
    • Break the adoption plan into concrete, ordered implementation tasks.
    • Express effort estimates as ranges with explicit uncertainty drivers (e.g., "0.5–1 day for core adapter; +0.5 day if custom streaming backpressure is needed").

Anti-Patterns to Avoid

  • Recommending a full framework migration for a minor feature: Never propose replacing the host project's core framework just to adopt a convenience library.
  • Leaking third-party types into every domain model: Always define a clean boundary seam at the integration edge.

Enthaltene Dateien 1

  • SKILL.md