@agent-blueprint/free-blueprints 1.0.0

package/dist/blueprints/employee-onboarding/files/implementation-state.js

@@ -0,0 +1,91 @@
+export const content = `schema_version: "1.0"
+overall_status: not_started
+
+platform:
+  name: TBD
+  version: TBD
+  environment: TBD
+
+agents:
+  - name: Onboarding Orchestrator
+    type: manager
+    status: not_started
+    phase: 1
+    tools_implemented: []
+    integrations_connected: []
+    tests_passing: false
+    notes: ""
+
+  - name: Document Processor
+    type: worker
+    status: not_started
+    phase: 1
+    tools_implemented: []
+    integrations_connected: []
+    tests_passing: false
+    notes: ""
+
+  - name: IT Provisioning Coordinator
+    type: worker
+    status: not_started
+    phase: 2
+    tools_implemented: []
+    integrations_connected: []
+    tests_passing: false
+    notes: ""
+
+  - name: Training Curriculum Assembler
+    type: worker
+    status: not_started
+    phase: 2
+    tools_implemented: []
+    integrations_connected: []
+    tests_passing: false
+    notes: ""
+
+  - name: Progress Tracker
+    type: worker
+    status: not_started
+    phase: 2
+    tools_implemented: []
+    integrations_connected: []
+    tests_passing: false
+    notes: ""
+
+pilot:
+  status: not_started
+  start_date: TBD
+  end_date: TBD
+  decision_gate:
+    document_accuracy: null
+    time_reduction: null
+    compliance_gaps: null
+    critical_errors: null
+  stakeholder_signoff: false
+
+full_implementation:
+  status: not_started
+  start_date: TBD
+  end_date: TBD
+
+integrations:
+  - name: HR System (new-hire event trigger)
+    status: not_started
+    notes: ""
+  - name: Document Management (e-signature, storage)
+    status: not_started
+    notes: ""
+  - name: Identity Management (directory, SSO)
+    status: not_started
+    notes: ""
+  - name: IT Service Management (tickets, assets)
+    status: not_started
+    notes: ""
+  - name: Learning Management System
+    status: not_started
+    notes: ""
+  - name: Communication Channels (email, chat)
+    status: not_started
+    notes: ""
+`;
+//# sourceMappingURL=implementation-state.js.map

package/dist/blueprints/employee-onboarding/files/implementation-state.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"implementation-state.js","sourceRoot":"","sources":["../../../../src/blueprints/employee-onboarding/files/implementation-state.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyFtB,CAAC"}

package/dist/blueprints/employee-onboarding/files/platform-connectivity.d.ts

@@ -0,0 +1 @@
+export declare const content = "# Platform Connectivity\n\nIntegration points and patterns for connecting the Employee Onboarding Automation system to your technology stack. All guidance is vendor-agnostic. Adapt to whatever systems your organization uses.\n\n---\n\n## HR System Integration\n\n**Purpose:** Source of truth for new-hire data. Triggers the onboarding process.\n\n### Required Capabilities\n\n- **New-hire event notification.** The HR system must emit an event (webhook, message queue, or polling-compatible API) when a new hire record is created or a start date is confirmed. This is the trigger for the entire onboarding workflow.\n- **Employee data read access.** The Orchestrator needs: employee name, email, role title, department, start date, employment type (full-time, contractor, intern), reporting manager, office location, and remote/hybrid/onsite status.\n- **Employee status updates.** The system needs to detect offer rescissions, start date changes, and role changes that affect onboarding tasks already in progress.\n\n### Integration Pattern\n\nEvent-driven is preferred. Configure the HR system to emit a webhook on new-hire creation. The Orchestrator subscribes to this event. If webhooks are not available, poll the HR system API for new hires on a 15-minute interval and deduplicate using employee ID.\n\n---\n\n## Identity Management\n\n**Purpose:** User account lifecycle. SSO configuration. Directory group membership.\n\n### Required Capabilities\n\n- **User account creation.** Create accounts in the organization's directory service with appropriate attributes (name, email, department, manager, role).\n- **Group membership management.** Add new accounts to the correct security groups and distribution lists based on role and department.\n- **SSO provisioning.** Configure single sign-on access for downstream applications.\n- **Account status management.** Activate accounts on start date, deactivate if onboarding is cancelled.\n\n### Integration Pattern\n\nUse the directory service's administrative API (SCIM, REST, or platform-specific SDK). The IT Provisioning Coordinator calls this API to create accounts and manage group memberships. Idempotency is critical: the API call to create an account must be safe to retry without creating duplicates. Use the employee's HR system ID as the external identifier for deduplication.\n\n---\n\n## Document Management\n\n**Purpose:** Collect, store, and manage new-hire documents with e-signature support.\n\n### Required Capabilities\n\n- **E-signature workflows.** Send documents (NDAs, offer letters, policy acknowledgments) for electronic signature. Track signature status.\n- **Form generation.** Generate pre-filled tax forms and benefits enrollment forms from HR system data.\n- **Document upload and storage.** Accept uploaded documents (ID photos, certifications) from new hires via a secure portal or email.\n- **Document retrieval.** Retrieve stored documents for validation and processing.\n- **Retention management.** Tag documents with retention categories and support automated deletion at expiry.\n\n### Integration Pattern\n\nThe Document Processor connects to the e-signature service API for signature workflows and to the document storage API for uploads and retrieval. New hires interact with the e-signature service directly (signing documents) and with a portal or email for uploads. The Document Processor monitors completion events from the e-signature service to trigger validation.\n\n---\n\n## IT Service Management\n\n**Purpose:** Hardware procurement, ticket tracking, and asset management.\n\n### Required Capabilities\n\n- **Ticket creation.** Create provisioning requests (hardware orders, software installation, desk setup) as trackable tickets.\n- **Asset assignment.** Record which assets (laptop serial number, monitor, peripherals) are assigned to which employee.\n- **Ticket status tracking.** Monitor ticket progress to detect delays and blockers.\n- **Catalog item requests.** Submit requests from a service catalog (standard laptop configurations, software bundles) rather than free-form tickets.\n\n### Integration Pattern\n\nThe IT Provisioning Coordinator creates tickets or catalog requests via the ITSM API. It polls or subscribes to status updates. For hardware, the pattern is: create a catalog request with specifications and shipping details, then monitor the request through fulfillment stages (ordered, shipped, delivered, configured). For software, the pattern is: submit a license assignment request, then verify the assignment is active.\n\n---\n\n## Learning Management System\n\n**Purpose:** Training course catalog, enrollment, and completion tracking.\n\n### Required Capabilities\n\n- **Course catalog API.** Query available training modules with metadata (category, duration, prerequisites, compliance flag, format).\n- **Enrollment management.** Enroll employees in specific courses with deadlines. Modify or cancel enrollments.\n- **Completion tracking.** Receive notifications or query completion status for enrolled courses.\n- **Training path support.** If the LMS supports learning paths or curricula natively, use that. Otherwise, the Training Curriculum Assembler manages sequencing externally and enrolls modules individually as prerequisites are met.\n\n### Integration Pattern\n\nThe Training Curriculum Assembler queries the course catalog to build training paths, then uses the enrollment API to assign modules. Completion events (if the LMS emits them) trigger the Assembler to enroll the next module in the sequence. If the LMS does not emit completion events, poll the completion status API on a 1-hour interval for active enrollments.\n\n---\n\n## Communication Channels\n\n**Purpose:** Notifications, reminders, and status updates to new hires, managers, and HR.\n\n### Required Capabilities\n\n- **Email sending.** Programmatic email for document collection requests, welcome messages, and escalation notifications. Must support HTML templates.\n- **Chat messaging.** Programmatic chat messages for reminders, status updates, and quick notifications. Preferred for time-sensitive items.\n- **Channel selection logic.** Critical/urgent items use both email and chat. Routine items use the employee's preferred channel if known, defaulting to email.\n\n### Integration Pattern\n\nThe system sends notifications through two channels: email API for formal communications and chat API for informal/urgent ones. The Progress Tracker manages reminder frequency (maximum 2 per action per 48-hour period). Each agent sends its own notifications for immediate operational items (e.g., Document Processor sends collection requests). The Progress Tracker handles reminders for overdue items and status reports.\n\n---\n\n## Common Integration Considerations\n\n### Authentication\n\nAll integrations should use OAuth 2.0 or API key authentication. Service accounts are preferred over user-impersonation tokens. Store credentials in a secrets manager. Rotate API keys on a quarterly cadence at minimum.\n\n### Rate Limiting\n\nEnterprise APIs enforce rate limits. The system must respect them:\n\n- Implement backoff on 429 responses (rate limit exceeded)\n- Batch operations where the API supports it (e.g., creating 5 accounts in one call vs. 5 separate calls)\n- Distribute API calls across time rather than bursting (relevant when processing a large cohort of new hires)\n\n### Error Handling\n\nIntegration failures are expected. The system handles them through:\n\n- Retry with exponential backoff for transient errors (timeouts, 500s, rate limits)\n- Escalation to the Orchestrator for persistent errors (3 consecutive failures)\n- Graceful degradation: if a non-critical integration is down (e.g., chat notifications), fall back to email. If a critical integration is down (e.g., HR system), halt new case creation and alert operations.\n\n### Data Mapping\n\nEach integration requires mapping between the onboarding system's data model and the external system's data model. Document these mappings explicitly. Common mapping challenges:\n\n- Role titles in the HR system may not match role templates in the provisioning system\n- Department names may differ between HR and directory services\n- Employee IDs may be formatted differently across systems\n\nCreate a mapping configuration that translates between systems. Do not hard-code mappings in agent logic.\n";

