agents-united 1.0.0 → 1.2.0

package/registry/skills/replicate-model-inference/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: replicate-model-inference
+description: Integrating hosted open-source AI models, streaming responses, webhook handlers, and fine-tuning jobs on Replicate.com.
+metadata:
+  author: "Replicate / agents-united"
+  version: "2.0.0"
+  license: "MIT"
+---
+
+# Replicate Model Inference Playbook
+
+## Overview & Purpose
+`replicate-model-inference` provides comprehensive patterns for invoking, streaming, and managing open-source AI models deployed on the Replicate cloud infrastructure.
+
+## When to Trigger
+Trigger this skill whenever:
+- Integrating hosted open-source LLMs, image generation (Flux, SDXL), or audio models via API.
+- Setting up async webhook handlers for long-running prediction jobs.
+- Implementing real-time text/token streaming in web applications.
+- Managing model fine-tuning and custom Cog container deployments.
+
+## Input & Output Requirements
+- **Inputs**: Model version string (`owner/model:version`), prompt payload, generation parameters (temperature, max_tokens, guidance_scale), and `REPLICATE_API_TOKEN`.
+- **Outputs**: Output streams, prediction JSON objects, signed image/audio URLs, and error status responses.
+
+## Step-by-Step Execution Runbook
+
+### Phase 1 — Client Setup & Model Version Pinning
+- Authenticate API client using environment token.
+- Lock exact model version hash to prevent breaking changes from upstream model updates.
+
+### Phase 2 — Inference Execution & Streaming
+- Use synchronous predictions for fast requests (<5s).
+- Use streaming iterators (`replicate.stream()`) for LLMs to deliver immediate tokens.
+- Use webhook callbacks for asynchronous generation tasks (>10s).
+
+### Phase 3 — Verification & Retry Handling
+- Implement exponential backoff for HTTP 429 rate limit responses.
+- Verify generated output formats and validate against expected response schemas.
+
+## Edge Cases & Boundary Conditions
+- **Cold-Start Latency**: Account for 15-30s cold starts on un-cached model hardware by displaying UI progress indicators.
+- **Payload Truncation**: Truncate or chunk user inputs exceeding the model's context window.
+- **Hardware Failures**: Handle HTTP 500/503 responses gracefully with fallback replica endpoints.
+
+## Error Recovery & Fallbacks
+- If prediction times out, cancel the active prediction via API to prevent ongoing billing.
+- Fall back to secondary models (e.g. Llama-3.1-70B -> Llama-3.1-8B) during upstream service degradations.
+
+## Code Exemplars & Patterns
+
+```typescript
+import Replicate from "replicate";
+
+const replicate = new Replicate({
+  auth: process.env.REPLICATE_API_TOKEN,
+});
+
+export async function* streamLlamaCompletion(prompt: string) {
+  const model = "meta/meta-llama-3.1-405b-instruct";
+  const stream = replicate.stream(model, {
+    input: {
+      prompt,
+      max_tokens: 1024,
+      temperature: 0.7,
+    },
+  });
+
+  for await (const event of stream) {
+    yield event.toString();
+  }
+}
+```

package/registry/skills/requesting-code-review/SKILL.md

@@ -1,13 +1,134 @@
 ---
 name: requesting-code-review
-description: Official Requesting Code Review skill for Agents United ecosystem providing runbooks and guidelines.
+description: Production-grade Requesting Code Review playbook for authoring high-context PRs, reviewer routing, and accelerating velocity.
+metadata:
+  author: "agents-united"
+  version: "2.0.0"
 ---
 
-# Requesting Code Review
+# Requesting Code Review & Authoring High-Context Pull Requests
 
-This skill provides comprehensive instructions, runbooks, and guidelines for Requesting Code Review.
+## Overview & Purpose
+The Requesting Code Review & Authoring High-Context Pull Requests skill provides a deterministic, battle-tested framework for executing requesting-code-review processes across the Agents United multi-agent ecosystem.
 
