howlil/agentflow

Route coding and SDLC tasks to the smallest relevant set of engineering skills by identifying unresolved product, architecture, UI, implementation, verification, security, operations, review, or delegation decisions. Use for task routing, cross-domain engineering audits, and explicit $agentflow orchestration. Skip unnecessary specialist steps for deterministic edits.

Render already-understood call paths, runtime flows, architecture relationships, or orchestration DAGs as compact plain-text graphs when a graph materially improves human understanding. Use for architecture explanations, execution traces, implementation summaries, review evidence, or delegated-work DAGs. Preserve the semantics supplied by the owning skill; do not invent architecture, dependencies, workers, edge types, or verification requirements. Do not emit a graph for every change. Prefer outcome/responsibility labels over filenames, show Production/Tests only when they materially differ, and compare planned vs actual graphs by contract/outcome rather than demanding structural equality.

Review an existing code change, pull request, commit, or implementation by reconstructing what the changed code actually does and finding concrete mismatches against intended behavior, system contracts, invariants, and codebase structure. Use after implementation or when explicitly asked to review, audit, inspect, or assess code. Default to diff-based review when a change set exists; inspect surrounding code only as needed to understand impact. Report only actionable findings with evidence and consequence. Do not redesign the product, repeat implementation planning, or emit style/nit feedback that automated tooling or existing conventions can handle.

Turn a product behavior contract into an explicit interface graph of surfaces, user/system moves, primary content/actions, meaningful rendered variants, prerequisites, interaction semantics, and environment-specific projections. Use when designing, reviewing, auditing, or implementing a non-trivial screen, flow, form, dashboard, navigation structure, or interactive component. Do not redefine product behavior; consume it from product-design or the task. Do not treat client-side validation as a security trust boundary, force 1:1 symmetry with design-thinking, or require every surface/state/context to share one identical graph.

Turn an engineering contract or local implementation request into a concrete implementation graph covering domain shapes, success flow, execution semantics, expected failures, contextual capabilities, trust boundaries, runtime policies, resource lifetimes, targeted verification, and code. Use when deciding how a known system contract becomes implementation. Do not own product behavior, system architecture, code review, security review, production operations, or non-trivial test strategy. Use Effect-specific A/E/R, Layer, Stream, Scope, and API conventions only when the repository actually uses Effect or the task explicitly requests Effect-style modeling; inspect the installed Effect version before generating version-specific code.

Turn a product contract or architecture-changing request into a minimal system contract by modeling required responsibilities, state ownership, boundaries and contracts, critical runtime flows, quality guarantees, and consequential architectural decisions before implementation. Use for greenfield system architecture, non-trivial feature architecture, cross-module refactors, storage or data-ownership changes, protocol changes, concurrency or consistency changes, external integrations, and production-sensitive system changes. Read .agents/product.md and the existing codebase when present. Do not design function-level code or implementation details; hand those to design-thinking. Record ADRs only for consequential decisions with real alternatives or significant long-term consequences.

Orchestrate delegated engineering work as an adaptive execution DAG of contracted outcomes, dependencies, conflicts, evidence, and integration. Use when delegation materially helps through specialization, independent parallel work, context isolation, or separate verification. Do not delegate merely because a task is medium/large or because multiple agents are available. Nodes are outcome contracts, not files. The coordinator owns scheduling, conflict avoidance, replanning, integration, and final verification; worker output is untrusted until supported by evidence.

Turn raw app or feature ideas, or changes to an existing product, into a minimal testable product contract by modeling the user problem, job, observable behavior, scope, constraints, edge cases, and proof before engineering design or implementation. Use for greenfield product definition, feature brainstorming or refinement, and product-level review. Do not choose technical architecture or implementation; use design-graph only when interface surfaces or interaction need explicit modeling.

Design and operate the minimum production health, observability, alerting, recovery, and incident-response capability required by a workload. Use when preparing a workload for first production use, when a change materially alters runtime health or recovery, when adding or reviewing monitoring/alerts/runbooks/backups, or when diagnosing and recovering from a production incident. Derive operational controls from critical flows and real failure risks. Do not own CI/CD, rollout, or rollback mechanics; release-engineering owns those mechanisms. Do not add SRE ceremony, dashboards, alerts, SLOs, or disaster-recovery machinery without a concrete operational need.

Review a code change or security-sensitive implementation by tracing changed trust, authority, exposure, and sensitive-data flows to find concrete reachable security failures. Use when a change materially touches authentication, authorization, sessions/tokens, tenant isolation, privileged operations, untrusted input to sensitive sinks, files/paths, network requests, webhooks, external integrations, secrets/keys, cryptography, sensitive data, public exposure, CORS/CSRF, abuse controls, security configuration, or security-relevant dependencies. Default to the smallest affected security graph; use broader threat-based review only for new applications, major security redesigns, incidents, or explicit audits. Do not run generic OWASP/ASVS/STRIDE checklists by ritual, block solely on scanner/CVE presence, invent custom security controls when trusted primitives already satisfy the property, or report vulnerabilities without a reachable path and evidence.

Turn a meaningful software behavior, invariant, failure mode, or regression risk into the smallest reliable executable proof at the boundary where correctness actually lives. Use when testing itself requires design: choosing unit vs integration vs contract vs concurrency vs E2E boundaries, reproducing races or async failures, proving transaction or migration behavior, designing failure/recovery tests, fixing flaky or brittle suites, or building a focused regression strategy. Do not invoke for obvious local tests that design-thinking can write directly. Do not maximize coverage, generate one test per function/file, mock the semantics being proven, or require TDD/test-pyramid quotas.