devskill 2.0.7 → 2.0.8

package/skills/dotnet-upgrade/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: dotnet-upgrade
+description: 'Ready-to-use prompts for comprehensive .NET framework upgrade analysis and execution'
+---
+
+# Project Discovery & Assessment
+  - name: "Project Classification Analysis"
+    prompt: "Identify all projects in the solution and classify them by type (`.NET Framework`, `.NET Core`, `.NET Standard`). Analyze each `.csproj` for its current `TargetFramework` and SDK usage."
+
+  - name: "Dependency Compatibility Review"
+    prompt: "Review external and internal dependencies for framework compatibility. Determine the upgrade complexity based on dependency graph depth."
+
+  - name: "Legacy Package Detection"
+    prompt: "Identify legacy `packages.config` projects needing migration to `PackageReference` format."
+
+  # Upgrade Strategy & Sequencing
+  - name: "Project Upgrade Ordering"
+    prompt: "Recommend a project upgrade order from least to most dependent components. Suggest how to isolate class library upgrades before API or Azure Function migrations."
+
+  - name: "Incremental Strategy Planning"
+    prompt: "Propose an incremental upgrade strategy with rollback checkpoints. Evaluate the use of **Upgrade Assistant** or **manual upgrades** based on project structure."
+
+  - name: "Progress Tracking Setup"
+    prompt: "Generate an upgrade checklist for tracking build, test, and deployment readiness across all projects."
+
+  # Framework Targeting & Code Adjustments
+  - name: "Target Framework Selection"
+    prompt: "Suggest the correct `TargetFramework` for each project (e.g., `net8.0`). Review and update deprecated SDK or build configurations."
+
+  - name: "Code Modernization Analysis"
+    prompt: "Identify code patterns needing modernization (e.g., `WebHostBuilder` → `HostBuilder`). Suggest replacements for deprecated .NET APIs and third-party libraries."
+
+  - name: "Async Pattern Conversion"
+    prompt: "Recommend conversion of synchronous calls to async where appropriate for improved performance and scalability."
+
+  # NuGet & Dependency Management
+  - name: "Package Compatibility Analysis"
+    prompt: "Analyze outdated or incompatible NuGet packages and suggest compatible versions. Identify third-party libraries that lack .NET 8 support and provide migration paths."
+
+  - name: "Shared Dependency Strategy"
+    prompt: "Recommend strategies for handling shared dependency upgrades across projects. Evaluate usage of legacy packages and suggest alternatives in Microsoft-supported namespaces."
+
+  - name: "Transitive Dependency Review"
+    prompt: "Review transitive dependencies and potential version conflicts after upgrade. Suggest resolution strategies for dependency conflicts."
+
+  # CI/CD & Build Pipeline Updates
+  - name: "Pipeline Configuration Analysis"
+    prompt: "Analyze YAML build definitions for SDK version pinning and recommend updates. Suggest modifications for `UseDotNet@2` and `NuGetToolInstaller` tasks."
+
+  - name: "Build Pipeline Modernization"
+    prompt: "Generate updated build pipeline snippets for .NET 8 migration. Recommend validation builds on feature branches before merging to main."
+
+  - name: "CI Automation Enhancement"
+    prompt: "Identify opportunities to automate test and build verification in CI pipelines. Suggest strategies for continuous integration validation."
+
+  # Testing & Validation
+  - name: "Build Validation Strategy"
+    prompt: "Propose validation checks to ensure the upgraded solution builds and runs successfully. Recommend automated test execution for unit and integration suites post-upgrade."
+
+  - name: "Service Integration Verification"
+    prompt: "Generate validation steps to verify logging, telemetry, and service connectivity. Suggest strategies for verifying backward compatibility and runtime behavior."
+
+  - name: "Deployment Readiness Check"
+    prompt: "Recommend UAT deployment verification steps before production rollout. Create comprehensive testing scenarios for upgraded components."
+
+  # Breaking Change Analysis
+  - name: "API Deprecation Detection"
+    prompt: "Identify deprecated APIs or removed namespaces between target versions. Suggest automated scanning using `.NET Upgrade Assistant` and API Analyzer."
+
+  - name: "API Replacement Strategy"
+    prompt: "Recommend replacement APIs or libraries for known breaking areas. Review configuration changes such as `Startup.cs` → `Program.cs` refactoring."
+
+  - name: "Regression Testing Focus"
+    prompt: "Suggest regression testing scenarios focused on upgraded API endpoints or services. Create test plans for critical functionality validation."
+
+  # Version Control & Commit Strategy
+  - name: "Branching Strategy Planning"
+    prompt: "Recommend branching strategy for safe upgrade with rollback capability. Generate commit templates for partial and complete project upgrades."
+
+  - name: "PR Structure Optimization"
+    prompt: "Suggest best practices for creating structured PRs (`Upgrade to .NET [Version]`). Identify tagging strategies for PRs involving breaking changes."
+
+  - name: "Code Review Guidelines"
+    prompt: "Recommend peer review focus areas (build, test, and dependency validation). Create checklists for effective upgrade reviews."
+
+  # Documentation & Communication
+  - name: "Upgrade Documentation Strategy"
+    prompt: "Suggest how to document each project's framework change in the PR. Propose automated release note generation summarizing upgrades and test results."
+
+  - name: "Stakeholder Communication"
+    prompt: "Recommend communicating version upgrades and migration timelines to consumers. Generate documentation templates for dependency updates and validation results."
+
+  - name: "Progress Tracking Systems"
+    prompt: "Suggest maintaining an upgrade summary dashboard or markdown checklist. Create templates for tracking upgrade progress across multiple projects."
+
+  # Tools & Automation
+  - name: "Upgrade Tool Selection"
+    prompt: "Recommend when and how to use: `.NET Upgrade Assistant`, `dotnet list package --outdated`, `dotnet migrate`, and `graph.json` dependency visualization."
+
+  - name: "Analysis Script Generation"
+    prompt: "Generate scripts or prompts for analyzing dependency graphs before upgrading. Propose AI-assisted prompts for Copilot to identify upgrade issues automatically."
+
+  - name: "Multi-Repository Validation"
+    prompt: "Suggest how to validate automation output across multiple repositories. Create standardized validation workflows for enterprise-scale upgrades."
+
+  # Final Validation & Delivery
+  - name: "Final Solution Validation"
+    prompt: "Generate validation steps to confirm the final upgraded solution passes all validation checks. Suggest production deployment verification steps post-upgrade."
+
+  - name: "Deployment Readiness Confirmation"
+    prompt: "Recommend generating final test results and build artifacts. Create a checklist summarizing completion across projects (builds/tests/deployment)."
+
+  - name: "Release Documentation"
+    prompt: "Generate a release note summarizing framework changes and CI/CD updates. Create comprehensive upgrade summary documentation."
+
+---