package/dist/blueprints/employee-onboarding/files/platform-connectivity.js

@@ -0,0 +1,140 @@
+export const content = `# Platform Connectivity
+
+Integration points and patterns for connecting the Employee Onboarding Automation system to your technology stack. All guidance is vendor-agnostic. Adapt to whatever systems your organization uses.
+
+---
+
+## HR System Integration
+
+**Purpose:** Source of truth for new-hire data. Triggers the onboarding process.
+
+### Required Capabilities
+
+- **New-hire event notification.** The HR system must emit an event (webhook, message queue, or polling-compatible API) when a new hire record is created or a start date is confirmed. This is the trigger for the entire onboarding workflow.
+- **Employee data read access.** The Orchestrator needs: employee name, email, role title, department, start date, employment type (full-time, contractor, intern), reporting manager, office location, and remote/hybrid/onsite status.
+- **Employee status updates.** The system needs to detect offer rescissions, start date changes, and role changes that affect onboarding tasks already in progress.
+
+### Integration Pattern
+
+Event-driven is preferred. Configure the HR system to emit a webhook on new-hire creation. The Orchestrator subscribes to this event. If webhooks are not available, poll the HR system API for new hires on a 15-minute interval and deduplicate using employee ID.
+
+---
+
+## Identity Management
+
+**Purpose:** User account lifecycle. SSO configuration. Directory group membership.
+
+### Required Capabilities
+
+- **User account creation.** Create accounts in the organization's directory service with appropriate attributes (name, email, department, manager, role).
+- **Group membership management.** Add new accounts to the correct security groups and distribution lists based on role and department.
+- **SSO provisioning.** Configure single sign-on access for downstream applications.
+- **Account status management.** Activate accounts on start date, deactivate if onboarding is cancelled.
+
+### Integration Pattern
+
+Use the directory service's administrative API (SCIM, REST, or platform-specific SDK). The IT Provisioning Coordinator calls this API to create accounts and manage group memberships. Idempotency is critical: the API call to create an account must be safe to retry without creating duplicates. Use the employee's HR system ID as the external identifier for deduplication.
+
+---
+
+## Document Management
+
+**Purpose:** Collect, store, and manage new-hire documents with e-signature support.
+
+### Required Capabilities
+
+- **E-signature workflows.** Send documents (NDAs, offer letters, policy acknowledgments) for electronic signature. Track signature status.
+- **Form generation.** Generate pre-filled tax forms and benefits enrollment forms from HR system data.
+- **Document upload and storage.** Accept uploaded documents (ID photos, certifications) from new hires via a secure portal or email.
+- **Document retrieval.** Retrieve stored documents for validation and processing.
+- **Retention management.** Tag documents with retention categories and support automated deletion at expiry.
+
+### Integration Pattern
+
+The Document Processor connects to the e-signature service API for signature workflows and to the document storage API for uploads and retrieval. New hires interact with the e-signature service directly (signing documents) and with a portal or email for uploads. The Document Processor monitors completion events from the e-signature service to trigger validation.
+
+---
+
+## IT Service Management
+
+**Purpose:** Hardware procurement, ticket tracking, and asset management.
+
+### Required Capabilities
+
+- **Ticket creation.** Create provisioning requests (hardware orders, software installation, desk setup) as trackable tickets.
+- **Asset assignment.** Record which assets (laptop serial number, monitor, peripherals) are assigned to which employee.
+- **Ticket status tracking.** Monitor ticket progress to detect delays and blockers.
+- **Catalog item requests.** Submit requests from a service catalog (standard laptop configurations, software bundles) rather than free-form tickets.
+
+### Integration Pattern
+
+The IT Provisioning Coordinator creates tickets or catalog requests via the ITSM API. It polls or subscribes to status updates. For hardware, the pattern is: create a catalog request with specifications and shipping details, then monitor the request through fulfillment stages (ordered, shipped, delivered, configured). For software, the pattern is: submit a license assignment request, then verify the assignment is active.
+
+---
+
+## Learning Management System
+
+**Purpose:** Training course catalog, enrollment, and completion tracking.
+
+### Required Capabilities
+
+- **Course catalog API.** Query available training modules with metadata (category, duration, prerequisites, compliance flag, format).
+- **Enrollment management.** Enroll employees in specific courses with deadlines. Modify or cancel enrollments.
+- **Completion tracking.** Receive notifications or query completion status for enrolled courses.
+- **Training path support.** If the LMS supports learning paths or curricula natively, use that. Otherwise, the Training Curriculum Assembler manages sequencing externally and enrolls modules individually as prerequisites are met.
+
+### Integration Pattern
+
+The Training Curriculum Assembler queries the course catalog to build training paths, then uses the enrollment API to assign modules. Completion events (if the LMS emits them) trigger the Assembler to enroll the next module in the sequence. If the LMS does not emit completion events, poll the completion status API on a 1-hour interval for active enrollments.
+
+---
+
+## Communication Channels
+
+**Purpose:** Notifications, reminders, and status updates to new hires, managers, and HR.
+
+### Required Capabilities
+
+- **Email sending.** Programmatic email for document collection requests, welcome messages, and escalation notifications. Must support HTML templates.
+- **Chat messaging.** Programmatic chat messages for reminders, status updates, and quick notifications. Preferred for time-sensitive items.
+- **Channel selection logic.** Critical/urgent items use both email and chat. Routine items use the employee's preferred channel if known, defaulting to email.
+
+### Integration Pattern
+
+The system sends notifications through two channels: email API for formal communications and chat API for informal/urgent ones. The Progress Tracker manages reminder frequency (maximum 2 per action per 48-hour period). Each agent sends its own notifications for immediate operational items (e.g., Document Processor sends collection requests). The Progress Tracker handles reminders for overdue items and status reports.
+
+---
+
+## Common Integration Considerations
+
+### Authentication
+
+All integrations should use OAuth 2.0 or API key authentication. Service accounts are preferred over user-impersonation tokens. Store credentials in a secrets manager. Rotate API keys on a quarterly cadence at minimum.
+
+### Rate Limiting
+
+Enterprise APIs enforce rate limits. The system must respect them:
+
+- Implement backoff on 429 responses (rate limit exceeded)
+- Batch operations where the API supports it (e.g., creating 5 accounts in one call vs. 5 separate calls)
+- Distribute API calls across time rather than bursting (relevant when processing a large cohort of new hires)
+
+### Error Handling
+
+Integration failures are expected. The system handles them through:
+
+- Retry with exponential backoff for transient errors (timeouts, 500s, rate limits)
+- Escalation to the Orchestrator for persistent errors (3 consecutive failures)
+- Graceful degradation: if a non-critical integration is down (e.g., chat notifications), fall back to email. If a critical integration is down (e.g., HR system), halt new case creation and alert operations.
+
+### Data Mapping
+
+Each integration requires mapping between the onboarding system's data model and the external system's data model. Document these mappings explicitly. Common mapping challenges:
+
+- Role titles in the HR system may not match role templates in the provisioning system
+- Department names may differ between HR and directory services
+- Employee IDs may be formatted differently across systems
+
+Create a mapping configuration that translates between systems. Do not hard-code mappings in agent logic.
+`;
+//# sourceMappingURL=platform-connectivity.js.map

