@agent-blueprint/free-blueprints 1.0.0

package/dist/blueprints/employee-onboarding/files/business-context.js

@@ -0,0 +1,107 @@
+export const content = `# Business Context
+
+The business problem, current state pain points, and target outcomes for Employee Onboarding Automation.
+
+---
+
+## The Onboarding Challenge
+
+Employee onboarding sits at the intersection of HR, IT, legal, and operations. It touches more systems and more people than almost any other recurring business process. And it happens every time someone is hired, which for growing companies means constantly.
+
+The fundamental challenge: onboarding requires coordinating dozens of tasks across multiple departments, each with different systems, different timelines, and different owners. No single person or team has visibility into the full picture. Things fall through the cracks because the process depends on manual handoffs, tribal knowledge, and individual diligence.
+
+**Scale makes it worse, not better.** A company hiring 10 people per quarter can handle onboarding with spreadsheets and personal attention. A company hiring 50 or 100 cannot. The process that worked at 200 employees breaks at 500 and is unmanageable at 2,000.
+
+---
+
+## Current State Pain Points
+
+These are the problems that exist in most organizations before automation. Not all will apply to every company, but most companies experience at least three of the five.
+
+### Manual Checklists
+
+Onboarding tasks are tracked in spreadsheets, wikis, or email threads. Each new hire gets a copy of the checklist. Someone (HR generalist, hiring manager, or office coordinator) manually checks off items as they are completed. Items get missed. Different people follow different versions of the checklist. There is no real-time visibility into where things stand.
+
+### Tribal Knowledge
+
+"Ask Sarah in IT to set up the VPN" and "Make sure you CC finance on the laptop request." Critical process steps live in people's heads, not in systems. When those people are on vacation, busy, or leave the company, steps get skipped. New HR team members take months to learn all the informal procedures.
+
+### Delayed Provisioning
+
+IT provisioning is the most common bottleneck. Account creation requires tickets to multiple teams. Hardware procurement has lead times. Software licenses require budget approval. The result: new hires show up on Day 1 and cannot log in, do not have a laptop, or do not have access to the tools they need. They sit idle while IT catches up. First impressions are terrible.
+
+### Inconsistent Experience
+
+Onboarding quality varies wildly depending on who handles it. Some hiring managers plan structured first weeks with introductions, training, and mentorship. Others hand the new hire a laptop and say "let me know if you have questions." This inconsistency affects retention: employees who have a poor onboarding experience are 2x more likely to look for a new job within the first year.
+
+### Compliance Risk
+
+Tax forms, I-9 verification, mandatory training, and policy acknowledgments have legal deadlines. Manual processes miss them because:
+
+- Reminders are sent by people who forget
+- Tracking is in spreadsheets that nobody updates
+- Responsibility is split across HR, legal, and hiring managers with no clear owner
+- The consequences of missing a deadline are invisible until an audit surfaces them
+
+---
+
+## Impact of Poor Onboarding
+
+### Employee Turnover
+
+Employees who report a negative onboarding experience are 2x more likely to seek a new opportunity within 12 months. At an average replacement cost of 50-200% of annual salary (depending on role seniority), this is the most expensive consequence of bad onboarding.
+
+### Time-to-Productive
+
+The longer it takes a new hire to get fully set up and trained, the longer the company waits for return on its hiring investment. For technical roles with 3-6 month ramp times, even a 2-week delay in onboarding has measurable productivity impact.
+
+### Compliance Exposure
+
+Missed I-9 deadlines: fines range from $252 to $2,507 per violation for first offenses (US). Missed tax form processing: payroll errors and IRS penalties. Missed mandatory training: liability exposure for harassment, safety, and data privacy incidents.
+
+### Manager and HR Burden
+
+Every hour a hiring manager spends chasing IT tickets, filling out forms, and sending reminder emails is an hour they are not spending on their actual job. HR generalists managing 20+ concurrent onboardings spend the majority of their time on administrative coordination rather than strategic work.
+
+---
+
+## Industry Benchmarks
+
+These are representative benchmarks from published HR research. Use them as reference points, not absolute targets.
+
+| Metric | Typical | Good | Best-in-Class |
+|--------|---------|------|---------------|
+| Time to full productivity | 8-12 weeks | 4-8 weeks | 2-4 weeks |
+| Onboarding satisfaction (NPS) | 10-30 | 30-50 | 50-80 |
+| Day 1 IT readiness | 40-60% | 70-85% | 90-99% |
+| Compliance completion within 30 days | 65-80% | 85-95% | 98-100% |
+| First-year voluntary turnover | 20-30% | 12-18% | 5-10% |
+| HR hours per onboarding | 10-20 hours | 5-10 hours | 2-4 hours |
+
+Sources vary by industry and company size. Measure your own baseline before comparing to benchmarks.
+
+---
+
+## Target Outcomes
+
+What the automated system should achieve, expressed as improvements over the current manual process.
+
+### Primary Outcomes
+
+1. **Reduce time-to-productive by 30% or more.** Parallel execution of provisioning, document collection, and training eliminates the sequential bottlenecks that delay manual onboarding.
+
+2. **Achieve 100% compliance completion within 30 days.** Automated tracking with escalation ensures no compliance item is forgotten or delayed past its deadline.
+
+3. **Deliver Day 1 readiness for 95%+ of new hires.** Automated IT provisioning triggered immediately on hire confirmation means accounts, hardware, and software are ready before the employee arrives.
+
+4. **Eliminate manual tracking overhead.** HR generalists and hiring managers stop spending time on spreadsheets, reminder emails, and status check meetings. The system tracks everything and reports proactively.
+
+### Secondary Outcomes
+
+5. **Consistent experience regardless of location, department, or manager.** Every new hire goes through the same structured, complete onboarding process. Quality does not depend on individual diligence.
+
+6. **Onboarding NPS above 60.** A smooth, fast onboarding experience is one of the strongest signals a new hire receives about the company's competence and culture.
+
+7. **Reusable patterns for offboarding and transfers.** The orchestration pattern, integration infrastructure, and agent architecture built for onboarding directly apply to employee offboarding (reverse provisioning) and internal transfers (delta provisioning).
+`;
+//# sourceMappingURL=business-context.js.map

