design-autonomous-ai-interfaces
Skill4 starsChanged 3 months agoMITView on GitHub
WHEN/WHERE/WHO: Product designers, UX researchers, architects, and AI agents should use this skill when asked to design an autonomous AI interface, agentic product UX, AI copilots that plan or act, human-in-the-loop controls, AI workflow checkpoints, or interfaces for creative and autonomous AI systems. Near-miss: do not use it for backend-only agent implementation, prompt tuning alone, generic UI polish, or non-agentic chat copy unless the request explicitly needs user-facing AI interaction design. HOW: Use this COMPLEX SKILL to frame user intent and autonomy level, map capability and orchestration, design input/context capture, expose planning and permissions, manage progress/checkpoints/recovery, shape outputs for verification and onward action, and validate the design against shared-control criteria. WHY: Autonomous AI products can become opaque, over-trusting, or over-controlling when input, computation, output, and agent action are not designed as one loop. This skill keeps users oriented, empowered, and able to verify or redirect the system.
In this repository61 other files it gives its agents.
- activate-personalSkill
- analyze-with-tactics-questionnairesSkill
- apply-agile-testing-quadrantsSkill
- apply-architectural-tacticsSkill
- apply-attribute-driven-designSkill
- apply-fundamentals-of-data-visualizationSkill
- apply-oopsi-modelSkill
- apply-screenplay-patternSkill
- apply-specification-by-exampleSkill
- blog-topic-discoverSkill
- build-agent-memory-systemsSkill
- build-business-objectives-modelSkill
- build-data-dictionarySkill
- build-feature-treeSkill
- comment-alive-test-driven-developmentSkill
- conduct-event-stormingSkill
- create-ecosystem-mapSkill
- create-living-documentationSkill
- create-skill-from-bookSkill
- CREATING-SKILL-TEMPLATESkill
- define-architectural-driversSkill
- define-bounded-contextsSkill
- define-ubiquitous-languageSkill
- design-agentic-screenplay-modelSkill
- design-agent-perception-layersSkill
- design-agent-planningSkill
- design-agent-reward-functionsSkill
- design-agents-using-patternsSkill
- design-architecture-viewpointsSkill
- design-ddd-aggregatesSkill
- design-tool-use-sandboxingSkill
- document-architectural-decisionsSkill
- document-legacy-codebaseSkill
- doc-with-usage-exampleSkill
- draft-srs-documentSkill
- elicit-requirements-modelsSkill
- evolve-skill-with-wikiSkill
- extract-business-rulesSkill
- facilitate-example-mappingSkill
- facilitate-user-story-mappingSkill
- implement-agent-observabilitySkill
- implement-agent-reflectionSkill
- improve-existing-skillSkill
- improve-user-storySkill
- managing-ai-projectsSkill
- orchestrate-multi-agent-collaborationSkill
- prioritize-requirementsSkill
- review-c4-modelSkill
- review-data-engineeringSkill
- save-as-skillSkill
- scaffold-cmake-cxx-sanitize-gtest-envSkill
- skill-commonSkill
- task-commit-triggerSkill
- test-case-with-demoSkill
- test-case-with-readmeSkill
- test-driven-developmentSkill
- UnitTesting-convert2CaTDDSkill
- update-my-resumeSkill
- update-spec-contextSkill
- validate-requirements-criteriaSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
31 rules. About 0 are common, 31 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈31
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
When this skill is activated, first load skill-common and apply the shared conventions it defines: canonical section order, frontmatter …
- Distinctive: line 22
Use when the request includes phrases such as "design an autonomous AI interface", "agentic UX", "AI copilot workflow", "human-in-the-loop …
- Distinctive: line 23
Use when an AI feature needs visible planning, capability discovery, context controls, output verification, permission boundaries, or …
- Distinctive: line 54
Transfer Check: Verify the workflow works for at least two different AI interface types, such as a creative drafting assistant and an …
- Distinctive: line 55
Stop Rule: If the user job, AI capabilities, or side-effect risk cannot be determined, stop and ask for the missing context before …
- Distinctive: line 59
Do not make a blank prompt box carry the whole interaction when implicit context, structured fields, direct manipulation, examples, or …
- Distinctive: line 60
Do not hide which context, files, tools, memory, assumptions, or permissions shape the result.
- Distinctive: line 61
Do not present fluent output as authoritative unless the interface provides grounding, sources, review paths, or uncertainty handling …
- Distinctive: line 62
Do not use model-generated confidence percentages as the main trust mechanism.
- Distinctive: line 63
Do not flood users with every internal detail.
- Distinctive: line 66
Anti-Pattern Mapping: Avoid generic starter prompts, hidden orchestration, passive spinners for long-running work, irreversible agent …
- Distinctive: line 69
If the target user, task stakes, tool permissions, or expected AI autonomy are unclear or conflicting, stop and ask before designing the …
- Distinctive: line 77
If the task affects people, money, production systems, private data, legal obligations, or external communication, require human review …
- Distinctive: line 78
If the user only needs a simple answer or non-agentic chat, switch to a simpler UX/prompt workflow and do not add autonomous controls.
- Distinctive: line 87
If a required capability is absent or unreliable, design a fallback, escalation path, or refusal state rather than implying unsupported …
- Distinctive: line 93
Use the CARE structure for explicit prompts: context, action, results, and examples.
- Distinctive: line 96
If ambiguity is high and the cost of being wrong is meaningful, insert a short clarification step.
- Distinctive: line 105
If the agent delegates to tools or other agents, show delegated responsibilities at the level users need to evaluate risk and progress.
- Distinctive: line 112
Add checkpoints before plan approval, assumption lock-in, external action, irreversible change, low-confidence branch, or major artifact …
- Distinctive: line 115
If an error occurs, state what happened, what work was preserved, what is blocked, and what the user can do next.
- Distinctive: line 129
Run the checklist in validation-checklist against the candidate design.
- Distinctive: line 131
If validation fails and the failure is local, revise the corresponding phase and rerun the same checklist.
- Distinctive: line 132
If two validation loops fail for the same missing capability, unclear risk boundary, or impossible recovery path, stop and ask for product …
- Distinctive: line 154
Verify the design names the user job, success outcome, AI role, autonomy level, and risk profile.
- Distinctive: line 155
Verify every AI capability, tool, context source, memory source, and permission appears in the intent-capability-orchestration map.
- Distinctive: line 156
Verify users can see and adjust the context the system uses before costly or risky computation begins.
- Distinctive: line 157
Verify multistep or high-stakes workflows expose a plan, checkpoints, permission prompts, and interruption paths.
- Distinctive: line 158
Verify latency feedback explains progress at the right level without exposing irrelevant internal noise.
- Distinctive: line 159
Verify outputs are clear, grounded, verifiable, actionable, adjustable, and visually distinct from irreversible actions.
- Distinctive: line 160
Verify the design supports pause, edit direction, resume, retry, cancel, branch, and rollback wherever autonomous work can go off course.
- Distinctive: line 161
Verify at least four scenarios pass: happy path, ambiguous input, tool/permission failure, and high-risk or irreversible action.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Design Autonomous AI Interfaces
Common Contract (Load First)
When this skill is activated, first load skill-common and apply the shared conventions it defines: canonical section order, frontmatter rules, anti-pattern guidance, and the Review In Mind loop in review-in-mind. This skill adds only domain-specific rules below.
Who
Product designers, UX researchers, AI product managers, architects, and coding agents designing user-facing AI systems that capture intent, compute or plan behind the scenes, produce outputs, and may act autonomously through tools, agents, or workflows.
What
Designs an autonomous AI interface as a complete user-control loop: input, computation, output, planning, permissions, checkpoints, recovery, and onward action. The output is a design brief, flow, checklist, or implementation-ready UX specification that shows how users stay informed and in control while the AI assists, plans, or acts.
When
- Use when the request includes phrases such as "design an autonomous AI interface", "agentic UX", "AI copilot workflow", "human-in-the-loop agent", "AI checkpoints", "AI planning UI", "tool-use permissions", "agent progress and rollback", or "creative/autonomous AI interface".
- Use when an AI feature needs visible planning, capability discovery, context controls, output verification, permission boundaries, or recovery from partial failures.
- Near-miss: do not use for model training, backend orchestration code, prompt engineering alone, or generic visual redesign unless the work includes user-facing AI behavior and control surfaces.
Where
Applies to product specs, UX flows, prototypes, agentic workflow designs, AI copilots, creative AI tools, enterprise automation, developer agents, and any interface where an AI system interprets user intent, uses hidden computation, returns generated output, or performs multistep autonomous work.
Why
Autonomous AI interfaces fail when users cannot tell what the system can do, what context it is using, why it is waiting, what it plans to do next, whether an output is trustworthy, or how to stop and recover. This skill converts the book-derived input-computation-output model into a practical design workflow that preserves shared control instead of asking the user to either micromanage or surrender.
Inputs
- User Job: The user's goal, workflow, artifact, decision, or real-world action.
- AI Role: Whether the AI should advise, draft, plan, act with approval, or act with monitoring.
- Capabilities: Models, tools, data sources, retrieval paths, memory, connected services, and known limits.
- Risk Profile: Task stakes, reversibility, duration, cost, privacy sensitivity, compliance obligations, and external side effects.
- Interface Context: Platform, modality, UI constraints, existing design system, and expected user expertise.
- Evidence: Existing specs, screenshots, workflows, user research, failure reports, or source material when available.
Output (Logical Evidence)
- An autonomous AI interface design brief or UX specification.
- An intent/capability/orchestration map.
- An input and context-capture model.
- A planning, progress, permissions, checkpoint, and recovery model.
- Output presentation rules for clarity, grounding, verification, actionability, and adjustability.
- A validation checklist or scenario walkthrough proving the design supports shared control.
Optimization Readiness
- Failure Signals: Designs rely on a blank prompt box, hide context or tools, expose plans at the wrong granularity, overuse approvals for low-risk actions, skip approval for high-impact actions, make output look authoritative without evidence, or provide only "try again" recovery.
- Evidence To Collect: User journey maps, prototype walkthroughs, usability findings, support tickets, agent traces, permission prompts, error states, user edits, rollback events, and examples where users misunderstood AI capability or output confidence.
- Safe Mutation Boundaries: Refine trigger wording, phase prompts, checklist items, risk categories, autonomy labels, examples, and detail files without removing the input-computation-output spine or the shared-control validation gate.
- Acceptance Criteria: Accept revisions only if the skill still produces designs that name user intent, map capability, show context, define autonomy level, expose planning when stakes require it, manage latency, validate outputs, and preserve pause/edit/resume/rollback paths.
- Rejected Revision Handling: Record failed patterns such as generic "ask me anything" flows, opaque agent execution, decorative confidence scores, consent-dark-pattern permissions, and irreversible action shortcuts so future revisions do not reintroduce them.
- Transfer Check: Verify the workflow works for at least two different AI interface types, such as a creative drafting assistant and an enterprise automation agent.
- Stop Rule: If the user job, AI capabilities, or side-effect risk cannot be determined, stop and ask for the missing context before designing autonomous behavior.
Constraints (Logical Boundaries)
- Design from the user's job and success outcome first, then map AI capability to that workflow.
- Do not make a blank prompt box carry the whole interaction when implicit context, structured fields, direct manipulation, examples, or clarifying questions would reduce ambiguity.
- Do not hide which context, files, tools, memory, assumptions, or permissions shape the result.
- Do not present fluent output as authoritative unless the interface provides grounding, sources, review paths, or uncertainty handling appropriate to the domain.
- Do not use model-generated confidence percentages as the main trust mechanism.
- Do not flood users with every internal detail. Use progressive disclosure from glanceable state to detailed records.
- Require explicit approval for external, expensive, privacy-sensitive, destructive, or hard-to-reverse actions.
- Preserve recovery paths: pause, edit direction, resume, retry from checkpoint, skip, cancel, branch, and roll back.
- Anti-Pattern Mapping: Avoid generic starter prompts, hidden orchestration, passive spinners for long-running work, irreversible agent actions that look like previews, vague errors, and output-only designs with no onward action.
One More Thing
If the target user, task stakes, tool permissions, or expected AI autonomy are unclear or conflicting, stop and ask before designing the interface.
How (Structural Workflow)
Phase 1: Frame the User Job and Autonomy Level
Input State: A product idea, AI feature request, user workflow, or interface problem.
- Name the primary user, the job to be done, the workflow start and end state, and the output or action the user values.
- Classify the AI role: Advise, Draft, Plan, Act With Approval, or Act With Monitoring.
- If the task affects people, money, production systems, private data, legal obligations, or external communication, require human review before meaningful action.
- If the user only needs a simple answer or non-agentic chat, switch to a simpler UX/prompt workflow and do not add autonomous controls. Output State: A declared user job, success outcome, risk profile, and autonomy level.
Phase 2: Map Capability, Discovery, and Orchestration
Input State: A declared user job and autonomy level.
- Inventory the model capabilities, tools, data sources, memory, retrieval paths, connected services, and known limitations.
- Map each capability to a concrete user task. If a capability does not serve the user job, remove it from the primary flow.
- Design capability discovery through task-specific examples, templates, controls, empty states, and mode labels.
- Make orchestration intentional, transparent, and recognizable: show what changed when a model, tool, permission, data source, or mode changes.
- If a required capability is absent or unreliable, design a fallback, escalation path, or refusal state rather than implying unsupported autonomy. Output State: An intent-capability-orchestration map with visible user-facing controls.
Phase 3: Design Input, Context, and Clarification
Input State: A capability map and target workflow.
- Split intent capture across implicit context, explicit prompts, and direct manipulation.
- Use the CARE structure for explicit prompts: context, action, results, and examples.
- Show context that the AI will use, such as selected text, attached files, active workspace, source data, prior turns, or connected tools.
- Let users add, remove, narrow, replace, or freeze context before expensive or risky computation begins.
- If ambiguity is high and the cost of being wrong is meaningful, insert a short clarification step. If cost is low, allow execution with editable assumptions. Output State: An input model that captures intent without making the user over-explain everything in text.
Phase 4: Design Planning, Permissions, and Execution
Input State: An input model and AI autonomy level.
- For multistep, high-stakes, expensive, or long-running work, expose an initial plan before execution.
- For routine low-risk tasks, allow silent planning but keep progress and recovery visible.
- Tune plan granularity to task complexity: short tasks need a compact outline; longer workflows need phases, dependencies, branch points, and expandable detail.
- Define permission prompts at the moment access is needed. Each prompt must state what is accessed, why it is needed, what will happen next, and how access can be revoked.
- If the agent delegates to tools or other agents, show delegated responsibilities at the level users need to evaluate risk and progress. Output State: A plan and execution model with consent boundaries and visible delegation.
Phase 5: Design Progress, Checkpoints, and Recovery
Input State: A plan and execution model.
- Match latency feedback to duration and stakes: immediate results for subsecond work, status for short delays, and progress with estimates or step state for long-running work.
- Layer progress communication: notification, overview status, detailed step view, and full record or trace.
- Add checkpoints before plan approval, assumption lock-in, external action, irreversible change, low-confidence branch, or major artifact transition.
- At each checkpoint, show what was done, what is pending, what the system is waiting for, and what options the user has.
- Preserve rollback or branching for evolving artifacts such as documents, dashboards, code, workflows, or generated media.
- If an error occurs, state what happened, what work was preserved, what is blocked, and what the user can do next. Output State: A progress and recovery model that keeps long-running autonomy understandable and interruptible.
Phase 6: Design Outputs and Onward Action
Input State: A completed or intermediate AI result.
- Shape outputs to be clear, verifiable, grounded, actionable, and adjustable.
- Choose presentation structures that match the task: summary, comparison, table, canvas, diff, preview, generated artifact, recommendation, or step-by-step plan.
- Separate draft, preview, send, publish, commit, delete, and external-share actions visually and behaviorally.
- Provide citations, source links, provenance, comparison views, review-before-act flows, or human approval where objective claims or real-world effects matter.
- Let users revise selected parts, regenerate variants, compare versions, accept partial outputs, or turn output edits into the next input. Output State: An output and action model that supports trust, editing, verification, and continuation.
Phase 7: Validate with Scenarios and Iterate
Input State: A candidate autonomous AI interface design.
- Run the checklist in validation-checklist against the candidate design.
- Walk through at least four scenarios: happy path, ambiguous input, tool/permission failure, and high-risk or irreversible action.
- If validation fails and the failure is local, revise the corresponding phase and rerun the same checklist.
- If two validation loops fail for the same missing capability, unclear risk boundary, or impossible recovery path, stop and ask for product or technical clarification. Output State: A validated design brief or a clearly stated blocker with the missing decision.
Resources
- principles - Core principles and the input-computation-output control loop.
- intent-capability-orchestration - Capability discovery, orchestration, and configuration guidance.
- input-patterns - Implicit context, explicit prompting, direct manipulation, and CARE prompts.
- agentic-workflow-patterns - Planning, delegation, branching, and autonomy-level patterns.
- progress-checkpoints-permissions - Latency, progress, checkpoints, rollback, and permissions.
- output-validation-and-recovery - Output design, grounding, verification, action, and recovery.
- validation-checklist - Operational checklist for scenario review.
Review In Mind (ReviewInMindGenie)
Execute the common review loop in review-in-mind before delivering.
Review lens for this skill:
- Does the design close the full loop: input, computation, output, planning, permissions, checkpoints, recovery, onward action?
- Are permission gates and checkpoints placed before every risky mutation?
- Would a user remain informed and in control at every stage?
Validation (Verifiable Rewards)
- Verify the design names the user job, success outcome, AI role, autonomy level, and risk profile.
- Verify every AI capability, tool, context source, memory source, and permission appears in the intent-capability-orchestration map.
- Verify users can see and adjust the context the system uses before costly or risky computation begins.
- Verify multistep or high-stakes workflows expose a plan, checkpoints, permission prompts, and interruption paths.
- Verify latency feedback explains progress at the right level without exposing irrelevant internal noise.
- Verify outputs are clear, grounded, verifiable, actionable, adjustable, and visually distinct from irreversible actions.
- Verify the design supports pause, edit direction, resume, retry, cancel, branch, and rollback wherever autonomous work can go off course.
- Verify at least four scenarios pass: happy path, ambiguous input, tool/permission failure, and high-risk or irreversible action.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

