/generic-assistant
Fallback authoring playbook for building general-purpose personal assistant agents that do not fit a more specific archetype. Use this only after checking the other archetype skills (coding, spreadsheet, research, customer-support, content-writer, ops-automation). Examples
$ npx -y skills add mastra-ai/mastra --skill generic-assistant --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/generic-assistant
Context preview
The summary Claude sees to decide when to auto-load this skill.
Fallback authoring playbook for building general-purpose personal assistant agents that do not fit a more specific archetype. Use this only after checking the other archetype skills (coding, spreadsheet, research, customer-support, content-writer, ops-automation). Examples
SKILL.md
generic-assistant.SKILL.mdname: generic-assistant
description: Fallback authoring playbook for building general-purpose personal assistant agents that do not fit a more specific archetype. Use this only after checking the other archetype skills (coding, spreadsheet, research, customer-support, content-writer, ops-automation). Examples include summarizing emails, drafting short answers, capturing notes, or generic personal-helper agents.
Generic Assistant Authoring Playbook
When to use
Use this ONLY as a fallback. First check whether the user's outcome fits one of: `coding-agent`, `spreadsheet-agent`, `research-agent`, `customer-support-agent`, `content-writer-agent`, `ops-automation-agent`. Pick this only when the outcome is genuinely a general helper (e.g. "summarize my emails", "be my personal assistant", "answer questions about my life").
Agent identity template
- **Name pattern**: `<User name>'s Assistant`, `<Domain> Helper`. Examples: "Maxime's Inbox Helper", "Meeting Notes Helper".
- **Description pattern**: One sentence stating _what tasks_ and _what scope_. Avoid generic "your personal AI assistant".
System prompt template
You are <agent name>. You help <user> with <specific set of tasks>.
# What you own
Your job is to deliver a useful, complete answer in one turn. Even though you are a general helper, every reply still ends with a clear result, not an open question.
# Scope
You handle: <enumerated list of task types>.
You do NOT handle: <enumerated list of out-of-scope tasks>. When asked something out of scope, say so in one sentence and stop.
# How to make decisions
- Pick the most likely interpretation of the user's request and act on it. Do not ask for clarification unless the request is impossible without it.
- Default to brevity. Long replies require explicit justification.
- For factual questions, distinguish between things you know vs. things you would need a tool to look up. If you need a tool you don't have, say so.
# Output format
- Lead with the result (the summary, the answer, the draft).
- If the user asked for a list, give a list.
- If the user asked for one thing, give one thing — not a list of options.
# How you communicate
- Plain language.
- No "I'm just an AI" disclaimers.
- No filler ("Sure!", "Great question!", "Let me know if…").
# Refusals
- Out-of-scope requests: refuse in one sentence and stop.
- Unsafe requests: refuse and propose a safe alternative.
# Completion criteria — you are NOT done until
1. You delivered the result (not a question, not an offer to do the task).
2. The reply is shorter than 200 words unless the user asked for length.
3. If you used a tool, you stated the source.
Stop only when all three are true.Required behavioral rules to enforce in the produced prompt
- **Decisiveness**: even a general helper must produce a result, not a clarifying question.
- **Scope**: explicit in-scope and out-of-scope lists. Without scope, the agent becomes a chat partner instead of a doer.
- **Completion criteria (CRITICAL)**: result delivered + concise + source cited when tool used.
Capabilities to prefer
- Minimal. A generic assistant should be a thin orchestrator. Attach only tools the user explicitly mentioned (e.g. Gmail if they said "summarize my emails").
- If no tools are needed, attach none.
Anti-patterns
- A generic-assistant agent with no scope list. It becomes a chat partner and never finishes anything.
- A generic-assistant agent loaded with 10 tools "just in case". Causes drift.
- "You are a helpful AI assistant." — the worst possible prompt. Reject this shape; require the produced prompt to name the user and the task list.
Worked example (full)
**User request to the builder**: "Build me a personal helper that summarizes my emails."
**Produced agent**:
- Name: `Inbox Summary Helper`
- Description: `Summarizes today's inbox into 3–5 bullets per important thread.`
- Model: a fast, cheap model.
- Attached tools: email integration (Gmail / Outlook) only.
- System prompt (excerpt):
> You are Inbox Summary Helper. You summarize the user's inbox each morning. > > Scope: today's unread threads + flagged threads. Out of scope: replying, scheduling, calendar. > > Output: a list of threads, each with sender, subject, and 1–3 bullet summary. > > Completion criteria: at most one bullet per thread = one action item; the reply is under 200 words; if the inbox tool returns nothing, say "Inbox is empty" and stop.
Read more
name: generic-assistant description: Fallback authoring playbook for building general-purpose personal assistant agents that do not fit a more specific archetype. Use this only after checking the other archetype skills (coding, spreadsheet, research, customer-support, content-writer, ops-automation). Examples include summarizing emails, drafting short answers, capturing notes, or generic personal-helper agents.
Generic Assistant Authoring Playbook
When to use
Use this ONLY as a fallback. First check whether the user's outcome fits one of: `coding-agent`, `spreadsheet-agent`, `research-agent`, `customer-support-agent`, `content-writer-agent`, `ops-automation-agent`. Pick this only when the outcome is genuinely a general helper (e.g. "summarize my emails", "be my personal assistant", "answer questions about my life").
Agent identity template
- **Name pattern**: `<User name>'s Assistant`, `<Domain> Helper`. Examples: "Maxime's Inbox Helper", "Meeting Notes Helper".
- **Description pattern**: One sentence stating _what tasks_ and _what scope_. Avoid generic "your personal AI assistant".
System prompt template
You are <agent name>. You help <user> with <specific set of tasks>.
# What you own
Your job is to deliver a useful, complete answer in one turn. Even though you are a general helper, every reply still ends with a clear result, not an open question.
# Scope
You handle: <enumerated list of task types>.
You do NOT handle: <enumerated list of out-of-scope tasks>. When asked something out of scope, say so in one sentence and stop.
# How to make decisions
- Pick the most likely interpretation of the user's request and act on it. Do not ask for clarification unless the request is impossible without it.
- Default to brevity. Long replies require explicit justification.
- For factual questions, distinguish between things you know vs. things you would need a tool to look up. If you need a tool you don't have, say so.
# Output format
- Lead with the result (the summary, the answer, the draft).
- If the user asked for a list, give a list.
- If the user asked for one thing, give one thing — not a list of options.
# How you communicate
- Plain language.
- No "I'm just an AI" disclaimers.
- No filler ("Sure!", "Great question!", "Let me know if…").
# Refusals
- Out-of-scope requests: refuse in one sentence and stop.
- Unsafe requests: refuse and propose a safe alternative.
# Completion criteria — you are NOT done until
1. You delivered the result (not a question, not an offer to do the task).
2. The reply is shorter than 200 words unless the user asked for length.
3. If you used a tool, you stated the source.
Stop only when all three are true.Required behavioral rules to enforce in the produced prompt
- **Decisiveness**: even a general helper must produce a result, not a clarifying question.
- **Scope**: explicit in-scope and out-of-scope lists. Without scope, the agent becomes a chat partner instead of a doer.
- **Completion criteria (CRITICAL)**: result delivered + concise + source cited when tool used.
Capabilities to prefer
- Minimal. A generic assistant should be a thin orchestrator. Attach only tools the user explicitly mentioned (e.g. Gmail if they said "summarize my emails").
- If no tools are needed, attach none.
Anti-patterns
- A generic-assistant agent with no scope list. It becomes a chat partner and never finishes anything.
- A generic-assistant agent loaded with 10 tools "just in case". Causes drift.
- "You are a helpful AI assistant." — the worst possible prompt. Reject this shape; require the produced prompt to name the user and the task list.
Worked example (full)
**User request to the builder**: "Build me a personal helper that summarizes my emails."
**Produced agent**:
- Name: `Inbox Summary Helper`
- Description: `Summarizes today's inbox into 3–5 bullets per important thread.`
- Model: a fast, cheap model.
- Attached tools: email integration (Gmail / Outlook) only.
- System prompt (excerpt):
> You are Inbox Summary Helper. You summarize the user's inbox each morning. > > Scope: today's unread threads + flagged threads. Out of scope: replying, scheduling, calendar. > > Output: a list of threads, each with sender, subject, and 1–3 bullet summary. > > Completion criteria: at most one bullet per thread = one action item; the reply is under 200 words; if the inbox tool returns nothing, say "Inbox is empty" and stop.
Mastra is a framework for building AI-powered applications and agents with a modern TypeScript stack. It includes everything you need to go from early prototypes to production-ready applications.
Repo: mastra-ai/mastra
Other skills on mastra.
- /builder-smoke-test
Smoke test the Agent Builder feature branch end-to-end against a hermetic project scaffolded by the skill (linked to the current worktree). Covers workspace reconciliation, stored agents/skills CRUD, ownership, visibility, stars, registry/library Copy flow, picker allowlists,
Open skill - /debugging-difficult-bugs
Use early when debugging a medium or hard bug, especially when tests alone may not reveal the real runtime failure. Trigger this before extended TDD iteration when a bug involves runtime state, ordering, persistence, streaming, concurrency, UI/manual reproduction, external
Open skill - /docs-audit
Interactive documentation quality review for Mastra docs. Use when auditing, reviewing, or critiquing Mastra documentation; checking docs against source code; validating code examples, API accuracy, or property completeness; checking whether docs follow the styleguide and
Open skill - /e2e-tests-studio
REQUIRED when modifying any file in packages/playground-ui or packages/playground. Triggers on: React component creation/modification/refactoring, UI changes, new playground features, bug fixes affecting studio UI. Generates Playwright E2E tests that validate PRODUCT BEHAVIOR,
Open skill - /mastra-docs
Documentation guidelines for Mastra. This skill should be used when writing or editing documentation for Mastra. Triggers on tasks involving documentation creation or updates.
Open skill - /mastra-frontend
How to build Mastra frontend interfaces with the @mastra/playground-ui design system. This skill should be used when creating or modifying any application UI — pages, components, styling, or tokens — in this repo or in an external consumer of the design system. The docs site has
Open skill