package/dist/blueprints/employee-onboarding/files/business-context.js.map

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

package/dist/blueprints/employee-onboarding/files/evaluation-criteria.d.ts

@@ -0,0 +1 @@
+export declare const content = "# Evaluation Criteria\n\nSpecific metrics, targets, and measurement methodologies for validating the Employee Onboarding Automation system.\n\n---\n\n## Document Processing Accuracy\n\n**Target:** > 98% first-pass completion rate\n\n**Definition:** The percentage of submitted documents that are correctly validated on the first attempt without requiring human intervention or resubmission.\n\n**Measurement methodology:**\n- Numerator: documents that pass validation on first submission and require no subsequent correction\n- Denominator: total documents submitted\n- Measurement period: rolling 30 days\n- Exclude: documents rejected due to genuinely incorrect submissions by the new hire (wrong form, missing signature). Count only system errors (valid document incorrectly rejected, invalid document incorrectly accepted).\n\n**Baseline:** Measure the current manual process error rate before automation. Typical manual processes see 15-25% of documents requiring follow-up due to missing fields, wrong forms, or processing errors.\n\n---\n\n## Time-to-Productive\n\n**Target:** > 30% reduction vs. manual baseline\n\n**Definition:** The elapsed time from a new hire's official start date to the date they have all accounts, access, equipment, training, and documentation complete. \"Productive\" means no outstanding onboarding blockers preventing the hire from doing their job.\n\n**Measurement methodology:**\n- Start: employee's official start date in the HR system\n- End: date when the onboarding case reaches \"complete\" status (all tasks resolved, compliance verified)\n- Compare: average time-to-productive for automated onboardings vs. average for the last 6 months of manual onboardings\n- Segment by: role type, department, office location, remote vs. onsite (these variables significantly affect onboarding complexity)\n\n**Baseline:** Survey hiring managers and HR to establish the current average. Typical ranges: 1-2 weeks for simple roles, 3-6 weeks for complex technical roles.\n\n---\n\n## IT Provisioning Speed (Day 1 Readiness)\n\n**Target:** > 95% of new hires have all IT resources ready on Day 1\n\n**Definition:** On the new hire's first day, they can log in to all required systems, their hardware is physically present (or shipped for remote), and their software is installed or accessible.\n\n**Measurement methodology:**\n- Check each new hire's IT provisioning status at 9 AM on their start date\n- \"Ready\" means: all accounts active, all permissions applied, hardware delivered, software licenses assigned\n- \"Not ready\" means: any IT provisioning task still incomplete\n- Report the percentage of new hires at \"ready\" status\n\n**Breakdown tracking:**\n- Account creation readiness (target: 99%)\n- Hardware delivery readiness (target: 90%, lower due to shipping variability)\n- Software license assignment (target: 98%)\n- Access permissions applied (target: 97%)\n\n**Baseline:** Audit the last 20 onboardings. For each, check how many had all IT resources on Day 1. Typical baseline: 40-60%.\n\n---\n\n## Training Path Relevance\n\n**Target:** > 85% employee satisfaction score\n\n**Definition:** New hires rate the relevance and usefulness of their assigned training path. Measured via survey at Day 30.\n\n**Measurement methodology:**\n- Survey question: \"How relevant was your assigned training to your actual role?\" (1-5 scale)\n- Survey question: \"Did your training prepare you for your day-to-day work?\" (1-5 scale)\n- Survey question: \"Was anything missing from your training that you needed?\" (free text)\n- Score = average of the two numerical questions, converted to percentage (e.g., 4.3/5 = 86%)\n- Minimum sample size: 15 completed surveys before reporting the metric\n\n**Segmentation:** Break down by department and role to identify where training paths need improvement. A low score in one department may indicate missing department-specific content, not a system-wide problem.\n\n**Baseline:** If the organization currently surveys onboarding satisfaction, use that. If not, the first cohort of automated onboardings becomes the baseline for future comparison.\n\n---\n\n## Compliance Completion Rate\n\n**Target:** 100% within first 30 days\n\n**Definition:** All mandatory compliance training modules and required documentation completed within 30 calendar days of the hire's start date.\n\n**Measurement methodology:**\n- For each new hire, check completion status of all compliance-flagged items at Day 30\n- Compliance items include: anti-harassment training, security awareness training, data privacy training, I-9 completion, tax form processing, NDA execution\n- 100% means every hire completed every required compliance item. One missed item for one hire means the target is not met.\n- Track which specific items are most commonly delayed to identify systemic issues\n\n**Escalation trigger:** If any compliance item is incomplete at Day 20, the Progress Tracker escalates to the hiring manager and HR. This gives 10 days of buffer before the hard deadline.\n\n**Baseline:** Pull the last 6 months of compliance training records. Calculate the percentage completed within 30 days. Typical baseline: 70-85%.\n\n---\n\n## Onboarding NPS\n\n**Target:** > 60\n\n**Definition:** Net Promoter Score measuring new hire satisfaction with the overall onboarding experience.\n\n**Measurement methodology:**\n- Survey question at Day 30: \"How likely are you to recommend this company's onboarding experience to a friend joining the company?\" (0-10 scale)\n- NPS = % Promoters (9-10) minus % Detractors (0-6)\n- Minimum sample size: 20 responses before reporting\n- Also collect: \"What was the best part of your onboarding?\" and \"What would you improve?\" (free text)\n\n**Interpretation:** NPS is a lagging indicator that reflects the overall experience, not just the automation. A high NPS with low training relevance scores, for example, suggests the automation is working well but training content needs attention.\n\n**Baseline:** If the organization tracks onboarding NPS, use the current number. Industry benchmarks: average onboarding NPS is 20-40. Top performers reach 60-80.\n\n---\n\n## Operational Metrics (Non-Target, Track for Diagnostics)\n\nThese metrics do not have pass/fail targets but should be tracked to diagnose issues and optimize the system:\n\n- **Average tasks per onboarding case:** Tracks complexity. Rising numbers may indicate scope creep or unnecessary tasks.\n- **Escalation rate:** Percentage of tasks that require human escalation. Should decrease over time as the system handles more edge cases.\n- **Reminder-to-action conversion rate:** Percentage of reminders that result in the recipient completing the action. Low rates indicate reminder fatigue or poor targeting.\n- **Agent processing time per task:** How long each agent takes to complete its tasks. Identifies bottlenecks.\n- **Integration error rate:** Percentage of API calls to external systems that fail. Identifies unreliable integrations.\n";

