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

creating-skills

Creates GitHub Copilot skills with reusable workflows, companion resources, and validation gates. Use when packaging repeatable expertise into a `SKILL.md` folder, deciding what belongs in the skill body versus resources, or producing install-ready skill examples for a team or collection.

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

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

実行スコア 未検証

インストール方法を見る

含まれるファイル(4)

  • SKILL.md5.2 KB
  • resources/skill-quality-checklist.md1.7 KB
  • resources/SKILL.example.md1.9 KB
  • resources/SKILL.template.md1.5 KB

SKILL.md(原文)

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

Creating Copilot Skills

Use this skill when reusable know-how deserves a home of its own instead of living in prompts or chat history. It helps create skills that are discoverable, concise, and bundled with the right supporting assets.

When to Use

Use this skill when the user asks for things like:

  • "create a new Copilot skill"
  • "package this workflow as a reusable skill"
  • "turn our team process into a SKILL.md"
  • "add templates and examples to a skill folder"
  • "fix a skill that is too long, vague, or hard to trigger"

Typical scenarios:

  • creating a brand-new skill folder
  • refactoring a bloated SKILL.md into a leaner body plus resource files
  • improving discovery quality through better naming and descriptions
  • preparing a public-ready skill with templates, examples, and a validation checklist

Outcome Standard

A strong skill contribution usually includes:

  • a name that clearly describes the activity the skill supports
  • a description that explains both what the skill does and when to use it
  • a SKILL.md body that teaches a workflow, not a persona
  • supporting resources that are loaded on demand instead of bloating the main file
  • a clear definition of done so the agent knows when to stop

Skill Design Rules

  • Activity, not topic - name the skill after the task it performs, not the subject area alone.
  • Trigger-friendly descriptions - include realistic user phrases and contexts.
  • Progressive disclosure - keep the skill body focused; move templates, examples, and detailed checklists into resources/.
  • One coherent capability - avoid turning one skill into a junk drawer of unrelated workflows.
  • Workflow first - the main body should help the agent execute the task step by step.

Workflow

Phase 0: Frame the capability

Clarify or infer:

  • the exact task the skill should help perform
  • the signals that should trigger the skill
  • the expected output or artifact bundle
  • what makes the skill distinct from nearby skills in the repository

Phase 1: Map the activation surface

Before writing:

  • inspect nearby skills for naming, tone, and scope boundaries
  • list the phrases a user would naturally use when asking for this capability
  • identify which context belongs in the body and which belongs in resources

Phase 2: Design the skill folder

Plan the folder contents before drafting:

  • SKILL.md for the activation and workflow logic
  • resources/ for templates, examples, decision guides, or checklists
  • optional scripts only when executable logic is genuinely useful

Default to a small bundle first. Add more files only when they remove ambiguity or repetition.

Phase 3: Draft the SKILL.md

Make the main file do the high-value work:

  • introduce when the skill should activate
  • explain what a good outcome looks like
  • provide a concrete workflow with phases or checklists
  • link to supporting files instead of duplicating their content
  • include a short definition of done

Phase 4: Add the artifact bundle

Use these support files when building the folder:

  • ./resources/SKILL.template.md
  • ./resources/SKILL.example.md
  • ./resources/skill-quality-checklist.md

At minimum, include:

  • one template or scaffold
  • one example showing tone and scope
  • one checklist or quality gate for final validation

Phase 5: Validate for discoverability

Check the final result against ./resources/skill-quality-checklist.md.

Pay special attention to:

  • whether the name still makes sense as a slash command
  • whether the description would help an agent choose the skill correctly
  • whether the workflow is concrete enough to execute without guesswork
  • whether supporting files are shallow, relevant, and clearly named

Common Failure Modes

  • using a noun like playwright or security as the entire skill name
  • writing a description that says what the skill is about but never says when to use it
  • turning the body into a long theory document instead of a working procedure
  • embedding templates inline until the skill becomes noisy and fragile
  • mixing multiple loosely related jobs into one skill because they feel adjacent

Resource Map

  • ./resources/SKILL.template.md - base scaffold for the main skill file
  • ./resources/SKILL.example.md - complete example of a compact, user-invocable skill
  • ./resources/skill-quality-checklist.md - final review checklist before shipping

Definition of Done

A task using this skill is complete when:

  • the folder name, frontmatter name, and skill purpose all align
  • the description is discoverable and specific
  • the body teaches a repeatable workflow rather than generic advice
  • templates, examples, and validation material exist where they reduce ambiguity
  • the final bundle passes the checklist without obvious overlap or missing context

レビュー

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

コメント

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

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

送信するとすぐに公開されます。メールアドレスや電話番号などの個人情報は書かないでください。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 のスキルをすべて見る

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