agents-united 1.0.0 → 1.2.0

package/registry/skills/frontend-component-design/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: frontend-component-design
+description: Production-grade Frontend Component Design playbook for reusable, accessible UI primitives in React, Vue, and Web Components.
+metadata:
+  author: "agents-united"
+  version: "2.0.0"
+---
+
+# Frontend Component Architecture, Accessibility & Storybook Playgrounds
+
+## Overview & Purpose
+The Frontend Component Architecture, Accessibility & Storybook Playgrounds skill provides a deterministic, battle-tested framework for executing frontend-component-design 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 frontend-component-design.
+- Auditing, implementing, or standardizing frontend-component-design 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/frontend-component-design/spec.md` | Full technical specification and architectural plan |
+| Implementation Files | `src/frontend-component-design/*` | Production-ready source code, tests, and configurations |
+| Execution Report | `reports/frontend-component-design/summary.json` | Verification metrics, test results, and audit summary |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Component API Design & Props Interface
+1. Define component prop types in TypeScript with strict discrimination unions.
+2. Establish single responsibility: separate layout containers from atomic UI primitives.
+3. Support composability via asChild / slot patterns or polymorphic as props.
+4. Ensure standard HTML attribute passthrough and forwardRef propagation.
+5. Avoid boolean prop explosion by using typed union variants (variant="primary").
+
+### Phase 2: Accessibility & Keyboard Navigation Specification
+1. Assign appropriate WAI-ARIA roles, states, and properties (aria-expanded, aria-controls).
+2. Implement complete keyboard interaction models according to W3C APG guidelines.
+3. Ensure explicit, high-contrast :focus-visible styling on all interactive elements.
+4. Manage focus trapping and restoration for modal dialogs and flyout menus.
+5. Verify screen reader announcements for dynamic state transitions.
+
+### Phase 3: Styling & Design Token Integration
+1. Bind component styles strictly to semantic design tokens (var(--color-brand-primary)).
+2. Ensure zero hardcoded magic numbers or hex colors in stylesheet.
+3. Implement fluid responsiveness using CSS container queries and clamp().
+4. Provide seamless dark/light theme adaptation via CSS custom property overrides.
+5. Enforce prefers-reduced-motion fallbacks for all transitions and micro-animations.
+
+### Phase 4: Storybook Documentation & Interactive Playground
+1. Create Storybook CSF3 story file with interactive Controls (argTypes).
+2. Author stories covering all variants, sizes, edge-case text lengths, and error states.
+3. Write accessibility regression tests using @storybook/addon-a11y.
+4. Include MDX documentation with copy-paste code snippets and UX usage guidelines.
+5. Validate visual regression snapshots.
+
+### Phase 5: Automated Testing & Packaging
+1. Author unit tests with Testing Library verifying rendering, user events, and accessibility.
+2. Verify zero console errors or hydration mismatch warnings.
+3. Export component from package entrypoint index.
+4. Run typecheck and build validation.
+5. Publish component to shared internal UI library.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: Frontend Component Architecture, Accessibility & Storybook Playgrounds Configuration & Specification
+```yaml
+import React, { forwardRef } from 'react';
+import clsx from 'clsx';
+
+export interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
+  variant?: 'primary' | 'secondary' | 'ghost' | 'danger';
+  size?: 'sm' | 'md' | 'lg';
+  isLoading?: boolean;
+}
+
+export const Button = forwardRef<HTMLButtonElement, ButtonProps>(({
+  variant = 'primary',
+  size = 'md',
+  isLoading = false,
+  className,
+  disabled,
+  children,
+  ...props
+}, ref) => (
+  <button
+    ref={ref}
+    disabled={disabled || isLoading}
+    className={clsx('ui-button', `ui-button--${variant}`, `ui-button--${size}`, className)}
+    aria-busy={isLoading}
+    {...props}
+  >
+    {isLoading ? <span className="ui-spinner" aria-hidden="true" /> : children}
+  </button>
+));
+```
+
+### Exemplar 2: Frontend Component Architecture, Accessibility & Storybook Playgrounds TypeScript Type Contract
+```typescript
+export interface ComponentSpecification {
+  name: string;
+  variants: string[];
+  sizes: string[];
+  interactiveStates: ['default', 'hover', 'focus-visible', 'active', 'disabled', 'loading'];
+  ariaRoles: string[];
+  keyboardInteractions: Record<string, string>;
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in Frontend Component Architecture, Accessibility & Storybook Playgrounds
+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/git-guardrails/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: git-guardrails
+description: Operational safety policies and git guardrails to prevent destructive force-pushes, unintended commits to main branches, and secret leaks.
+metadata:
+  author: "Matt Pocock (mattpocock/skills)"
+  version: "1.0.0"
+  source: "https://github.com/mattpocock/skills"
+---
+
+# Git Safety & Guardrails Playbook
+
+## Overview & Purpose
+`git-guardrails` enforces strict version control safety rules for AI agents and orchestrators, ensuring working tree stability, branch hygiene, and protection of main branches and credentials.
+
+## Rules & Constraints
+1. **Never commit directly to protected branches** (`main`, `master`, `production`, `release/*`). Always verify current branch with `git branch --show-current`.
+2. **Never execute force pushes** (`git push --force` or `-f`).
+3. **Never expose secrets or API keys**. Check staged diffs with `git diff --cached` before committing.
+4. **Never leave detached HEAD state unaddressed**.
+5. **Always write clear, imperative commit messages**.
+
+## Step-by-Step Execution Runbook
+
+### Phase 1 — Pre-Operation Inspection
+1. Run `git status` to verify working tree status.
+2. Verify active branch name. If on `main`, create a feature branch (`git checkout -b feature/<name>`).
+
+### Phase 2 — Staging & Secret Check
+1. Inspect staged changes with `git diff --cached`.
+2. Ensure no `.env`, token, credential, or secret strings are staged.
+
+### Phase 3 — Verification Gate & Commit
+1. Run linting and test verification suite before finalizing commit.
+2. Commit with standard Conventional Commits format (`feat:`, `fix:`, `docs:`, `refactor:`).
+
+## Verification & Validation Checklist
+- [ ] Frontmatter contains author attribution to Matt Pocock.
+- [ ] Safe git execution rules clearly stated.

package/registry/skills/google-ads-optimization/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: google-ads-optimization
+description: Google Search & Performance Max campaign optimization, keyword match types, negative keyword sculpting, and Quality Score improvement.
+metadata:
+  author: "Agents United Performance Group"
+  version: "1.0.0"
+  license: "MIT"
+---
+
+# Google Ads Optimization Playbook
+
+## Overview & Purpose
+`google-ads-optimization` provides systematic frameworks for launching, managing, and scaling high-ROAS Google Search and Performance Max ad campaigns.
+
+## Core Directives & Standards
+1. **Keyword Match Architecture** — Group exact match keywords into focused Single Keyword Ad Groups (SKAGs) or tightly themed ad groups.
+2. **Negative Keyword Guardrails** — Pre-populate universal negative keyword lists (e.g. "free", "login", "careers", "cracked", "torrent").
+3. **Responsive Search Ad (RSA) Assembly** — Provide 15 headlines and 4 descriptions per ad group with diverse value propositions.
+4. **Quality Score Optimization** — Align landing page headline copy directly with ad keyword search queries to maximize expected CTR and landing page experience score.
+
+## Verification Checklist
+- [ ] Conversion tracking pixels and enhanced conversion tags verified.
+- [ ] Negative keyword lists assigned at campaign or account level.
+- [ ] Bid strategies (Target CPA / Target ROAS) configured with realistic baseline data.

package/registry/skills/graphql-schema-design/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: graphql-schema-design
+description: Production-grade GraphQL Schema Design playbook for scalable type systems, DataLoader batching, and Apollo Federation.
+metadata:
+  author: "agents-united"
+  version: "2.0.0"
+---
+
+# GraphQL Schema Architecture, Resolvers & Federation
+
+## Overview & Purpose
+The GraphQL Schema Architecture, Resolvers & Federation skill provides a deterministic, battle-tested framework for executing graphql-schema-design 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 graphql-schema-design.
+- Auditing, implementing, or standardizing graphql-schema-design 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/graphql-schema-design/spec.md` | Full technical specification and architectural plan |
+| Implementation Files | `src/graphql-schema-design/*` | Production-ready source code, tests, and configurations |
+| Execution Report | `reports/graphql-schema-design/summary.json` | Verification metrics, test results, and audit summary |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1: Schema Domain Modeling & Type Architecture
+1. Model business domain as strongly-typed GraphQL schema using Schema Definition Language (SDL).
+2. Enforce non-nullable fields (!) strictly on guaranteed domain properties.
+3. Implement Relay Cursor Connections specification for all paginated list queries.
+4. Structure mutations with dedicated Input and Payload types (CreateOrderInput / CreateOrderPayload).
+5. Design domain error reporting via union types (union CreateOrderResult = Order | OrderError).
+
+### Phase 2: Apollo Federation & Subgraph Boundary Design
+1. Define federation @key directives for entity identification across subgraphs.
+2. Mark shared entity references with @external and @requires directives.
+3. Design clean subgraph boundaries matching domain bounded contexts.
+4. Compose supergraph schema using Rover CLI to verify federation compatibility.
+5. Validate schema against breaking change rules with Apollo Studio / GraphQL Inspector.
+
+### Phase 3: Resolver Implementation & DataLoader Batching
+1. Implement type resolvers with clean separation between transport and business services.
+2. Implement DataLoader instances to batch and cache database lookups, solving N+1 query problem.
+3. Enforce authentication and tenant authorization checks inside resolver context.
+4. Set query complexity calculation and depth limits to prevent malicious nested queries.
+5. Implement field-level telemetry and tracing headers.
+
+### Phase 4: Schema Validation & Contract Testing
+1. Run automated schema linting with graphql-eslint to enforce naming conventions.
+2. Execute integration tests executing GraphQL queries against in-memory test database.
+3. Verify error handling returns structured error extensions with error codes.
+4. Benchmark query execution latency under simulated concurrent requests.
+5. Confirm backwards-compatibility of newly introduced fields.
+
+### Phase 5: Client Code Generation & Gateway Deployment
+1. Generate TypeScript types and React Apollo hooks using @graphql-codegen/cli.
+2. Publish updated subgraph schemas to supergraph gateway.
+3. Deploy updated GraphQL service to production cluster.
+4. Monitor query performance and error rates in gateway analytics dashboard.
+5. Update public GraphQL documentation.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: GraphQL Schema Architecture, Resolvers & Federation Configuration & Specification
+```yaml
+type Order @key(fields: "id") {
+  id: ID!
+  customer: Customer!
+  items: [OrderItem!]!
+  totalCents: Int!
+  status: OrderStatus!
+  createdAt: String!
+}
+
+enum OrderStatus {
+  PENDING
+  PROCESSING
+  SHIPPED
+  DELIVERED
+  CANCELLED
+}
+
+type Query {
+  order(id: ID!): Order
+  orders(first: Int = 20, after: String): OrderConnection!
+}
+```
+
+### Exemplar 2: GraphQL Schema Architecture, Resolvers & Federation TypeScript Type Contract
+```typescript
+export interface GraphQLResolverContext {
+  userId?: string;
+  tenantId: string;
+  dataLoaders: {
+    userLoader: unknown;
+    orderLoader: unknown;
+  };
+}
+```
+
+## Edge Cases & Error Recovery Procedures
+
+### Scenario A: Validation Failure in GraphQL Schema Architecture, Resolvers & Federation
+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/grill-me/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: grill-me
+description: Pure Socratic alignment questioning to interrogate requirements, uncover blind spots, and eliminate ambiguity before taking action.
+metadata:
+  author: "Matt Pocock (mattpocock/skills)"
+  version: "1.0.0"
+  source: "https://github.com/mattpocock/skills"
+---
+
+# Grill Me: Socratic Alignment Interview
+
+## Overview & Purpose
+`grill-me` engages the developer in a focused, iterative Q&A session. It prevents premature implementation ("vibe coding") by asking hard, clarifying questions about scope, assumptions, edge cases, and success criteria.
+
+## Execution Triggers & Prerequisites
+### Execution Triggers
+- Invoked via `/grill-me`.
+- User request is high-level, ambiguous, or lacks clear boundaries.
+
+### Prerequisites
+- Clear user goal or initial idea prompt.
+
+## Input & Output Requirements
+### Inputs
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `goal` | String | Yes | High-level goal or requirement prompt |
+
+### Outputs
+| Artifact | Path / Format | Description |
+|---|---|---|
+| Clarified Requirements | Console / Inline | Refined specification and agreed approach |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1 — Problem Framing
+1. Read the user's initial prompt and identify open questions or implicit assumptions.
+2. Ask 2–4 concise, direct questions focusing on user outcomes and technical constraints.
+
+### Phase 2 — Iterative Grilling
+1. Process user responses.
+2. If new ambiguities emerge, ask follow-up questions one round at a time.
+3. Stop grilling as soon as scope, edge cases, and non-goals are explicit.
+
+### Phase 3 — Summary & Hand-off
+1. Present a concise bulleted summary of agreed scope.
+2. Offer next steps (e.g. proceed to `/to-spec` or implementation).
+
+## Verification & Validation Checklist
+- [ ] Frontmatter contains author attribution to Matt Pocock.
+- [ ] Grilling questions are targeted and non-redundant.

package/registry/skills/grill-with-docs/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: grill-with-docs
+description: Interactive alignment grilling session that asks deep probing questions before coding, establishes ubiquitous domain vocabulary (CONTEXT.md), and records architectural decisions (ADRs).
+metadata:
+  author: "Matt Pocock (mattpocock/skills)"
+  version: "1.0.0"
+  source: "https://github.com/mattpocock/skills"
+---
+
+# Grill With Docs: Socratic Alignment & Domain Documentation
+
+## Overview & Purpose
+`grill-with-docs` bridges the alignment gap between developers and AI orchestrators before implementation begins. It uses structured Socratic questioning to uncover hidden assumptions, update the shared domain language in `CONTEXT.md`, and record architectural decisions as formal ADRs (`docs/adr/*.md`).
+
+## Execution Triggers & Prerequisites
+### Execution Triggers
+- Starting a new feature, module, or complex refactor.
+- Ambiguous requirements or conflicting design preferences.
+- Directly running `/grill-with-docs` or initiating interactive orchestration.
+
+### Prerequisites
+- Accessible project root with `CONTEXT.md` (or permissions to create one).
+- Working directory initialized with version control.
+
+## Input & Output Requirements
+### Inputs
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `topic` | String | Yes | Feature, task, or architectural change to align on |
+| `issue_tracker` | String | Optional | Target tracker (`github`, `linear`, or `local`) |
+| `doc_path` | String | Optional | Path for documentation output (default: `docs/adr/`) |
+
+### Outputs
+| Artifact | Path / Format | Description |
+|---|---|---|
+| Domain Dictionary | `CONTEXT.md` | Ubiquitous vocabulary and domain model mapping |
+| Architectural Decision Record | `docs/adr/ADR-XXXX-<title>.md` | Formal decision log documenting problem, context, and choice |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1 — Socratic Alignment Interview
+1. Ask 3–5 probing, targeted questions about the requested feature (e.g., boundaries, data flow, edge cases, failure modes).
+2. Wait for developer responses before proceeding.
+3. Challenge ambiguous assumptions or underspecified constraints.
+
+### Phase 2 — Ubiquitous Language & Domain Modeling
+1. Identify new domain concepts, entity names, or system jargon surfaced during grilling.
+2. Update or create `CONTEXT.md` at the project root with clear, concise term definitions.
+3. Ensure orchestrators and developer use consistent terminology across code and documentation.
+
+### Phase 3 — Architectural Decision Record (ADR) Generation
+1. Format agreed architectural choices into an ADR stored under `docs/adr/`.
+2. Include Title, Status (Proposed/Accepted), Context, Decision, and Consequences.
+3. Summarize key takeaways and hand off to implementation workflows.
+
+## Code & Configuration Exemplars
+
+### Exemplar 1: ADR Structure
+```markdown
+# ADR-0001: Adopt Scoped Safety Policies for Sub-Agent Execution
+
+## Status
+Accepted
+
+## Context
+Sub-agents require predictable execution boundaries without prompting the user for every shell tool call.
+
+## Decision
+Implement `permissionMode: acceptEdits` and `commandExecutionPolicy` headers in sub-agent frontmatter.
+
+## Consequences
+Reduces human-in-the-loop overhead while keeping security constraints explicit.
+```
+
+## Verification & Validation Checklist
+- [ ] Frontmatter includes `author: "Matt Pocock (mattpocock/skills)"`.
+- [ ] `CONTEXT.md` updated with any newly introduced domain terms.
+- [ ] ADR document saved with proper sequence number under `docs/adr/`.

package/registry/skills/growth-experiment-design/SKILL.md

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

@@ -0,0 +1,41 @@
+---
+name: handoff
+description: Capture session progress, active context, decision logs, and remaining tasks to pass context seamlessly between subagents or future sessions.
+metadata:
+  author: "Matt Pocock (mattpocock/skills)"
+  version: "1.0.0"
+  source: "https://github.com/mattpocock/skills"
+---
+
+# Session Handoff & Context Persistence
+
+## Overview & Purpose
+`handoff` creates structured context handoff notes at the end of an agent session or before delegating tasks to subagents. This preserves context momentum and prevents redundant discovery work.
+
+## Input & Output Requirements
+### Inputs
+| Parameter | Type | Required | Description |
+|---|---|---|---|
+| `summary` | String | Yes | Brief description of completed work and current state |
+
+### Outputs
+| Artifact | Path / Format | Description |
+|---|---|---|
+| Handoff Document | `docs/handoff/HANDOFF-<date>.md` | Persistent session summary and open task list |
+
+## Step-by-Step Execution Runbook
+
+### Phase 1 — State Capture
+1. Summarize key achievements and completed PRs/commits in this session.
+2. List modified files and current git branch.
+
+### Phase 2 — Remaining Work & Blockers
+1. Highlight open tasks, failing tests, or unmerged branches.
+2. Document explicit next steps for the incoming agent.
+
+### Phase 3 — Persistence
+1. Save handoff notes to `docs/handoff/` or output directly in session response.
+
+## Verification & Validation Checklist
+- [ ] Frontmatter contains author attribution to Matt Pocock.
+- [ ] Handoff summary includes completed items, open items, and next steps.