Generating Agent Specifications

• Name: refund-handler-agent
• Purpose: Process and validate customer refund requests end-to-end
• Role: Autonomous transactional agent, operates within finance workflow
• Capabilities:
  • Validate refund eligibility against policy rules
  • Interface with payment gateway API
  • Escalate ambiguous cases to human reviewer
• Inputs: refund request payload (order_id, reason, amount)
• Outputs: refund_status, audit_log_entry
• Constraints: max refund without approval = $200; must log every decision

• validating-refund-eligibility → checks order history + policy
• calling-payment-gateway → issues refund transaction
• escalating-to-human → routes edge cases

• Requires: order database (read), payment gateway (write), policy config
• Depends on: auth-agent (for permission checks)
• Consumed by: customer-support-agent

• Init: load policy config, verify gateway credentials
• Active: process requests, log decisions
• Degrade: fallback to human queue if gateway unavailable
• Retire: deprecate when replaced by v2, archive audit logs

• Name: comment-moderation-agent
• Purpose: Detect and act on policy-violating comments in real time
• Role: Autonomous, low-risk actions auto-applied; high-risk flagged
• Capabilities:
  • Classify comment toxicity/spam
  • Auto-hide comments above severity threshold
  • Flag borderline cases for human moderator
• Inputs: comment_text, user_id, thread_context
• Outputs: moderation_decision, flagged_queue_entry
• Constraints: false-positive rate must stay below 2%; all auto-hides reversible within 24h

• classifying-comment-toxicity → NLP classification model call
• auto-hiding-comments → applies moderation action
• flagging-for-review → sends to human queue

• Requires: toxicity classifier model, forum comment DB
• Depends on: user-reputation-agent (context signal)
• Consumed by: forum-frontend-service

• Init: load classifier model, warm cache of recent user history
• Active: stream-process incoming comments
• Degrade: if classifier latency > 500ms, fallback to keyword filter only
• Retire: sunset when replaced by multilingual model v3

**Example 2:**
Input: "agent buat"

Output:
```markdown

• Name: unnamed-agent (needs clarification)
• Purpose: [insufficient information — request more detail on domain/goal]
• Role: TBD
• Capabilities: TBD
• Inputs/Outputs: TBD
• Constraints: TBD

• TBD — cannot map skills without defined capabilities

• TBD — cannot determine dependencies without scope

• TBD — cannot plan lifecycle without purpose

Note: Provide the agent's domain, task, and expected inputs/outputs to generate a complete specification.

• Keep capability names as concrete verb phrases ("validate X", "call Y API"), never abstract traits ("smart", "helpful").
• Every skill in Skill Mapping must trace back to a capability in the Agent Specification — no orphan skills.
• Dependency Map must distinguish between hard dependencies (blocking) and soft dependencies (optional/fallback exists).
• Lifecycle Plan must always include a degrade/fallback state — agents without failure modes are incomplete specs.
• Prefer narrow, single-responsibility agents over broad multi-purpose ones; split if capability list exceeds ~5 distinct concerns.

• Don't skip straight to implementation details (code, prompts) — this skill produces specs, not the agent itself.
• Don't leave Dependency Map empty just because the agent "seems standalone" — check for implicit data/auth/config dependencies.
• Don't conflate Role with Capabilities — role is the agent's operating posture (autonomous/assistive/supervisory), capabilities are what it does.
• Don't omit the Retire stage in Lifecycle Plan — every agent needs a deprecation/replacement path.
• If the request is vague, don't fabricate specifics — output a partial spec with explicit "TBD/needs clarification" markers instead of guessing.