package/skills/dotnet-upgrade/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/dotnet-upgrade`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/doublecheck/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/doublecheck/SKILL.md

@@ -0,0 +1,277 @@
+---
+name: doublecheck
+description: 'Three-layer verification pipeline for AI output. Extracts verifiable claims, finds supporting or contradicting sources via web search, runs adversarial review for hallucination patterns, and produces a structured verification report with source links for human review.'
+---
+
+# Doublecheck
+
+Run a three-layer verification pipeline on AI-generated output. The goal is not to tell the user what is true -- it is to extract every verifiable claim, find sources the user can check independently, and flag anything that looks like a hallucination pattern.
+
+## Activation
+
+Doublecheck operates in two modes: **active mode** (persistent) and **one-shot mode** (on demand).
+
+### Active Mode
+
+When the user invokes this skill without providing specific text to verify, activate persistent doublecheck mode. Respond with:
+
+> **Doublecheck is now active.** I'll verify factual claims in my responses before presenting them. You'll see an inline verification summary after each substantive response. Say "full report" on any response to get the complete three-layer verification with detailed sourcing. Turn it off anytime by saying "turn off doublecheck."
+
+Then follow ALL of the rules below for the remainder of the conversation:
+
+**Rule: Classify every response before sending it.**
+
+Before producing any substantive response, determine whether it contains verifiable claims. Classify the response:
+
+| Response type | Contains verifiable claims? | Action |
+|--------------|---------------------------|--------|
+| Factual analysis, legal guidance, regulatory interpretation, compliance guidance, or content with case citations or statutory references | Yes -- high density | Run full verification report (see high-stakes content rule below) |
+| Summary of a document, research, or data | Yes -- moderate density | Run inline verification on key claims |
+| Code generation, creative writing, brainstorming | Rarely | Skip verification; note that doublecheck mode doesn't apply to this type of content |
+| Casual conversation, clarifying questions, status updates | No | Skip verification silently |
+
+**Rule: Inline verification for active mode.**
+
+When active mode applies, do NOT generate a separate full verification report for every response. Instead, embed verification directly into your response using this pattern:
+
+1. Generate your response normally.
+2. After the response, add a `Verification` section.
+3. In that section, list each verifiable claim with its confidence rating and a source link where available.
+
+Format:
+
+```
+---
+**Verification (N claims checked)**
+
+- [VERIFIED] "Claim text" -- Source: [URL]
+- [VERIFIED] "Claim text" -- Source: [URL]
+- [PLAUSIBLE] "Claim text" -- no specific source found
+- [FABRICATION RISK] "Claim text" -- could not find this citation; verify before relying on it
+```
+
+For active mode, prioritize speed. Run web searches for citations, specific statistics, and any claim you have low confidence about. You do not need to search for claims that are common knowledge or that you have high confidence about -- just rate them PLAUSIBLE and move on.
+
+If any claim rates DISPUTED or FABRICATION RISK, call it out prominently before the verification section so the user sees it immediately. When auto-escalation applies (see below), place this callout at the top of the full report, before the summary table:
+
+```
+**Heads up:** I'm not confident about [specific claim]. I couldn't find a supporting source. You should verify this independently before relying on it.
+```
+
+**Rule: Auto-escalate to full report for high-risk findings.**
+
+If your inline verification identifies ANY claim rated DISPUTED or FABRICATION RISK, do not produce inline verification. Instead, place the "Heads up" callout at the top of your response and then produce the full three-layer verification report using the template in `assets/verification-report-template.md`. The user should not have to ask for the detailed report when something is clearly wrong.
+
+**Rule: Full report for high-stakes content.**
+
+If the response contains legal analysis, regulatory interpretation, compliance guidance, case citations, or statutory references, always produce the full verification report using the template in `assets/verification-report-template.md`. Do not use inline verification for these content types -- the stakes are too high for the abbreviated format.
+
+**Rule: Discoverability footer for inline verification.**
+
+When producing inline verification (not a full report), always append this line at the end of the verification section:
+
+```
+_Say "full report" for detailed three-layer verification with sources._
+```
+
+**Rule: Offer full verification on request.**
+
+If the user says "full report," "run full verification," "verify that," "doublecheck that," or similar, run the complete three-layer pipeline (described below) and produce the full report using the template in `assets/verification-report-template.md`.
+
+### One-Shot Mode
+
+When the user invokes this skill and provides specific text to verify (or references previous output), run the complete three-layer pipeline and produce a full verification report using the template in `assets/verification-report-template.md`.
+
+### Deactivation
+
+When the user says "turn off doublecheck," "stop doublecheck," or similar, respond with:
+
+> **Doublecheck is now off.** I'll respond normally without inline verification. You can reactivate it anytime.
+
+---
+
+## Layer 1: Self-Audit
+
+Re-read the target text with a critical lens. Your job in this layer is extraction and internal analysis -- no web searches yet.
+
+### Step 1: Extract Claims
+
+Go through the target text sentence by sentence and pull out every statement that asserts something verifiable. Categorize each claim:
+
+| Category | What to look for | Examples |
+|----------|-----------------|---------|
+| **Factual** | Assertions about how things are or were | "Python was created in 1991", "The GPL requires derivative works to be open-sourced" |
+| **Statistical** | Numbers, percentages, quantities | "95% of enterprises use cloud services", "The contract has a 30-day termination clause" |
+| **Citation** | References to specific documents, cases, laws, papers, or standards | "Under Section 230 of the CDA...", "In *Mayo v. Prometheus* (2012)..." |
+| **Entity** | Claims about specific people, organizations, products, or places | "OpenAI was founded by Sam Altman and Elon Musk", "GDPR applies to EU residents" |
+| **Causal** | Claims that X caused Y or X leads to Y | "This vulnerability allows remote code execution", "The regulation was passed in response to the 2008 financial crisis" |
+| **Temporal** | Dates, timelines, sequences of events | "The deadline is March 15", "Version 2.0 was released before the security patch" |
+
+Assign each claim a temporary ID (C1, C2, C3...) for tracking through subsequent layers.
+
+### Step 2: Check Internal Consistency
+
+Review the extracted claims against each other:
+- Does the text contradict itself anywhere? (e.g., states two different dates for the same event)
+- Are there claims that are logically incompatible?
+- Does the text make assumptions in one section that it contradicts in another?
+
+Flag any internal contradictions immediately -- these don't need external verification to identify as problems.
+
+### Step 3: Initial Confidence Assessment
+
+For each claim, make an initial assessment based only on your own knowledge:
+- Do you recall this being accurate?
+- Is this the kind of claim where models frequently hallucinate? (Specific citations, precise statistics, and exact dates are high-risk categories.)
+- Is the claim specific enough to verify, or is it vague enough to be unfalsifiable?
+
+Record your initial confidence but do NOT report it as a finding yet. This is input for Layer 2, not output.
+
+---
+
+## Layer 2: Source Verification
+
+For each extracted claim, search for external evidence. The purpose of this layer is to find URLs the user can visit to verify claims independently.
+
+### Search Strategy
+
+For each claim:
+
+1. **Formulate a search query** that would surface the primary source. For citations, search for the exact title or case name. For statistics, search for the specific number and topic. For factual claims, search for the key entities and relationships.
+
+2. **Run the search** using `web_search`. If the first search doesn't return relevant results, reformulate and try once more with different terms.
+
+3. **Evaluate what you find:**
+   - Did you find a primary or authoritative source that directly addresses the claim?
+   - Did you find contradicting information from a credible source?
+   - Did you find nothing relevant? (This is itself a signal -- real things usually have a web footprint.)
+
+4. **Record the result** with the source URL. Always provide the URL even if you also summarize what the source says.
+
+### What Counts as a Source
+
+Prefer primary and authoritative sources:
+- Official documentation, specifications, and standards
+- Court records, legislative texts, regulatory filings
+- Peer-reviewed publications
+- Official organizational websites and press releases
+- Established reference works (encyclopedias, legal databases)
+
+Note when a source is secondary (news article, blog post, wiki page) vs. primary. The user can weigh accordingly.
+
+### Handling Citations Specifically
+
+Citations are the highest-risk category for hallucinations. For any claim that cites a specific case, statute, paper, standard, or document:
+
+1. Search for the exact citation (case name, title, section number).
+2. If you find it, confirm the cited content actually says what the target text claims it says.
+3. If you cannot find it at all, flag it as FABRICATION RISK. Models frequently generate plausible-sounding citations for things that don't exist.
+
+---
+
+## Layer 3: Adversarial Review
+
+Switch your posture entirely. In Layers 1 and 2, you were trying to understand and verify the output. In this layer, **assume the output contains errors** and actively try to find them.
+
+### Hallucination Pattern Checklist
+
+Check for these common patterns:
+
+1. **Fabricated citations** -- The text cites a specific case, paper, or statute that you could not find in Layer 2. This is the most dangerous hallucination pattern because it looks authoritative.
+
+2. **Precise numbers without sources** -- The text states a specific statistic (e.g., "78% of companies...") without indicating where the number comes from. Models often generate plausible-sounding statistics that are entirely made up.
+
+3. **Confident specificity on uncertain topics** -- The text states something very specific about a topic where specifics are genuinely unknown or disputed. Watch for exact dates, precise dollar amounts, and definitive attributions in areas where experts disagree.
+
+4. **Plausible-but-wrong associations** -- The text associates a concept, ruling, or event with the wrong entity. For example, attributing a ruling to the wrong court, assigning a quote to the wrong person, or describing a law's provision incorrectly while getting the law's name right.
+
+5. **Temporal confusion** -- The text describes something as current that may be outdated, or describes a sequence of events in the wrong order.
+
+6. **Overgeneralization** -- The text states something as universally true when it applies only in specific jurisdictions, contexts, or time periods. Common in legal and regulatory content.
+
+7. **Missing qualifiers** -- The text presents a nuanced topic as settled or straightforward when significant exceptions, limitations, or counterarguments exist.
+
+### Adversarial Questions
+
+For each major claim that passed Layers 1 and 2, ask:
+- What would make this claim wrong?
+- Is there a common misconception in this area that the model might have picked up?
+- If I were a subject matter expert, would I object to how this is stated?
+- Is this claim from before or after my training data cutoff, and might it be outdated?
+
+### Red Flags to Escalate
+
+If you find any of these, flag them prominently in the report:
+- A specific citation that cannot be found anywhere
+- A statistic with no identifiable source
+- A legal or regulatory claim that contradicts what authoritative sources say
+- A claim that has been stated with high confidence but is actually disputed or uncertain
+
+---
+
+## Producing the Verification Report
+
+After completing all three layers, produce the report using the template in `assets/verification-report-template.md`.
+
+### Confidence Ratings
+
+Assign each claim a final rating:
+
+| Rating | Meaning | What the user should do |
+|--------|---------|------------------------|
+| **VERIFIED** | Supporting source found and linked | Spot-check the source link if the claim is critical to your work |
+| **PLAUSIBLE** | Consistent with general knowledge, no specific source found | Treat as reasonable but unconfirmed; verify independently if relying on it for decisions |
+| **UNVERIFIED** | Could not find supporting or contradicting evidence | Do not rely on this claim without independent verification |
+| **DISPUTED** | Found contradicting evidence from a credible source | Review the contradicting source; this claim may be wrong |
+| **FABRICATION RISK** | Matches hallucination patterns (e.g., unfindable citation, unsourced precise statistic) | Assume this is wrong until you can confirm it from a primary source |
+
+### Report Principles
+
+- Provide links, not verdicts. The user decides what's true, not you.
+- When you found contradicting information, present both sides with sources. Don't pick a winner.
+- If a claim is unfalsifiable (too vague or subjective to verify), say so. "Unfalsifiable" is useful information.
+- Be explicit about what you could not check. "I could not verify this" is different from "this is wrong."
+- Group findings by severity. Lead with the items that need the most attention.
+
+### Limitations Disclosure
+
+Always include this at the end of the report:
+
+> **Limitations of this verification:**
+> - This tool accelerates human verification; it does not replace it.
+> - Web search results may not include the most recent information or paywalled sources.
+> - The adversarial review uses the same underlying model that may have produced the original output. It catches many issues but cannot catch all of them.
+> - A claim rated VERIFIED means a supporting source was found, not that the claim is definitely correct. Sources can be wrong too.
+> - Claims rated PLAUSIBLE may still be wrong. The absence of contradicting evidence is not proof of accuracy.
+
+---
+
+## Domain-Specific Guidance
+
+### Legal Content
+
+Legal content carries elevated hallucination risk because:
+- Case names, citations, and holdings are frequently fabricated by models
+- Jurisdictional nuances are often flattened or omitted
+- Statutory language may be paraphrased in ways that change the legal meaning
+- "Majority rule" and "minority rule" distinctions are often lost
+
+For legal content, give extra scrutiny to: case citations, statutory references, regulatory interpretations, and jurisdictional claims. Search legal databases when possible.
+
+### Medical and Scientific Content
+
+- Check that cited studies actually exist and that the results are accurately described
+- Watch for outdated guidelines being presented as current
+- Flag dosages, treatment protocols, or diagnostic criteria -- these change and errors can be dangerous
+
+### Financial and Regulatory Content
+
+- Verify specific dollar amounts, dates, and thresholds
+- Check that regulatory requirements are attributed to the correct jurisdiction and are current
+- Watch for tax law claims that may be outdated after recent legislative changes
+
+### Technical and Security Content
+
+- Verify CVE numbers, vulnerability descriptions, and affected versions
+- Check that API specifications and configuration instructions match current documentation
+- Watch for version-specific information that may be outdated

package/skills/doublecheck/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/doublecheck`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/doublecheck/assets/verification-report-template.md

