agentic-harness-agents

Audit user-facing journeys for accessibility defects and WCAG-aligned risks using repository, Design Analysis, manual, and automated evidence. Use when accessibility, keyboard, screen-reader, focus, contrast, forms, motion, touch targets, zoom, or reflow is explicitly requested. Do not use for general UX design, visual-style judgment, or design-system conformance alone.

Synchronize vendor-required agent instruction files as thin adapters to root AGENTS.md and .agentic project truth. Use when creating, updating, checking, or reconciling Codex, Claude, Gemini, Copilot, or Cursor adapter files. Do not use for general documentation migration or for changing canonical project rules.

Create, update, supersede, reject, or index Architecture Decision Records while preserving decision history. Use when a consequential technical or product decision has been proposed or accepted and needs durable rationale. Do not use merely to edit current architecture documentation or to design a solution that has not yet been decided.

Initialize, upgrade, migrate, or broadly audit a repository using the Agentic Harness project contract and selected catalog modules. Use when the requested job spans overall harness setup or lifecycle rather than one specialist procedure. Do not use for a focused readiness score, a standalone legacy migration, or a single domain review when a narrower skill owns the task.

Improve an existing repository's agent instructions, context routing and skill design. Use when the user asks to reduce token use, repeated reads, duplicated guidance or verbose handoffs while preserving evidence and completion checks. Do not use for the initial readiness audit, ordinary code refactoring, typed semantic judgments or model-fit comparisons.

Evaluate Agentic Readiness: context architecture, AGENTS.md quality, skill routing, completion/autonomy, verification, portability, instruction health, decision history, and agent security. Use when the user asks how agent-ready a repository is or requests a model compatibility score. Do not use for broad code-quality auditing or for applying fixes.

Design or review external or internal API contracts including resources, operations, errors, pagination, versioning, idempotency, authentication boundaries, and compatibility. Use when an API surface or contract is the requested design artifact. Do not use primarily for database schema design, implementation debugging, or broad codebase review.

Perform a broad evidence-backed technical audit of code quality, maintainability, architecture, tests, dependencies, documentation, operations, performance posture, and security signals. Use when the user asks for an overall repository/codebase audit. Do not use when the requested score is specifically Agentic Readiness or when a single specialist review is sufficient.

Research current competitors, alternatives, positioning, capabilities, pricing, and market gaps using cited external evidence. Use when the user asks for competitive landscape research or evidence-backed comparison. Do not use merely to write marketing copy or to design product flows without external market research.

Resolve an implementation component need against approved project primitives, internal registries, and compatible external UI component providers, then produce a safe adaptation/import plan. Use when the user asks which component/library to use, wants to reuse Spectrum/shadcn-style source, or needs to avoid inventing a duplicate primitive. Do not use to define the visual identity, browse inspiration without implementation intent, or silently install incompatible provider code.

Design or review persistent data models, relational schemas, constraints, indexes, transactions, migrations, retention, and data-access boundaries. Use when the requested artifact is a database/data-model design or schema evolution. Do not use primarily for API contract design, dependency upgrades, or generic backend implementation.

Design or review bounded semantic decisions with explicit evidence, finite outcomes and abstention. Use when a task asks for evidence-support judgments, typed task classification or Jev decision guidance. Do not use for open-ended generation, ordinary code review, deterministic parsing, model-fit ranking or action authorisation.

Plan and execute safe package, framework, runtime, or toolchain dependency upgrades with changelog review and compatibility verification. Use when the main task is changing dependency versions or adapting to their breaking changes. Do not use for Agentic Harness filesystem migration, ordinary release packaging, or unrelated refactoring.

Interpret measured design evidence and structured analysis artifacts, classify conclusions by confidence and evidence type, and reconcile external analysis proposals with approved project truth. Use when the user asks what an existing interface's measured colors, type, spacing, components, motion, responsive behavior, or design drift mean. Do not use to invent a new visual identity, design a user journey, or perform the deterministic measurement itself when tooling can do it.

Orchestrate the repository-native Analyze → Preserve → Compile → Verify design lifecycle across canonical Design Analysis, Design Genome, Design Task, and drift artifacts. Use when a request spans multiple design-intelligence stages or asks to make an existing product reproducible for AI implementation. Do not use for one isolated UX flow, a standalone design-system definition, or a narrow compliance/accessibility audit.

