agentic-skill-architect

Files (1)

• SKILL.md

SKILL.md (first lines)

# Agentic Skill Architect

Use this skill when someone wants to design, audit, or share an "agentic skill" and the real question is:

- what should be inside the skill itself
- what should stay in runtime infrastructure
- what safety, durability, and approval requirements must exist before the workflow is trustworthy

This skill is intentionally useful to both:

- builders designing new skill systems or shareable skills
- practical users trying to judge whether an AI workflow is sensible or over-engineered

## What This Skill Does

- separates lightweight skill logic from runtime dependencies
- converts vague "make it agentic" requests into a concrete design review
- identifies trust boundaries, side effects, and approval needs
- recommends activation posture and evaluation checks
- returns a shareable skill concept without pretending runtime infrastructure belongs inside `SKILL.md`

## What This Skill Does Not Do

- it does not install or enable a skill automatically
- it does not invent a second plugin system
- it does not treat policy, checkpoints, or memory stores as skill-owned code by default
- it does not assume that more autonomy is always better

## When To Use

Use this skill when the user asks things like:

- "Design an agentic skill for this workflow."
- "Review this skill architecture."
- "Is this actually a skill or is it runtime infrastructure?"
- "Help me make this shareable."
- "What belongs in `SKILL.md` versus the underlying system?"

## When Not To Use

Do not use this skill when:

- the task is simply to author a basic skill and the structure is already obvious
- the task is to implement runtime code, not design the boundary
- the user is asking for a normal prompt, playbook, or template with no architecture question

## Required Inputs

- the workflow or capability being proposed
- target users or operators
- expected side effects, if any
- environment assumptions:
  - local only
  - cloud
  - hybrid
- trust expectations:
  - read-only
  - approval-gated writes
  - autonomous writes

## Optional Inputs

- current skill or prompt draft
- existing runtime primitives
- target surface or mode
- examples of good and bad prior behavior

## Core Distinction

Start with this rule:

- put **instructions, heuristics, triggers, output expectations, and workflow guidance** in the skill
- put **policy, approvals, durability, memory storage, orchestration state, execution engines, and audit systems** in runtime infrastructure

If a proposal includes per-skill executors, checkpoint stores, approval services, or tool runtimes, assume it is probably drifting out of skill territory unless there is a very strong reason otherwise.

## Review Workflow

1. Clarify the real job:
   - What outcome should the skill help produce?
   - Who is using it?
   - What is the minimum successful behavior?

2. Identify side effects:
   - read-only
   - write to local files
   - external API mutation
   - messaging, billing, deployment, or production control

3. Separate skill content from runtime requirements:
   - Skill content:
     - triggers
     - workflow
     - output contract
     - failure modes
     - examples
   - Runtime requirements:
     - approvals
     - tool execution
     - checkpointing
     - audit logging
     - memory persistence
     - multi-agent coordination

4. Decide activation posture:
   - advisory only
   - operator-guided
   - approval-gated execution
   - highly restricted / not appropriate as a skill

5. Define evaluation:
   - how do we know the skill helped?
   - what regressions would make it unsafe or noisy?
   - what should never happen silently?

## Output Contract

Return these sections:

From goatcitadel/GoatCitadel, Apache-2.0.

More from goatcitadel/GoatCitadel