Dadmin88/hermes-agency - Page 14

interface-design

Design durable software interfaces between components or services with explicit ownership, contracts, semantics, evolution, trust boundaries, and failure behavior.

migration-design

Design safe architectural migrations across data, interfaces, components, deployments, and consumers using compatibility stages, observability, rollback or forward recovery, and explicit completion criteria.

technical-research

Research technical approaches from project documents of record through current primary sources and prior art, evaluate evidence and licenses, and convert findings into architecture or implementation implications without answering from memory.

implementation-handoff

Hand a validated solution to implementation/customer-success owners with architecture, configuration, acceptance evidence, gaps, dependencies, and unresolved risks.

proof-of-concept

Design and execute a bounded proof of concept that validates the riskiest customer-specific technical assumptions with real evidence.

solution-architecture-brief

Produce a customer-facing solution architecture that maps supported product components and integration boundaries to the customer environment without redefining core product architecture.

technical-demo

Deliver a customer-specific technical demonstration that proves relevant workflows, handles likely questions, and distinguishes configured demo behavior from product guarantees.

technical-discovery

Run technical customer discovery that surfaces current architecture, workflows, constraints, success criteria, security/compliance needs, and decision risks without prematurely designing a solution.

bug-reproduction

Reproduce a reported customer issue from exact environment, inputs, account state, sequence, and evidence so engineering receives a bounded defect instead of an anecdote.

escalation

Escalate a support case with severity, impact, evidence, attempted work, decision needed, owner, and customer context so the receiving specialist can act without restarting intake.

response-drafting

Draft support responses that acknowledge the actual problem, answer what is known, avoid invented certainty, give concrete next steps, and preserve ownership through resolution.

support-trend-analysis

Analyze support volume and case evidence to identify recurring product, documentation, reliability, onboarding, policy, or operational problems without mistaking ticket count for root cause.

support-triage

Triage a support request into a reproducible problem, user impact, severity, workaround, and correct escalation path.

architecture-diagram

Dark-themed SVG architecture/cloud/infra diagrams as HTML.

capacity-model

Build a system-level capacity model that connects workload demand to bottlenecks across services, nodes, queues, storage, network, shared dependencies, redundancy, and placement constraints.

deployment-topology

Design how distributed components may be placed and rolled out across failure domains, networks, state, trust boundaries, heterogeneous nodes, and upgrade cohorts without confusing architecture with live scheduler state.

distributed-systems-design

Design distributed behavior explicitly around ownership, coordination, consistency, ordering, retries, duplicate delivery, partitions, discovery, membership, and evolution rather than assuming a reliable single machine.

fault-tolerance

Design and test fault tolerance by defining expected faults, containment boundaries, detection, failover, retry/replay semantics, state reconciliation, and safe recovery after partial failure.

reliability-design

Design system reliability from user-critical outcomes through service objectives, dependency budgets, redundancy, graceful degradation, recovery, observability, and operational ownership.

systems-design

Design a multi-service or distributed system around responsibilities, protocols, topology, identity, consistency, failure, capacity, observability, and evolution.

systems-topology

Model a system's logical and physical topology across services, nodes, networks, state, control planes, trust boundaries, failure domains, dependencies, and communication paths.

art-pipeline

Design or troubleshoot an art production pipeline across DCC tools, import/export, shaders, assets, validation, automation, and runtime constraints.

asset-performance

Profile and optimize art-asset runtime cost across geometry, materials, textures, animation, VFX, draw calls, overdraw, memory, streaming, and scene density without sacrificing visible intent blindly.

engine-handoff

Define and validate the art-to-engine contract for formats, scale, naming, materials, rigs, animation, metadata, import settings, automation, and ownership across distributed production.

procedural-tools

Design procedural art tools that encode repeatable artistic constraints while exposing useful controls, deterministic generation, editable outputs, performance limits, and safe artist override.

shader-debugging

Diagnose shader and material failures using reproduction, render-state inspection, inputs, spaces, precision, variants, platform differences, and frame or debugger evidence.

codebase-scoping

Scope an engineering change in an unfamiliar or evolving codebase by tracing entry points, ownership, callers, data flow, tests, configuration, generated artifacts, and adjacent contracts before assigning implementation work.

implementation-coordination

Coordinate parallel engineering implementation by keeping ownership, contracts, dependencies, integration state, blockers, and validation evidence aligned without taking over specialists' work.

integration-plan

Plan how independently owned engineering changes will combine into one working system, including interface readiness, merge order, data/schema compatibility, feature exposure, test environments, and rollback checkpoints.

technical-execution-plan

Convert approved product scope and architecture into a coordinated technical execution plan across engineering specialties.

technical-risk-assessment

Assess implementation risk across uncertainty, blast radius, compatibility, data, concurrency, dependencies, performance, security, operations, and reversibility so engineering effort follows the risks that can actually derail delivery.

configuration-diagnosis

Diagnose configuration failures by comparing effective values, precedence, environment, defaults, validation, and version compatibility rather than assuming the visible file is authoritative.

engineering-escalation-package

Prepare an engineering escalation with minimal reproduction, impact, evidence, suspected boundary, failed hypotheses, workaround status, and exact decision or fix needed.

environment-reproduction

Recreate a customer or operator environment closely enough to validate a technical failure without copying secrets or unnecessary private data.

log-trace-triage

Turn noisy logs and traces into a precise failure timeline by correlating identifiers, requests, retries, dependencies, resource state, and user-visible outcomes.

technical-case-diagnosis

Diagnose a complex support case by reconstructing environment, configuration, timeline, logs, network, dependencies, and reproduction evidence before assigning cause.

api-docs

Write API documentation that lets a developer correctly authenticate, call, interpret, retry, paginate, version, and troubleshoot an interface using verified contracts and executable examples.

code-example-validation

Validate documentation code examples by executing them against the documented version, checking dependencies, setup, security, output, cleanup, platform assumptions, and consistency with current APIs.

migration-guide

Write a technical migration guide from a known old state to a supported new state with compatibility, prerequisites, staged changes, data or configuration transformation, verification, mixed-version behavior, and recovery.

release-docs

Coordinate the technical documentation required for a release by identifying changed behavior, affected pages, new reference, migration, configuration, examples, troubleshooting, and versioned notices tied to the released state.