메뉴
Create or update .agents/OPERATOR.md in the current workspace — a personal profile that tells AI models who you are, your skill levels, and how you like to collaborate. Only invoke when the user explicitly runs /operator-setup. Do not auto-trigger based on context.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | operator-setup |
| description | Create or update .agents/OPERATOR.md in the current workspace — a personal profile that tells AI models who you are, your skill levels, and how you like to collaborate. Only invoke when the user explicitly runs /operator-setup. Do not auto-trigger based on context. |
Interview the operator to create .agents/OPERATOR.md in the current workspace. This file is gitignored and loaded at the start of every session to help models calibrate explanation depth, autonomy level, and communication style.
Check if .agents/OPERATOR.md already exists. If it does, tell the user what it currently contains and ask if they want to update specific sections or start fresh.
Read AGENTS.md (or CLAUDE.md) and scan the project root for signals:
*.csproj → C# / .NETpackage.json → JavaScript / TypeScript*.py → Python*.go → GoDockerfile / docker-compose.yml → Docker / containers*.tf → TerraformYou'll use the top 2–4 technologies to ask targeted skill-level questions.
Ask questions one at a time. If a tool for presenting structured questions is available (e.g. AskUserQuestion), prefer it. Otherwise ask in plain text. Do not ask the next question until the previous one is answered.
Q1 — Role What is their primary role on this project? Ask as an open question; do not constrain to a fixed list. Common examples: Solo owner, Lead developer, Solution Architect, Backend developer, Frontend developer, Full-stack developer, Test Analyst, DevSecOps engineer, DevOps engineer. Use the answer to infer decision authority and what kinds of concerns they care about.
Q2 — Autonomy How autonomous should the model be? Options:
Q3 — Verbosity How much explanation do they want? Options:
Q4 — Working mode How do they focus when working with an AI? Options:
Q5 — Skill levels (repeat for each detected technology) For each significant technology from the detection step, ask:
How would you rate your [Technology] skill level? Options: Expert | Proficient | Functional | Beginner
Expert = deep knowledge, no need to explain idioms Proficient = comfortable day-to-day, occasional gaps in advanced topics Functional = gets things done, not a primary domain Beginner = still building foundational knowledge
Limit to the 2–4 most relevant technologies. Don't ask about every library.
Create .agents/ if it doesn't exist, then write .agents/OPERATOR.md in the workspace root:
# OPERATOR.md
Context about the human operator working with this codebase. Use this to calibrate
explanation depth, autonomy, and collaboration style.
## Role
[Role + decision authority. E.g. "Solo owner/developer. Full decision authority — no
approvals needed from stakeholders or teammates."]
## Autonomy
[One paragraph describing when to act vs. check in, based on their answer.]
## Communication Style
- **Verbosity:** [Their choice + one-line description]
- **Working mode:** [Their choice + one-line description]
## Skill Levels
| Area | Level | Notes |
|------|-------|-------|
[One row per technology. Notes column: what to skip explaining / what to surface.]
Find the repo-level instructions file: prefer AGENTS.md at the repository root, fall
back to CLAUDE.md. If neither exists, create AGENTS.md.
Add the following block if it isn't already present — don't overwrite anything else:
At the start of every session, read `.agents/OPERATOR.md` for context about the
operator (role, skill levels, collaboration style). If the file does not exist, end
your first response with:
> No operator profile found. Run `/operator-setup` to create one.
If the current directory is a git repository, add .agents/OPERATOR.md to .gitignore
(under a "User-specific files" comment if one exists, otherwise at the top). This
prevents the personal profile from being accidentally committed to a shared repo.
Tell the user the file was written and that it will be loaded automatically in future sessions in this workspace.
Identify structural problems in a codebase and write them up as technical debt documentation — one file per issue in a subfolder, plus an index. Use this skill when the user asks about structural problems, code smells, maintainability issues, architectural concerns, god classes, tight coupling, or "what's wrong with this code at a high level." Also use it when the user says things like "what should we clean up", "where is this hard to change", "what are the pain points", or "document our tech debt." The skill produces actionable write-ups, not vague observations.
Release a new version of a plugin in this repo. Handles the full release workflow — bumps both plugin.json files, writes the changelog entry, updates the Skills or Agents section of the plugin README when something new was added, and runs the sync scripts. Invoke with /release or whenever the user says "bump version", "release plugin", "add changelog", "run sync", or asks to publish or version a plugin after making any kind of change.
Use this skill for systematic scenario analysis — whenever a problem involves multiple variables, states, conditions, or failure modes and the user needs to enumerate the scenario space to find gaps, validate assumptions, or ensure coverage. Activate eagerly when the user asks "what cases should I handle?", "what could go wrong?", "am I missing any scenarios?", "how do I systematically test/model this?", or when they describe a decision table, state machine, input space, feature flag combination, risk matrix, or any artifact where multiple interacting variables might produce unexpected outcomes. Also use for non-testing contexts: config-flag interactions, requirement gap-finding, risk registers, design tradeoffs, business rule validation. This skill selects the right systematic technique, explains its reasoning, confirms with the user, and produces a structured markdown output for gap detection in code, requirements, design docs, or business rules.
Use this skill when the user wants to add test coverage targeting blind spots in a specific method — uncovered branches, edge cases, or unusual inputs. Activate on explicit requests to cover blind spots or when the user asks "what should I test here?" about a particular method. This is not about achieving 100% line coverage, but about ensuring the method behaves correctly in scenarios that are easy to miss.
Reference for adding and ordering Aspire deploy pipeline steps, tagging steps, parameterizing deployment with AddParameter, configuring per-environment values with WithEnvironment, and using PipelineStepContext services. Use when asked to add a pipeline step, order deploy steps, set up infrastructure provisioning, configure deployment, or wire up aspire deploy.
Help the user fill a specific gap in their mental model of a system. Use this skill when the user asks "why doesn't X happen", "how does Y work here", "why is this method not called", "why does this text get clipped", or any question where they clearly understand most of the system but are stuck on one specific behavior or mechanism. They have most of the picture — one piece is missing or wrong. This skill always reads back an interpretation of the gap before answering, so misunderstandings get caught early. Activate eagerly on "why" or "how does this work" questions about specific behaviors.