From whetstone
Design agent-native applications where agents replace UI users as the primary actor. Use when designing MCP tools, agent-loop architectures, system prompt design, hooks policy, shared-workspace file patterns, or self-modifying agent systems.
How this skill is triggered — by the user, by Claude, or both
Slash command
/whetstone:ia-agent-native-architectureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Five principles govern agent-native design. For detailed explanations, examples, and test criteria, see [core-principles.md](./references/core-principles.md).
SPEC.mdreferences/action-parity-discipline.mdreferences/agent-execution-patterns.mdreferences/agent-native-testing.mdreferences/anti-patterns.mdreferences/architecture-patterns.mdreferences/core-principles.mdreferences/dynamic-context-injection.mdreferences/files-universal-interface.mdreferences/from-primitives-to-domain-tools.mdreferences/hooks-patterns.mdreferences/mcp-tool-design.mdreferences/mobile-cost.mdreferences/mobile-execution.mdreferences/mobile-patterns.mdreferences/mobile-storage.mdreferences/product-implications.mdreferences/quick-start.mdreferences/refactoring-to-prompt-native.mdreferences/self-modification.mdFive principles govern agent-native design. For detailed explanations, examples, and test criteria, see core-principles.md.
| Principle | One-line test |
|---|---|
| Parity | Can the agent achieve every outcome the UI allows? |
| Granularity | Changing behavior means editing prose, not refactoring code |
| Composability | Can a feature be added by writing a new prompt, without new code? |
| Emergent Capability | Can the agent handle open-ended requests it wasn't designed for? |
| Improvement Over Time | Does the app work better after a month, even without code changes? |
Wait for response before proceeding.
| Response | Action |
|---|---|
| 1, "design", "architecture", "plan" | Read architecture-patterns.md, then apply Architecture Checklist below |
| 2, "files", "workspace", "filesystem" | Read files-universal-interface.md and shared-workspace-architecture.md |
| 3, "tool", "mcp", "primitive", "crud" | Read mcp-tool-design.md |
| 4, "domain tool", "when to add" | Read from-primitives-to-domain-tools.md |
| 5, "execution", "completion", "loop" | Read agent-execution-patterns.md |
| 6, "prompt", "system prompt", "behavior" | Read system-prompt-design.md |
| 7, "context", "inject", "runtime", "dynamic" | Read dynamic-context-injection.md |
| 8, "parity", "ui action", "capability map" | Read action-parity-discipline.md |
| 9, "self-modify", "evolve", "git" | Read self-modification.md |
| 10, "product", "progressive", "approval", "latent demand" | Read product-implications.md |
| 11, "mobile", "ios", "android", "background", "checkpoint" | Read mobile-patterns.md |
| 11a, "icloud", "storage", "documents", "file state", "entitlement" | Read mobile-storage.md |
| 11b, "background task", "battery", "on-device", "cloud routing" | Read mobile-execution.md |
| 11c, "model tier", "token budget", "cost-aware", "batch", "caching" | Read mobile-cost.md |
| 12, "test", "testing", "verify", "validate" | Read agent-native-testing.md |
| 13, "review", "refactor", "existing" | Read refactoring-to-prompt-native.md |
| 14, "anti-pattern", "mistake", "wrong" | Read anti-patterns.md |
| 15, "success", "criteria", "verify", "checklist" | Read success-criteria.md |
| 16, "hook", "hooks", "PreToolUse", "decision control", "async hook" | Read hooks-patterns.md |
| 0, "quick start", "getting started", "overview", "introduction" | Read quick-start.md |
After reading the reference, apply those patterns to the user's specific context.
When designing an agent-native system, verify these before implementation:
z.string() inputs when the API validates, not z.enum()complete_task tool (not heuristic detection)refresh_context tool)When designing architecture, explicitly address each checkbox in the plan.
npx claudepluginhub iliaal/whetstone --plugin whetstoneCreates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.