package/dist/blueprints/employee-onboarding/files/platform-connectivity.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"platform-connectivity.js","sourceRoot":"","sources":["../../../../src/blueprints/employee-onboarding/files/platform-connectivity.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA0ItB,CAAC"}

package/dist/blueprints/employee-onboarding/files/skill.d.ts

@@ -0,0 +1 @@
+export declare const content = "---\nname: employee-onboarding-automation\ndescription: >-\n  Implementation specification for Employee Onboarding Automation. 5 AI agents,\n  Manager-Workers pattern, vendor-agnostic.\ncompatibility: Any coding agent (Claude Code, Codex, Cursor).\nmetadata:\n  generated-by: agent-blueprint\n  generated-at: \"2026-04-08T00:00:00.000Z\"\n  blueprint-id: \"free-employee-onboarding\"\n  target-platform: \"vendor_agnostic\"\n  agent-count: \"5\"\n  pattern: \"Manager-Workers\"\n  investment-tier: \"medium\"\n---\n\n# Implementation Specification\n\n> Automate the employee onboarding lifecycle with 5 AI agents in a Manager-Workers pattern. One orchestrator coordinates four specialized workers that handle document processing, IT provisioning, training assembly, and progress tracking. Vendor-agnostic. Phased rollout. Production-ready specification.\n\n## Business Problem\n\nEmployee onboarding is broken at most organizations. The symptoms are predictable:\n\n- **Slow ramp time.** New hires wait days or weeks for accounts, hardware, and access. Their first impression is sitting idle.\n- **Inconsistent experience.** Onboarding quality depends on which manager or HR generalist handles it. Some new hires get a structured first week. Others get a laptop and a \"good luck.\"\n- **Manual tracking.** HR teams juggle spreadsheets, email threads, and tribal knowledge to track who has completed what. Things fall through the cracks constantly.\n- **Compliance gaps.** Tax forms, NDAs, and mandatory training have hard deadlines. Manual processes miss them. The company eats the risk.\n- **IT provisioning delays.** Account creation, software licenses, and access permissions require multiple teams and multiple tickets. Coordination overhead is enormous.\n\nThese problems scale linearly with headcount. A company hiring 50 people per quarter has 50 opportunities per quarter for something to go wrong.\n\n## Solution Architecture\n\n- **Platform:** Vendor-agnostic (adaptable to any HR, IT, or workflow platform)\n- **Pattern:** Manager-Workers\n- **Agents:** 5\n\n| # | Agent | Role | Type |\n|---|-------|------|------|\n| 1 | Onboarding Orchestrator | Coordinates full onboarding lifecycle, manages task dependencies, tracks completion, escalates blockers | Manager |\n| 2 | Document Processor | Collects, validates, and processes new hire documentation (tax forms, ID verification, benefits enrollment, NDAs) | Worker |\n| 3 | IT Provisioning Coordinator | Provisions accounts, hardware, software licenses, access permissions, and environment setup | Worker |\n| 4 | Training Curriculum Assembler | Builds personalized training paths based on role, department, and experience level | Worker |\n| 5 | Progress Tracker | Monitors onboarding milestones, generates status reports, identifies at-risk onboards, triggers reminders | Worker |\n\n## Phase 1: Pilot\n\n**Goal:** Validate the core pattern with the two highest-impact agents before investing in the full system.\n\n**Duration:** 4 weeks\n\n**Why these two agents first:** Document processing is the highest-volume, most error-prone part of onboarding. The orchestrator is required regardless. Together they prove the architecture works and deliver measurable value.\n\n### Pilot Workstreams\n\n1. **Week 1-2: Scaffold and integrate.** Deploy the Onboarding Orchestrator and Document Processor. Connect to the HR system's new-hire event trigger. Wire up document collection and validation workflows.\n2. **Week 2-3: Run parallel.** Process real new hires through both the automated system and the existing manual process. Compare results side by side.\n3. **Week 3-4: Measure and decide.** Collect metrics against the decision gate criteria below. Present findings to stakeholders.\n\n### Decision Gate Criteria\n\nThe pilot passes if ALL of the following are met:\n\n- Document processing accuracy > 95% (first-pass completion without human correction)\n- Time from new-hire event to document completion reduced by > 50% vs. manual baseline\n- Zero compliance gaps (no missed deadlines for required documents)\n- No critical errors requiring manual intervention more than once per 20 onboards\n\n### Exit Criteria\n\n- Stakeholder sign-off on pilot metrics\n- Architecture validated for adding additional workers\n- Integration patterns documented for reuse in Phase 2\n\n## Phase 2: Full Implementation\n\n**Duration:** 6 weeks\n\n**Scope:** Add the remaining three workers to the validated architecture.\n\n1. **IT Provisioning Coordinator** (Weeks 1-3): Account creation, hardware assignment, software licensing, access permissions. Integrates with identity management and IT service management systems.\n2. **Training Curriculum Assembler** (Weeks 2-4): Personalized training path generation based on role, department, seniority, and compliance requirements. Integrates with learning management systems.\n3. **Progress Tracker** (Weeks 3-6): Real-time milestone monitoring, at-risk identification, automated reminders, and status reporting for HR and hiring managers.\n\nWorkers are deployed incrementally. Each new worker is validated independently before the next begins.\n\n## Agent Specifications Summary\n\n1. **Onboarding Orchestrator** - Manager agent that coordinates the full onboarding lifecycle from new-hire event to Day 90 completion.\n2. **Document Processor** - Collects, validates, and routes all required new-hire documentation with compliance deadline enforcement.\n3. **IT Provisioning Coordinator** - Provisions accounts, hardware, software, and access permissions with Day 1 readiness as the target.\n4. **Training Curriculum Assembler** - Builds role-specific, department-aware training paths and tracks module completion.\n5. **Progress Tracker** - Monitors all onboarding milestones, flags at-risk onboards, and generates status reports for stakeholders.\n\nFull specifications including tools, data contracts, and success metrics: `references/agent-specifications.md`\n\n## Risk & Governance Summary\n\n### Top 3 Technical Risks\n\n1. **Integration fragility.** HR, IT, and document systems have different APIs, data formats, and reliability characteristics. A single integration failure can stall an entire onboarding.\n2. **PII exposure.** Onboarding involves SSNs, government IDs, bank account details, and medical information. Every data flow is a potential leak.\n3. **State synchronization.** Five agents operating on overlapping data create race conditions and consistency risks. The orchestrator must be the single source of truth.\n\n### Top 3 Business Risks\n\n1. **Employee experience degradation.** Automation that feels robotic or impersonal can make onboarding worse, not better. Human touchpoints must be preserved for high-impact moments.\n2. **Compliance liability.** Automated document processing that misses a required form or accepts an invalid one creates legal exposure.\n3. **Change management resistance.** HR teams and hiring managers have established workflows. Forcing adoption without demonstrating value creates friction and workarounds.\n\nFull risk analysis, escalation rules, and governance framework: `references/guardrails-and-governance.md`\n\n## How to Use This Spec\n\n1. Read this file top to bottom to understand the architecture and phasing.\n2. Read `GETTING-STARTED.md` for implementation instructions.\n3. Read `references/agent-specifications.md` for detailed agent definitions, tools, and data contracts.\n4. Read `references/platform-connectivity.md` to plan your integrations.\n5. Use `implementation-state.yaml` to track your build progress as you go.\n\n---\n\nGenerated by [Agent Blueprint](https://agentblueprint.ai) - Free Community Blueprint\n";

