Agently Agentic Design

Use this Skill for cross-owner design and audit. It produces ownership and handoff contracts; it does not become a scheduler, TriggerFlow definition, TaskDAG, retry engine, or RuntimeEvent protocol.

For iterative design or review, use Conversation and Collaboration alongside this method for task context, progress, decisions and handoffs.

Product and collaboration boundaries

Human journeys, role/permission scenarios, UI layout, component reuse, reading experience, STE writing and diagram presentation belong to agently-product-design. Use it only for that part of a mixed task; an Agentic audit does not automatically require UI work. Pass goals, role constraints, event meanings and evidence gaps across the boundary; keep one existing work-item record.

Coding-agent progress and handoff records are owned by agently-collaboration's collaboration guidance. Runtime progress is different: request/stage completion, evidence lineage, retry convergence, provisional results and terminal acceptance stay here; mechanics stay with runtime/Stage/TriggerFlow. Never move runtime contracts into a conversation checklist or infer completion from polished status prose.

Project Stage and Scope

Infer whether the task is a new design, a partial implementation, or a production review from the available assets and evidence. Explain the basis briefly and read Project Stages for the matching questions and deliverable. Ask only for missing facts that materially change the design. Start with the business goal, constraints, and simplest sufficient solution; do not introduce a model where an exact query or deterministic program suffices. This does not permit substituting keyword rules for semantic judgment.

Do not assume a model, SDK, or framework has already been selected. For an unselected or explicitly different stack, express contracts in neutral roles first and respect that stack; apply Agently owner/API mappings only when Agently is in scope. This design review alone does not authorize a framework migration. Unresolved product/project shape still routes through agently; cross-owner design belongs here, while a resolved single-request or runtime question stays with its existing mechanism owner.

Core Workflow

1. State the business decisions and completion invariants.
2. Classify each decision as model-owned semantic work, host-owned deterministic work, or a hybrid bounded-enum/key decision.
3. Assign every decision, state, effect, and wait to one existing owner.
4. Draw request-time value dependencies and execution-time event dependencies before choosing APIs.
5. Combine ordered fields in one ModelRequest only when later fields need no observation created after dispatch. Split after Actions, system access, approval, artifact readback, or host computation needed by a later model decision.
6. Derive each prompt/output field from an authorized consumer and declare its type, constraints, visibility, retention, and failure behavior.
7. Design evidence, canonical identity joins, lifecycle, convergence, pressure, and observation before implementation.
8. For an audit, reconstruct the observed topology and identify the earliest divergent node or edge rather than inferring root cause from final output. Follow the ordered diagnostic gates in Observability and Validation: execution reachability, execution logic, actual model input, bounded Prompt experiments, then an authorized stronger-model comparison if tuning fails. When DevTools evidence or reviewer comments are available, read them through the review workflow, verify the source evidence, and return rerun findings to the original review.
9. Hand concrete implementation to the mechanism-owning Skill.

Required Topology Contract

Use the report language and record conventions in the shared collaboration guidance.

Use collaborative review when it can answer the developer's question about model-node definitions, execution effects, data completeness/redundancy, or model/Host division of work; do not require the phrase "Prompt review". First show the whole in-scope flow, highlighting model nodes, their duties and input/output handoffs alongside Host work. Read references/model-request-topology.md for the question-to-evidence checks. Use the existing topology, not another ledger; a drawing alone does not prove runtime correctness or quality. Group related node tables for comparison under ../agently-request/references/prompt-management.md: up to three logical nodes may share a reply, and tightly coupled larger groups are allowed. Clear scope can be shown with its details in the same reply. Preserve consequential-change confirmation and revisit only affected responsibilities/handoffs after revision.

Every non-trivial linear, branching, concurrent, or looped application needs:

• an owner/invariant ledger;
• a planned node ledger with each ModelRequest or host stage and its boundary reason;
• a value/event edge ledger with exact producer, validation, and consumer;
• a production-necessity ledger for every requested node, field, and artifact.

Use small project-defined reference data at a handoff only when it enables an independent consumer, parallel development, replay, local validation, or fault localization. Mark simulated data honestly and prove that real producer output can replace it. Do not invent a universal handoff packet.

Treat a non-terminal model result as a stage-scoped contribution: it must satisfy its local contract and create observable progress, but it does not need to claim whole-task completion. Unknown or deferred work remains explicit; terminal results and irreversible effects still require full acceptance.

Read by Design Question

• Owner matrix, project layers, terminology, state/storage, and stable flow versus submitted DAG: references/system-boundaries.md.
• Model-node definitions, effect tuning, data-flow correctness/redundancy, flow-first review, prompt/output contracts, same-response consumption, fan-out, joins, and instant: references/model-request-topology.md.
• Full planned-versus-observed value/signal audit: references/execution-topology-validation.md.
• TaskContext packages, TaskWorkspace/RecordStore evidence, trusted selection keys, refs, citations, snapshots, and fail-closed joins: references/information-and-evidence-design.md.
• Concurrency, retries, repair, replan, approval, pause/resume, cancellation, close, pressure, and planned long-form section generation: references/lifecycle-and-pressure-design.md.
• RuntimeEvents, lineage, request telemetry, model-quality review, and experiment comparison: references/observability-and-validation.md.

After ownership is clear:

• one request family routes to agently-request;
• AgentExecution plugins/final policies, Action, MCP, ExecutionResource, TaskWorkspace, RecordStore, service, or telemetry mechanics route to agently-runtime;
• developer-owned executable orchestration routes to agently-triggerflow;
• explicit submitted TaskDAG data remains a low-frequency agently advanced reference rather than a standalone default Skill;
• source-framework mapping routes to agently-migration.

Non-Negotiable Boundaries

• Model participation alone does not justify another request. Split only for a real decision, evidence, consumer, authorization, retry, lifecycle, or parallelism boundary.
• A ModelRequest is a dispatch-time snapshot. Provisional instant output may update UI or start cancelable/idempotent preparation, but cannot inject that preparation's result back into the running request.
• Give the model one host-issued selection key plus relevant facts. Host code validates the offered key and reconstructs canonical ids and metadata.
• If a selection can cross cache, queue, retry, persistence, or replay, bind it to host-owned semantic-request lineage and validate freshness before lookup.
• Every model-satisfiable business rule reaches the producer before its first attempt. Deliberately hidden security or integrity gates remain host-owned and need explicit failure/terminal policy.
• Do not request hidden chain-of-thought. Keep only bounded task-specific process fields with an explicit consumer and retention contract.

Completion Gate

Before implementation, confirm that every invariant has one owner, every request boundary has a reason, every output field has an authorized consumer, every provisional path has invalidation behavior, every loop has progress and terminal rules, every cross-boundary identity has freshness/correlation, and every validation rule has a declared producer or deliberately hidden host gate.

Do not replace semantic routing, relevance, planning, or quality judgment with keywords, regex, tokenization, or local score tables. Do not add a parallel execution topology beside TriggerFlow or TaskDAG.