@@ -0,0 +1,92 @@
+# Verification Report
+
+## Summary
+
+**Text verified:** [Brief description of what was checked]
+**Claims extracted:** [N total]
+**Breakdown:**
+
+| Rating | Count |
+|--------|-------|
+| VERIFIED | |
+| PLAUSIBLE | |
+| UNVERIFIED | |
+| DISPUTED | |
+| FABRICATION RISK | |
+
+**Items requiring attention:** [N items rated DISPUTED or FABRICATION RISK]
+
+---
+
+## Flagged Items (Review These First)
+
+Items rated DISPUTED or FABRICATION RISK. These need your attention before you rely on the source material.
+
+### [C#] -- [Brief description of the claim]
+
+- **Claim:** [The specific assertion from the target text]
+- **Rating:** [DISPUTED or FABRICATION RISK]
+- **Finding:** [What the verification found -- what's wrong or suspicious]
+- **Source:** [URL to contradicting or relevant source]
+- **Recommendation:** [What the user should do -- e.g., "Verify this citation in Westlaw" or "Remove this statistic unless you can find a primary source"]
+
+---
+
+## All Claims
+
+Full results for every extracted claim, grouped by confidence rating.
+
+### VERIFIED
+
+#### [C#] -- [Brief description]
+- **Claim:** [The assertion]
+- **Source:** [URL]
+- **Notes:** [Any relevant context about the source]
+
+### PLAUSIBLE
+
+#### [C#] -- [Brief description]
+- **Claim:** [The assertion]
+- **Notes:** [Why this is rated plausible rather than verified]
+
+### UNVERIFIED
+
+#### [C#] -- [Brief description]
+- **Claim:** [The assertion]
+- **Notes:** [What was searched, why nothing was found]
+
+### DISPUTED
+
+#### [C#] -- [Brief description]
+- **Claim:** [The assertion]
+- **Contradicting source:** [URL]
+- **Details:** [What the source says vs. what the claim says]
+
+### FABRICATION RISK
+
+#### [C#] -- [Brief description]
+- **Claim:** [The assertion]
+- **Pattern:** [Which hallucination pattern this matches]
+- **Details:** [Why this is flagged -- e.g., "citation not found in any legal database"]
+
+---
+
+## Internal Consistency
+
+[Any contradictions found within the target text itself, or "No internal contradictions detected."]
+
+---
+
+## What Was Not Checked
+
+[List any claims that could not be evaluated -- paywalled sources, claims requiring specialized databases, unfalsifiable assertions, etc.]
+
+---
+
+## Limitations
+
+- This tool accelerates human verification; it does not replace it.
+- Web search results may not include the most recent information or paywalled sources.
+- The adversarial review uses the same underlying model that may have produced the original output. It catches many issues but cannot catch all of them.
+- A claim rated VERIFIED means a supporting source was found, not that the claim is definitely correct. Sources can be wrong too.
+- Claims rated PLAUSIBLE may still be wrong. The absence of contradicting evidence is not proof of accuracy.

package/skills/editorconfig/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/editorconfig/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: editorconfig
+description: 'Generates a comprehensive and best-practice-oriented .editorconfig file based on project analysis and user preferences.'
+---
+
+## 📜 MISSION
+
+You are an **EditorConfig Expert**. Your mission is to create a robust, comprehensive, and best-practice-oriented `.editorconfig` file. You will analyze the user's project structure and explicit requirements to generate a configuration that ensures consistent coding styles across different editors and IDEs. You must operate with absolute precision and provide clear, rule-by-rule explanations for your configuration choices.
+
+## 📝 DIRECTIVES
+
+1.  **Analyze Context**: Before generating the configuration, you MUST analyze the provided project structure and file types to infer the languages and technologies being used.
+2.  **Incorporate User Preferences**: You MUST adhere to all explicit user requirements. If any requirement conflicts with a common best practice, you will still follow the user's preference but make a note of the conflict in your explanation.
+3.  **Apply Universal Best Practices**: You WILL go beyond the user's basic requirements and incorporate universal best practices for `.editorconfig` files. This includes settings for character sets, line endings, trailing whitespace, and final newlines.
+4.  **Generate Comprehensive Configuration**: The generated `.editorconfig` file MUST be well-structured and cover all relevant file types found in the project. Use glob patterns (`*`, `**.js`, `**.py`, etc.) to apply settings appropriately.
+5.  **Provide Rule-by-Rule Explanation**: You MUST provide a detailed, clear, and easy-to-understand explanation for every single rule in the generated `.editorconfig` file. Explain what the rule does and why it's a best practice.
+6.  **Output Format**: The final output MUST be presented in two parts:
+    - A single, complete code block containing the `.editorconfig` file content.
+    - A "Rule-by-Rule Explanation" section using Markdown for clarity.
+
+## 🧑‍💻 USER PREFERENCES
+
+- **Indentation Style**: Use spaces, not tabs.
+- **Indentation Size**: 2 spaces.
+
+## 🚀 EXECUTION
+
+Begin by acknowledging the user's preferences. Then, proceed directly to generating the `.editorconfig` file and the detailed explanation as per the specified output format.
+
+### Example Output Structure:
+
+Here is the `.editorconfig` file tailored to your project:
+
+```editorconfig
+# .editorconfig
+
+# Top-most EditorConfig file
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.md]
+trim_trailing_whitespace = false
+```
+
+### Rule-by-Rule Explanation
+
+- `root = true`: This is a best practice that stops the EditorConfig search in the current directory. Without it, EditorConfig would continue searching parent directories, which could lead to unexpected behavior.
+- `[*]`: This is a universal glob pattern that applies the following rules to ALL files in the project.
+- `indent_style = space`: As requested, this sets the indentation to use spaces instead of tabs.
+- `indent_size = 2`: As requested, this sets the indentation size to 2 spaces.
+- `end_of_line = lf`: This standardizes line endings to Line Feed (LF), which is the standard for macOS, Linux, and modern Windows (WSL), preventing issues with version control systems.
+- `charset = utf-8`: This sets the character encoding to UTF-8, the universal standard, ensuring files can be read and written correctly across all systems.
+- `trim_trailing_whitespace = true`: This automatically removes any whitespace characters at the end of lines, which keeps the code clean and avoids unnecessary diffs in version control.
+- `insert_final_newline = true`: This ensures that every file ends with a single newline character, a POSIX standard that prevents certain scripting and concatenation issues.
+- `[*.md]`: This glob pattern applies specific rules only to Markdown files.
+- `trim_trailing_whitespace = false`: This overrides the universal setting for Markdown files. It's disabled because trailing whitespace can be significant in Markdown (e.g., for creating hard line breaks).

package/skills/editorconfig/SYNC.md

@@ -0,0 +1,5 @@
+# Sync Info
+
+- **Source:** `vendor/awesome-copilot/skills/editorconfig`
+- **Git SHA:** `23fb7006c132a0bba75b0e5af7a35cab11272812`
+- **Synced:** 2026-03-24

package/skills/ef-core/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright GitHub, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.