package/dist/blueprints/employee-onboarding/files/skill.js

@@ -0,0 +1,126 @@
+export const content = `---
+name: employee-onboarding-automation
+description: >-
+  Implementation specification for Employee Onboarding Automation. 5 AI agents,
+  Manager-Workers pattern, vendor-agnostic.
+compatibility: Any coding agent (Claude Code, Codex, Cursor).
+metadata:
+  generated-by: agent-blueprint
+  generated-at: "2026-04-08T00:00:00.000Z"
+  blueprint-id: "free-employee-onboarding"
+  target-platform: "vendor_agnostic"
+  agent-count: "5"
+  pattern: "Manager-Workers"
+  investment-tier: "medium"
+---
+
+# Implementation Specification
+
+> Automate the employee onboarding lifecycle with 5 AI agents in a Manager-Workers pattern. One orchestrator coordinates four specialized workers that handle document processing, IT provisioning, training assembly, and progress tracking. Vendor-agnostic. Phased rollout. Production-ready specification.
+
+## Business Problem
+
+Employee onboarding is broken at most organizations. The symptoms are predictable:
+
+- **Slow ramp time.** New hires wait days or weeks for accounts, hardware, and access. Their first impression is sitting idle.
+- **Inconsistent experience.** Onboarding quality depends on which manager or HR generalist handles it. Some new hires get a structured first week. Others get a laptop and a "good luck."
+- **Manual tracking.** HR teams juggle spreadsheets, email threads, and tribal knowledge to track who has completed what. Things fall through the cracks constantly.
+- **Compliance gaps.** Tax forms, NDAs, and mandatory training have hard deadlines. Manual processes miss them. The company eats the risk.
+- **IT provisioning delays.** Account creation, software licenses, and access permissions require multiple teams and multiple tickets. Coordination overhead is enormous.
+
+These problems scale linearly with headcount. A company hiring 50 people per quarter has 50 opportunities per quarter for something to go wrong.
+
+## Solution Architecture
+
+- **Platform:** Vendor-agnostic (adaptable to any HR, IT, or workflow platform)
+- **Pattern:** Manager-Workers
+- **Agents:** 5
+
+| # | Agent | Role | Type |
+|---|-------|------|------|
+| 1 | Onboarding Orchestrator | Coordinates full onboarding lifecycle, manages task dependencies, tracks completion, escalates blockers | Manager |
+| 2 | Document Processor | Collects, validates, and processes new hire documentation (tax forms, ID verification, benefits enrollment, NDAs) | Worker |
+| 3 | IT Provisioning Coordinator | Provisions accounts, hardware, software licenses, access permissions, and environment setup | Worker |
+| 4 | Training Curriculum Assembler | Builds personalized training paths based on role, department, and experience level | Worker |
+| 5 | Progress Tracker | Monitors onboarding milestones, generates status reports, identifies at-risk onboards, triggers reminders | Worker |
+
+## Phase 1: Pilot
+
+**Goal:** Validate the core pattern with the two highest-impact agents before investing in the full system.
+
+**Duration:** 4 weeks
+
+**Why these two agents first:** Document processing is the highest-volume, most error-prone part of onboarding. The orchestrator is required regardless. Together they prove the architecture works and deliver measurable value.
+
+### Pilot Workstreams
+
+1. **Week 1-2: Scaffold and integrate.** Deploy the Onboarding Orchestrator and Document Processor. Connect to the HR system's new-hire event trigger. Wire up document collection and validation workflows.
+2. **Week 2-3: Run parallel.** Process real new hires through both the automated system and the existing manual process. Compare results side by side.
+3. **Week 3-4: Measure and decide.** Collect metrics against the decision gate criteria below. Present findings to stakeholders.
+
+### Decision Gate Criteria
+
+The pilot passes if ALL of the following are met:
+
+- Document processing accuracy > 95% (first-pass completion without human correction)
+- Time from new-hire event to document completion reduced by > 50% vs. manual baseline
+- Zero compliance gaps (no missed deadlines for required documents)
+- No critical errors requiring manual intervention more than once per 20 onboards
+
+### Exit Criteria
+
+- Stakeholder sign-off on pilot metrics
+- Architecture validated for adding additional workers
+- Integration patterns documented for reuse in Phase 2
+
+## Phase 2: Full Implementation
+
+**Duration:** 6 weeks
+
+**Scope:** Add the remaining three workers to the validated architecture.
+
+1. **IT Provisioning Coordinator** (Weeks 1-3): Account creation, hardware assignment, software licensing, access permissions. Integrates with identity management and IT service management systems.
+2. **Training Curriculum Assembler** (Weeks 2-4): Personalized training path generation based on role, department, seniority, and compliance requirements. Integrates with learning management systems.
+3. **Progress Tracker** (Weeks 3-6): Real-time milestone monitoring, at-risk identification, automated reminders, and status reporting for HR and hiring managers.
+
+Workers are deployed incrementally. Each new worker is validated independently before the next begins.
+
+## Agent Specifications Summary
+
+1. **Onboarding Orchestrator** - Manager agent that coordinates the full onboarding lifecycle from new-hire event to Day 90 completion.
+2. **Document Processor** - Collects, validates, and routes all required new-hire documentation with compliance deadline enforcement.
+3. **IT Provisioning Coordinator** - Provisions accounts, hardware, software, and access permissions with Day 1 readiness as the target.
+4. **Training Curriculum Assembler** - Builds role-specific, department-aware training paths and tracks module completion.
+5. **Progress Tracker** - Monitors all onboarding milestones, flags at-risk onboards, and generates status reports for stakeholders.
+
+Full specifications including tools, data contracts, and success metrics: \`references/agent-specifications.md\`
+
+## Risk & Governance Summary
+
+### Top 3 Technical Risks
+
+1. **Integration fragility.** HR, IT, and document systems have different APIs, data formats, and reliability characteristics. A single integration failure can stall an entire onboarding.
+2. **PII exposure.** Onboarding involves SSNs, government IDs, bank account details, and medical information. Every data flow is a potential leak.
+3. **State synchronization.** Five agents operating on overlapping data create race conditions and consistency risks. The orchestrator must be the single source of truth.
+
+### Top 3 Business Risks
+
+1. **Employee experience degradation.** Automation that feels robotic or impersonal can make onboarding worse, not better. Human touchpoints must be preserved for high-impact moments.
+2. **Compliance liability.** Automated document processing that misses a required form or accepts an invalid one creates legal exposure.
+3. **Change management resistance.** HR teams and hiring managers have established workflows. Forcing adoption without demonstrating value creates friction and workarounds.
+
+Full risk analysis, escalation rules, and governance framework: \`references/guardrails-and-governance.md\`
+
+## How to Use This Spec
+
+1. Read this file top to bottom to understand the architecture and phasing.
+2. Read \`GETTING-STARTED.md\` for implementation instructions.
+3. Read \`references/agent-specifications.md\` for detailed agent definitions, tools, and data contracts.
+4. Read \`references/platform-connectivity.md\` to plan your integrations.
+5. Use \`implementation-state.yaml\` to track your build progress as you go.
+
+---
+
+Generated by [Agent Blueprint](https://agentblueprint.ai) - Free Community Blueprint
+`;
+//# sourceMappingURL=skill.js.map