package/dist/blueprints/employee-onboarding/files/evaluation-criteria.js

@@ -0,0 +1,126 @@
+export const content = `# Evaluation Criteria
+
+Specific metrics, targets, and measurement methodologies for validating the Employee Onboarding Automation system.
+
+---
+
+## Document Processing Accuracy
+
+**Target:** > 98% first-pass completion rate
+
+**Definition:** The percentage of submitted documents that are correctly validated on the first attempt without requiring human intervention or resubmission.
+
+**Measurement methodology:**
+- Numerator: documents that pass validation on first submission and require no subsequent correction
+- Denominator: total documents submitted
+- Measurement period: rolling 30 days
+- Exclude: documents rejected due to genuinely incorrect submissions by the new hire (wrong form, missing signature). Count only system errors (valid document incorrectly rejected, invalid document incorrectly accepted).
+
+**Baseline:** Measure the current manual process error rate before automation. Typical manual processes see 15-25% of documents requiring follow-up due to missing fields, wrong forms, or processing errors.
+
+---
+
+## Time-to-Productive
+
+**Target:** > 30% reduction vs. manual baseline
+
+**Definition:** The elapsed time from a new hire's official start date to the date they have all accounts, access, equipment, training, and documentation complete. "Productive" means no outstanding onboarding blockers preventing the hire from doing their job.
+
+**Measurement methodology:**
+- Start: employee's official start date in the HR system
+- End: date when the onboarding case reaches "complete" status (all tasks resolved, compliance verified)
+- Compare: average time-to-productive for automated onboardings vs. average for the last 6 months of manual onboardings
+- Segment by: role type, department, office location, remote vs. onsite (these variables significantly affect onboarding complexity)
+
+**Baseline:** Survey hiring managers and HR to establish the current average. Typical ranges: 1-2 weeks for simple roles, 3-6 weeks for complex technical roles.
+
+---
+
+## IT Provisioning Speed (Day 1 Readiness)
+
+**Target:** > 95% of new hires have all IT resources ready on Day 1
+
+**Definition:** On the new hire's first day, they can log in to all required systems, their hardware is physically present (or shipped for remote), and their software is installed or accessible.
+
+**Measurement methodology:**
+- Check each new hire's IT provisioning status at 9 AM on their start date
+- "Ready" means: all accounts active, all permissions applied, hardware delivered, software licenses assigned
+- "Not ready" means: any IT provisioning task still incomplete
+- Report the percentage of new hires at "ready" status
+
+**Breakdown tracking:**
+- Account creation readiness (target: 99%)
+- Hardware delivery readiness (target: 90%, lower due to shipping variability)
+- Software license assignment (target: 98%)
+- Access permissions applied (target: 97%)
+
+**Baseline:** Audit the last 20 onboardings. For each, check how many had all IT resources on Day 1. Typical baseline: 40-60%.
+
+---
+
+## Training Path Relevance
+
+**Target:** > 85% employee satisfaction score
+
+**Definition:** New hires rate the relevance and usefulness of their assigned training path. Measured via survey at Day 30.
+
+**Measurement methodology:**
+- Survey question: "How relevant was your assigned training to your actual role?" (1-5 scale)
+- Survey question: "Did your training prepare you for your day-to-day work?" (1-5 scale)
+- Survey question: "Was anything missing from your training that you needed?" (free text)
+- Score = average of the two numerical questions, converted to percentage (e.g., 4.3/5 = 86%)
+- Minimum sample size: 15 completed surveys before reporting the metric
+
+**Segmentation:** Break down by department and role to identify where training paths need improvement. A low score in one department may indicate missing department-specific content, not a system-wide problem.
+
+**Baseline:** If the organization currently surveys onboarding satisfaction, use that. If not, the first cohort of automated onboardings becomes the baseline for future comparison.
+
+---
+
+## Compliance Completion Rate
+
+**Target:** 100% within first 30 days
+
+**Definition:** All mandatory compliance training modules and required documentation completed within 30 calendar days of the hire's start date.
+
+**Measurement methodology:**
+- For each new hire, check completion status of all compliance-flagged items at Day 30
+- Compliance items include: anti-harassment training, security awareness training, data privacy training, I-9 completion, tax form processing, NDA execution
+- 100% means every hire completed every required compliance item. One missed item for one hire means the target is not met.
+- Track which specific items are most commonly delayed to identify systemic issues
+
+**Escalation trigger:** If any compliance item is incomplete at Day 20, the Progress Tracker escalates to the hiring manager and HR. This gives 10 days of buffer before the hard deadline.
+
+**Baseline:** Pull the last 6 months of compliance training records. Calculate the percentage completed within 30 days. Typical baseline: 70-85%.
+
+---
+
+## Onboarding NPS
+
+**Target:** > 60
+
+**Definition:** Net Promoter Score measuring new hire satisfaction with the overall onboarding experience.
+
+**Measurement methodology:**
+- Survey question at Day 30: "How likely are you to recommend this company's onboarding experience to a friend joining the company?" (0-10 scale)
+- NPS = % Promoters (9-10) minus % Detractors (0-6)
+- Minimum sample size: 20 responses before reporting
+- Also collect: "What was the best part of your onboarding?" and "What would you improve?" (free text)
+
+**Interpretation:** NPS is a lagging indicator that reflects the overall experience, not just the automation. A high NPS with low training relevance scores, for example, suggests the automation is working well but training content needs attention.
+
+**Baseline:** If the organization tracks onboarding NPS, use the current number. Industry benchmarks: average onboarding NPS is 20-40. Top performers reach 60-80.
+
+---
+
+## Operational Metrics (Non-Target, Track for Diagnostics)
+
+These metrics do not have pass/fail targets but should be tracked to diagnose issues and optimize the system:
+
+- **Average tasks per onboarding case:** Tracks complexity. Rising numbers may indicate scope creep or unnecessary tasks.
+- **Escalation rate:** Percentage of tasks that require human escalation. Should decrease over time as the system handles more edge cases.
+- **Reminder-to-action conversion rate:** Percentage of reminders that result in the recipient completing the action. Low rates indicate reminder fatigue or poor targeting.
+- **Agent processing time per task:** How long each agent takes to complete its tasks. Identifies bottlenecks.
+- **Integration error rate:** Percentage of API calls to external systems that fail. Identifies unreliable integrations.
+`;
+//# sourceMappingURL=evaluation-criteria.js.map

