devskill 2.0.7 → 2.0.8

package/skills/secret-scanning/references/push-protection.md

@@ -0,0 +1,164 @@
+# Push Protection Reference
+
+Detailed reference for GitHub push protection — preventing secrets from reaching repositories, bypass workflows, and delegated bypass configuration.
+
+## How Push Protection Works
+
+Push protection scans for secrets during the push process and blocks pushes containing detected secrets. It operates as a preventative control, unlike standard secret scanning which detects secrets after commit.
+
+### What Gets Scanned
+
+| Surface | Scanned |
+|---|---|
+| Command line pushes | ✅ |
+| GitHub UI commits | ✅ |
+| File uploads to repo | ✅ |
+| REST API content creation requests | ✅ |
+
+### Types of Push Protection
+
+**Repository push protection:**
+- Requires GitHub Secret Protection enabled
+- Disabled by default; enabled by repo admin, org owner, or security manager
+- Generates alerts for bypasses in the Security tab
+- Can be enabled at repository, organization, or enterprise level
+
+**User push protection:**
+- Enabled by default for all GitHub.com accounts
+- Blocks pushes to public repositories containing supported secrets
+- Does NOT generate alerts when bypassed (unless repo also has push protection enabled)
+- Managed via personal account settings
+
+## Resolving Blocked Pushes — Command Line
+
+When push protection blocks a push, the error message includes:
+- The secret type detected
+- Commit SHAs containing the secret
+- File paths and line numbers
+- A URL to bypass (if permitted)
+
+### Remove Secret from Latest Commit
+
+```bash
+# Edit the file to remove the secret
+# Amend the commit
+git commit --amend --all
+
+# Push again
+git push
+```
+
+### Remove Secret from Earlier Commits
+
+```bash
+# 1. Review the push error for all commits containing the secret
+# 2. Find the earliest commit with the secret
+git log
+
+# 3. Interactive rebase before that commit
+git rebase -i <EARLIEST-COMMIT>~1
+
+# 4. Change 'pick' to 'edit' for the offending commit(s)
+# 5. Remove the secret from the file
+# 6. Stage and amend
+git add .
+git commit --amend
+
+# 7. Continue rebase
+git rebase --continue
+
+# 8. Push
+git push
+```
+
+### Bypass Push Protection
+
+1. Visit the URL from the error message (must be the same user who pushed)
+2. Select a reason:
+   - **It's used in tests** → creates a closed alert (resolved as "used in tests")
+   - **It's a false positive** → creates a closed alert (resolved as "false positive")
+   - **I'll fix it later** → creates an open alert
+3. Click **Allow me to push this secret**
+4. Re-push within **3 hours** (after that, repeat the bypass process)
+
+> A bypass reason is required when the repo has secret scanning enabled. For public repos with only user push protection (no repo push protection), no reason is needed and no alert is generated.
+
+## Resolving Blocked Pushes — GitHub UI
+
+When creating or editing a file in the GitHub UI:
+1. A banner appears warning about the detected secret
+2. Options to remove the secret or bypass are presented inline
+3. Same bypass reasons apply as command line
+
+## Resolving Blocked Pushes — REST API
+
+Push protection also applies to REST API content creation endpoints. When blocked:
+- The API returns an error response with details about the detected secret
+- Include the bypass reason in the request to proceed
+
+## Delegated Bypass
+
+Delegated bypass gives organizations fine-grained control over who can bypass push protection.
+
+### How It Works
+
+1. Organization owners/repo admins create a **bypass list** of users, roles, or teams
+2. Users on the bypass list can bypass push protection directly (with a reason)
+3. All other contributors must **submit a bypass request** for review
+4. Bypass requests appear in the Security tab → "Push protection bypass" page
+5. Requests expire after **7 days** if not reviewed
+
+### Who Can Always Bypass (Without Request)
+
+- Organization owners
+- Security managers
+- Users in teams/roles added to the bypass list
+- Users with custom role having "review and manage secret scanning bypass requests" permission
+
+### Enabling Delegated Bypass
+
+**Repository level:**
+1. Settings → Advanced Security → Push protection
+2. Enable "Restrict who can bypass push protection"
+3. Add users, teams, or roles to the bypass list
+
+**Organization level:**
+1. Organization Settings → Advanced Security → Global settings
+2. Configure delegated bypass in security configuration
+
+### Managing Bypass Requests
+
+Designated reviewers:
+1. Navigate to repository Security tab → "Push protection bypass"
+2. Review pending requests (includes the secret, commit, and contributor's comment)
+3. **Approve** — contributor can push the secret and any future commits with the same secret
+4. **Deny** — contributor must remove the secret before pushing
+
+### Bypass Request Flow (Contributor Perspective)
+
+1. Push is blocked; visit the URL from the error message
+2. Add a comment explaining why the secret is safe to push
+3. Click **Submit request**
+4. Wait for email notification of approval/denial
+5. If approved: push the commit
+6. If denied: remove the secret and push again
+
+## Push Protection Patterns
+
+Push protection supports a subset of secret scanning patterns. Not all detected secret types trigger push protection blocks.
+
+Key considerations:
+- Older/legacy token formats may not be supported by push protection
+- Some patterns have higher false positive rates and are excluded from push protection
+- Custom patterns can have push protection enabled after publishing
+
+For the full list of patterns supported by push protection, see [Supported secret scanning patterns](https://docs.github.com/en/code-security/secret-scanning/introduction/supported-secret-scanning-patterns).
+
+## Configuring Push Protection for Custom Patterns
+
+After publishing a custom pattern:
+1. Navigate to the custom pattern in Settings → Advanced Security
+2. Click **Enable** next to push protection
+3. The pattern will now block pushes containing matching secrets
+
+> Push protection for custom patterns only applies to repos that have push protection enabled. Enabling push protection for commonly found patterns can be disruptive to contributors.

package/skills/semantic-kernel/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/semantic-kernel/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: semantic-kernel
+description: 'Create, update, refactor, explain, or review Semantic Kernel solutions using shared guidance plus language-specific references for .NET and Python.'
+---
+
+# Semantic Kernel
+
+Use this skill when working with applications, plugins, function-calling flows, or AI integrations built on Semantic Kernel.
+
+Always ground implementation advice in the latest Semantic Kernel documentation and samples rather than memory alone.
+
+## Determine the target language first
+
+Choose the language workflow before making recommendations or code changes:
+
+1. Use the **.NET** workflow when the repository contains `.cs`, `.csproj`, `.sln`, or other .NET project files, or when the user explicitly asks for C# or .NET guidance. Follow [references/dotnet.md](references/dotnet.md).
+2. Use the **Python** workflow when the repository contains `.py`, `pyproject.toml`, `requirements.txt`, or the user explicitly asks for Python guidance. Follow [references/python.md](references/python.md).
+3. If the repository contains both ecosystems, match the language used by the files being edited or the user's stated target.
+4. If the language is ambiguous, inspect the current workspace first and then choose the closest language-specific reference.
+
+## Always consult live documentation
+
+- Read the Semantic Kernel overview first: <https://learn.microsoft.com/semantic-kernel/overview/>
+- Prefer official docs and samples for the current API surface.
+- Use the Microsoft Docs MCP tooling when available to fetch up-to-date framework guidance and examples.
+
+## Shared guidance
+
+When working with Semantic Kernel in any language:
+
+- Use async patterns for kernel operations.
+- Follow official plugin and function-calling patterns.
+- Implement explicit error handling and logging.
+- Prefer strong typing, clear abstractions, and maintainable composition patterns.
+- Use built-in connectors for Azure AI Foundry, Azure OpenAI, OpenAI, and other AI services, while preferring Azure AI Foundry services for new projects when that fits the task.
+- Use the kernel's memory and context-management capabilities when they simplify the solution.
+- Use `DefaultAzureCredential` when Azure authentication is appropriate.
+
+## Workflow
+
+1. Determine the target language and read the matching reference file.
+2. Fetch the latest official docs and samples before making implementation choices.
+3. Apply the shared Semantic Kernel guidance from this skill.
+4. Use the language-specific package, repository, sample paths, and coding practices from the chosen reference.
+5. When examples in the repo differ from current docs, explain the difference and follow the current supported pattern.
+
+## References
+
+- [.NET reference](references/dotnet.md)
+- [Python reference](references/python.md)
+
+## Completion criteria
+
+- Recommendations match the target language.
+- Package names, repository paths, and sample locations match the selected ecosystem.
+- Guidance reflects current Semantic Kernel documentation rather than stale assumptions.

package/skills/semantic-kernel/SYNC.md

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

package/skills/semantic-kernel/references/dotnet.md

@@ -0,0 +1,15 @@
+# Semantic Kernel for .NET
+
+Use this reference when the target project is written in C# or another .NET language.
+
+## Authoritative sources
+
+- Repository: <https://github.com/microsoft/semantic-kernel/tree/main/dotnet>
+- Samples: <https://github.com/microsoft/semantic-kernel/tree/main/dotnet/samples>
+
+## .NET-specific guidance
+
+- Use `async`/`await` patterns consistently for kernel operations.
+- Follow .NET best practices with strong typing and explicit interfaces.
+- Keep service registration, configuration, and authentication aligned with standard .NET hosting patterns.
+- Check the latest .NET samples before introducing new APIs, plugins, or orchestration patterns.

package/skills/semantic-kernel/references/python.md

@@ -0,0 +1,15 @@
+# Semantic Kernel for Python
+
+Use this reference when the target project is written in Python.
+
+## Authoritative sources
+
+- Repository: <https://github.com/microsoft/semantic-kernel/tree/main/python>
+- Samples: <https://github.com/microsoft/semantic-kernel/tree/main/python/samples>
+
+## Python-specific guidance
+
+- Use modern async patterns throughout kernel operations.
+- Add type hints and keep APIs explicit even in dynamic code.
+- Follow standard Python packaging and environment practices for dependencies and tooling.
+- Check the latest Python samples before introducing new APIs, plugins, or orchestration patterns.

package/skills/shuffle-json-data/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/shuffle-json-data/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: shuffle-json-data
+description: 'Shuffle repetitive JSON objects safely by validating schema consistency before randomising entries.'
+---
+
+# Shuffle JSON Data
+
+## Overview
+
+Shuffle repetitive JSON objects without corrupting the data or breaking JSON
+syntax. Always validate the input file first. If a request arrives without a
+data file, pause and ask for one. Only proceed after confirming the JSON can be
+shuffled safely.
+
+## Role
+
+You are a data engineer who understands how to randomise or reorder JSON data
+without sacrificing integrity. Combine data-engineering best practices with
+mathematical knowledge of randomizing data to protect data quality.
+
+- Confirm that every object shares the same property names when the default
+  behavior targets each object.
+- Reject or escalate when the structure prevents a safe shuffle (for example,
+  nested objects while operating in the default state).
+- Shuffle data only after validation succeeds or after reading explicit
+  variable overrides.
+
+## Objectives
+
+1. Validate that the provided JSON is structurally consistent and can be
+   shuffled without producing invalid output.
+2. Apply the default behavior—shuffle at the object level—when no variables
+   appear under the `Variables` header.
+3. Honour variable overrides that adjust which collections are shuffled, which
+   properties are required, or which properties must be ignored.
+
+## Data Validation Checklist
+
+Before shuffling:
+
+- Ensure every object shares an identical set of property names when the
+  default state is in effect.
+- Confirm there are no nested objects in the default state.
+- Verify that the JSON file itself is syntactically valid and well formed.
+- If any check fails, stop and report the inconsistency instead of modifying
+  the data.
+
+## Acceptable JSON
+
+When the default behavior is active, acceptable JSON resembles the following
+pattern:
+
+```json
+[
+  {
+    "VALID_PROPERTY_NAME-a": "value",
+    "VALID_PROPERTY_NAME-b": "value"
+  },
+  {
+    "VALID_PROPERTY_NAME-a": "value",
+    "VALID_PROPERTY_NAME-b": "value"
+  }
+]
+```
+
+## Unacceptable JSON (Default State)
+
+If the default behavior is active, reject files that contain nested objects or
+inconsistent property names. For example:
+
+```json
+[
+  {
+    "VALID_PROPERTY_NAME-a": {
+      "VALID_PROPERTY_NAME-a": "value",
+      "VALID_PROPERTY_NAME-b": "value"
+    },
+    "VALID_PROPERTY_NAME-b": "value"
+  },
+  {
+    "VALID_PROPERTY_NAME-a": "value",
+    "VALID_PROPERTY_NAME-b": "value",
+    "VALID_PROPERTY_NAME-c": "value"
+  }
+]
+```
+
+If variable overrides clearly explain how to handle nesting or differing
+properties, follow those instructions; otherwise do not attempt to shuffle the
+data.
+
+## Workflow
+
+1. **Gather Input** – Confirm that a JSON file or JSON-like structure is
+   attached. If not, pause and request the data file.
+2. **Review Configuration** – Merge defaults with any supplied variables under
+   the `Variables` header or prompt-level overrides.
+3. **Validate Structure** – Apply the Data Validation Checklist to confirm that
+   shuffling is safe in the selected mode.
+4. **Shuffle Data** – Randomize the collection(s) described by the variables or
+   the default behavior while maintaining JSON validity.
+5. **Return Results** – Output the shuffled data, preserving the original
+   encoding and formatting conventions.
+
+## Requirements for Shuffling Data
+
+- Each request must provide a JSON file or a compatible JSON structure.
+- If the data cannot remain valid after a shuffle, stop and report the
+  inconsistency.
+- Observe the default state when no overrides are supplied.
+
+## Examples
+
+Below are two sample interactions demonstrating an error case and a successful
+configuration.
+
+### Missing File
+
+```text
+[user]
+> /shuffle-json-data
+[agent]
+> Please provide a JSON file to shuffle. Preferably as chat variable or attached context.
+```
+
+### Custom Configuration
+
+```text
+[user]
+> /shuffle-json-data #file:funFacts.json ignoreProperties = "year", "category"; requiredProperties = "fact"
+```
+
+## Default State
+
+Unless variables in this prompt or in a request override the defaults, treat the
+input as follows:
+
+- fileName = **REQUIRED**
+- ignoreProperties = none
+- requiredProperties = first set of properties from the first object
+- nesting = false
+
+## Variables
+
+When provided, the following variables override the default state. Interpret
+closely related names sensibly so that the task can still succeed.
+
+- ignoreProperties
+- requiredProperties
+- nesting

package/skills/shuffle-json-data/SYNC.md

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

package/skills/snowflake-semanticview/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/snowflake-semanticview/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: snowflake-semanticview
+description: Create, alter, and validate Snowflake semantic views using Snowflake CLI (snow). Use when asked to build or troubleshoot semantic views/semantic layer definitions with CREATE/ALTER SEMANTIC VIEW, to validate semantic-view DDL against Snowflake via CLI, or to guide Snowflake CLI installation and connection setup.
+---
+
+# Snowflake Semantic Views
+
+## One-Time Setup
+
+- Verify Snowflake CLI installation by opening a new terminal and running `snow --help`.
+- If Snowflake CLI is missing or the user cannot install it, direct them to https://docs.snowflake.com/en/developer-guide/snowflake-cli/installation/installation.
+- Configure a Snowflake connection with `snow connection add` per https://docs.snowflake.com/en/developer-guide/snowflake-cli/connecting/configure-connections#add-a-connection.
+- Use the configured connection for all validation and execution steps.
+
+## Workflow For Each Semantic View Request
+
+1. Confirm the target database, schema, role, warehouse, and final semantic view name.
+2. Confirm the model follows a star schema (facts with conformed dimensions).
+3. Draft the semantic view DDL using the official syntax:
+   - https://docs.snowflake.com/en/sql-reference/sql/create-semantic-view
+4. Populate synonyms and comments for each dimension, fact, and metric:
+   - Read Snowflake table/view/column comments first (preferred source):
+     - https://docs.snowflake.com/en/sql-reference/sql/comment
+   - If comments or synonyms are missing, ask whether you can create them, whether the user wants to provide text, or whether you should draft suggestions for approval.
+5. Use SELECT statements with DISTINCT and LIMIT (maximum 1000 rows) to discover relationships between fact and dimension tables, identify column data types, and create more meaningful comments and synonyms for columns.
+6. Create a temporary validation name (for example, append `__tmp_validate`) while keeping the same database and schema.
+7. Always validate by sending the DDL to Snowflake via Snowflake CLI before finalizing:
+   - Use `snow sql` to execute the statement with the configured connection.
+   - If flags differ by version, check `snow sql --help` and use the connection option shown there.
+8. If validation fails, iterate on the DDL and re-run the validation step until it succeeds.
+9. Apply the final DDL (create or alter) using the real semantic view name.
+10. Run a sample query against the final semantic view to confirm it works as expected. It has a different SQL syntax as can be seen here: https://docs.snowflake.com/en/user-guide/views-semantic/querying#querying-a-semantic-view
+Example:
+
+```SQL
+SELECT * FROM SEMANTIC_VIEW(
+    my_semview_name
+    DIMENSIONS customer.customer_market_segment
+    METRICS orders.order_average_value
+)
+ORDER BY customer_market_segment;
+```
+
+11. Clean up any temporary semantic view created during validation.
+
+## Synonyms And Comments (Required)
+
+- Use the semantic view syntax for synonyms and comments:
+
+```
+WITH SYNONYMS [ = ] ( 'synonym' [ , ... ] )
+COMMENT = 'comment_about_dim_fact_or_metric'
+```
+
+- Treat synonyms as informational only; do not use them to reference dimensions, facts, or metrics elsewhere.
+- Use Snowflake comments as the preferred and first source for synonyms and comments:
+  - https://docs.snowflake.com/en/sql-reference/sql/comment
+- If Snowflake comments are missing, ask whether you can create them, whether the user wants to provide text, or whether you should draft suggestions for approval.
+- Do not invent synonyms or comments without user approval.
+
+## Validation Pattern (Required)
+
+- Never skip validation. Always execute the DDL against Snowflake with Snowflake CLI before presenting it as final.
+- Prefer a temporary name for validation to avoid clobbering the real view.
+
+## Example CLI Validation (Template)
+
+```bash
+# Replace placeholders with real values.
+snow sql -q "<CREATE OR ALTER SEMANTIC VIEW ...>" --connection <connection_name>
+```
+
+If the CLI uses a different connection flag in your version, run:
+
+```bash
+snow sql --help
+```
+
+## Notes
+
+- Treat installation and connection setup as one-time steps, but confirm they are done before the first validation.
+- Keep the final semantic view definition identical to the validated temporary definition except for the name.
+- Do not omit synonyms or comments; consider them required for completeness even if optional in syntax.

package/skills/snowflake-semanticview/SYNC.md

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

package/skills/sponsor-finder/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.