package/dist/blueprints/employee-onboarding/files/skill.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"skill.js","sourceRoot":"","sources":["../../../../src/blueprints/employee-onboarding/files/skill.ts"],"names":[],"mappings":"AAAA,MAAM,CAAC,MAAM,OAAO,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4HtB,CAAC"}

package/dist/blueprints/employee-onboarding/index.d.ts

@@ -0,0 +1,2 @@
+import type { Blueprint } from '../../types.js';
+export declare const employeeOnboarding: Blueprint;

package/dist/blueprints/employee-onboarding/index.js

@@ -0,0 +1,37 @@
+import { content as skill } from './files/skill.js';
+import { content as gettingStarted } from './files/getting-started.js';
+import { content as agents } from './files/agents.js';
+import { content as implementationState } from './files/implementation-state.js';
+import { content as agentSpecifications } from './files/agent-specifications.js';
+import { content as architectureDecisions } from './files/architecture-decisions.js';
+import { content as guardrailsAndGovernance } from './files/guardrails-and-governance.js';
+import { content as evaluationCriteria } from './files/evaluation-criteria.js';
+import { content as platformConnectivity } from './files/platform-connectivity.js';
+import { content as businessContext } from './files/business-context.js';
+export const employeeOnboarding = {
+    catalog: {
+        id: 'employee-onboarding',
+        title: 'Employee Onboarding Automation',
+        description: 'Automate document processing, IT provisioning, training assembly, and progress tracking with 5 AI agents in a Manager-Workers pattern.',
+        agentCount: 5,
+        pattern: 'Manager-Workers',
+        category: 'Human Resources',
+    },
+    manifest: {
+        directory: 'employee-onboarding-automation',
+        files: [
+            { path: 'SKILL.md', content: skill },
+            { path: 'GETTING-STARTED.md', content: gettingStarted },
+            { path: 'AGENTS.md', content: agents },
+            { path: 'implementation-state.yaml', content: implementationState },
+            { path: 'references/agent-specifications.md', content: agentSpecifications },
+            { path: 'references/architecture-decisions.md', content: architectureDecisions },
+            { path: 'references/guardrails-and-governance.md', content: guardrailsAndGovernance },
+            { path: 'references/evaluation-criteria.md', content: evaluationCriteria },
+            { path: 'references/platform-connectivity.md', content: platformConnectivity },
+            { path: 'references/business-context.md', content: businessContext },
+        ],
+        installHint: 'Write these files to .agent-blueprint/employee-onboarding-automation/',
+    },
+};
+//# sourceMappingURL=index.js.map

