nist0
66 verified skills
copilot_dev/.github/skills/engineering/cicd/github-actions
# GitHub Actions CI/CD Basics ## When to use - You need to build a pipeline or troubleshoot a failing workflow - You want quality gates (lint/tests/docs) enforced on PRs - You need a minimal, reliable “fast checks” stage ## Workflow 1) Identify pipeline intent: - PR checks vs main branch release 2) Standard jobs: - build, unit tests, lint/format, docs quality 3) Use caching carefully: - restore keys, avoid stale artifacts 4) Fail-fast rules: - small fast jobs on PR - separate
development
copilot_dev/.github/skills/engineering/cicd/release
# Release Engineering (SemVer, Artifacts, Rollout/Rollback) ## When to use - You need a consistent release process across repositories - You’re preparing a release: version bump, changelog, tag, artifacts, rollout plan - You want release readiness checks and rollback strategy ## Workflow 1) Define scope and readiness - What is included/excluded in this release? - Required checks: CI green, security checks, docs updated 2) Versioning rules (SemVer) - Major: breaking changes - Mino
development
copilot_dev/.github/skills/engineering/devops-cloud/helm
# Helm (Charts, Upgrades, Rollbacks) ## When to use - Helm upgrade/install fails, hangs, or produces unexpected manifests - You suspect values drift, templating issues, hooks/CRDs ordering, or immutable field updates - You want a safe upgrade/rollback workflow (production-grade) ## Workflow 1) Collect context - Release name, namespace, chart name/version, values source (files/--set), upgrade time window - Cluster type (AKS), ingress controller, CRDs involved, recent changes 2) Validate
development
copilot_dev/.github/skills/engineering/docs-system/doc-qa
# Doc QA (Lint + Links) ## When to use - Docs must pass markdownlint and link check. - You need a checklist to keep docs maintainable. ## Workflow 1) Validate headings (no skipped levels). 2) Validate code fences (language identifiers where possible). 3) Validate links (relative intra-repo; no broken links). 4) Validate DAM template sections (Purpose/Audience/Last updated). 5) Fix issues with minimal content changes. ## Outputs - Doc QA checklist - A corrected markdown version - A list of
development
copilot_dev/.github/skills/engineering/documentation/onboarding-factory
# Onboarding Factory ## When to use - You need onboarding docs for new contributors (dev + ops). - You want a consistent onboarding template across repos. ## Workflow 1) Gather prerequisites (SDKs, tools, env vars). 2) Provide setup steps (clone, restore, build). 3) Provide test steps (unit/integration/e2e if applicable). 4) Provide run/debug steps (local + docker/k8s if applicable). 5) Provide contribution workflow (branching, PR, checks). 6) Provide “first tasks” for newcomers. ## Outputs
tools
copilot_dev/.github/skills/engineering/frontend/html-css
# HTML/CSS (Structure, Accessibility, Maintainability) ## When to use - You need clean, accessible markup and maintainable styling. - You’re working on layout issues, responsiveness, or UI consistency. ## Workflow 1) Semantic structure - Use semantic elements (`main`, `nav`, `section`, `button`). 2) Accessibility baseline - Keyboard navigation, focus states, ARIA only when needed. - Color contrast and readable typography. 3) Responsive design - Mobile-first layout; avoid fixed wi
development
copilot_dev/.github/skills/engineering/fullstack-patterns/contracts
# Full-stack Contracts (API ↔ Client) ## When to use - You need stable contracts between backend and frontend. - You want versioning, compatibility, and shared DTO strategy. ## Workflow 1) Define contract ownership - Backend owns OpenAPI or schema; consumers follow. 2) Versioning strategy - Backward-compatible changes, deprecations, breaking changes. 3) Schema generation - Use OpenAPI to generate clients if appropriate. 4) Validation and examples - Provide examples in OpenAPI and
tools
copilot_dev/.github/skills/engineering/github-delivery/commits
# Commits (Hygiene, Conventional Commits) ## When to use - You want consistent commit messages and history. - You want readable changelogs and safe backports. ## Workflow 1) Choose convention - Conventional Commits: `feat:`, `fix:`, `chore:`, `docs:`, `refactor:`, `test:` 2) Scope usage - Use scope for bounded contexts: `feat(api): ...` 3) Commit size - Prefer small, focused commits; avoid “mega commits”. 4) History strategy - Decide merge strategy: squash vs merge commits vs reb
development
copilot_dev/.github/skills/engineering/native/asm-x86
# x86 Assembly (Intel) Basics ## When to use - You need to read/write x86 assembly for performance or low-level debugging. - You need to understand calling conventions, stack frames, and registers. ## Workflow 1) Establish context - Architecture (x86/x64), OS, calling convention, toolchain. 2) Read control flow - prologue/epilogue, stack usage, register saving. 3) Data flow - track values through registers and memory. 4) Debugging approach - minimal repro, disassembly, breakpoint
tools
copilot_dev/.github/skills/engineering/native/c
# C (Safety, Portability, Debugging) ## When to use - You write or review C code and want safe, portable patterns. - You debug memory corruption, UB, or performance issues. ## Workflow 1) Safety defaults - initialize variables, bounds checks, avoid dangerous APIs. 2) Error handling - clear error codes, single exit cleanup (goto cleanup). 3) Memory discipline - ownership rules, alloc/free symmetry. 4) Tooling - compiler warnings, sanitizers (ASan/UBSan), static analysis. 5) Testin
tools
copilot_dev/.github/skills/engineering/native/cpp
# C++ (Modern Practices, Safety, Performance) ## When to use - You write or review C++ code and want modern safe patterns. - You need RAII, ownership clarity, and performance tuning. ## Workflow 1) Ownership and lifetime - prefer RAII; use smart pointers appropriately. 2) APIs and const correctness - const where meaningful; avoid raw owning pointers. 3) Error handling - exceptions vs error codes policy; be consistent. 4) Performance - measure first; avoid premature optimization.
development
copilot_dev/.github/skills/engineering/observability/apm
# APM (Traces, Transactions, Spans) Triage ## When to use - Latency spike or error spike with unclear root cause - You need to locate hotspots (DB, downstream calls, serialization, retries) - You need to correlate traces with logs (trace.id / transaction.id) ## Workflow 1) Define scope and time window - service name, environment, release version or image tag 2) Identify the first symptom - highest error transactions - largest latency regressions (p95/p99) 3) Breakdown analysis -
development
copilot_dev/.github/skills/engineering/observability/logs-alerts
# Logs, Alerts & APM Triage ## When to use - You have errors but unclear root cause - You need to correlate logs ↔ traces ↔ metrics - You need actionable next queries and improved alerting ## Workflow 1) Define timeframe: - when started, deployment window, incident window 2) Extract first symptom: - earliest error type, first failing dependency call, first timeout 3) Correlate signals: - error rate, latency spikes, saturation (CPU/mem), downstream failures 4) Query strategy: - na
development
copilot_dev/.github/skills/engineering/project-management/adr
# ADR (Architecture Decision Records) ## When to use - You need to record architectural decisions with context and tradeoffs. - You want traceability of “why” over time. ## Workflow 1) Define decision scope - what decision, what is impacted, who are stakeholders 2) Capture context - constraints, goals, alternatives 3) Compare options - tradeoffs (risk, cost, maintainability) 4) Decision and consequences - what we choose and what it implies 5) Follow-ups - implementation tasks
development
copilot_dev/.github/skills/engineering/project-management/delivery
# Delivery (Execution, Quality Gates, Release Readiness) ## When to use - You want consistent delivery practices: from planning to PR to release. - You need quality gates and release readiness checklists. ## Workflow 1) Define done - acceptance criteria, tests, docs, rollout notes 2) PR discipline - small PRs, clear description, links to issues 3) Quality gates - tests + linters + docs checks in CI 4) Release readiness - versioning, changelog, rollout plan, rollback plan 5) Post-
development
copilot_dev/.github/skills/engineering/scripting/perl
# Perl (Pragmatic Scripting) ## When to use - You maintain or write Perl scripts for automation or data processing. - You need reliable CLI behavior and readable structure. ## Workflow 1) Structure - clear entrypoint, functions, minimal global state 2) Inputs/outputs - validate args; print usage on error 3) Safety - strict/warnings; avoid unsafe eval patterns 4) Testing - basic tests for non-trivial parsing/transform logic 5) Idempotence - safe to rerun where applicable ## Ou
tools
copilot_dev/.github/skills/engineering/testing-quality/js-testing
# JS/TS Testing (Unit + Component + E2E) ## When to use - You need tests for TS utilities, React components, or E2E flows. - You want reliable tests and good developer experience. ## Workflow 1) Choose layers - unit for pure functions; component tests for UI behaviors; E2E for top flows 2) Tools - unit: vitest/jest - component: testing-library - e2e: playwright/cypress 3) Test data - minimal fixtures; avoid brittle selectors 4) Flakiness prevention - wait for conditions, av
tools
copilot_dev/.github/skills/engineering/tooling/az
# Azure CLI (az) Operational Playbook ## When to use - You need reliable Azure CLI workflows (login, context, AKS ops) - You need to avoid “wrong subscription / wrong cluster” mistakes - You want a safe, repeatable command sequence for triage and deployment ## Workflow 1) Identity and context safety - `az account show -o table` - `az account list -o table` - `az account set --subscription "<subIdOrName>"` - Always confirm again: `az account show -o table` 2) Resource discovery
tools
copilot_dev/.github/skills/engineering/tooling/bruno
# Bruno (API Testing Client) ## When to use - You want to test REST APIs with a lightweight client (collections, env vars). - You want repeatable API checks locally and optionally in CI. ## Workflow 1) Organize collections by domain (auth, users, orders, etc.) 2) Use environments - dev/staging/prod base URLs; auth tokens 3) Standardize requests - headers, correlation IDs, request naming 4) Validate responses - status codes, key fields, error schemas 5) Export/share - keep collect
tools
copilot_dev/.github/skills/engineering/tooling/dotnet-cli
# dotnet CLI (Build/Test/Publish) ## When to use - You need reliable dotnet commands for local dev and CI. - You want a standard build/test/publish workflow. ## Workflow 1) Restore/build - `dotnet restore` - `dotnet build -c Release` 2) Test - `dotnet test -c Release --collect:"XPlat Code Coverage"` (optional) 3) Format/lint (if configured) - `dotnet format` (optional) 4) Publish - `dotnet publish -c Release -o out/` 5) Diagnostics - `dotnet --info`, `dotnet --list-sdks` #
tools
copilot_dev/.github/skills/engineering/tooling/git
# Git (Everyday Workflow) ## When to use - You want consistent branching/PR habits. - You need safe rebasing, conflict resolution, and history hygiene. ## Workflow 1) Branching - short-lived feature branches; name by issue/task 2) Sync - rebase or merge based on team policy 3) Commit hygiene - small commits, meaningful messages, link to issues 4) PR workflow - clear description, screenshots/logs if needed, checklist 5) Conflict resolution - resolve locally, run tests, push upd
tools
copilot_dev/.github/skills/engineering/tooling/helm-cli
# Helm CLI Cheatsheet (Operational) ## When to use - You need fast, correct Helm commands (install/upgrade/status/history/rollback) - You want deterministic chart rendering and debugging ## Workflow 1) Inspect releases - `helm list -A` - `helm status <release> -n <ns>` - `helm history <release> -n <ns>` 2) Get rendered state - `helm get manifest <release> -n <ns>` - `helm get values <release> -n <ns> -a` 3) Render locally (debug) - `helm lint <chartDir>` - `helm template
tools
copilot_dev/.github/skills/engineering/tooling/kubectl
# kubectl Cheatsheet (Operational) ## When to use - You need fast commands for triage and verification - You want consistent, copy/paste-friendly kubectl usage ## Workflow 1) Context and namespaces: - `kubectl config current-context` - `kubectl get ns` 2) Workloads: - `kubectl get deploy,rs,po -n <ns> -o wide` 3) Describe and logs: - `kubectl describe po <pod> -n <ns>` - `kubectl logs <pod> -n <ns> --previous` 4) Events: - `kubectl get events -n <ns> --sort-by=.lastTimestam
tools
copilot_dev/.github/skills/engineering/tooling/npm
# npm (Node Tooling) ## When to use - You need consistent install/build/test scripts for JS/TS projects. - You want reproducible CI runs. ## Workflow 1) Install strategy - use `npm ci` in CI for reproducibility 2) Scripts - standard scripts: `lint`, `test`, `build`, `typecheck` 3) Lockfile discipline - commit `package-lock.json`; avoid drift 4) Troubleshooting - clear cache carefully; check node/npm versions 5) CI gating - run lint+tests on PR, build on main ## Outputs - Rec
tools
copilot_dev/.github/skills/engineering/tooling/postman
# Postman (API Collections) ## When to use - You want repeatable API request collections with environments. - You want to validate API contract behavior manually or in CI. ## Workflow 1) Organize collections by domain 2) Use environments for base URLs and auth tokens 3) Add tests - status code assertions, schema checks where possible 4) Documentation - include examples and descriptions 5) Version control - export collections; keep in repo if required ## Outputs - Collection struct
tools
copilot_dev/.github/skills/engineering/tooling/vscode
# VS Code (Copilot Dev Framework Usage) ## When to use - You need to ensure Copilot Dev Framework is loaded correctly in VS Code. - You want best practices for working with prompts, agents, and skills. ## Workflow 1) Bootstrap integration - run `copilot_dev/bootstrap/bootstrap.ps1` or `.sh` 2) Reload - Reload window after bootstrap 3) Discoverability - use `/route` to select agent/prompt/skill - verify prompts appear in the slash command list 4) Multi-root workspaces - ensure
tools
copilot_dev/.github/skills/research/brainstorming/innovation-sprint
# Innovation Sprint ## When to use - You need new ideas or alternative designs. - You want a short, structured ideation session. ## Workflow 1) Clarify constraints and success criteria. 2) Generate 8–12 ideas quickly (no filtering). 3) Cluster similar ideas and pick top 3. 4) For top 3: define value, feasibility, risks, and a 1–2h spike plan. ## Outputs - Idea list - Top 3 shortlist + tradeoffs - Spike plan for each shortlisted idea
development
copilot_dev/.github/skills/research/tech-watch/weekly-digest
# Tech Watch (Weekly Digest) ## When to use - You want a weekly digest on selected topics (dotnet, k8s/aks, observability, security, LLM tooling). ## Workflow 1) Define topics and priority order. 2) Collect primary sources (release notes, official docs, papers). 3) Summarize: what changed + why it matters. 4) Propose 1–3 experiments to try next week. ## Outputs - Weekly digest (Markdown) - Experiments list (1–3) with expected payoff - Source list (primary preferred)
tools
copilot_dev/.github/skills/engineering/backend-dotnet/postgres
# PostgreSQL (Schema, Indexes, Query Patterns) ## When to use - You use PostgreSQL and need schema/index guidance. - You’re diagnosing slow queries, locks, or concurrency issues. - You want Postgres-safe patterns for migrations and data evolution. ## Workflow 1) Identify access patterns - Critical queries: predicates, sorts, joins, cardinality. 2) Index strategy - Create indexes aligned with predicates and sorting (composite indexes). - Consider partial indexes for sparse conditions
development
copilot_dev/.github/skills/engineering/backend-dotnet/aspnet-core
# ASP.NET Core (REST API) ## When to use - Building or evolving an ASP.NET Core REST API. - Defining API conventions: routing, versioning, validation, error handling, auth. - Improving production readiness (health checks, rate limits, observability). ## Workflow 1) Define API shape - Resources, endpoints, HTTP verbs, status codes, pagination strategy. - Versioning strategy (URI or header) and backward compatibility rules. 2) Setup baseline project conventions - Global exception hand
development
copilot_dev/.github/skills/engineering/backend-dotnet/ef-core
# EF Core (Modeling, Migrations, Performance) ## When to use - Designing or refactoring EF Core models. - Handling migrations and schema evolution safely. - Investigating performance issues (N+1, slow queries, indexes). - Implementing concurrency control and transactions. ## Workflow 1) Model design - Identify aggregates, boundaries, and navigation properties. - Prefer explicit configurations (Fluent API) for complex mappings. 2) Migrations discipline - Generate migration, review SQ
development
copilot_dev/.github/skills/engineering/backend-dotnet/mediatr
# MediatR (CQRS, Pipelines, Cross-cutting Concerns) ## When to use - You use CQRS (Commands/Queries) and want a consistent application layer. - You need pipeline behaviors for validation, logging, retries, transactions. - You want clean separation between API and business logic. ## Workflow 1) Establish conventions - Commands for writes, queries for reads. - Keep handlers small and focused; avoid business logic in controllers. 2) Define request/response shapes - Prefer explicit resu
development
copilot_dev/.github/skills/engineering/backend-dotnet/openapi
# OpenAPI / Swagger (Contracts, Examples, Auth) ## When to use - You want a reliable API contract for consumers. - You need consistent error schemas, examples, and auth definitions. - You want versioned APIs with clean documentation. ## Workflow 1) Define contract rules - Stable DTOs, backward-compatible changes, deprecation policy. 2) Configure OpenAPI - Title, versioning, server URLs (env-aware), tags by domain. 3) Error model - Standardize `ProblemDetails` (or custom) and documen
development
copilot_dev/.github/skills/engineering/copilot-framework/canonical-routing
# Canonical Routing ## When to use - You want to decide which agent/prompt/skill to use for a request. - The request crosses multiple domains (e.g., debugging + AKS + logs). ## Workflow 1) Identify capability (what you want to do). 2) Identify domain (where it applies). 3) Apply `routing/matrix.yaml` rules: - try capability + domain - fallback to capability-only 4) Recommend: - agent handoff - best slash command - skill modules ## Outputs - Selected capability + domain - Rec
development
copilot_dev/.github/skills/engineering/copilot-framework/prompt-engineering
# Prompt Engineering (Copilot Dev Framework) ## When to use - You need consistent prompts that produce deterministic, reviewable outputs. - You want prompts that work well with routing (capability + domain). - You want to reduce ambiguity and hallucinations. ## Workflow 1) Define intent - “What is the task?” (triage, generate, review, plan, refactor, explain) - Pick the right interaction mode for the task size/complexity. 2) Provide constraints - Tech stack, style rules, safety cons
development
copilot_dev/.github/skills/engineering/debugging/perf-regression
# Performance Regression Triage ## When to use - Latency p95/p99 increased, throughput dropped, CPU/memory spiked. - You suspect a regression after a deployment. - You need a measure-first plan (not guesswork). ## Workflow 1) Define the regression - What changed? When? Which endpoint or workload? - Confirm metrics: p50/p95/p99, error rate, saturation. 2) Establish baseline - Compare before/after deployment window. - Identify whether regression is global or scoped (tenant/region/p
development
copilot_dev/.github/skills/engineering/debugging/triage
# Debugging Triage ## When to use - You have an exception/stacktrace/crash/regression/timeout and need a plan. - You want a reproducible case and ranked hypotheses. ## Workflow 1) Capture context: environment, versions, inputs, timeline, recent changes. 2) Build minimal reproduction steps (reduce until smallest failing case). 3) Extract the first symptom (earliest error/log). 4) Propose 3–5 hypotheses (rank by likelihood × cost to validate). 5) Define validation steps per hypothesis (instrum
development
copilot_dev/.github/skills/engineering/devops-cloud/aks
# AKS Troubleshooting ## When to use - AKS node pool issues, scheduling problems, cluster upgrades/regressions - Azure-related failures (identity, networking, load balancer) - You need a structured AKS-first diagnostic path ## Workflow 1) Confirm AKS context: - subscription, resource group, cluster name, node pool 2) Cluster access and basic health: - `az aks show -g <rg> -n <cluster> -o table` - `kubectl get nodes` 3) Node pool focus: - node readiness, capacity, taints, pressure
development
copilot_dev/.github/skills/engineering/devops-cloud/azure
# Azure (Operational Basics) ## When to use - You work on Azure resources (AKS, Key Vault, Container Registry, networking). - You need safe operational workflows and common pitfalls checklist. ## Workflow 1) Identity & subscription safety - Confirm account and subscription (`az account show`, `az account set`). 2) Resource navigation - Resource group, region, naming conventions. 3) AKS core operations (if applicable) - Get cluster details, credentials, node pools. 4) Secrets & confi
development
copilot_dev/.github/skills/engineering/devops-cloud/kubernetes
# Kubernetes Troubleshooting ## When to use - Pods are crashing / pending / not ready - Services are unreachable - Ingress routing fails - You suspect config drift, rollout issues, or resource pressure ## Workflow 1) Identify scope: - cluster, namespace, workload name, rollout time, image tag 2) Fast health checks: - `kubectl get nodes -o wide` - `kubectl get pods -n <ns> -o wide` - `kubectl get deploy,rs -n <ns>` 3) Pod-level diagnostics: - `kubectl describe pod <pod> -n <ns>
development
copilot_dev/.github/skills/engineering/devops-cloud/supply-chain
# Supply Chain Basics (CI/CD Security) ## When to use - You want minimal, high-impact CI/CD security practices - You publish artifacts/images/packages and need provenance basics ## Workflow 1) Dependency hygiene - pin dependencies where possible - avoid untrusted scripts; review new build tooling 2) GitHub Actions hardening - least-privilege permissions - pin action versions (commit SHA for high assurance) - restrict `GITHUB_TOKEN` permissions 3) Secrets handling - never ec
tools
copilot_dev/.github/skills/engineering/documentation/repo-understanding
# Repo Understanding ## When to use - You need to understand an unfamiliar repository quickly. - You need a module map and doc-ready explanation of boundaries. ## Workflow 1) Identify entry points (apps, services, CLI, main modules). 2) Identify build/test commands and toolchain. 3) Map modules: responsibilities, dependencies, boundaries. 4) Identify configuration (env vars, config files, secrets). 5) Identify critical flows (request path, data flow, side effects). 6) Produce doc-ready summa
tools
copilot_dev/.github/skills/engineering/frontend/react
# React (Architecture, State, Performance) ## When to use - Building or refactoring React components/pages. - Choosing state management patterns. - Fixing performance or re-render issues. ## Workflow 1) Component boundaries - Split container vs presentational components where useful. 2) State strategy - Local state for local concerns; lift state only when needed. - Use derived state carefully; prefer memoization only after measuring. 3) Data fetching - Centralize fetch logic; han
development
copilot_dev/.github/skills/engineering/frontend/typescript
# TypeScript (Types, Boundaries, Safety) ## When to use - Designing types at API boundaries. - Cleaning up unsafe types (`any`, overly broad unions). - Improving DX and correctness with strong typing. ## Workflow 1) Identify boundaries - API clients, external libs, storage, runtime inputs. 2) Define types - Prefer explicit DTO interfaces and discriminated unions where relevant. 3) Narrow types early - Use type guards; validate runtime inputs. 4) Avoid unsafe patterns - No implici
tools
copilot_dev/.github/skills/engineering/fullstack-patterns/e2e
# End-to-End (E2E) Testing ## When to use - You need confidence that user-critical flows work across the whole stack. - You’re validating deployments and regressions. ## Workflow 1) Select critical flows - Login, checkout, core workflows; keep E2E scope small. 2) Test environment - Stable test data, isolated environment, deterministic setup. 3) Tool choice - Choose Playwright/Cypress/etc. based on team fit. 4) Flakiness prevention - Avoid sleeps; wait for specific conditions. 5)
tools
copilot_dev/.github/skills/engineering/fullstack-patterns/test-strategy
# Full-stack Test Strategy ## When to use - You need a test pyramid for a full-stack system. - You want to align unit/integration/contract/E2E tests. ## Workflow 1) Identify critical behaviors and risks 2) Allocate test types - Unit for logic, integration for infra boundaries, contract for APIs, E2E for top flows. 3) Define data strategy - Fixtures/builders; seed data; isolation. 4) CI gating - PR: fast suite; main: full suite. 5) Measure and improve - Track flakiness and runtime
development
copilot_dev/.github/skills/engineering/github-delivery/planning
# Planning (GitHub Projects, Milestones, Roadmaps) ## When to use - You need lightweight planning and delivery tracking. - You want consistent triage → execution → release mapping. ## Workflow 1) Decide planning granularity - milestones for releases, projects for workflows, issues for tasks. 2) Prioritization - impact vs effort, dependencies, risk. 3) Execution cadence - weekly planning, daily async updates, PR-based delivery. 4) Reporting - simple metrics: cycle time, throughput
development
copilot_dev/.github/skills/engineering/github-delivery/issues
# Issues (Triage, Labels, Quality) ## When to use - You need to triage incoming issues efficiently. - You want consistent labels, priorities, and acceptance criteria. ## Workflow 1) Triage quickly - Is it bug, feature, question? 2) Require minimum info - repro steps, expected vs actual, environment/version. 3) Labeling system - type, priority, area, status. 4) Definition of done - acceptance criteria, tests, docs, rollout notes. 5) Planning link - assign to milestone/project.
development
copilot_dev/.github/skills/engineering/github-delivery/pr-review
# PR Review ## When to use - You want a consistent PR review checklist. - You need to assess correctness, risks, and readiness. ## Workflow 1) Summarize changes in your own words. 2) Check correctness risks and edge cases. 3) Check tests (coverage gaps; regression tests for bug fixes). 4) Check security and data handling. 5) Check performance regressions and observability. 6) Check docs and release notes needs. ## Outputs - Structured review notes (prioritized) - Suggested follow-up tasks - A
development
copilot_dev/.github/skills/engineering/native/avr
# AVR (Atmel) Firmware Basics ## When to use - You write/debug AVR firmware (Arduino-class MCUs). - You need low-level constraints: timers, interrupts, IO, memory. ## Workflow 1) Identify target - MCU model, clock, toolchain, fuses, programmer. 2) Interrupt strategy - keep ISRs short; avoid blocking; shared data atomicity. 3) Timing and peripherals - timers, UART/SPI/I2C configuration. 4) Memory constraints - stack/heap usage; PROGMEM for constants. 5) Debugging - serial logs,
tools
copilot_dev/.github/skills/engineering/native/pic
# PIC Firmware Basics ## When to use - You write/debug PIC firmware (Microchip). - You need to handle low-level constraints, interrupts, and peripherals. ## Workflow 1) Identify target - PIC model, toolchain (MPLAB XC), clock, configuration bits. 2) Interrupt strategy - minimal ISR, shared state protection. 3) Peripheral setup - timers, UART, ADC, PWM as needed. 4) Memory and performance constraints - keep loops tight; avoid heavy runtime features. 5) Debugging - serial loggin
tools
copilot_dev/.github/skills/engineering/observability/elastic
# Elasticsearch & Kibana (Queries, Dashboards, Root Cause) ## When to use - You need to find the “first symptom” in logs quickly - You need to build queries/dashboards that support incident response - You need guidance on common query patterns (KQL/Lucene) and grouping ## Workflow 1) Define the incident window and scope - Time range (start, detection time, deployment window) - Services involved, environments, correlation IDs if any 2) Find the first symptom - Narrow by service + env
development
copilot_dev/.github/skills/engineering/postmortem/rca-kit
# RCA Kit (Postmortem) ## When to use - An incident happened and you need a blameless postmortem. - You need timeline + root cause + action items. ## Workflow 1) Write summary and impact (customer/system impact, blast radius). 2) Build a timeline (facts only; timestamps). 3) Identify root cause and contributing factors (systems/processes). 4) Evaluate detection/response gaps (alerts, runbooks, ownership). 5) Produce corrective actions (owners + deadlines). 6) Produce preventative actions (sy
development
copilot_dev/.github/skills/engineering/project-management/rfc
# RFC (Request For Comments) ## When to use - You need to propose a change that impacts architecture, APIs, or team workflows. - You want early feedback before implementation. ## Workflow 1) Problem statement 2) Goals and non-goals 3) Proposed solution 4) Alternatives considered 5) Risks and mitigations 6) Rollout plan 7) Open questions ## Outputs - RFC document outline - Decision criteria and tradeoffs list - Next steps for validation/prototyping
development
copilot_dev/.github/skills/engineering/project-management/roadmap
# Roadmap (Vision → Milestones → Execution) ## When to use - You want a roadmap that stays actionable (not a slide deck). - You want milestones tied to deliverables and risks. ## Workflow 1) Define outcomes (not just features) 2) Break into milestones (timeboxed) 3) Identify dependencies and risks 4) Define success metrics per milestone 5) Review cadence (monthly/quarterly) ## Outputs - Roadmap structure (milestones + outcomes + metrics) - Dependency/risk register outline - Review cadence
development
copilot_dev/.github/skills/engineering/scripting/python
# Python (Automation and Tooling) ## When to use - You need scripts, CLI tools, automation, or data transformations. - You want safe, maintainable Python with clear error handling. ## Workflow 1) Structure - main entrypoint, functions/modules, avoid global state 2) CLI ergonomics - argparse/typer style, helpful errors, exit codes 3) Safety and correctness - validate inputs; handle IO failures 4) Testing - unit tests for core logic; golden files for transformations 5) Packaging (o
tools
copilot_dev/.github/skills/engineering/shell-automation/bash
# Bash (Safe Shell Scripting) ## When to use - You need automation scripts on Unix-like systems. - You want safe, rerunnable scripts with predictable behavior. ## Workflow 1) Safety defaults - `set -euo pipefail`, quote variables, validate inputs 2) Idempotence - check before create/delete; avoid destructive defaults 3) Logging - echo key steps; errors to stderr 4) Portability - avoid non-portable flags unless required 5) Verification - dry-run mode and minimal tests ## Outpu
tools
copilot_dev/.github/skills/engineering/shell-automation/batch
# Windows Batch (cmd) Basics ## When to use - You need a simple Windows batch script for legacy environments. - You want predictable behavior and clear error paths. ## Workflow 1) Use `setlocal enabledelayedexpansion` carefully 2) Validate inputs and print usage 3) Check errorlevels after commands 4) Avoid complex parsing; prefer PowerShell when possible 5) Make scripts idempotent when feasible ## Outputs - Batch scripting safety checklist - Recommended structure and error handling tips -
tools
copilot_dev/.github/skills/engineering/shell-automation/powershell
# PowerShell (Robust Automation) ## When to use - You need Windows automation or cross-platform pwsh scripts. - You want idempotent operations and proper error handling. ## Workflow 1) Safety defaults - `$ErrorActionPreference = 'Stop'`, parameter validation 2) Idempotence - check state before mutating, use `-WhatIf` patterns if relevant 3) Structured output - return objects where possible; avoid parsing text 4) Logging - clear progress and actionable errors 5) Verification -
tools
copilot_dev/.github/skills/engineering/testing-quality/dotnet-testing
# .NET Testing (Unit + Integration) ## When to use - You need tests for ASP.NET Core APIs, EF Core, or application services. - You want deterministic tests and good coverage for critical paths. ## Workflow 1) Choose test types - unit tests for pure logic; integration for API + DB behavior 2) Integration testing approach - `WebApplicationFactory` for API integration - prefer real Postgres via testcontainers when DB behavior matters 3) Test data strategy - builders/fixtures; isolat
development
copilot_dev/.github/skills/engineering/testing-quality/linters
# Linters & Quality Gates ## When to use - You need consistent formatting and static checks. - You want CI gates for code and docs quality. ## Workflow 1) Pick linters/formatters per stack (dotnet/ts/python/shell/docs). 2) Define local commands and CI commands. 3) Define severity: warn vs fail. 4) Integrate into PR checks. ## Outputs - Recommended tool list + commands - CI gate checklist - Suggestions to reduce noise (baseline, incremental adoption)
tools
copilot_dev/.github/skills/engineering/testing-quality/test-strategy
# Test Strategy ## When to use - You need a pragmatic test plan and a test pyramid. - You’re adding features or fixing bugs and need coverage guidance. ## Workflow 1) Identify critical behaviors (what must never break). 2) Choose test types per behavior (unit/integration/contract/e2e). 3) Define test data strategy (fixtures, builders, fakes). 4) Define flakiness prevention measures. 5) Define CI gates (what runs when). ## Outputs - Test plan table (scenario → type → why) - Recommended test
development
copilot_dev/.github/skills/engineering/tooling/k9s
# k9s (Kubernetes Triage UI) ## When to use - You need faster feedback than raw kubectl during an incident - You want to inspect pods/logs/events interactively across namespaces ## Workflow 1) Start and confirm context - Run `k9s` - Confirm current context/namespace at the top bar 2) High-signal views - Pods (crashloop, restarts, readiness) - Events (recent failures, scheduling, image pull) - Deployments/ReplicaSets (rollout state) - Services/Endpoints (routing readiness) 3
tools
copilot_dev/.github/skills/engineering/tooling/lens
# Lens (Kubernetes Cluster Explorer) ## When to use - You need a richer UI to explore workloads, configs, and cluster resources - You want to correlate object configuration with runtime status quickly ## Workflow 1) Confirm cluster context (avoid wrong cluster operations) 2) Navigate: - Workloads → Deployments/Pods - Configuration → ConfigMaps/Secrets - Network → Services/Ingress/Endpoints - Events and metrics views 3) Diagnose: - Identify failing pods (restarts, readiness)
tools
copilot_dev/.github/skills/engineering/tooling/pgadmin
# pgAdmin (PostgreSQL Admin UI) ## When to use - You need to inspect schema, indexes, and query plans. - You want to validate migrations and troubleshoot DB behavior. ## Workflow 1) Connection setup - host/port/db/user; SSL settings as needed 2) Schema inspection - tables, columns, constraints, indexes 3) Query analysis - use EXPLAIN (ANALYZE, BUFFERS) for slow queries 4) Migration validation - verify expected schema changes after migration 5) Safety - avoid direct production
tools
copilot_dev/.github/skills/engineering/docs-system/doc-architecture-model
# Doc Architecture Model Support ## When to use - You want to define or align a `docs/` tree to the DAM. - You want consistent templates across repositories. ## Workflow 1) Propose a `docs/` tree aligned with the DAM. 2) Provide templates for each doc type (overview/architecture/how-to/reference/runbooks). 3) Define required sections: Purpose, Audience, Last updated. 4) Ensure link strategy and navigation consistency. ## Outputs - `docs/` tree proposal - Templates per doc type - Migration
development