agents-united 0.5.0

package/registry/skills/state-driven-ui-animation/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: state-driven-ui-animation
+description: Production-grade State Driven Ui Animation playbook for design
+  operations, UX systems, and growth strategy.
+metadata:
+  author: agents-united
+  version: 2.0.0
+  icon: 🎬
+disable-slash-command: true
+---
+
+# State Driven Ui Animation
+
+## Overview & Purpose
+The State Driven Ui Animation skill provides a deterministic framework for executing state driven ui animation 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 State Driven Ui Animation tasks.
+- Auditing existing product assets or workflows.
+- Standardizing state-driven-ui-animation 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/state-driven-ui-animation/spec.md` | Full specification and guidelines document |
+| Component / Asset Files | `src/state-driven-ui-animation/*` | Implemented design tokens, components, or campaign assets |
+| Audit Report | `reports/state-driven-ui-animation/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/state-driven-ui-animation/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/state-driven-ui-animation/summary.md`.
+2. Clean up temporary build artifacts and scratch files.
+3. Commit generated files to git repository.
+   ```bash
+   git add docs/state-driven-ui-animation/ reports/state-driven-ui-animation/
+   git commit -m "feat(state-driven-ui-animation): implement State Driven Ui Animation playbook artifacts"
+   ```
+4. Publish documentation for team review.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: State Driven Ui Animation Configuration Specification
+```yaml
+version: "2.0.0"
+metadata:
+  skill: "state-driven-ui-animation"
+  author: "agents-united"
+rules:
+  strictValidation: true
+  reporting:
+    format: "json"
+    output: "reports/state-driven-ui-animation/summary.json"
+```
+
+### Exemplar 2: State Driven Ui Animation Helper Module
+```typescript
+export function runStateDrivenUiAnimation(scope: string): boolean {
+  console.log('Running State Driven Ui Animation on:', scope);
+  return true;
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in State Driven Ui Animation
+1. **Diagnosis**: Specification or code asset fails validation rules in state-driven-ui-animation.
+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 State Driven Ui Animation
+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/subagent-driven-development/SKILL.md

@@ -0,0 +1,135 @@
+---
+name: subagent-driven-development
+description: Production-grade Multi-Agent Orchestration playbook for task
+  decomposition, parallel execution, and boundary isolation.
+metadata:
+  author: agents-united
+  version: 2.0.0
+  icon: 🤖
+disable-slash-command: true
+---
+
+# Subagent-Driven Development & Autonomous Task Orchestration
+
+## Overview & Purpose
+The Subagent-Driven Development & Autonomous Task Orchestration skill provides a deterministic, battle-tested framework for executing subagent-driven-development processes across the Agents United multi-agent ecosystem.
+
+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 subagent-driven-development.
+- Auditing, implementing, or standardizing subagent-driven-development 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/subagent-driven-development/spec.md` | Full technical specification and architectural plan |
+| Implementation Files | `src/subagent-driven-development/*` | Production-ready source code, tests, and configurations |
+| Execution Report | `reports/subagent-driven-development/summary.json` | Verification metrics, test results, and audit summary |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Task Decomposition & Workstream Partitioning
+1. Analyze parent project request and identify independent, parallelizable workstreams.
+2. Partition tasks by architectural layer (e.g. Database -> API -> UI) or vertical domain slices.
+3. Identify strict sequential dependencies vs concurrent execution candidates.
+4. Ensure subagent workstreams do not concurrently modify the same mutable files to prevent collisions.
+5. Formulate master orchestration graph with dependency edges.
+
+### Phase 2: Self-Contained Subagent Prompt Formulation
+1. Author explicit, self-contained task prompts for each subagent (zero implicit context assumption).
+2. Specify exact file paths to read, modify, or create in prompt metadata.
+3. Define required tool privileges (read-only vs acceptEdits vs full terminal access).
+4. Include explicit verification commands the subagent must execute before declaring completion.
+5. Set strict boundary constraints prohibiting out-of-scope code modifications.
+
+### Phase 3: Parallel Subagent Invocation & Monitoring
+1. Dispatch concurrent subagents using invoke_subagent tool calls.
+2. Monitor background execution lifecycle and handle reactive wakeups.
+3. Inspect intermediate deliverables and log outputs for error conditions.
+4. If a subagent encounters rate limits or errors, isolate failure and execute targeted retry.
+5. Collect completed subagent artifact deliverables.
+
+### Phase 4: Synthesis, Integration & Conflict Resolution
+1. Integrate subagent output deliverables into master branch workspace.
+2. Resolve any overlapping interface contracts or import references between workstreams.
+3. Run full cross-module integration test suite verifying end-to-end functionality.
+4. Perform code review on all generated subagent code to maintain quality standards.
+5. Verify zero regression across all integrated components.
+
+### Phase 5: Master Verification & Final Deliverable Reporting
+1. Execute full project verification pipeline: npm run typecheck && npm test && npm run build.
+2. Run workspace health check: node dist/cli.js doctor.
+3. Compile comprehensive orchestration walkthrough summarizing all subagent contributions.
+4. Commit all unified changes to git with structured conventional commit message.
+5. Present final deliverables to user.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: Subagent-Driven Development & Autonomous Task Orchestration Configuration & Specification
+```yaml
+// Subagent dispatch configuration
+export interface SubagentTask {
+  role: 'Backend Architect' | 'Frontend Architect' | 'Code Reviewer' | 'Security Auditor';
+  type: string;
+  prompt: string;
+  contextFiles: string[];
+  expectedDeliverables: string[];
+  verificationCommand: string;
+}
+```
+
+### Exemplar 2: Subagent-Driven Development & Autonomous Task Orchestration TypeScript Type Contract
+```typescript
+export interface OrchestratorPlan {
+  masterTaskId: string;
+  workstreams: Array<{
+    id: string;
+    subagentRole: string;
+    status: 'pending' | 'running' | 'completed' | 'failed';
+    dependencies: string[];
+  }>;
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in Subagent-Driven Development & Autonomous Task Orchestration
+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/supabase-backend-architecture/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: supabase-backend-architecture
+description: PostgreSQL database modeling, Row Level Security (RLS) policies,
+  Edge Functions (Deno), Auth hooks, and Realtime subscriptions on Supabase.
+metadata:
+  author: Agents United Backend Group
+  version: 1.0.0
+  license: MIT
+  icon: ⚡
+disable-slash-command: true
+---
+
+# Supabase Backend Architecture Playbook
+
+## Overview & Purpose
+`supabase-backend-architecture` establishes security, performance, and operational best practices for applications built on the Supabase BaaS platform.
+
+## Core Directives & Standards
+1. **Row Level Security (RLS) Mandatory** — Enable RLS on every public table (`ALTER TABLE ... ENABLE ROW LEVEL SECURITY;`) and write explicit granular policies for `SELECT`, `INSERT`, `UPDATE`, and `DELETE`.
+2. **Database Migration CLI Workflow** — Manage all schema changes through Supabase CLI migrations (`supabase migration new <name>`) and seed scripts (`supabase/seed.sql`).
+3. **Edge Functions with Deno** — Author Deno TypeScript Edge Functions for third-party webhook receivers (Stripe, GitHub), secret handling, and background processing.
+4. **Auth & Custom JWT Claims** — Utilize Postgres database triggers on `auth.users` to automatically populate public user profile records and assign custom claims/roles.
+5. **Realtime Channels & Broadcasts** — Structure Supabase Realtime channel subscriptions with specific filter clauses (`filter: 'room_id=eq.123'`) to prevent unnecessary socket broadcast traffic.
+
+## Verification Checklist
+- [ ] Database linter confirms 0 tables with RLS disabled.
+- [ ] Supabase local development stack starts cleanly with `supabase start`.
+- [ ] Service role key is never exposed to browser clients.

package/registry/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: systematic-debugging
+description: Production-grade Systematic Debugging playbook for isolating
+  elusive bugs, root-cause analysis, and regression prevention.
+metadata:
+  author: agents-united
+  version: 2.0.0
+  icon: 🐞
+disable-slash-command: true
+---
+
+# Hypothesis-Driven Systematic Debugging & Root Cause Isolation
+
+## Overview & Purpose
+The Hypothesis-Driven Systematic Debugging & Root Cause Isolation skill provides a deterministic, battle-tested framework for executing systematic-debugging processes across the Agents United multi-agent ecosystem.
+
+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 systematic-debugging.
+- Auditing, implementing, or standardizing systematic-debugging 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/systematic-debugging/spec.md` | Full technical specification and architectural plan |
+| Implementation Files | `src/systematic-debugging/*` | Production-ready source code, tests, and configurations |
+| Execution Report | `reports/systematic-debugging/summary.json` | Verification metrics, test results, and audit summary |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Symptom Collection & Defect Reproduction
+1. Capture exact error messages, stack traces, HTTP status codes, and user environment details.
+2. Identify affected software versions, recent commits, and environment variables.
+3. Formulate deterministic reproduction steps in local development environment.
+4. Author a minimal failing test case that reliably reproduces the bug 100% of the time.
+5. Verify test failure matches reported production symptom exactly.
+
+### Phase 2: Hypothesis Generation & Ranking
+1. Formulate 3 to 5 distinct candidate hypotheses for root cause based on system architecture.
+2. Rank hypotheses by probability based on error signatures and recent code changes.
+3. Identify fault domains: network transport, data serialization, database state, race conditions.
+4. Design quick, non-destructive test procedures to validate or falsify each hypothesis.
+5. Document hypotheses in debugging log.
+
+### Phase 3: Binary Search Isolation & Root Cause Identification
+1. Use git bisect (git bisect start) to isolate the exact commit that introduced the defect.
+2. Apply binary search logging: add diagnostic logs at boundary interfaces to halve the search space.
+3. Inspect variable states and asynchronous call stacks during step-by-step execution.
+4. Falsify invalid hypotheses systematically until the singular root cause is isolated with proof.
+5. Document confirmed root cause mechanism.
+
+### Phase 4: Targeted Fix Implementation & Regression Testing
+1. Implement minimal, surgical code fix targeting the verified root cause (avoid broad refactoring).
+2. Run the minimal reproduction test case to verify that it now passes green.
+3. Run full automated test suite to ensure the fix introduces zero secondary regressions.
+4. Test edge cases and boundary inputs around the fixed logic.
+5. Verify type checking and linting pass cleanly.
+
+### Phase 5: Post-Mortem Documentation & Defect Prevention
+1. Permanently commit the reproduction test case to the test suite as a regression safeguard.
+2. Document root cause analysis, timeline, and remediation in post-mortem record.
+3. Implement preventative measures: improved input validation, lint rules, or type narrowing.
+4. Clean up temporary diagnostic log statements.
+5. Commit fix and deploy to production.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: Hypothesis-Driven Systematic Debugging & Root Cause Isolation Configuration & Specification
+```yaml
+// Minimal reproducible test case exemplar
+describe('Order Cancellation Bug Isolation', () => {
+  it('should not mark order as cancelled when refund webhook fails', async () => {
+    // 1. Arrange: setup order in processing state
+    const order = await createTestOrder({ status: 'processing' });
+    // 2. Act: trigger failed refund event
+    const response = await handleRefundWebhook({ orderId: order.id, status: 'failed' });
+    // 3. Assert: order status must remain processing, not cancelled
+    expect(response.status).toBe(400);
+    const updated = await getOrderById(order.id);
+    expect(updated.status).toBe('processing');
+  });
+});
+```
+
+### Exemplar 2: Hypothesis-Driven Systematic Debugging & Root Cause Isolation TypeScript Type Contract
+```typescript
+export interface DebugHypothesis {
+  hypothesisId: string;
+  description: string;
+  likelihood: 'high' | 'medium' | 'low';
+  testProcedure: string;
+  result: 'confirmed' | 'disproven' | 'inconclusive';
+  rootCauseEvidence?: string;
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in Hypothesis-Driven Systematic Debugging & Root Cause Isolation
+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/technical-documentation/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: technical-documentation
+description: Production-grade Technical Documentation playbook for Diátaxis
+  framework, developer onboarding, and living architecture manuals.
+metadata:
+  author: agents-united
+  version: 2.0.0
+  icon: 📄
+disable-slash-command: true
+---
+
+# Technical Documentation, Architecture Specs & API Reference Authoring
+
+## Overview & Purpose
+The Technical Documentation, Architecture Specs & API Reference Authoring skill provides a deterministic, battle-tested framework for executing technical-documentation processes across the Agents United multi-agent ecosystem.
+
+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 technical-documentation.
+- Auditing, implementing, or standardizing technical-documentation 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/technical-documentation/spec.md` | Full technical specification and architectural plan |
+| Implementation Files | `src/technical-documentation/*` | Production-ready source code, tests, and configurations |
+| Execution Report | `reports/technical-documentation/summary.json` | Verification metrics, test results, and audit summary |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Audience Profiling & Diátaxis Framework Selection
+1. Identify primary audience: new engineers, API consumers, operations teams, or technical leadership.
+2. Classify documentation mode using Diátaxis framework: Tutorial (learning), How-To (goal-oriented), Reference (information), Explanation (understanding).
+3. Audit existing documentation for outdated diagrams, broken code samples, and missing prerequisites.
+4. Establish documentation style guide: active voice, direct phrasing, clean markdown formatting.
+5. Draft documentation outline.
+
+### Phase 2: Architecture Diagrams & Visual Modeling
+1. Author C4 / sequence diagrams using Mermaid syntax embedded directly in markdown.
+2. Illustrate data flows, authentication handshakes, and component boundary interactions.
+3. Ensure diagram labels are concise, legible, and maintainable as pure text.
+4. Include high-level system topology and deployment infrastructure overviews.
+5. Review diagrams for technical accuracy.
+
+### Phase 3: Code Examples & Copy-Pasteable Runbooks
+1. Author complete, self-contained code samples (avoid non-compiling pseudo-code).
+2. Provide verified terminal commands with explicit prerequisites and expected output.
+3. Document all environment variables, configuration parameters, and default values.
+4. Include comprehensive error code reference table with troubleshooting remedies.
+5. Verify every code example by executing it against a live test environment.
+
+### Phase 4: Review, Accuracy Validation & Link Checking
+1. Run automated markdown linter (markdownlint) to enforce formatting consistency.
+2. Check for dead markdown links and broken anchor references.
+3. Verify that all code blocks specify valid language tags for syntax highlighting.
+4. Perform peer review with a domain engineer to validate factual accuracy.
+5. Ensure zero typos or outdated terminology.
+
+### Phase 5: Publication & Living Documentation Maintenance
+1. Publish documentation to repository docs directory or documentation site (Docusaurus / MkDocs).
+2. Update table of contents and root README index links.
+3. Set up automated doc-testing in CI to prevent code sample bitrot.
+4. Commit documentation changes to version control.
+5. Notify team of published documentation updates.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: Technical Documentation, Architecture Specs & API Reference Authoring Configuration & Specification
+```yaml
+# System Architecture Specification
+## Component Overview
+```mermaid
+graph TD
+  Client[Web Client] --> Gateway[API Gateway]
+  Gateway --> AuthService[Auth Service]
+  Gateway --> OrderService[Order Service]
+  OrderService --> DB[(PostgreSQL)]
+```
+### Communication Contracts
+- Edge: HTTPS / RESTful JSON
+- Internal: gRPC over HTTP/2 with mTLS
+```
+
+### Exemplar 2: Technical Documentation, Architecture Specs & API Reference Authoring TypeScript Type Contract
+```typescript
+export interface DocumentationArtifact {
+  title: string;
+  category: 'tutorial' | 'how-to' | 'reference' | 'explanation';
+  targetAudience: 'developers' | 'architects' | 'operations' | 'end-users';
+  path: string;
+  lastReviewed: string;
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in Technical Documentation, Architecture Specs & API Reference Authoring
+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/technical-seo-audit/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: technical-seo-audit
+description: Technical SEO audits covering Core Web Vitals, crawl budget,
+  robots.txt directives, structured JSON-LD data, and indexing hygiene.
+metadata:
+  author: Agents United SEO Group
+  version: 1.0.0
+  license: MIT
+  icon: ⚙️
+disable-slash-command: true
+---
+
+# Technical SEO Audit Playbook
+
+## Overview & Purpose
+`technical-seo-audit` provides a rigorous testing and auditing methodology for web applications to achieve maximum search engine crawlability and indexability.
+
+## Core Directives & Standards
+1. **Robots.txt & Sitemap Validation** — Verify `robots.txt` disallows private routes while allowing Googlebot/Bingbot access to public assets.
+2. **Schema JSON-LD Verification** — Validate structured data against Schema.org standards (`SoftwareApplication`, `Product`, `Article`, `FAQPage`).
+3. **Core Web Vitals Thresholds** — Enforce LCP < 2.5s, CLS < 0.1, and INP < 200ms across all public entry points.
+4. **Header & Status Code Hygiene** — Ensure clean 200 OK responses, proper 301 permanent redirects, and no redirect chains > 1 hop.
+
+## Verification Checklist
+- [ ] Valid JSON-LD structured data confirmed with Schema Validator.
+- [ ] No indexing directives set to `noindex` on production-ready public pages.
+- [ ] Canonical tags point strictly to self or canonical primary URL.

package/registry/skills/telemetry-monitoring/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: telemetry-monitoring
+description: Configures Prometheus metrics, Grafana dashboards, OpenTelemetry
+  distributed tracing, log aggregation, and SLO/SLA alert thresholds.
+metadata:
+  author: Agents United Core Team
+  version: 1.0.0
+  source: https://github.com/NeoAnthropocene/agents-united
+  icon: 📊
+disable-slash-command: true
+---
+
+# Telemetry & Observability Playbook
+
+## Overview & Purpose
+`telemetry-monitoring` provides systemic guidance for instrumenting application services with observability metrics, structured logging, distributed tracing, and alert monitoring.
+
+## Rules & Constraints
+1. **Focus alerts on SLO symptoms** (high error rate, tail latency) rather than noisy transient metrics.
+2. **Enforce structured JSON logging** with standard fields (`timestamp`, `level`, `trace_id`, `service`, `message`).
+3. **Inject OpenTelemetry context propagation** headers (`traceparent`) across RPC / HTTP calls.
+4. **Define explicit metric buckets** for histograms (HTTP response latency in ms).
+
+## Step-by-Step Execution Runbook
+
+### Phase 1 — Instrumentation Setup
+- Add Prometheus client metrics (`counter`, `gauge`, `histogram`) to core API endpoints.
+- Configure OpenTelemetry SDK exporter for distributed tracing.
+
+### Phase 2 — Dashboard & Alert Rules
+- Author Grafana dashboard JSON configuration files covering RED metrics (Rate, Errors, Duration).
+- Define Prometheus Alertmanager rules for p99 latency spikes and 5xx error rate thresholds.
+
+### Phase 3 — Verification
+- Validate log JSON schema parsing and trace propagation across microservice boundaries.
+
+## Verification Checklist
+- [ ] Prometheus metrics endpoint (`/metrics`) returns valid exposition format.
+- [ ] Distributed tracing headers properly injected.
+- [ ] Alerting thresholds aligned with SLO targets.