package/dist/blueprints/employee-onboarding/files/evaluation-criteria.js.map

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

package/dist/blueprints/employee-onboarding/files/getting-started.d.ts

@@ -0,0 +1 @@
+export declare const content = "# Getting Started\n\n**YOU ARE THE IMPLEMENTER.** This blueprint is your specification. You are a coding agent building employee onboarding automation for an organization. The spec tells you what to build. You decide how to build it on whatever platform you are working with.\n\n## Ground Rules\n\n- **Do not summarize this document back to the user.** Read it, internalize it, act on it.\n- **Do not ask unnecessary questions.** If the spec provides enough information to proceed, proceed. Ask only when you genuinely cannot infer the answer.\n- **Act, then report.** Build the thing first. Explain what you built after.\n- **Be decisive.** When the spec gives you a choice, make it. Do not present options and wait. Pick the best one and move.\n- **Verify before presenting.** Test your work programmatically. Do not hand the user something you have not validated.\n\n## Step 1: Understand the Architecture\n\nRead these files in order:\n\n1. `SKILL.md` - Architecture overview, phasing, agent summary\n2. `references/agent-specifications.md` - Detailed agent definitions, tools, data contracts, success metrics\n3. `references/architecture-decisions.md` - Why this architecture, why these trade-offs\n4. `references/guardrails-and-governance.md` - Risk categories, escalation rules, PII handling\n5. `references/platform-connectivity.md` - Integration points and patterns\n\nDo not skim. These files contain specific tool definitions, data contracts, and escalation rules that you will implement directly.\n\n## Step 2: Connect to the Target Platform\n\nYou are in one of three scenarios:\n\n### A) Platform is ready and accessible\n\nYou have credentials, API access, or an SDK for the target platform (HR system, IT service management, workflow engine). Connect to it. Read its schema. Map the blueprint's agent definitions to the platform's native constructs.\n\n### B) Building on custom code\n\nNo enterprise platform. You are building agents in code (Python, TypeScript, etc.) with direct API integrations. Use the agent specifications as your class/module definitions. Implement tools as functions. Wire up the orchestrator as the entry point.\n\n### C) Unsure what platform to use\n\nRead `references/platform-connectivity.md` for the integration categories you will need. Pick a platform or stack that covers HR system integration, identity management, document management, IT service management, and a learning management system. Or build incrementally: start with the pilot (orchestrator + document processor) and expand your platform choices as you learn.\n\nRegardless of scenario: the orchestrator is triggered by a new-hire event from the HR system. That integration is your first technical task.\n\n## Step 3: Build and Validate the Pilot\n\nFollow the phased approach. Do not build all five agents at once.\n\n### Phase A: Scaffold the orchestration\n\n1. Implement the Onboarding Orchestrator with its four tools: `create_onboarding_case`, `assign_task`, `check_milestone_status`, `escalate_blocker`.\n2. Implement the Document Processor with its four tools: `collect_document`, `validate_document`, `process_tax_forms`, `verify_identity`.\n3. Wire the orchestrator to receive new-hire events and delegate document collection to the Document Processor.\n4. Implement the message format and retry policy defined in `AGENTS.md`.\n\n### Phase B: Make the pilot real\n\n1. Connect to actual data sources: HR system for new-hire records, document storage for form templates, e-signature service for collection.\n2. Run a test onboarding end-to-end. Verify every document type is collected, validated, and stored correctly.\n3. Verify escalation works: simulate a failed identity verification and confirm it routes to a human reviewer.\n4. Measure against the pilot decision gate criteria in `SKILL.md`.\n\n### Phase C: Expand to full implementation\n\nOnce the pilot passes its decision gate:\n\n1. Add the IT Provisioning Coordinator. Test account creation, hardware assignment, and access provisioning independently before connecting to the orchestrator.\n2. Add the Training Curriculum Assembler. Verify it generates role-appropriate training paths.\n3. Add the Progress Tracker. Verify milestone monitoring, at-risk detection, and reporting.\n4. Run a full end-to-end onboarding with all five agents active.\n\n## Step 4: Validate\n\nTest programmatically against the metrics in `references/evaluation-criteria.md`:\n\n- Document processing accuracy (target: > 98% first-pass completion)\n- Time-to-productive reduction (target: > 30% vs. manual baseline)\n- IT provisioning Day 1 readiness (target: > 95% of new hires)\n- Compliance completion within 30 days (target: 100%)\n\nDo not eyeball these. Write tests. Measure against real or realistic data. If a metric falls short, diagnose and fix before moving on.\n\n## Step 5: Track Progress\n\nUpdate `implementation-state.yaml` as you complete each agent and integration. This file is your build progress record. Keep it current so that anyone (human or agent) picking up this project knows exactly where things stand.\n\n---\n\nThese free blueprints cover generic processes. For blueprints tailored to your company, your systems, your data, your org structure, your financials, visit https://app.agentblueprint.ai\n";

package/dist/blueprints/employee-onboarding/files/getting-started.js