package/dist/blueprints/employee-onboarding/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../../src/blueprints/employee-onboarding/index.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,OAAO,IAAI,KAAK,EAAE,MAAM,kBAAkB,CAAC;AACpD,OAAO,EAAE,OAAO,IAAI,cAAc,EAAE,MAAM,4BAA4B,CAAC;AACvE,OAAO,EAAE,OAAO,IAAI,MAAM,EAAE,MAAM,mBAAmB,CAAC;AACtD,OAAO,EAAE,OAAO,IAAI,mBAAmB,EAAE,MAAM,iCAAiC,CAAC;AACjF,OAAO,EAAE,OAAO,IAAI,mBAAmB,EAAE,MAAM,iCAAiC,CAAC;AACjF,OAAO,EAAE,OAAO,IAAI,qBAAqB,EAAE,MAAM,mCAAmC,CAAC;AACrF,OAAO,EAAE,OAAO,IAAI,uBAAuB,EAAE,MAAM,sCAAsC,CAAC;AAC1F,OAAO,EAAE,OAAO,IAAI,kBAAkB,EAAE,MAAM,gCAAgC,CAAC;AAC/E,OAAO,EAAE,OAAO,IAAI,oBAAoB,EAAE,MAAM,kCAAkC,CAAC;AACnF,OAAO,EAAE,OAAO,IAAI,eAAe,EAAE,MAAM,6BAA6B,CAAC;AAEzE,MAAM,CAAC,MAAM,kBAAkB,GAAc;IAC3C,OAAO,EAAE;QACP,EAAE,EAAE,qBAAqB;QACzB,KAAK,EAAE,gCAAgC;QACvC,WAAW,EACT,wIAAwI;QAC1I,UAAU,EAAE,CAAC;QACb,OAAO,EAAE,iBAAiB;QAC1B,QAAQ,EAAE,iBAAiB;KAC5B;IACD,QAAQ,EAAE;QACR,SAAS,EAAE,gCAAgC;QAC3C,KAAK,EAAE;YACL,EAAE,IAAI,EAAE,UAAU,EAAE,OAAO,EAAE,KAAK,EAAE;YACpC,EAAE,IAAI,EAAE,oBAAoB,EAAE,OAAO,EAAE,cAAc,EAAE;YACvD,EAAE,IAAI,EAAE,WAAW,EAAE,OAAO,EAAE,MAAM,EAAE;YACtC,EAAE,IAAI,EAAE,2BAA2B,EAAE,OAAO,EAAE,mBAAmB,EAAE;YACnE,EAAE,IAAI,EAAE,oCAAoC,EAAE,OAAO,EAAE,mBAAmB,EAAE;YAC5E,EAAE,IAAI,EAAE,sCAAsC,EAAE,OAAO,EAAE,qBAAqB,EAAE;YAChF,EAAE,IAAI,EAAE,yCAAyC,EAAE,OAAO,EAAE,uBAAuB,EAAE;YACrF,EAAE,IAAI,EAAE,mCAAmC,EAAE,OAAO,EAAE,kBAAkB,EAAE;YAC1E,EAAE,IAAI,EAAE,qCAAqC,EAAE,OAAO,EAAE,oBAAoB,EAAE;YAC9E,EAAE,IAAI,EAAE,gCAAgC,EAAE,OAAO,EAAE,eAAe,EAAE;SACrE;QACD,WAAW,EAAE,uEAAuE;KACrF;CACF,CAAC"}

package/dist/blueprints/index.d.ts

@@ -0,0 +1,3 @@
+import type { Blueprint, BlueprintCatalogEntry } from '../types.js';
+export declare function getCatalog(): BlueprintCatalogEntry[];
+export declare function getBlueprint(id: string): Blueprint | undefined;

package/dist/blueprints/index.js

@@ -0,0 +1,14 @@
+import { rfxProcurement } from './rfx-procurement/index.js';
+import { employeeOnboarding } from './employee-onboarding/index.js';
+const blueprints = [
+    rfxProcurement,
+    employeeOnboarding,
+];
+const blueprintMap = new Map(blueprints.map((bp) => [bp.catalog.id, bp]));
+export function getCatalog() {
+    return blueprints.map((bp) => bp.catalog);
+}
+export function getBlueprint(id) {
+    return blueprintMap.get(id);
+}
+//# sourceMappingURL=index.js.map

package/dist/blueprints/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/blueprints/index.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,cAAc,EAAE,MAAM,4BAA4B,CAAC;AAC5D,OAAO,EAAE,kBAAkB,EAAE,MAAM,gCAAgC,CAAC;AAEpE,MAAM,UAAU,GAAgB;IAC9B,cAAc;IACd,kBAAkB;CACnB,CAAC;AAEF,MAAM,YAAY,GAAG,IAAI,GAAG,CAC1B,UAAU,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC,EAAE,CAAC,OAAO,CAAC,EAAE,EAAE,EAAE,CAAC,CAAC,CAC5C,CAAC;AAEF,MAAM,UAAU,UAAU;IACxB,OAAO,UAAU,CAAC,GAAG,CAAC,CAAC,EAAE,EAAE,EAAE,CAAC,EAAE,CAAC,OAAO,CAAC,CAAC;AAC5C,CAAC;AAED,MAAM,UAAU,YAAY,CAAC,EAAU;IACrC,OAAO,YAAY,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC;AAC9B,CAAC"}

package/dist/blueprints/rfx-procurement/files/agent-specifications.d.ts