-## Procedure & Guidelines
-1. Review domain requirements and constraints.
-2. Execute step-by-step procedures test-first.
-3. Validate results against acceptance criteria.
+Following this skill ensures high quality, zero-regression execution, rigorous testing gates, and seamless cross-functional team alignment.
+
+## Execution Triggers & Prerequisites
+### Execution Triggers
+- Direct request or workflow step invoking requesting-code-review.
+- Auditing, implementing, or standardizing requesting-code-review procedures.
+- Addressing technical debt, architectural reviews, or production readiness gates.
+- Preparing pull requests or automated release validations.
+
+### Prerequisites
+- Active project repository workspace with version control configured.
+- Operational testing, typechecking, and build toolchains.
+- Domain requirements, architectural constraints, or user stories defined.
+- Clean git working tree before beginning execution.
+
+## Input & Output Requirements
+### Inputs
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `target_scope` | String | Yes | Target module, service, component, or file path |
+| `config` | Object | Optional | Specific domain configurations, thresholds, and options |
+| `output_dir` | Directory Path | Optional | Destination directory for generated artifacts and reports |
+| `strict_mode` | Boolean | Optional | Enforce strict zero-warning validation and high test coverage |
+
+### Outputs
+| Artifact | Path / Format | Description |
+|---|---|---|
+| Specification Document | `docs/requesting-code-review/spec.md` | Full technical specification and architectural plan |
+| Implementation Files | `src/requesting-code-review/*` | Production-ready source code, tests, and configurations |
+| Execution Report | `reports/requesting-code-review/summary.json` | Verification metrics, test results, and audit summary |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Pre-Submission Self-Review & Diff Scrutiny
+1. Perform a thorough self-review of your own pull request diff on GitHub / CLI before requesting peers.
+2. Check for leftover debug logs (console.log), temporary test files, or commented-out code.
+3. Ensure the diff size is manageable (< 400 lines modified) to facilitate thorough review.
+4. Split oversized PRs into smaller, sequential, independently-testable PRs if necessary.
+5. Verify clean branch rebase on latest main.
+
+### Phase 2: High-Context PR Description Authoring
+1. Write concise, informative PR title following Conventional Commits (feat(auth): add OAuth2 refresh token flow).
+2. Document Motivation: Why is this change necessary? Link relevant issue tickets.
+3. Document Approach: How was the problem solved? What architectural decisions were made?
+4. Document Tradeoffs: What alternatives were evaluated and why were they not chosen?
+5. Attach visual proof (screenshots, animated GIFs, or terminal logs) demonstrating functionality.
+
+### Phase 3: Verification Instructions & Test Evidence
+1. Provide clear, copy-pasteable terminal commands for reviewers to verify the changes locally.
+2. Document manual test steps and environment prerequisites.
+3. Include test execution results and code coverage metrics in PR description.
+4. Highlight any database migrations or environment variable changes required.
+5. Confirm all automated CI checks are passing green.
+
+### Phase 4: Reviewer Routing & Context Briefing
+1. Assign code owners and subject-matter experts based on modified file paths (CODEOWNERS).
+2. Add inline comments on complex or non-obvious algorithms explaining the rationale.
+3. Tag security or architecture specialists if sensitive boundaries were touched.
+4. Ping assigned reviewers in team chat with a one-sentence summary and urgency level.
+5. Monitor PR for incoming comments.
+
+### Phase 5: Review Coordination & Handoff
+1. Respond promptly to incoming reviewer questions and feedback.
+2. Keep PR branch updated with main during extended review cycles.
+3. Coordinate final sign-off once all review requirements are satisfied.
+4. Merge PR according to repository merge strategy (Squash and Merge).
+5. Confirm deployment in staging / production.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: Requesting Code Review & Authoring High-Context Pull Requests Configuration & Specification
+```yaml
+## Summary of Changes
+- Implemented idempotent payment checkout flow using Stripe Webhooks.
+- Added transactional outbox pattern to prevent double-charging on network timeout.
+- Added comprehensive unit and integration tests with 94% code coverage.
+
+## Verification
+```bash
+npm run typecheck && npm test
+```
+- [x] All 28 automated tests passing.
+- [x] Tested against Stripe test environment.
+```
+
+### Exemplar 2: Requesting Code Review & Authoring High-Context Pull Requests TypeScript Type Contract
+```typescript
+export interface PullRequestMetadata {
+  title: string;
+  description: string;
+  type: 'feat' | 'fix' | 'refactor' | 'perf' | 'docs';
+  scope: string;
+  breakingChanges: boolean;
+  issueReferences: string[];
+  reviewers: string[];
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in Requesting Code Review & Authoring High-Context Pull Requests
+1. **Diagnosis**: Static analysis, typechecking, or unit tests fail validation rules during execution.
+2. **Recovery Protocol**:
+   - Step 1: Inspect detailed error log output in test/build terminal.
+   - Step 2: Formulate targeted hypothesis and isolate failing line or assertion.
+   - Step 3: Implement surgical code fix and re-run verification suite.
+
+### Scenario B: Missing or Incompatible Dependency
+1. **Diagnosis**: Required toolchain binary or library dependency is missing from the environment.
+2. **Recovery Protocol**:
+   - Step 1: Verify `package.json` engine requirements and local environment versions.
+   - Step 2: Install required peer dependencies cleanly with lockfile sync.
+   - Step 3: Resume runbook from Phase 1.
+
+## Verification & Validation Checklist
+- [ ] Frontmatter conforms strictly to `author: "agents-united"` and `version: "2.0.0"`.
+- [ ] All 7 mandatory sections present with explicit headers.
+- [ ] Step-by-Step Execution Runbook body contains >= 50 lines.
+- [ ] Code exemplars provided with valid syntax fencing.
+- [ ] Zero dummy placeholder strings or unpopulated template markers present.
+- [ ] Project build, test suite, and doctor check pass 100% cleanly.

package/registry/skills/responsive-design-audit/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: responsive-design-audit
+description: Production-grade Responsive Design Audit playbook for design operations, UX systems, and growth strategy.
+metadata:
+  author: "agents-united"
+  version: "2.0.0"
+---
+
+# Responsive Design Audit
+
+## Overview & Purpose
+The Responsive Design Audit skill provides a deterministic framework for executing responsive design audit processes in modern software products.
+
+Following this skill ensures high usability, visual consistency, rapid iteration, and complete cross-functional team alignment.
+
+## Execution Triggers & Prerequisites
+### Execution Triggers
+- Direct request to execute Responsive Design Audit tasks.
+- Auditing existing product assets or workflows.
+- Standardizing responsive-design-audit procedures across team projects.
+- Preparing design handoffs or growth campaign launches.
+
+### Prerequisites
+- Project workspace configured with design system tokens or component libraries.
+- Target UI design specification or growth experiment hypothesis.
+- Testing and linting tools operational.
+- Clean git working directory.
+
+## Input & Output Requirements
+### Inputs
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `target_scope` | String | Yes | Target UI component, page, or campaign scope |
+| `config` | Object | Optional | Specific parameters and threshold configurations |
+| `output_dir` | Directory Path | Optional | Destination directory for generated artifacts |
+| `strict_mode` | Boolean | Optional | Enforce strict zero-warning validation |
+
+### Outputs
+| Artifact | Path / Format | Description |
+|---|---|---|
+| Specification Document | `docs/responsive-design-audit/spec.md` | Full specification and guidelines document |
+| Component / Asset Files | `src/responsive-design-audit/*` | Implemented design tokens, components, or campaign assets |
+| Audit Report | `reports/responsive-design-audit/summary.json` | Health check and audit metric results |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Pre-Execution Discovery & Workspace Analysis
+1. Inspect workspace repository to locate relevant UI components, tokens, or campaign assets.
+   ```bash
+   find src/ docs/ -maxdepth 3 -type f
+   ```
+2. Analyze domain requirements and classify core UI elements, interaction flows, or growth metrics.
+3. Establish baseline quality metrics and target benchmarks.
+4. Verify working tree status to ensure clean git workspace.
+   ```bash
+   git status --short
+   ```
+5. Formulate initial execution plan.
+
+### Phase 2: Input Contract Validation & Strategy Selection
+1. Validate input parameters against technical feasibility and design system guidelines.
+2. Select implementation pattern matching component or campaign architecture.
+3. Establish verification rules and accessibility / conversion thresholds.
+4. Formulate atomic step-by-step execution sequence.
+5. Create temporary working directory if needed.
+
+### Phase 3: Core Step-by-Step Implementation Execution
+1. Author primary specification document at `docs/responsive-design-audit/spec.md`.
+2. Generate code, token, or layout implementation files.
+   ```bash
+   npm run typecheck
+   ```
+3. Apply automated formatting and linting tools.
+4. Execute unit or visual regression tests.
+   ```bash
+   npm test
+   ```
+5. Refactor asset structure for optimal performance and maintainability.
+
+### Phase 4: Verification, Testing & Quality Gate Checking
+1. Run full project verification suite.
+   ```bash
+   npm run typecheck && npm test && npm run build
+   ```
+2. Verify zero lint errors, type warnings, or broken references.
+3. Execute CLI health doctor check.
+   ```bash
+   node dist/cli.js doctor
+   ```
+4. Assert all acceptance criteria are satisfied.
+
+### Phase 5: Post-Execution Cleanup & Artifact Generation
+1. Generate execution summary report at `reports/responsive-design-audit/summary.md`.
+2. Clean up temporary build artifacts and scratch files.
+3. Commit generated files to git repository.
+   ```bash
+   git add docs/responsive-design-audit/ reports/responsive-design-audit/
+   git commit -m "feat(responsive-design-audit): implement Responsive Design Audit playbook artifacts"
+   ```
+4. Publish documentation for team review.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: Responsive Design Audit Configuration Specification
+```yaml
+version: "2.0.0"
+metadata:
+  skill: "responsive-design-audit"
+  author: "agents-united"
+rules:
+  strictValidation: true
+  reporting:
+    format: "json"
+    output: "reports/responsive-design-audit/summary.json"
+```
+
+### Exemplar 2: Responsive Design Audit Helper Module
+```typescript
+export function runResponsiveDesignAudit(scope: string): boolean {
+  console.log('Running Responsive Design Audit on:', scope);
+  return true;
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in Responsive Design Audit
+1. **Diagnosis**: Specification or code asset fails validation rules in responsive-design-audit.
+2. **Recovery Protocol**:
+   - Step 1: Inspect error log at reports directory.
+   - Step 2: Correct non-compliant syntax or structure.
+   - Step 3: Re-run verification pipeline.
+
+### Scenario B: Missing Resource for Responsive Design Audit
+1. **Diagnosis**: Target design token or configuration asset missing from workspace.
+2. **Recovery Protocol**:
+   - Step 1: Generate baseline resource file from standard template.
+   - Step 2: Update configuration references.
+   - Step 3: Resume runbook execution.
+
+## Verification & Validation Checklist
+- [ ] Frontmatter conforms strictly to `author: "agents-united"` and `version: "2.0.0"`.
+- [ ] All 7 mandatory sections present with explicit headers.
+- [ ] Step-by-Step Execution Runbook body contains >= 50 lines.
+- [ ] Code exemplars provided with valid syntax fencing.
+- [ ] Zero dummy placeholder strings or unpopulated template markers present.
+- [ ] Project build, test suite, and doctor check pass 100% cleanly.

package/registry/skills/runpod-gpu-orchestration/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: runpod-gpu-orchestration
+description: On-demand GPU instance provisioning, serverless worker handler creation, network volume configuration, and spot pricing optimization on RunPod.io.
+metadata:
+  author: "RunPod / agents-united"
+  version: "2.0.0"
+  license: "MIT"
+---
+
+# RunPod GPU Orchestration Playbook
+
+## Overview & Purpose
+`runpod-gpu-orchestration` standardizes building, deploying, and managing custom AI containers on RunPod Serverless and GPU Pod instances with cost-effective spot pricing.
+
+## When to Trigger
+Trigger this skill whenever:
+- Creating custom CUDA Docker containers for high-performance model serving.
+- Implementing RunPod Serverless asynchronous and streaming worker handlers.
+- Configuring network storage volumes for shared model weight caching across pods.
+- Setting up automated scaling policies and spot GPU instance recovery.
+
+## Input & Output Requirements
+- **Inputs**: Base Dockerfile, Python worker script, RunPod API Key, GPU type requirements (RTX 4090, A100, H100), and network volume IDs.
+- **Outputs**: Docker container registry images, RunPod endpoint configurations, and health monitoring alerts.
+
+## Step-by-Step Execution Runbook
+
+### Phase 1 — Worker Implementation & Containerization
+- Author the Python worker handler conforming to `runpod.serverless.start()`.
+- Package dependencies with CUDA runtime base layers in Dockerfile.
+
+### Phase 2 — Network Volume Caching & Endpoint Deployment
+- Mount `/runpod-volume` to share checkpoints and avoid downloading model weights on worker initialization.
+- Deploy the serverless endpoint with concurrency limits and idle timeout thresholds.
+
+### Phase 3 — Verification & Load Testing
+- Trigger test jobs via RunPod `/run` and `/runsync` REST endpoints.
+- Validate worker auto-scaling under load and clean scale-down on idle.
+
+## Edge Cases & Boundary Conditions
+- **Spot Pod Interruption**: Implement checkpoint saves every N training steps to recover from spot instance preemptions.
+- **CUDA OOM on High Concurrency**: Enforce max concurrent jobs per worker container (`concurrency_modifier`).
+- **Disk Space Exhaustion**: Clean `/tmp` and PyTorch cache files between batch jobs.
+
+## Error Recovery & Fallbacks
+- If serverless job fails with worker error, inspect container stderr logs via RunPod API.
+- Fall back from spot instances to on-demand secure cloud pods when guaranteed uptime is required.
+
+## Code Exemplars & Patterns
+
+```python
+import runpod
+import torch
+from transformers import AutoModelForCausalLM, AutoTokenizer
+
+model = None
+tokenizer = None
+
+def load_model():
+    global model, tokenizer
+    model_name = "mistralai/Mistral-7B-Instruct-v0.3"
+    tokenizer = AutoTokenizer.from_pretrained(model_name)
+    model = AutoModelForCausalLM.from_pretrained(
+        model_name,
+        torch_dtype=torch.float16,
+        device_map="auto"
+    )
+
+def handler(job):
+    job_input = job["input"]
+    prompt = job_input.get("prompt", "")
+    inputs = tokenizer(prompt, return_tensors="pt").to("cuda")
+    with torch.no_grad():
+        outputs = model.generate(**inputs, max_new_tokens=256)
+    result = tokenizer.decode(outputs[0], skip_special_tokens=True)
+    return {"output": result}
+
+if __name__ == "__main__":
+    load_model()
+    runpod.serverless.start({"handler": handler})
+```

package/registry/skills/schema-markup-strategy/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: schema-markup-strategy
+description: Production-grade Schema Markup Strategy playbook for JSON-LD structured data architecture, Schema.org entities, rich snippet qualification, and SERP visibility.
+metadata:
+  author: "agents-united"
+  version: "2.0.0"
+---
+
+# Schema Markup Strategy & JSON-LD Structured Data Architecture
+
+## Overview & Purpose
+The Schema Markup Strategy skill provides a deterministic framework for architecting and deploying production-grade JSON-LD structured data conforming to Schema.org standards and Google Search Gallery specifications.
+
+Following this skill structures interconnected entity graphs (`@graph`), linking Organization, WebSite, WebPage, SoftwareApplication, Product, FAQPage, BreadcrumbList, HowTo, and Article entities to unlock Google rich snippets, Knowledge Panels, and LLM semantic web parsing.
+
+## Execution Triggers & Prerequisites
+### Execution Triggers
+- Implementing structured data for SaaS product pages, blog articles, documentation, or FAQs.
+- Qualifying web pages for Google Rich Results (FAQ accordions, breadcrumbs, star ratings, software pricing).
+- Resolving Google Search Console structured data warnings and validation errors.
+- Establishing brand entity Knowledge Graph authority across organizational domains.
+
+### Prerequisites
+- Target page URLs, entity data (authors, publish dates, ratings, pricing, FAQ items).
+- Web application framework supporting `<script type="application/ld+json">` injection.
+- Google Rich Results Test or Schema Validator testing tools.
+- Clean git working directory.
+
+## Input & Output Requirements
+### Inputs
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `entity_types` | Array<String> | Yes | Target entities: `['SoftwareApplication', 'FAQPage', 'Organization', 'BreadcrumbList']` |
+| `page_url` | String | Yes | Canonical URL of target page |
+| `organization_metadata` | Object | Yes | Name, logo URL, sameAs social links, contact point |
+| `item_payload` | Object | Yes | Specific entity properties (pricing, ratings, steps, questions) |
+| `strict_mode` | Boolean | Optional | Enforce zero-warning validation against Google specs |
+
+### Outputs
+| Artifact | Path / Format | Description |
+|---|---|---|
+| Schema Architecture Spec | `docs/schema-markup-strategy/schema-spec.md` | Entity graph definitions and property mapping |
+| React / Next.js Component | `src/components/seo/JsonLd.tsx` | Reusable JSON-LD script injector component |
+| Validation Audit Report | `reports/schema-markup-strategy/validation.json` | Google Rich Results API test output and status |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Entity Graph Discovery & Schema Vocabulary Selection
+1. Inspect target page content to classify required Schema.org entity types.
+2. Review Google Search Gallery guidelines for eligible rich result types (e.g. Software App, FAQ, Breadcrumb).
+3. Extract core entity properties: `@id` URI anchors, `@type`, name, url, description, author, dateModified.
+4. Establish entity graph relationships using `@graph` notation to link sub-entities to parent Organization and WebPage.
+5. Verify schema licensing and compliance against Schema.org vocabulary version 26+.
+
+### Phase 2: Structured JSON-LD Graph (`@graph`) Data Modeling
+1. Author canonical Organization root entity with official logo URL and verified `sameAs` social profiles.
+2. Build WebSite and WebPage entities referencing root Organization as `publisher`.
+3. Construct specific domain entities:
+   - `SoftwareApplication`: include `operatingSystem`, `applicationCategory`, `offers` (price, currency), `aggregateRating`.
+   - `FAQPage`: build `mainEntity` array containing `Question` and accepted `Answer` blocks.
+   - `BreadcrumbList`: define `itemListElement` array with positional integers and item URLs.
+4. Link entities using unambiguous `@id` URI fragments (e.g., `https://example.com/#organization`).
+
+### Phase 3: Component Integration & Dynamic Hydration
+1. Create a typed, reusable Next.js / React component (`<JsonLd data={graph} />`) that renders sanitized JSON-LD in `<head>` or page root.
+2. Implement XSS escaping for user-generated strings injected into JSON-LD script tags.
+3. Configure dynamic metadata hooks to populate real-time pricing and rating changes into the schema payload.
+4. Integrate schema generation directly into CMS or programmatic template render pipelines.
+
+### Phase 4: Schema Validation, Google Rich Results Testing & Syntax Linting
+1. Run local JSON-LD parser validation to confirm zero trailing commas or syntax errors.
+2. Test rendered output against Google Rich Results Test API / schema validator CLI.
+   ```bash
+   npx schema-dts-gen --input docs/schema-markup-strategy/sample.json --validate
+   ```
+3. Assert that zero required fields are missing and all recommended fields are populated where applicable.
+4. Verify that schema content exactly mirrors visible on-page user content to prevent manual spam actions.
+
+### Phase 5: Deployment Verification & SERP Feature Monitoring
+1. Deploy structured data component to staging / preview environment.
+2. Execute live URL inspection check confirming correct MIME type `<script type="application/ld+json">`.
+3. Log schema deployment metadata to `reports/schema-markup-strategy/validation.json`.
+4. Commit validated schema components to repository.
+   ```bash
+   git add docs/schema-markup-strategy/ src/components/seo/
+   git commit -m "feat(schema-markup-strategy): implement nested JSON-LD structured data engine"
+   ```
+5. Set up Google Search Console Rich Results tracking.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: Multi-Entity Nested JSON-LD `@graph` Specification
+```json
+{
+  "@context": "https://schema.org",
+  "@graph": [
+    {
+      "@type": "Organization",
+      "@id": "https://agents-united.dev/#organization",
+      "name": "Agents United",
+      "url": "https://agents-united.dev",
+      "logo": "https://agents-united.dev/logo.png",
+      "sameAs": [
+        "https://github.com/agents-united",
+        "https://twitter.com/agentsunited"
+      ]
+    },
+    {
+      "@type": "SoftwareApplication",
+      "@id": "https://agents-united.dev/#software",
+      "name": "Agents United CLI",
+      "operatingSystem": "All",
+      "applicationCategory": "DeveloperApplication",
+      "offers": {
+        "@type": "Offer",
+        "price": "0",
+        "priceCurrency": "USD"
+      },
+      "aggregateRating": {
+        "@type": "AggregateRating",
+        "ratingValue": "4.9",
+        "ratingCount": "128"
+      }
+    },
+    {
+      "@type": "FAQPage",
+      "@id": "https://agents-united.dev/#faq",
+      "mainEntity": [
+        {
+          "@type": "Question",
+          "name": "How do I install Agents United?",
+          "acceptedAnswer": {
+            "@type": "Answer",
+            "text": "Run npm install -g agents-united to install globally."
+          }
+        }
+      ]
+    }
+  ]
+}
+```
+
+### Exemplar 2: TypeScript React Reusable JSON-LD Injection Component
+```typescript
+import React from 'react';
+
+export interface JsonLdProps {
+  data: Record<string, any>;
+}
+
+export function JsonLd({ data }: JsonLdProps): React.JSX.Element {
+  const jsonString = JSON.stringify(data, null, 2)
+    .replace(/</g, '\\u003c')
+    .replace(/>/g, '\\u003e')
+    .replace(/&/g, '\\u0026');
+
+  return (
+    <script
+      type="application/ld+json"
+      dangerouslySetInnerHTML={{ __html: jsonString }}
+    />
+  );
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Google Rich Results Error on Missing Required Schema Properties
+1. **Diagnosis**: Validator flags missing required fields (e.g., `offers.priceCurrency` or `publisher.logo`).
+2. **Recovery Protocol**:
+   - Step 1: Consult Google Search Gallery documentation for the failing entity type.
+   - Step 2: Inject fallback default values for missing required properties into data mapper.
+   - Step 3: Re-run schema validator script and assert zero errors.
+
+### Scenario B: Schema Content Mismatch with On-Page Rendered HTML
+1. **Diagnosis**: Search engine flags cloaking or deceptive markup because schema price/rating differs from page text.
+2. **Recovery Protocol**:
+   - Step 1: Ensure JSON-LD generator consumes the exact same data source object as React UI components.
+   - Step 2: Implement build-time assertion checking parity between DOM text nodes and JSON-LD properties.
+   - Step 3: Re-deploy corrected unified data source.
+
+## Verification & Validation Checklist
+- [ ] Frontmatter conforms strictly to `author: "agents-united"` and `version: "2.0.0"`.
+- [ ] All 7 mandatory sections present with explicit headers.
+- [ ] Step-by-Step Execution Runbook body contains >= 50 lines.
+- [ ] Nested `@graph` syntax used for cross-entity referencing.
+- [ ] XSS escaping sanitization implemented for JSON-LD strings.
+- [ ] Code exemplars provided with valid syntax fencing.
+- [ ] Zero dummy placeholder strings or unpopulated template markers present.
+- [ ] Project build, test suite, and doctor check pass 100% cleanly.