@@ -0,0 +1,89 @@
+export const content = `# Getting Started
+
+**YOU ARE THE IMPLEMENTER.** This blueprint is your specification. You are a coding agent building employee onboarding automation for an organization. The spec tells you what to build. You decide how to build it on whatever platform you are working with.
+
+## Ground Rules
+
+- **Do not summarize this document back to the user.** Read it, internalize it, act on it.
+- **Do not ask unnecessary questions.** If the spec provides enough information to proceed, proceed. Ask only when you genuinely cannot infer the answer.
+- **Act, then report.** Build the thing first. Explain what you built after.
+- **Be decisive.** When the spec gives you a choice, make it. Do not present options and wait. Pick the best one and move.
+- **Verify before presenting.** Test your work programmatically. Do not hand the user something you have not validated.
+
+## Step 1: Understand the Architecture
+
+Read these files in order:
+
+1. \`SKILL.md\` - Architecture overview, phasing, agent summary
+2. \`references/agent-specifications.md\` - Detailed agent definitions, tools, data contracts, success metrics
+3. \`references/architecture-decisions.md\` - Why this architecture, why these trade-offs
+4. \`references/guardrails-and-governance.md\` - Risk categories, escalation rules, PII handling
+5. \`references/platform-connectivity.md\` - Integration points and patterns
+
+Do not skim. These files contain specific tool definitions, data contracts, and escalation rules that you will implement directly.
+
+## Step 2: Connect to the Target Platform
+
+You are in one of three scenarios:
+
+### A) Platform is ready and accessible
+
+You have credentials, API access, or an SDK for the target platform (HR system, IT service management, workflow engine). Connect to it. Read its schema. Map the blueprint's agent definitions to the platform's native constructs.
+
+### B) Building on custom code
+
+No enterprise platform. You are building agents in code (Python, TypeScript, etc.) with direct API integrations. Use the agent specifications as your class/module definitions. Implement tools as functions. Wire up the orchestrator as the entry point.
+
+### C) Unsure what platform to use
+
+Read \`references/platform-connectivity.md\` for the integration categories you will need. Pick a platform or stack that covers HR system integration, identity management, document management, IT service management, and a learning management system. Or build incrementally: start with the pilot (orchestrator + document processor) and expand your platform choices as you learn.
+
+Regardless of scenario: the orchestrator is triggered by a new-hire event from the HR system. That integration is your first technical task.
+
+## Step 3: Build and Validate the Pilot
+
+Follow the phased approach. Do not build all five agents at once.
+
+### Phase A: Scaffold the orchestration
+
+1. Implement the Onboarding Orchestrator with its four tools: \`create_onboarding_case\`, \`assign_task\`, \`check_milestone_status\`, \`escalate_blocker\`.
+2. Implement the Document Processor with its four tools: \`collect_document\`, \`validate_document\`, \`process_tax_forms\`, \`verify_identity\`.
+3. Wire the orchestrator to receive new-hire events and delegate document collection to the Document Processor.
+4. Implement the message format and retry policy defined in \`AGENTS.md\`.
+
+### Phase B: Make the pilot real
+
+1. Connect to actual data sources: HR system for new-hire records, document storage for form templates, e-signature service for collection.
+2. Run a test onboarding end-to-end. Verify every document type is collected, validated, and stored correctly.
+3. Verify escalation works: simulate a failed identity verification and confirm it routes to a human reviewer.
+4. Measure against the pilot decision gate criteria in \`SKILL.md\`.
+
+### Phase C: Expand to full implementation
+
+Once the pilot passes its decision gate:
+
+1. Add the IT Provisioning Coordinator. Test account creation, hardware assignment, and access provisioning independently before connecting to the orchestrator.
+2. Add the Training Curriculum Assembler. Verify it generates role-appropriate training paths.
+3. Add the Progress Tracker. Verify milestone monitoring, at-risk detection, and reporting.
+4. Run a full end-to-end onboarding with all five agents active.
+
+## Step 4: Validate
+
+Test programmatically against the metrics in \`references/evaluation-criteria.md\`:
+
+- Document processing accuracy (target: > 98% first-pass completion)
+- Time-to-productive reduction (target: > 30% vs. manual baseline)
+- IT provisioning Day 1 readiness (target: > 95% of new hires)
+- Compliance completion within 30 days (target: 100%)
+
+Do not eyeball these. Write tests. Measure against real or realistic data. If a metric falls short, diagnose and fix before moving on.
+
+## Step 5: Track Progress
+
+Update \`implementation-state.yaml\` as you complete each agent and integration. This file is your build progress record. Keep it current so that anyone (human or agent) picking up this project knows exactly where things stand.
+
+---
+
+These free blueprints cover generic processes. For blueprints tailored to your company, your systems, your data, your org structure, your financials, visit https://app.agentblueprint.ai
+`;
+//# sourceMappingURL=getting-started.js.map

package/dist/blueprints/employee-onboarding/files/getting-started.js.map

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

package/dist/blueprints/employee-onboarding/files/guardrails-and-governance.d.ts