@@ -0,0 +1 @@
+export declare const content = "# Agent Specifications\n\nDetailed specifications for all 5 agents in the RFx Procurement Automation system. Each entry defines the agent's role, tools, data contracts, escalation conditions, and success metrics.\n\n---\n\n## 1. RFx Orchestrator\n\n- **Role:** Manager\n- **Type:** Orchestrator\n- **Phase:** 1\n\n### Responsibilities\n\n- Accept incoming RFx documents and classify them by type (RFP, RFQ, RFI).\n- Create and maintain a tracking record for each RFx through its full lifecycle.\n- Route tasks to the appropriate worker agents based on the current stage of processing.\n- Enforce approval gates at configured checkpoints (e.g., before response submission).\n- Monitor task completion, enforce timeouts, and handle retries and escalations.\n\n### Tools\n\n#### assign_rfx_task\n\nAssigns a specific task to a worker agent. Creates a task record linked to the RFx tracking record.\n\n- **Inputs:** `rfx_id` (string), `target_agent` (string, one of: requirements_analyzer, content_library_matcher, response_composer, compliance_validator), `task_type` (string, e.g., \"extract_requirements\", \"match_content\", \"compose_response\", \"validate_compliance\"), `payload` (object, task-specific data including relevant document content or prior stage outputs).\n- **Outputs:** `task_id` (string), `status` (\"assigned\"), `assigned_at` (ISO-8601 timestamp).\n\n#### check_completion_status\n\nChecks the current status of all tasks for a given RFx.\n\n- **Inputs:** `rfx_id` (string).\n- **Outputs:** `rfx_id` (string), `overall_status` (string: \"intake\", \"requirements_extracted\", \"content_matched\", \"response_drafted\", \"compliance_validated\", \"pending_approval\", \"submitted\", \"failed\"), `tasks` (array of objects with `task_id`, `agent`, `status`, `completed_at`, `error` if applicable).\n\n#### enforce_approval_gate\n\nTriggers a human approval checkpoint. Pauses processing until approval is received or the request is rejected.\n\n- **Inputs:** `rfx_id` (string), `gate_type` (string: \"phase1_exit\", \"response_review\", \"final_submission\"), `artifacts` (array of objects describing what the approver should review, each with `type` and `content_reference`).\n- **Outputs:** `gate_id` (string), `status` (\"pending_approval\"), `approvers` (array of strings, stakeholder identifiers), `requested_at` (ISO-8601 timestamp).\n\n#### notify_stakeholders\n\nSends a notification to relevant stakeholders about RFx status changes, approaching deadlines, or required actions.\n\n- **Inputs:** `rfx_id` (string), `notification_type` (string: \"status_update\", \"deadline_warning\", \"approval_required\", \"escalation\"), `recipients` (array of strings), `message` (string).\n- **Outputs:** `notification_id` (string), `sent_at` (ISO-8601 timestamp), `delivery_status` (string).\n\n### Input Contract\n\nThe Orchestrator receives raw RFx documents (PDF, DOCX, or plain text) along with metadata: `source_channel` (where the document came from), `received_at` (timestamp), `submitting_organization` (if known), and `priority` (optional override).\n\n### Output Contract\n\nThe Orchestrator produces a complete RFx tracking record including: classification, extracted requirements (from Requirements Analyzer), matched content (from Content Library Matcher), draft responses (from Response Composer), compliance report (from Compliance Validator), approval status, and audit log of all actions taken.\n\n### Escalation Conditions\n\n- Any worker fails twice on the same task.\n- A deadline conflict is detected (submission deadline is within 48 hours and processing is incomplete).\n- An approval gate is rejected by a reviewer.\n- The RFx document cannot be classified (unknown format or type).\n\n### Success Metrics\n\n- **Routing accuracy:** > 95% of tasks assigned to the correct worker on the first attempt.\n- **End-to-end cycle time:** Total processing time from intake to draft-ready is measurable and decreasing over time.\n- **Zero dropped RFx documents:** Every document that enters the system has a tracking record and reaches a terminal state.\n\n---\n\n## 2. Requirements Analyzer\n\n- **Role:** Worker\n- **Type:** Specialist\n- **Phase:** 1\n\n### Responsibilities\n\n- Parse RFx documents in multiple formats (PDF, DOCX, plain text) into structured content.\n- Extract individual requirements from document text, including nested and conditional requirements.\n- Categorize each requirement as mandatory, scored, or informational.\n- Identify all deadlines, milestones, and time-bound constraints.\n- Flag ambiguous or contradictory requirements for human review.\n\n### Tools\n\n#### parse_rfx_document\n\nConverts a raw RFx document into structured sections and paragraphs for downstream processing.\n\n- **Inputs:** `document_content` (string or binary reference), `document_format` (string: \"pdf\", \"docx\", \"txt\", \"html\"), `document_type` (string: \"rfp\", \"rfq\", \"rfi\" if known, or \"unknown\").\n- **Outputs:** `parsed_document` (object with `sections` array, each containing `section_number`, `title`, `content`, `subsections`), `metadata` (object with `page_count`, `word_count`, `detected_type`, `issuing_organization`), `parse_confidence` (number 0-1).\n\n#### extract_requirements\n\nIdentifies and extracts individual requirements from parsed document sections.\n\n- **Inputs:** `parsed_sections` (array of section objects from parse_rfx_document output), `extraction_rules` (optional object with custom keyword patterns or section hints).\n- **Outputs:** `requirements` (array of objects, each with `requirement_id`, `text`, `source_section`, `source_page`, `keywords` array, `confidence` score 0-1).\n\n#### categorize_requirements\n\nClassifies extracted requirements by type and priority.\n\n- **Inputs:** `requirements` (array of requirement objects from extract_requirements output).\n- **Outputs:** `categorized_requirements` (array of objects extending each requirement with `category` (string: \"mandatory\", \"scored\", \"informational\"), `priority` (string: \"critical\", \"high\", \"medium\", \"low\"), `evaluation_weight` (number, if stated in the document), `categorization_confidence` (number 0-1)).\n\n#### identify_deadlines\n\nExtracts all time-bound constraints from the document.\n\n- **Inputs:** `parsed_document` (object from parse_rfx_document), `reference_date` (ISO-8601, typically the document receipt date for calculating relative deadlines).\n- **Outputs:** `deadlines` (array of objects, each with `deadline_type` (string: \"submission\", \"questions_due\", \"site_visit\", \"notification\", \"other\"), `date` (ISO-8601), `description` (string), `source_section` (string), `is_mandatory` (boolean)).\n\n### Input Contract\n\nReceives a raw RFx document (content or reference) and its format. May also receive optional extraction hints from the Orchestrator based on the document type classification.\n\n### Output Contract\n\nReturns structured data: parsed document sections, extracted and categorized requirements, and identified deadlines. All outputs include confidence scores. Requirements with confidence below 0.7 are flagged for human review.\n\n### Escalation Conditions\n\n- Document parse confidence falls below 0.6 (heavily formatted, scanned image, or corrupted file).\n- More than 20% of extracted requirements have categorization confidence below 0.7.\n- Contradictory requirements detected (e.g., two mutually exclusive mandatory conditions).\n- Document contains embedded files or references to external documents that cannot be resolved.\n\n### Success Metrics\n\n- **Extraction recall:** > 95% of requirements identified compared to human baseline.\n- **Categorization accuracy:** > 90% of requirements correctly categorized (mandatory/scored/informational).\n- **Deadline identification:** 100% of submission deadlines correctly extracted.\n\n---\n\n## 3. Content Library Matcher\n\n- **Role:** Worker\n- **Type:** Specialist\n- **Phase:** 2\n\n### Responsibilities\n\n- Search organizational knowledge bases for content relevant to each extracted requirement.\n- Score the relevance of matched content against specific requirement text.\n- Identify content gaps where no existing material adequately addresses a requirement.\n- Track content freshness and flag stale matches that may need SME review.\n\n### Tools\n\n#### search_knowledge_base\n\nPerforms semantic and keyword search across configured content repositories.\n\n- **Inputs:** `query` (string, the requirement text or a derived search query), `filters` (optional object with `content_type` array, `max_age_days` number, `source_repository` string), `max_results` (number, default 10).\n- **Outputs:** `results` (array of objects, each with `content_id`, `title`, `snippet` (relevant excerpt), `source` (repository name and path), `last_updated` (ISO-8601), `content_type` (string: \"previous_response\", \"policy_document\", \"technical_spec\", \"marketing_material\")).\n\n#### score_content_relevance\n\nEvaluates how well a piece of content addresses a specific requirement.\n\n- **Inputs:** `requirement` (object with `requirement_id`, `text`, `category`), `content_candidates` (array of content objects from search results).\n- **Outputs:** `scored_matches` (array of objects, each with `content_id`, `relevance_score` (number 0-100), `coverage_assessment` (string: \"full\", \"partial\", \"tangential\"), `reuse_recommendation` (string: \"use_as_is\", \"adapt\", \"reference_only\"), `staleness_flag` (boolean, true if content is older than 12 months)).\n\n#### identify_content_gaps\n\nAnalyzes the set of requirements against available content matches to find gaps.\n\n- **Inputs:** `requirements` (array of categorized requirement objects), `matches` (array of scored match results, keyed by requirement_id).\n- **Outputs:** `gaps` (array of objects, each with `requirement_id`, `gap_type` (string: \"no_match\", \"low_relevance\", \"stale_only\", \"partial_coverage\"), `recommended_action` (string: \"generate_new\", \"request_sme_input\", \"adapt_partial_match\"), `priority` (string based on requirement category and evaluation weight)).\n\n### Input Contract\n\nReceives categorized requirements from the Requirements Analyzer (via the Orchestrator). Needs access to configured knowledge base endpoints.\n\n### Output Contract\n\nReturns a mapping of requirements to content matches with relevance scores, plus a gap analysis identifying requirements that need original content or SME input.\n\n### Escalation Conditions\n\n- Knowledge base connection fails or returns errors.\n- More than 50% of mandatory requirements have no match above relevance score 60.\n- Content freshness check reveals the majority of top matches are older than 18 months.\n\n### Success Metrics\n\n- **Average relevance score:** > 80% for top match per requirement.\n- **Gap identification accuracy:** > 90% agreement with human assessment of content coverage.\n- **Search latency:** < 5 seconds per requirement query.\n\n---\n\n## 4. Response Composer\n\n- **Role:** Worker\n- **Type:** Specialist\n- **Phase:** 2\n\n### Responsibilities\n\n- Assemble draft responses from matched content, adapting tone and structure to match the RFx requirements.\n- Generate new content for requirements where no adequate existing content was found.\n- Maintain consistent formatting, voice, and structure across all response sections.\n- Flag all generated (non-reused) content for mandatory SME review.\n\n### Tools\n\n#### assemble_response_draft\n\nCombines matched content into a structured response for a set of requirements.\n\n- **Inputs:** `requirements` (array of requirement objects with their matched content), `response_structure` (object defining section order, numbering scheme, and formatting rules from the RFx), `tone_guidelines` (optional object with `formality_level`, `voice`, `prohibited_terms`).\n- **Outputs:** `draft_response` (object with `sections` array, each containing `section_id`, `requirement_ids` addressed, `content` (assembled text), `content_sources` (array of content_ids used), `is_generated` (boolean, false for reused content), `confidence` (number 0-1)).\n\n#### generate_gap_content\n\nCreates original content for requirements where no suitable existing content was found.\n\n- **Inputs:** `requirement` (object with full requirement details), `context` (object with `organization_profile` if available, `related_content` array of tangentially relevant matches, `gap_type` from Content Library Matcher).\n- **Outputs:** `generated_content` (object with `text`, `confidence` (number 0-1), `requires_sme_review` (always true for generated content), `review_notes` (string describing what the SME should verify), `sources_referenced` (array of content_ids used as context)).\n\n#### format_response_document\n\nApplies formatting rules from the RFx to the assembled draft.\n\n- **Inputs:** `draft_sections` (array of section objects from assemble_response_draft), `formatting_rules` (object with `page_limit`, `font_requirements`, `margin_requirements`, `section_numbering_scheme`, `required_appendices`).\n- **Outputs:** `formatted_document` (object with `sections` array with formatting applied, `total_pages` (estimated), `formatting_warnings` (array of strings describing any rule violations, e.g., \"Section 3 exceeds recommended length by 200 words\")).\n\n### Input Contract\n\nReceives requirement-to-content mappings and gap analysis from the Content Library Matcher (via Orchestrator). Also receives formatting rules extracted by the Requirements Analyzer.\n\n### Output Contract\n\nReturns a complete draft response document with clear tracking of which content is reused vs. generated. All generated content is flagged for SME review. Formatting warnings are included for any rule violations.\n\n### Escalation Conditions\n\n- More than 30% of the response consists of generated (non-reused) content. This indicates a significant knowledge base gap.\n- Formatting rules cannot be satisfied (e.g., response exceeds page limit even after condensing).\n- Contradictory formatting requirements are detected.\n\n### Success Metrics\n\n- **Response completeness:** 100% of mandatory requirements have a corresponding response section.\n- **Content reuse rate:** > 60% of response content sourced from existing library (higher is better, indicates library health).\n- **Formatting compliance:** Zero formatting rule violations in final output.\n\n---\n\n## 5. Compliance Validator\n\n- **Role:** Worker\n- **Type:** Specialist\n- **Phase:** 2\n\n### Responsibilities\n\n- Cross-check every response section against the full set of mandatory requirements.\n- Validate that formatting rules (page limits, font, margins, section structure) are met.\n- Flag incomplete, non-responsive, or ambiguous response sections.\n- Produce a compliance report summarizing pass/fail status for every requirement and formatting rule.\n\n### Tools\n\n#### validate_mandatory_requirements\n\nChecks that every mandatory requirement has a corresponding response that substantively addresses it.\n\n- **Inputs:** `mandatory_requirements` (array of requirement objects where category is \"mandatory\"), `response_sections` (array of draft response sections with their addressed requirement_ids).\n- **Outputs:** `validation_results` (array of objects, each with `requirement_id`, `status` (string: \"addressed\", \"partially_addressed\", \"not_addressed\", \"non_responsive\"), `matched_section_id` (string or null), `assessment_notes` (string describing any concerns), `confidence` (number 0-1)).\n\n#### check_formatting_rules\n\nValidates the formatted document against all formatting requirements specified in the RFx.\n\n- **Inputs:** `formatted_document` (object from Response Composer), `formatting_rules` (object with all extracted formatting requirements).\n- **Outputs:** `formatting_compliance` (object with `overall_status` (string: \"compliant\", \"non_compliant\", \"warnings\"), `checks` (array of objects, each with `rule` (string), `status` (string: \"pass\", \"fail\", \"warning\"), `details` (string))).\n\n#### flag_incomplete_sections\n\nIdentifies response sections that are incomplete, vague, or non-responsive to their target requirements.\n\n- **Inputs:** `response_sections` (array of draft response sections), `requirements` (array of all requirements with categories).\n- **Outputs:** `flags` (array of objects, each with `section_id`, `requirement_id`, `flag_type` (string: \"incomplete\", \"vague\", \"non_responsive\", \"placeholder_detected\", \"unsubstantiated_claim\"), `severity` (string: \"blocking\", \"warning\"), `description` (string), `recommended_action` (string)).\n\n### Input Contract\n\nReceives the formatted draft response from the Response Composer (via Orchestrator), the full set of categorized requirements from the Requirements Analyzer, and the formatting rules.\n\n### Output Contract\n\nReturns a comprehensive compliance report with: per-requirement validation status, formatting compliance results, and flagged sections with severity and recommended actions. Any \"blocking\" flags prevent the response from proceeding to human approval without remediation.\n\n### Escalation Conditions\n\n- Any mandatory requirement has status \"not_addressed.\"\n- Formatting compliance overall status is \"non_compliant\" and cannot be remediated automatically.\n- More than 3 sections flagged as \"non_responsive.\"\n\n### Success Metrics\n\n- **Compliance check accuracy:** > 98% agreement with human compliance review.\n- **False negative rate:** < 1% (missed compliance issues that a human reviewer catches).\n- **Validation throughput:** Complete validation of a full RFx response in under 10 minutes.\n";