Workhuman performance tuning for employee recognition and rewards API.
--- name: workhuman-performance-tuning-cb9615450ee4 description: 'Measure and tune Workhuman adapter, worker-sync, recognition, reporting, and Store workflows within documented tenant limits. Use when tuning latency or throughput. Trigger with "tune Workhuman performance".' argument-hint: "[workflow] [service-level-objective]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.4.0 author: Jeremy Longshore <jeremy@intentsolutions.io> license: MIT tags: [saas, workhuman, performance, reliability, optimization] model: inherit effort: high compatibility: Designed for Claude Code; load tests and production concurrency, schedule, cache, or batch changes require accountable-owner approval --- # Workhuman Evidence-Based Performance Tuning ## Overview Improve an identified bottleneck while preserving correctness, freshness, privacy, financial integrity, and downstream capacity. ## Prerequisites - A named workflow, current baseline, service-level objective, volume model, and bottleneck hypothesis - Customer-authorized capacity and behavior contracts for every dependent system - Synthetic load fixtures, reconciliation, abort thresholds, and rollback ownership ## Tool Discipline Use `Read`, `Glob`, and `Grep` to inspect code and telemetry, `WebFetch` for current vendor context, and `Write` or `Edit` for benchmarks, controls, tests, and redacted receipts. ## Current Contract Workhuman supports global recognition, rewards, reporting, open-API use, and managed integrations, but its public pages do not publish universal performance limits. Optimize against measured customer behavior and current documented boundaries. ## Authentication Keep principals tenant- and environment-scoped during measurement. Do not increase credentials or bypass governance to raise throughput. ## Instructions 1. Freeze the workflow, source and destination, record volume, freshness, latency and throughput objectives, and correctness invariants. 2. Measure queue time, service time, retries, throttling, batch duration, payload size, downstream latency, and reconciliation lag. 3. Isolate whether the bottleneck is scheduling, serialization, network, vendor processing, HCM, reporting, Store, or downstream logic. 4. Choose one controlled change: batching, bounded concurrency, connection reuse, field minimization, scheduling, checkpointing, or an approved cache. 5. Define cache authority, key, tenant boundary, TTL, invalidation, sensitive fields, and staleness tolerance before caching. 6. Test steady, burst, empty, duplicate, partial, timeout, throttle, downstream-slow, and recovery cases with synthetic data. 7. Present expected gain, capacity impact, correctness proof, privacy effect, abort threshold, and rollback. 8. Canary after approval and retain before-and-after percentiles, throughput, errors, reconciliation, and cost effects. ## Approval Boundaries Do not load-test production, increase concurrency or schedules, cache workforce or award data, or relax correctness and privacy controls without approval. ## Output Return the baseline, bottleneck evidence, selected change, test matrix, capacity and privacy review, canary comparison, reconciliation, and rollback status. ## Error Handling | Condition | Response | |---|---| | Faster result changes authoritative state | Reject the optimization and preserve correctness. | | Tail latency improves but errors rise | Roll back and investigate retries or downstream saturation. | | Limit is undocumented | Use a bounded customer-approved canary and request vendor guidance. | ## Example A redacted completion receipt might look like this: ```text workflow=worker-sync; baseline-p95=18m; change=bounded-batches; canary-p95=9m; errors=unchanged; reconciliation=exact ``` ## Resources - [Workhuman integrations](https://www.workhuman.com/capabilities/integrations/) - [Workhuman Social Recognition](https://www.workhuman.com/platform/social-recognition/) ## Next Steps Monitor the new baseline through one full business cycle and revert if correctness or downstream health regresses.--- name: workhuman-performance-tuning-cb9615450ee4 description: 'Measure and tune Workhuman adapter, worker-sync, recognition, reporting, and Store workflows within documented tenant limits. Use when tuning latency or throughput. Trigger with "tune Workhuman performance".' argument-hint: "[workflow] [service-level-objective]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.4.0 author: Jeremy Longshore <jeremy@intentsolutions.io> license: MIT tags: [saas, workhuman, performance, reliability, optimization] model: inherit effort: high compatibility: Designed for Claude Code; load tests and production concurrency, schedule, cache, or batch changes require accountable-owner approval --- # Workhuman Evidence-Based Performance Tuning ## Overview Improve an identified bottleneck while preserving correctness, freshness, privacy, financial integrity, and downstream capacity. ## Prerequisites - A named workflow, current baseline, service-level objective, volume model, and bottleneck hypothesis - Customer-authorized capacity and behavior contracts for every dependent system - Synthetic load fixtures, reconciliation, abort thresholds, and rollback ownership ## Tool Discipline Use `Read`, `Glob`, and `Grep` to inspect code and telemetry, `WebFetch` for current vendor context, and `Write` or `Edit` for benchmarks, controls, tests, and redacted receipts. ## Current Contract Workhuman supports global recognition, rewards, reporting, open-API use, and managed integrations, but its public pages do not publish universal performance limits. Optimize against measured customer behavior and current documented boundaries. ## Authentication Keep principals tenant- and environment-scoped during measurement. Do not increase credentials or bypass governance to raise throughput. ## Instructions 1. Freeze the workflow, source and destination, record volume, freshness, latency and throughput objectives, and correctness invariants. 2. Measure queue time, service time, retries, throttling, batch duration, payload size, downstream latency, and reconciliation lag. 3. Isolate whether the bottleneck is scheduling, serialization, network, vendor processing, HCM, reporting, Store, or downstream logic. 4. Choose one controlled change: batching, bounded concurrency, connection reuse, field minimization, scheduling, checkpointing, or an approved cache. 5. Define cache authority, key, tenant boundary, TTL, invalidation, sensitive fields, and staleness tolerance before caching. 6. Test steady, burst, empty, duplicate, partial, timeout, throttle, downstream-slow, and recovery cases with synthetic data. 7. Present expected gain, capacity impact, correctness proof, privacy effect, abort threshold, and rollback. 8. Canary after approval and retain before-and-after percentiles, throughput, errors, reconciliation, and cost effects. ## Approval Boundaries Do not load-test production, increase concurrency or schedules, cache workforce or award data, or relax correctness and privacy controls without approval. ## Output Return the baseline, bottleneck evidence, selected change, test matrix, capacity and privacy review, canary comparison, reconciliation, and rollback status. ## Error Handling | Condition | Response | |---|---| | Faster result changes authoritative state | Reject the optimization and preserve correctness. | | Tail latency improves but errors rise | Roll back and investigate retries or downstream saturation. | | Limit is undocumented | Use a bounded customer-approved canary and request vendor guidance. | ## Example A redacted completion receipt might look like this: ```text workflow=worker-sync; baseline-p95=18m; change=bounded-batches; canary-p95=9m; errors=unchanged; reconciliation=exact ``` ## Resources - [Workhuman integrations](https://www.workhuman.com/capabilities/integrations/) - [Workhuman Social Recognition](https://www.workhuman.com/platform/social-recognition/) ## Next Steps Monitor the new baseline through one full business cycle and revert if correctness or downstream health regresses.
Imported from the listed AgentSkill.sh category. Complete supplied package files and notices are retained. Required external tools and credentials are not installed. No bundled code was executed during import. Individual agent task behavior has not been tested.