@@ -0,0 +1 @@
+export declare const content = "# Guardrails and Governance\n\nRisk management, escalation rules, approval gates, and data handling requirements for the Employee Onboarding Automation system.\n\n---\n\n## Risk Categories\n\n### PII Handling\n\nOnboarding involves the most sensitive categories of personal data. The system processes:\n\n- **Social Security Numbers** (tax forms, I-9)\n- **Government-issued ID documents** (passport, driver's license photos)\n- **Bank account details** (direct deposit enrollment)\n- **Medical information** (benefits enrollment, disability accommodations)\n- **Emergency contact information**\n- **Date of birth, home address, phone number**\n\nEvery data flow involving PII must be encrypted in transit (TLS 1.2+) and at rest (AES-256 or equivalent). PII must never appear in log files, error messages, or inter-agent message payloads in cleartext. Use tokenized references (document IDs, employee IDs) in messages and logs. The actual PII lives only in the secure document store and the HR system of record.\n\n### Unauthorized Access Provisioning\n\nThe IT Provisioning Coordinator creates accounts and grants access. Misconfigurations here create security vulnerabilities:\n\n- **Over-provisioning:** Granting more access than the role requires. Mitigated by role-based access templates and the principle of least privilege. No ad-hoc access grants without manager approval.\n- **Stale access:** Provisioning access for a hire who never starts (offer rescinded, start date delayed). Mitigated by the Orchestrator checking HR system status before dispatching provisioning tasks.\n- **Orphaned accounts:** Accounts created but not associated with an active onboarding case. Mitigated by the Orchestrator's case record being the authoritative source. Every account maps to a case ID.\n\n### Incomplete Compliance Training\n\nCompliance training has legal deadlines. Missing them creates liability:\n\n- **Anti-harassment training** is required within 30 days in many jurisdictions.\n- **Security awareness training** is required before access to production systems.\n- **Data privacy training** is required before handling customer data.\n\nThe Training Curriculum Assembler assigns these with hard deadlines. The Progress Tracker monitors completion and escalates non-compliance. The system does not allow deadline extensions for mandatory compliance modules without HR director approval.\n\n### Data Retention Violations\n\nOnboarding documents have different retention requirements:\n\n- **Tax forms:** Retained for the duration of employment plus 4 years (IRS requirement for US).\n- **I-9 forms:** Retained for 3 years after hire date or 1 year after termination, whichever is later.\n- **ID document copies:** Retained only for the duration of the verification process, then deleted. Storing copies long-term creates unnecessary exposure.\n- **Benefits enrollment:** Retained for the duration of the benefit plan year.\n\nThe Document Processor must tag every document with its retention category. Automated retention enforcement (deletion at expiry) should be implemented but requires legal review of the specific organization's jurisdiction and policies.\n\n---\n\n## Escalation Rules\n\n### When to Escalate to a Human\n\n| Situation | Escalation Target | Response SLA |\n|-----------|-------------------|--------------|\n| Identity verification failure or ambiguity | HR Compliance Specialist | 4 hours |\n| Document fails validation 3 times | HR Generalist | 8 hours |\n| Compliance document not submitted within 72 hours of start date | HR Manager + Hiring Manager | 4 hours |\n| PII mismatch between document and HR record | HR Compliance Specialist + Security | 2 hours |\n| Access request for restricted system | System Owner or Security Team | 12 hours |\n| Hardware cannot be delivered by start date | IT Manager + Hiring Manager | 24 hours |\n| License pool exhausted for required software | IT Procurement | 24 hours |\n| Employee has not started compliance training within 7 days | Hiring Manager | 24 hours |\n| At-risk onboarding flagged for 48+ hours with no progress | HR Director | 4 hours |\n\n### Escalation Message Requirements\n\nEvery escalation must include:\n\n1. The onboarding case ID and employee name\n2. The specific task that is blocked\n3. What was attempted (including retry history)\n4. Why automated resolution failed\n5. Recommended next action\n6. Deadline impact (how this affects the new hire's start date or compliance deadlines)\n\nEscalations without all six elements are rejected and returned to the originating agent for completion.\n\n---\n\n## Approval Gates\n\n### Phase 1 Exit Gate\n\nBefore expanding from pilot to full implementation:\n\n- Document processing accuracy > 95% measured over at least 20 onboardings\n- Time reduction > 50% vs. manual baseline\n- Zero compliance gaps during pilot period\n- Stakeholder review of pilot metrics and architecture validation\n- Budget approval for Phase 2 infrastructure and integration costs\n\nThis gate requires sign-off from: HR leadership, IT leadership, and the project sponsor.\n\n### Access Provisioning Sign-Off\n\nFor standard role-based access: automated provisioning is permitted using pre-approved role templates. No human approval needed.\n\nFor exceptions to the role template (additional systems, elevated permissions, admin access): the hiring manager must approve the request and the system owner must confirm. Both approvals are logged in the onboarding case record.\n\nFor access to regulated systems (financial systems, customer PII stores, production infrastructure): security team approval is required in addition to manager and system owner approval.\n\n### Compliance Verification Gate\n\nBefore an onboarding case is marked \"complete\" (typically Day 90):\n\n- All mandatory documents collected and validated\n- All tax forms processed and confirmed by payroll\n- Identity verification completed and approved\n- All compliance training modules completed\n- All access provisioning logged and reconciled against role templates\n\nThe Progress Tracker generates the completion checklist. A human (HR generalist or hiring manager) must review and confirm.\n\n---\n\n## Data Handling Requirements\n\n### PII Classification\n\n| Data Element | Classification | Handling |\n|-------------|---------------|----------|\n| SSN / Tax ID | Restricted | Encrypted at rest, tokenized in logs, access limited to Document Processor and payroll integration |\n| Government ID images | Restricted | Encrypted at rest, deleted after verification, never stored in logs or messages |\n| Bank account details | Restricted | Encrypted at rest, tokenized in transit, routed only to payroll system |\n| Medical / benefits info | Confidential | Encrypted at rest, access limited to benefits enrollment integration |\n| Home address, phone, DOB | Confidential | Encrypted at rest, available to HR and IT provisioning |\n| Emergency contacts | Internal | Encrypted at rest, stored in HR system |\n| Name, role, department | Internal | Available to all agents for task routing |\n\n### Encryption Requirements\n\n- Data in transit: TLS 1.2 or higher for all inter-system communication\n- Data at rest: AES-256 or equivalent for all PII storage\n- Inter-agent messages: use tokenized references (case ID, document ID, employee ID) rather than PII values\n- API keys and credentials: stored in a secrets manager, never in code or configuration files\n\n### Access Controls\n\n- Each agent accesses only the data it needs for its specific function\n- The Document Processor accesses document content; other agents access only document metadata (type, status, deadline)\n- The IT Provisioning Coordinator accesses employee role and department data; it does not access tax forms or ID documents\n- The Progress Tracker accesses milestone statuses and aggregate metrics; it does not access PII or document content\n- All data access is logged with agent identity, timestamp, data element accessed, and purpose\n\n---\n\n## Audit Trail Requirements\n\n### What Gets Logged\n\nEvery significant action in the system must be logged:\n\n- **Document actions:** collection request sent, document submitted, validation attempted (pass/fail with reason), document processed, document deleted (retention expiry)\n- **Access grants:** account created (which system, which permissions), permission modified, access revoked\n- **Identity verification:** verification initiated, result (verified/needs_review/failed), human reviewer decision\n- **Escalations:** escalation created, assigned to whom, response received, resolution\n- **Training:** path assigned, module enrolled, module completed, deadline extended (with approver)\n- **Orchestrator decisions:** case created, task dispatched, dependency resolved, case status changed, case completed\n\n### Log Format\n\nEach log entry includes:\n\n- Timestamp (UTC)\n- Agent ID (which agent performed the action)\n- Onboarding case ID\n- Action type\n- Action details\n- Result (success/failure/pending)\n- Correlation ID (links related actions across agents)\n\n### Log Retention\n\n- Audit logs for active onboarding cases: retained for the life of the case plus 1 year\n- Audit logs for completed cases: retained for 3 years minimum (align with employment record retention)\n- PII-containing log entries: must not exist. If PII appears in a log entry, it is a bug and must be fixed immediately.\n";

