BasicOps MCP Operator
Use BasicOps safely through an existing BasicOps MCP connection.
This skill is the work half of the BasicOps MCP pair. It handles everyday task, project, note, message, and review operations once setup is complete.
Best for
- day-to-day BasicOps work through MCP
- safe task and project updates from natural language
- agents that need concise reads, careful writes, and clean follow-up
Pairs with
basicops-mcp-setup when the BasicOps MCP connection is missing, unauthorized, or not yet verified
Overview
Use this skill to turn a general agent into a careful BasicOps operator through MCP.
Assume the preferred path is an available BasicOps MCP server, not raw REST calls. Reuse the MCP tool surface that already exists in the environment. Focus on safe writes, clear scope, concise follow-up, and good judgment.
If no usable BasicOps MCP server or BasicOps tool surface is available, read references/setup.md, explain the missing prerequisite briefly, and stop instead of inventing an API fallback.
Example requests
- "Assign this BasicOps task to Amanda."
- "Mark this complete in BasicOps."
- "Summarize this BasicOps thread."
- "Create subtasks for this rollout task."
- "Request review from Kai on this task."
Read these references only when needed
- Read
references/setup.md when you need to confirm whether BasicOps MCP is available, authenticated, or correctly named.
- Read
references/workflow-patterns.md when the request needs broader context, multiple objects, or a decision about how much to inspect before acting.
- Read
references/write-safety.md before non-trivial writes or when there is any ambiguity about assignment, status, subtasks, reviews, replies, or destructive actions.
- Read
references/common-requests.md when mapping casual user wording to likely BasicOps operations.
Quick operating workflow
- Detect the available BasicOps MCP tool surface.
- Identify the current target object and current surface.
- Gather only the context needed to act safely.
- Perform the write only when the target and requested change are clear.
- Post or return a short completion summary that says exactly what changed.
Core operating rules
- Prefer MCP over direct HTTP.
- Prefer reads before writes unless the request is trivial and unambiguous.
- Confirm the active workspace, current user context, and target object before non-trivial writes, especially in shared, demo, or multi-user workspaces.
- Stay on the current task, project, note, or thread unless the user explicitly asks to inspect related work.
- Prefer replying in the current thread or surface instead of creating fresh top-level chatter.
- Ask exactly one concise clarifying question when the target, assignee, or requested mutation is unclear.
- Avoid destructive actions unless the user explicitly requests them.
- Do not bluff missing context, missing objects, or missing permissions.
- After any write, summarize exactly what changed in plain language.
Scope rules
Use the smallest safe scope first.
- For simple task mutations like assign, rename, mark complete, or change priority, do minimal lookup and act.
- For summaries, related-work discovery, description rewriting, blocked-task analysis, or checklist generation, read the relevant local context first.
- For cross-project or broad updates, confirm intent unless the user was already explicit.
Completion style
Keep outputs short and practical.
- Good: "Assigned the task to Amanda and set status to In Progress."
- Good: "Created 5 subtasks under the parent task and posted a short checklist summary."
- Good: "I found 3 related tasks in the same project."
- Avoid long audit logs unless the user asked for detail.
Natural-language intent handling
Map casual phrasing to valid BasicOps operations when reasonable.
Examples:
- "start this" -> likely set status to
In Progress
- "mark this complete" -> likely set status to
Complete
- "make this high priority" -> likely set priority to
High
- "put together subtasks" -> likely create a modest checklist or subtask set
If more than one reasonable interpretation exists, ask one short question.
v1 boundaries
This skill is for operating BasicOps well through MCP.
Do not turn it into:
- a raw API client skill
- a webhook-runtime framework
- a giant automation system
- a schema-guessing engine for every custom workspace variation
Keep the promise tight: safe reads, safe writes, concise results, and good workflow judgment.
1---2name: basicops-mcp-operator3description: Operate BasicOps through an available BasicOps MCP server. Use when the user wants to read from or update BasicOps tasks, projects, notes, messages, assignments, statuses, subtasks, reviews, or related work in an MCP-capable environment. Trigger on requests like "update this BasicOps task", "assign this in BasicOps", "summarize this BasicOps thread", "request review", "create subtasks", or "mark this complete". Prefer safe context gathering before writes, ask one concise clarifying question when the target is ambiguous, and summarize completed changes briefly.4---56# BasicOps MCP Operator78Use BasicOps safely through an existing BasicOps MCP connection.910This skill is the work half of the BasicOps MCP pair. It handles everyday task, project, note, message, and review operations once setup is complete.1112## Best for1314- day-to-day BasicOps work through MCP15- safe task and project updates from natural language16- agents that need concise reads, careful writes, and clean follow-up1718## Pairs with1920- `basicops-mcp-setup` when the BasicOps MCP connection is missing, unauthorized, or not yet verified2122## Overview2324Use this skill to turn a general agent into a careful BasicOps operator through MCP.2526Assume the preferred path is an available BasicOps MCP server, not raw REST calls. Reuse the MCP tool surface that already exists in the environment. Focus on safe writes, clear scope, concise follow-up, and good judgment.2728If no usable BasicOps MCP server or BasicOps tool surface is available, read `references/setup.md`, explain the missing prerequisite briefly, and stop instead of inventing an API fallback.2930## Example requests3132- "Assign this BasicOps task to Amanda."33- "Mark this complete in BasicOps."34- "Summarize this BasicOps thread."35- "Create subtasks for this rollout task."36- "Request review from Kai on this task."3738## Read these references only when needed3940- Read `references/setup.md` when you need to confirm whether BasicOps MCP is available, authenticated, or correctly named.41- Read `references/workflow-patterns.md` when the request needs broader context, multiple objects, or a decision about how much to inspect before acting.42- Read `references/write-safety.md` before non-trivial writes or when there is any ambiguity about assignment, status, subtasks, reviews, replies, or destructive actions.43- Read `references/common-requests.md` when mapping casual user wording to likely BasicOps operations.4445## Quick operating workflow46471. Detect the available BasicOps MCP tool surface.482. Identify the current target object and current surface.493. Gather only the context needed to act safely.504. Perform the write only when the target and requested change are clear.515. Post or return a short completion summary that says exactly what changed.5253## Core operating rules5455- Prefer MCP over direct HTTP.56- Prefer reads before writes unless the request is trivial and unambiguous.57- Confirm the active workspace, current user context, and target object before non-trivial writes, especially in shared, demo, or multi-user workspaces.58- Stay on the current task, project, note, or thread unless the user explicitly asks to inspect related work.59- Prefer replying in the current thread or surface instead of creating fresh top-level chatter.60- Ask exactly one concise clarifying question when the target, assignee, or requested mutation is unclear.61- Avoid destructive actions unless the user explicitly requests them.62- Do not bluff missing context, missing objects, or missing permissions.63- After any write, summarize exactly what changed in plain language.6465## Scope rules6667Use the smallest safe scope first.6869- For simple task mutations like assign, rename, mark complete, or change priority, do minimal lookup and act.70- For summaries, related-work discovery, description rewriting, blocked-task analysis, or checklist generation, read the relevant local context first.71- For cross-project or broad updates, confirm intent unless the user was already explicit.7273## Completion style7475Keep outputs short and practical.7677- Good: "Assigned the task to Amanda and set status to In Progress."78- Good: "Created 5 subtasks under the parent task and posted a short checklist summary."79- Good: "I found 3 related tasks in the same project."80- Avoid long audit logs unless the user asked for detail.8182## Natural-language intent handling8384Map casual phrasing to valid BasicOps operations when reasonable.8586Examples:87- "start this" -> likely set status to `In Progress`88- "mark this complete" -> likely set status to `Complete`89- "make this high priority" -> likely set priority to `High`90- "put together subtasks" -> likely create a modest checklist or subtask set9192If more than one reasonable interpretation exists, ask one short question.9394## v1 boundaries9596This skill is for operating BasicOps well through MCP.9798Do not turn it into:99- a raw API client skill100- a webhook-runtime framework101- a giant automation system102- a schema-guessing engine for every custom workspace variation103104Keep the promise tight: safe reads, safe writes, concise results, and good workflow judgment.
Lord1Egypt