本文へ移動
cccskills
無料GitHub で公開

creating-custom-agents

Creates GitHub Copilot custom agents (`.agent.md`) for VS Code. Use when defining a specialized agent role, selecting a minimal toolset, referencing supporting skills, or shipping install-ready agent examples with clear boundaries and collaboration rules.

日本語の概要は準備中です。原文の説明を表示しています。

jaktestowac/awesome-copilot-for-testersスター 118(GitHub 118 + cccskills 0)
連携ツールGitHub

実行スコア 未検証

インストール方法を見る

含まれるファイル(4)

  • SKILL.md4.9 KB
  • resources/custom-agent-quality-checklist.md1.3 KB
  • resources/custom-agent.example.agent.md1.6 KB
  • resources/custom-agent.template.agent.md1.1 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Creating Custom Agents

Use this skill when a reusable role needs its own identity instead of hiding inside a prompt or a skill. It helps create custom agents that are focused, tool-aware, and easy to extend without scope creep.

When to Use

Use this skill when the user asks for things like:

  • "create a custom agent for this workflow"
  • "design an agent with limited tools"
  • "turn this expert role into a .agent.md file"
  • "define how an orchestrator should delegate to specialists"
  • "fix an agent that is too broad or too verbose"

Typical scenarios:

  • creating a new single-purpose agent
  • building a specialist for a multi-agent workflow
  • tightening an existing agent's scope and tool access
  • preparing a reusable example agent for a shared repository

Outcome Standard

A strong custom agent contribution usually includes:

  • a crisp role and mission
  • a deliberate toolset rather than blanket access
  • clear guidance on when the agent should be used
  • boundaries that stop the agent from absorbing work better handled by prompts, skills, or instructions
  • an install-ready .agent.md file plus reference material

Agent Design Rules

  • Role first - define who the agent is and what it owns before writing any workflow guidance.
  • Minimal tools - only grant the tools the role genuinely needs.
  • Skills for procedure - reference skills for reusable workflows instead of stuffing the entire playbook into the agent.
  • Prompts for entrypoints - if users need a guided starting command, create a prompt file in addition to the agent.
  • Boundaries matter - explain what the agent should not do, especially when nearby agents overlap.

Workflow

Phase 0: Decide whether an agent is the right primitive

Choose an agent only when the work needs a persistent role, a specific tool profile, or a distinct collaboration pattern. If the need is only a reusable task starter, prefer a prompt. If the need is procedural knowledge, prefer a skill.

Phase 1: Study adjacent artifacts

Before drafting:

  • inspect similar agents, prompts, and skills already in the repository
  • identify the smallest role boundary that still feels useful
  • note what the agent should own directly versus delegate or reference

Phase 2: Define the agent contract

Clarify or infer:

  • the agent's mission
  • the main user requests it should handle
  • the tools it must have and the ones it should avoid
  • the output style or deliverables it should consistently produce
  • any collaboration or orchestration behavior

Phase 3: Draft the .agent.md file

Use the supporting files below while drafting:

  • ./resources/custom-agent.template.agent.md
  • ./resources/custom-agent.example.agent.md

A good first draft should cover:

  • frontmatter for name, description, model, and tools
  • a role section describing what the agent is responsible for
  • a short workflow or operating rhythm
  • constraints or anti-patterns
  • output expectations

Phase 4: Add the reference bundle

At minimum, provide:

  • the main .agent.md file
  • one example or template for reuse
  • a summary of why the chosen toolset and boundaries make sense

If the agent is part of a larger workflow, mention the prompts or skills it should work with.

Phase 5: Validate before handoff

Check the result against ./resources/custom-agent-quality-checklist.md.

Pay special attention to:

  • whether the description clearly signals when the agent should be used
  • whether the tools are minimal and intentional
  • whether the agent body defines identity and behavior instead of duplicating a skill
  • whether the output style is specific enough to be useful

Common Failure Modes

  • giving the agent a vague job like "help with everything"
  • granting too many tools out of convenience
  • embedding detailed workflow instructions that belong in a skill
  • copying repository instructions into the agent file
  • creating a new agent when a prompt or skill would have been enough

Resource Map

  • ./resources/custom-agent.template.agent.md - scaffold for a focused custom agent
  • ./resources/custom-agent.example.agent.md - worked example of a bounded specialist agent
  • ./resources/custom-agent-quality-checklist.md - final review checklist before shipping

Definition of Done

A task using this skill is complete when:

  • the role and scope are easy to explain in one short paragraph
  • the toolset matches the actual responsibilities
  • the file is install-ready and internally consistent
  • supporting template or example material exists for reuse
  • the agent passes the quality checklist without obvious overlap or confusion

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

コメント

ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。

まだコメントはありません。最初のコメントを書いてみませんか。

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。URL は 2 つまでです。

0 / 1000 文字

このフォームは reCAPTCHA で保護されており、Google のプライバシーポリシーと利用規約が適用されます。

同じリポジトリのスキル

Defines, computes, and interprets test and quality metrics: pass rate, flake rate, suite duration, defect escape rate, time to detect, and coverage with its caveats. Use when building a QA dashboard, reporting suite health to stakeholders, comparing releases over time, or when a coverage percentage or a bug count is being treated as a measure of quality.

日本語の概要は準備中です。原文の説明を表示しています。

jaktestowac/awesome-copilot-for-testers1182026年8月27日 更新

Analyzes diffs, changed files, hotfixes, and release candidates to identify where regression risk spreads and what must be retested first. Use when scoping retest after a change, reviewing QA impact for a pull request, or building a minimal confidence suite for release validation.

日本語の概要は準備中です。原文の説明を表示しています。

jaktestowac/awesome-copilot-for-testers1182026年8月27日 更新

Writes and reviews API automation tests with Playwright Test, covering setup/teardown, assertions, data management, and hybrid API+UI flows. Use when creating backend API tests, contract checks, data-driven API coverage, API+UI hybrid workflows, or reviewing existing Playwright API suites.

日本語の概要は準備中です。原文の説明を表示しています。

jaktestowac/awesome-copilot-for-testers1182026年8月27日 更新

Measures the risk that code shipped without anyone understanding it: a teach-back attestation on high-risk changes, a risk band from changed-code complexity, diff size and whether a human explanation accompanied it, and optional AI-authorship provenance. Findings stay advisory by design. Use when an AI-assisted codebase grows faster than the team reads it, when reviews are rubber-stamped, when nobody can explain a module that ships weekly, or when leadership asks how much of the code the team can actually maintain.

日本語の概要は準備中です。原文の説明を表示しています。

jaktestowac/awesome-copilot-for-testers1182026年8月27日 更新

Produces an evidence-backed go/no-go recommendation: exit criteria status, open-defect risk profile, coverage against risk, environment parity, rollback readiness, and the residual risk stated plainly. Use when preparing a release sign-off, when someone asks whether a build is ready to ship, or when a decision to release is being made on impressions rather than evidence.

日本語の概要は準備中です。原文の説明を表示しています。

jaktestowac/awesome-copilot-for-testers1182026年8月27日 更新

Records human verification - code review, exploratory sessions, UAT, accessibility passes, UX and observability reviews - as dated, attributed attestations in a register, so human-centric practices stay in the quality contract without pretending to be automated checks. Use when a strategy requires verification no tool can prove, when sign-off evidence is scattered across chats and tickets, when a gap matrix needs to distinguish "attested" from "passed", or when an audit asks who verified what and when.

日本語の概要は準備中です。原文の説明を表示しています。

jaktestowac/awesome-copilot-for-testers1182026年8月27日 更新

jaktestowac のスキルをすべて見る

このスキルの問題を報告する