package/dist/blueprints/employee-onboarding/files/guardrails-and-governance.js

@@ -0,0 +1,182 @@
+export const content = `# Guardrails and Governance
+
+Risk management, escalation rules, approval gates, and data handling requirements for the Employee Onboarding Automation system.
+
+---
+
+## Risk Categories
+
+### PII Handling
+
+Onboarding involves the most sensitive categories of personal data. The system processes:
+
+- **Social Security Numbers** (tax forms, I-9)
+- **Government-issued ID documents** (passport, driver's license photos)
+- **Bank account details** (direct deposit enrollment)
+- **Medical information** (benefits enrollment, disability accommodations)
+- **Emergency contact information**
+- **Date of birth, home address, phone number**
+
+Every data flow involving PII must be encrypted in transit (TLS 1.2+) and at rest (AES-256 or equivalent). PII must never appear in log files, error messages, or inter-agent message payloads in cleartext. Use tokenized references (document IDs, employee IDs) in messages and logs. The actual PII lives only in the secure document store and the HR system of record.
+
+### Unauthorized Access Provisioning
+
+The IT Provisioning Coordinator creates accounts and grants access. Misconfigurations here create security vulnerabilities:
+
+- **Over-provisioning:** Granting more access than the role requires. Mitigated by role-based access templates and the principle of least privilege. No ad-hoc access grants without manager approval.
+- **Stale access:** Provisioning access for a hire who never starts (offer rescinded, start date delayed). Mitigated by the Orchestrator checking HR system status before dispatching provisioning tasks.
+- **Orphaned accounts:** Accounts created but not associated with an active onboarding case. Mitigated by the Orchestrator's case record being the authoritative source. Every account maps to a case ID.
+
+### Incomplete Compliance Training
+
+Compliance training has legal deadlines. Missing them creates liability:
+
+- **Anti-harassment training** is required within 30 days in many jurisdictions.
+- **Security awareness training** is required before access to production systems.
+- **Data privacy training** is required before handling customer data.
+
+The Training Curriculum Assembler assigns these with hard deadlines. The Progress Tracker monitors completion and escalates non-compliance. The system does not allow deadline extensions for mandatory compliance modules without HR director approval.
+
+### Data Retention Violations
+
+Onboarding documents have different retention requirements:
+
+- **Tax forms:** Retained for the duration of employment plus 4 years (IRS requirement for US).
+- **I-9 forms:** Retained for 3 years after hire date or 1 year after termination, whichever is later.
+- **ID document copies:** Retained only for the duration of the verification process, then deleted. Storing copies long-term creates unnecessary exposure.
+- **Benefits enrollment:** Retained for the duration of the benefit plan year.
+
+The Document Processor must tag every document with its retention category. Automated retention enforcement (deletion at expiry) should be implemented but requires legal review of the specific organization's jurisdiction and policies.
+
+---
+
+## Escalation Rules
+
+### When to Escalate to a Human
+
+| Situation | Escalation Target | Response SLA |
+|-----------|-------------------|--------------|
+| Identity verification failure or ambiguity | HR Compliance Specialist | 4 hours |
+| Document fails validation 3 times | HR Generalist | 8 hours |
+| Compliance document not submitted within 72 hours of start date | HR Manager + Hiring Manager | 4 hours |
+| PII mismatch between document and HR record | HR Compliance Specialist + Security | 2 hours |
+| Access request for restricted system | System Owner or Security Team | 12 hours |
+| Hardware cannot be delivered by start date | IT Manager + Hiring Manager | 24 hours |
+| License pool exhausted for required software | IT Procurement | 24 hours |
+| Employee has not started compliance training within 7 days | Hiring Manager | 24 hours |
+| At-risk onboarding flagged for 48+ hours with no progress | HR Director | 4 hours |
+
+### Escalation Message Requirements
+
+Every escalation must include:
+
+1. The onboarding case ID and employee name
+2. The specific task that is blocked
+3. What was attempted (including retry history)
+4. Why automated resolution failed
+5. Recommended next action
+6. Deadline impact (how this affects the new hire's start date or compliance deadlines)
+
+Escalations without all six elements are rejected and returned to the originating agent for completion.
+
+---
+
+## Approval Gates
+
+### Phase 1 Exit Gate
+
+Before expanding from pilot to full implementation:
+
+- Document processing accuracy > 95% measured over at least 20 onboardings
+- Time reduction > 50% vs. manual baseline
+- Zero compliance gaps during pilot period
+- Stakeholder review of pilot metrics and architecture validation
+- Budget approval for Phase 2 infrastructure and integration costs
+
+This gate requires sign-off from: HR leadership, IT leadership, and the project sponsor.
+
+### Access Provisioning Sign-Off
+
+For standard role-based access: automated provisioning is permitted using pre-approved role templates. No human approval needed.
+
+For exceptions to the role template (additional systems, elevated permissions, admin access): the hiring manager must approve the request and the system owner must confirm. Both approvals are logged in the onboarding case record.
+
+For access to regulated systems (financial systems, customer PII stores, production infrastructure): security team approval is required in addition to manager and system owner approval.
+
+### Compliance Verification Gate
+
+Before an onboarding case is marked "complete" (typically Day 90):
+
+- All mandatory documents collected and validated
+- All tax forms processed and confirmed by payroll
+- Identity verification completed and approved
+- All compliance training modules completed
+- All access provisioning logged and reconciled against role templates
+
+The Progress Tracker generates the completion checklist. A human (HR generalist or hiring manager) must review and confirm.
+
+---
+
+## Data Handling Requirements
+
+### PII Classification
+
+| Data Element | Classification | Handling |
+|-------------|---------------|----------|
+| SSN / Tax ID | Restricted | Encrypted at rest, tokenized in logs, access limited to Document Processor and payroll integration |
+| Government ID images | Restricted | Encrypted at rest, deleted after verification, never stored in logs or messages |
+| Bank account details | Restricted | Encrypted at rest, tokenized in transit, routed only to payroll system |
+| Medical / benefits info | Confidential | Encrypted at rest, access limited to benefits enrollment integration |
+| Home address, phone, DOB | Confidential | Encrypted at rest, available to HR and IT provisioning |
+| Emergency contacts | Internal | Encrypted at rest, stored in HR system |
+| Name, role, department | Internal | Available to all agents for task routing |
+
+### Encryption Requirements
+
+- Data in transit: TLS 1.2 or higher for all inter-system communication
+- Data at rest: AES-256 or equivalent for all PII storage
+- Inter-agent messages: use tokenized references (case ID, document ID, employee ID) rather than PII values
+- API keys and credentials: stored in a secrets manager, never in code or configuration files
+
+### Access Controls
+
+- Each agent accesses only the data it needs for its specific function
+- The Document Processor accesses document content; other agents access only document metadata (type, status, deadline)
+- The IT Provisioning Coordinator accesses employee role and department data; it does not access tax forms or ID documents
+- The Progress Tracker accesses milestone statuses and aggregate metrics; it does not access PII or document content
+- All data access is logged with agent identity, timestamp, data element accessed, and purpose
+
+---
+
+## Audit Trail Requirements
+
+### What Gets Logged
+
+Every significant action in the system must be logged:
+
+- **Document actions:** collection request sent, document submitted, validation attempted (pass/fail with reason), document processed, document deleted (retention expiry)
+- **Access grants:** account created (which system, which permissions), permission modified, access revoked
+- **Identity verification:** verification initiated, result (verified/needs_review/failed), human reviewer decision
+- **Escalations:** escalation created, assigned to whom, response received, resolution
+- **Training:** path assigned, module enrolled, module completed, deadline extended (with approver)
+- **Orchestrator decisions:** case created, task dispatched, dependency resolved, case status changed, case completed
+
+### Log Format
+
+Each log entry includes:
+
+- Timestamp (UTC)
+- Agent ID (which agent performed the action)
+- Onboarding case ID
+- Action type
+- Action details
+- Result (success/failure/pending)
+- Correlation ID (links related actions across agents)
+
+### Log Retention
+
+- Audit logs for active onboarding cases: retained for the life of the case plus 1 year
+- Audit logs for completed cases: retained for 3 years minimum (align with employment record retention)
+- PII-containing log entries: must not exist. If PII appears in a log entry, it is a bug and must be fixed immediately.
+`;
+//# sourceMappingURL=guardrails-and-governance.js.map