Research visual references, UI patterns, interaction patterns, product flows, design critiques, and interface datasets to inform a specific design/product question. Use when the user asks how other interfaces solve a problem, wants examples from UI/UX libraries, or needs evidence before choosing a design direction. Do not use for general competitor/business research, direct component installation, or to turn reference prevalence into project requirements.

Create or evolve the reusable UI system: tokens, semantic roles, component contracts, variants, states, layouts, patterns, accessibility expectations, and adoption rules. Use when the user asks to define or substantially extend shared interface primitives used across product surfaces. Do not use to discover the brand/art direction, research external UI references, select an external component provider, or merely audit conformance to an existing system.

Audit product implementation against an accepted design system for token bypasses, duplicate primitives, raw controls, invalid variants, missing required component behavior, and documented exceptions. Use when structural conformance to established project design rules is the goal. Do not use to create or revise the design system, infer brand identity, or conduct a full accessibility audit.

Create or update durable project documentation so current product, architecture, security, design, operational, API, data, or testing truth matches accepted changes. Use when documentation is itself the requested deliverable or must be synchronized after approved work. Do not use to invent decisions, create ADRs, or produce a temporary implementation plan.

Define or deliberately evolve a product's brand-facing visual identity and art direction: personality, differentiation, typography character, palette direction, imagery, geometry, density, composition, motion, voice, and intentional anti-patterns. Use when the user asks what the product should look or feel like, wants distinct visual directions, or needs identity continuity across surfaces. Do not use to engineer the reusable component/token system, design a product flow, or audit implementation compliance.

Turn accepted product or architecture scope into an executable, dependency-aware implementation plan with milestones, verification, risks, and rollback points. Use when the user asks how to implement approved work before or alongside coding. Do not use to decide unresolved architecture/product direction or to maintain general documentation after implementation.

Conduct a blameless post-incident review from timelines, logs, alerts, deployments, impact, response actions, and recovery evidence. Use after a reliability, security, or operational incident to establish contributing factors and corrective actions. Do not use for a proactive threat model, standalone performance benchmark, or general code review.

Create positioning, messaging, launch copy, value propositions, audience narratives, or marketing content from approved product facts and evidence. Use when the user wants communication or go-to-market material. Do not use to conduct primary competitive research, decide product requirements, or invent unsupported performance/customer claims.

Migrate legacy Agentic Harness repository layouts or canonical-context locations to the current root AGENTS.md plus .agentic contract with conflict detection, backup, and idempotence. Use when filesystem/project-contract migration is the primary task. Do not use for dependency upgrades, database migrations, or fresh project initialization.

Compare supported evidence-backed coding-agent model profiles for a specific repository or task, including current and post-improvement compatibility. Use when the user asks which model best fits the project/task or how model guidance differs. Do not use to score general Agentic Readiness or to invent rankings for models absent from the canonical registry.

Measure and diagnose performance bottlenecks in application, API, database, build, or runtime paths using profiling, tracing, benchmarks, metrics, and repository evidence. Use when latency, throughput, resource use, query cost, bundle/build speed, or performance regressions are explicitly requested. Do not use for generic code quality or incident review without a performance focus.

Design a feature's user journey, information hierarchy, interaction states, requirements, edge cases, recovery, and usability behavior from accepted product goals. Use when the requested output is UX/product interaction design for a screen, workflow, or end-to-end journey. Do not use to define brand/art direction, construct the shared token/component system, research reference libraries as the primary task, or turn competitor features into requirements.

Prepare and execute an approved software or package release: versioning, changelog, tests, artifacts, checksums, tagging, publishing, rollout, and rollback verification. Use when the user explicitly wants to create or publish a release. Do not use merely to review release readiness or to upgrade dependencies without releasing.

Review a release candidate against documented quality, security, migration, compatibility, documentation, artifact, and operational gates and return a go/no-go assessment. Use before publication when release readiness is the requested decision. Do not use to publish the release itself or for a general repository audit unrelated to a candidate.

Review an existing implementation or change for security weaknesses in authentication, authorization, tenancy, inputs/outputs, secrets, cryptography, privacy, dependencies, CI/release, logging, recovery, and abuse resistance. Use when a concrete security review or secure-by-default code assessment is requested. Do not use primarily for pre-implementation threat modeling or broad non-security code review.

Create or update a threat model for a proposed system, feature, integration, data flow, or architecture by mapping assets, actors, trust boundaries, attack paths, abuse cases, controls, and residual risk. Use before or during design when security threats must shape architecture. Do not use primarily to audit already-implemented code for vulnerabilities.