structural-integrating

Reviews integration of features, services, and dependencies into larger systems for boundary and failure risks.

Updated May 27, 2026
One-click install
npx skills add https://github.com/ybaspinar/agent-work-skills --skill structural-integrating-ybaspinar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: structural-integrating
Source: https://github.com/ybaspinar/agent-work-skills/tree/main/skills/structural-integrating
Command: npx skills add https://github.com/ybaspinar/agent-work-skills --skill structural-integrating-ybaspinar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Wiring a new feature, service, worker, or dependency into a larger system often breaks things at the seams: unenforced contracts, unbounded retries, hidden shared resources, and edges with no owner. This Skill provides a structured checklist for proving that a component integrates safely with the whole system, in both directions. ## Core Features & Use Cases - Whole-System Mapping: Surfaces shared substrates, boot cycles, cold-start risks, and existing control loops before wiring anything in. - Boundary Contract Enforcement: Pins producer/consumer contracts with schemas and contract tests, tolerating additive changes while rejecting invariant violations. - Bidirectional Blast Radius Analysis: Bounds what the system can do to your part (timeouts, breakers, fallbacks) and what your part can do to the system (load, fan-out, quotas). - Use Case: When adding a new worker that consumes from a shared queue owned by another team, use this Skill to define the contract test, cap retries with jitter and deadlines, plan a dark launch, and assign an owner with a sunset date for the new edge. ## Quick Start Ask the AI to run a structural integration review on the new service or dependency you are wiring into the system, covering contracts, blast radius, and rollout proof.

Frequently Asked Questions about structural-integrating

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely integrate a new service into an existing system?

Map the whole system first: shared config, identity, queues, tables, and boot cycles. Then pin the boundary contract with schema and contract tests, bound retries and fallbacks in both directions, wire in dark, and prove the full path with an end-to-end request plus a fault injection.

How to prevent retries from overloading a struggling dependency?

Bound every retry with a cap, jitter, deadline, and circuit breaker so a failing dependency cannot be hammered. Also bound your emitted load, fan-out, and resource share so your component cannot melt the wider system.

What is a contract test in service integration?

A contract test enforces the producer/consumer agreement at the boundary using schemas and automated tests rather than informal documentation. It should reject invariant violations while tolerating unknown additive fields where safe.

Why do separate services still fail together?

Separate deployables often share substrates like DNS, config, identity, zones, pools, and queues, so they do not fail independently. Integration review must surface these hidden couplings and give distributed invariants an explicit home such as a coordinator, saga, or idempotency key.

When should I use a dark launch for a new integration?

Use a dark launch whenever wiring a new component into a live system: deploy with fallback first, then ramp traffic gradually. This proves the whole path works under real conditions before full exposure and limits blast radius during rollout.