package/dist/blueprints/employee-onboarding/files/guardrails-and-governance.js.map

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

package/dist/blueprints/employee-onboarding/files/implementation-state.d.ts

@@ -0,0 +1 @@
+export declare const content = "schema_version: \"1.0\"\noverall_status: not_started\n\nplatform:\n  name: TBD\n  version: TBD\n  environment: TBD\n\nagents:\n  - name: Onboarding Orchestrator\n    type: manager\n    status: not_started\n    phase: 1\n    tools_implemented: []\n    integrations_connected: []\n    tests_passing: false\n    notes: \"\"\n\n  - name: Document Processor\n    type: worker\n    status: not_started\n    phase: 1\n    tools_implemented: []\n    integrations_connected: []\n    tests_passing: false\n    notes: \"\"\n\n  - name: IT Provisioning Coordinator\n    type: worker\n    status: not_started\n    phase: 2\n    tools_implemented: []\n    integrations_connected: []\n    tests_passing: false\n    notes: \"\"\n\n  - name: Training Curriculum Assembler\n    type: worker\n    status: not_started\n    phase: 2\n    tools_implemented: []\n    integrations_connected: []\n    tests_passing: false\n    notes: \"\"\n\n  - name: Progress Tracker\n    type: worker\n    status: not_started\n    phase: 2\n    tools_implemented: []\n    integrations_connected: []\n    tests_passing: false\n    notes: \"\"\n\npilot:\n  status: not_started\n  start_date: TBD\n  end_date: TBD\n  decision_gate:\n    document_accuracy: null\n    time_reduction: null\n    compliance_gaps: null\n    critical_errors: null\n  stakeholder_signoff: false\n\nfull_implementation:\n  status: not_started\n  start_date: TBD\n  end_date: TBD\n\nintegrations:\n  - name: HR System (new-hire event trigger)\n    status: not_started\n    notes: \"\"\n  - name: Document Management (e-signature, storage)\n    status: not_started\n    notes: \"\"\n  - name: Identity Management (directory, SSO)\n    status: not_started\n    notes: \"\"\n  - name: IT Service Management (tickets, assets)\n    status: not_started\n    notes: \"\"\n  - name: Learning Management System\n    status: not_started\n    notes: \"\"\n  - name: Communication Channels (email, chat)\n    status: not_started\n    notes: \"\"\n";