opencode-skills-collection 4.1.14 → 4.1.16

package/bundled-skills/automated-triage/references/triage-stages.md

@@ -0,0 +1,141 @@
+# Triage Stages
+
+Each stage of a triage workflow is optional and customisable. Design your workflow around the stages that match how your team manually reviews alerts — automate the parts that are repetitive or time-consuming, and keep humans in the loop for the parts that need judgement.
+
+---
+
+## Stage 1: Fetching alerts
+
+**Tool:** `get_alerts`
+
+Collect the alerts you want to triage. `get_alerts` supports the following filters — combine them to define your triage scope:
+
+**Status**
+- `statuses` — filter by alert status. Pass `NOT_ACKNOWLEDGED` to only pick up alerts that haven't been triaged yet. Other values: `ACKNOWLEDGED`, `WORK_IN_PROGRESS`, `FIXED`, `EXPECTED`, `NO_ACTION_NEEDED`.
+
+**Scope**
+- `domain_ids` — limit to one or more Monte Carlo domains. Use `getDomains` to look up IDs. Useful if different teams own different parts of the data estate.
+- `audience_ids`
+- `owners`
+
+**Alert Details**
+- `alert_types` — filter by alert category.
+- `priorities` — `P1` through `P5`.
+
+**Asset**
+- `table_mcons`, `table_names`, `table_schemas`, `table_databases` — narrow triage to specific tables or parts of the warehouse.
+
+**Pagination**
+- `first` — number of alerts per page (max 100, default 20). Check for a `truncation_note` in the response — if present, paginate using `cursor` to retrieve the remaining alerts.
+
+Take care to avoid triaging too many alerts in one batch — where required, split alerts across multiple triage runs.
+
+---
+
+## Stage 2: Initial investigation (alert scoring)
+
+**Tool:** `alert_assessment`
+
+This stage replicates what a knowledgeable engineer does when scanning the alert feed — quickly assessing what's fired and how serious it looks. `alert_assessment` is lightweight enough to run on every alert.
+
+It returns:
+- **`incident_likelihood`** (HIGH/MEDIUM/LOW) — how likely the alert represents a real issue. Affected by: number of events, presence of concerning root causes (query changes, failures), how much thresholds were exceeded, and how noisy the monitor typically is.
+- **`alert_impact`** (HIGH/MEDIUM/LOW) — how significant the potential downstream impact is.  Use cases impacted.  Dashboards affected etc.
+- **`alert_description`** — plain-language description of what happened in the incident.
+- **`triage_summary`** — the key reasoning behind the incident likelihood and potential impact scores.
+
+**Run `alert_assessment` in parallel**, in batches of up to 10 at a time.
+
+### Customising the scoring
+
+`alert_assessment` runs with a default prompt but accepts a `user_instructions` parameter that lets you adjust the emphasis it places on different factors. For example:
+
+- Increase the weight given to monitors that feed particular use cases
+- Alter the emphasis placed on different features: for example historical noise
+- Emphasise alerts involving specific tables or domains
+
+Start with the defaults and tune `user_instructions` once you've seen real output.
+
+### Scoring vs. persisting: `alert_assessment` vs `triage_alert`
+
+`alert_assessment` is **read-only** — it returns a verdict but records nothing. That's exactly what you want for this stage: score every alert cheaply, then decide per alert whether it warrants troubleshooting and which action to take. The workflow persists outcomes later, in Stage 5, through the explicit action tools — so you stay in control of what gets written and when.
+
+`triage_alert` is the **persisted** counterpart: it scores *and* writes the verdict back onto the alert (marks it triaged, posts a notification, records ML feedback), identical to the in-app Triage button. It's the right tool for interactive "triage this alert" requests where the user wants the result recorded, but it's a poor fit for the scoring stage of a batch workflow — it would mark every alert in the batch triaged and fire a notification for each. Keep batch scoring on `alert_assessment`, and reserve `triage_alert` for the case where recording a single alert's triage *is* the action. It's idempotent (re-running on an already-triaged alert returns the existing verdict) and requires the `mcp/edit` scope.
+
+---
+
+## Stage 3: Deep troubleshooting
+
+**Tools:** `run_troubleshooting_agent`, `get_troubleshooting_agent_results`
+
+`run_troubleshooting_agent` runs the Monte Carlo Troubleshooting Agent on a single alert. This is substantially more expensive than `alert_assessment` — it tracks the issue upstream through lineage, analyses all queries involved, examines relevant PRs, and samples affected tables to identify root cause.
+
+**Only run `run_troubleshooting_agent` on alerts that warrant it.** A common filter: run troubleshooting only when BOTH `incident_likelihood` AND `alert_impact` are MEDIUM or HIGH. Skip any alert where either is LOW.
+
+You can adjust this threshold based on your environment — for example, also running troubleshooting when either score is HIGH (even if the other is LOW), while still requiring MEDIUM/MEDIUM as the baseline.
+
+**Use async mode for parallelism.** `run_troubleshooting_agent` defaults to `async_mode=True`, returning immediately with one of three statuses:
+- `success` — a previous analysis already completed; results are available immediately, no polling needed
+- `queued` — the job was accepted but hasn't started yet; wait ~30 seconds then start polling
+- `running` — the job is in progress; poll with increasing intervals (30s, 60s, 60s…)
+
+Fire all eligible alerts simultaneously, then poll each with `get_troubleshooting_agent_results(incident_id=...)` until it returns `success` or `failed`. Classify each alert as its result arrives. This avoids the timeout issues of synchronous calls and removes the need to limit concurrency.
+
+---
+
+## Stage 4: Classification
+
+Classify each alert immediately after its troubleshooting result arrives. Use the troubleshooting output to determine which category fits best.
+
+| Classification              | Description                                                                                                                    |
+| --------------------------- |--------------------------------------------------------------------------------------------------------------------------------|
+| **Intentional change**      | Planned migrations, feature releases, or bug fixes                                                                             |
+| **Natural data variation**  | Seasonal patterns or expected volatility                                                                                       |
+| **Possible data incident**  | Anything that requires further investigation                                                                                   |
+| **Resolved incident**       | A real incident that has already been resolved                                                                                 |
+| **Verified ongoing incident** | A clear incident that has not resolved, where troubleshooting identified the root cause (e.g. query change or infrastructure failure) |
+| **Other**                   | Does not fit the above                                                                                                         |
+
+These categories are a starting point. Adapt them to the language your team uses — if you have an internal classification scheme, map to that instead.
+
+---
+
+## Stage 5: Taking actions
+
+What you do after triage depends on your integrations, your team's workflow, and the maturity of your automation process. Start conservative and expand as you validate results.
+
+### Adding comments
+
+`create_or_update_alert_comment` — always a good starting point. Comments provide a record of what the agent found and recommended, without taking any irreversible action. Useful at every stage, regardless of whether you automate anything else.
+
+Suggested comment content:
+- **Scored but not troubleshot**: one sentence describing the anomaly and the incident likelihood/potential impact scores. Do not explain why it wasn't troubleshot. No recommendations.
+- **Troubleshot alerts**: 2–4 sentences — classification, reasoning, action taken or recommended
+
+### Updating alert status
+
+`update_alert` — set status based on classification:
+
+| Classification              | Status               |
+| --------------------------- | -------------------- |
+| Natural data variation      | `NO_ACTION_NEEDED`   |
+| Intentional change          | `EXPECTED`           |
+| Resolved incident           | `FIXED`              |
+| Verified ongoing incident   | `ACKNOWLEDGED`       |
+| Possible data incident      | *(leave unchanged)*  |
+| Other                       | *(leave unchanged)*  |
+
+Only update status for alerts that went through full troubleshooting. Leave untroubleshot alerts unchanged.
+
+### Additional Monte Carlo actions
+
+- **Mark events as normal** — for alerts classified as natural variation, marking the underlying events as normal allows the detector to adapt thresholds to prevent further alerts on similar patterns. Only applies to monitors using automated (ML-based) thresholds — has no effect on static-threshold monitors.
+- **Declare an incident** (`update_alert` with `declared_incident_severity`) — promotes the alert to an incident, escalating visibility. Values: `SEV_1`–`SEV_4`. Use `NO_SEVERITY` to clear. Appropriate for verified ongoing incidents.
+- **Assign ownership** (`set_alert_owner`) — route a confirmed incident or required investigation to the right person.
+
+### External integrations
+
+- **Slack** — message a channel or individual with a triage summary or escalation
+- **Linear / Jira / Teams** — create a ticket for confirmed incidents
+
+Introduce these actions incrementally. Start with comments, validate, then enable status updates and additional actions.

package/bundled-skills/avoid-ai-writing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: avoid-ai-writing
-description: "Audit and rewrite content to remove 21 categories of AI writing patterns with a 43-entry replacement table"
+description: "Audit and rewrite prose for repetitive, vague, or formulaic wording while preserving meaning, evidence, and the writer's voice."
 risk: none
 source: https://github.com/conorbronsdon/avoid-ai-writing
 date_added: "2026-03-06"
@@ -8,7 +8,7 @@ date_added: "2026-03-06"
 
 # Avoid AI Writing — Audit & Rewrite
 
-Detects and fixes AI writing patterns ("AI-isms") that make text sound machine-generated. Covers 21 pattern categories with a 43-entry word/phrase replacement table that maps each flagged term to a specific, plainer alternative.
+Detects and fixes AI writing patterns ("AI-isms") that make text sound machine-generated. Covers 21 pattern categories with examples of plainer alternatives. The full upstream pattern catalog is not bundled in this AAS entrypoint; do not claim a complete 43-entry table is present.
 
 ## When to Use This Skill
 
@@ -37,6 +37,8 @@ Audit this for AI writing patterns:
 4. **Second-pass audit** — re-reads the rewrite to catch any surviving tells
 
 ## Limitations
+- These are editorial heuristics, not proof of AI authorship. Preserve factual claims, uncertainty, attributed quotations, code, identifiers, and the requested scope.
+- For audit-only requests, report findings without rewriting. Avoid replacing a precise technical term merely because it appears on a word list.
 
 - Does not detect AI-generated code, only prose
 - Pattern matching is guideline-based, not absolute — some flagged words are fine in context

package/bundled-skills/awareness-stage-mapper/SKILL.md

@@ -1,16 +1,22 @@
 ---
 name: awareness-stage-mapper
-description: "One sentence - what this skill does and when to invoke it"
+description: "Map audience awareness stages to messaging strategy when planning a campaign, offer, or persuasion sequence."
 risk: safe
 source: community
 date_added: "2026-04-04"
 ---
-You are a **Cognitive Psychologist specializing in persuasion and belief change**. Your task is to diagnose precisely where a customer sits on the awareness ladder and calibrate the psychological approach, language register, and persuasion strategy accordingly.
+Use a marketing planning and audience-research lens. Your task is to diagnose precisely where a customer sits on the awareness ladder and calibrate the psychological approach, language register, and persuasion strategy accordingly.
 
 ## When to Use
 - Use when you need to identify how aware an audience already is before writing messaging or offers.
 - Use when a campaign needs stage-specific language, sequencing, or persuasion strategy.
 
+## Evidence and scope
+
+Use observed audience research and verified product facts. Psychological interpretations and the author-year references below are inherited conceptual context, not validated evidence for this exact workflow or a guaranteed conversion effect. Before using a scientific claim externally, verify the actual publication, method and applicability; omit unsupported claims. This is marketing planning, not clinical diagnosis. Do not infer sensitive traits or exploit vulnerabilities.
+
+Original contribution: [PR 451](https://github.com/sickn33/agentic-awesome-skills/pull/451) by MMEHDI0606; [immutable source snapshot](https://github.com/MMEHDI0606/antigravity-awesome-skills/blob/9c61357e3e6bb167946036f52ac1e28fc82e04d0/skills/awareness-stage-mapper/SKILL.md). This identifies the contributed instructions, not scientific validation or a new upstream endorsement.
+
 ## CONTEXT GATHERING
 
 Before diagnosing awareness, establish:
@@ -31,23 +37,23 @@ Awareness determines whether the audience can process central arguments or will
 
 **Step 1 - Classify the awareness stage**
 Label the audience as unaware, problem aware, solution aware, product aware, or most aware.
-*Research basis: message processing differs sharply by prior knowledge and perceived relevance (ELM; Zhang et al., 2024).*
+*Planning hypothesis (verify before presenting as research): message processing differs sharply by prior knowledge and perceived relevance (ELM; Zhang et al., 2024).*
 
 **Step 2 - Assess motivation and ability**
-Decide whether the audience has enough motivation and cognitive capacity for detailed argument.
-*Research basis: the central route works when involvement and ability are high; otherwise peripheral cues dominate (Quick et al., 2018; SanJose-Cabezudo et al., 2009).*
+Use observable evidence of interest and familiarity: questions prospects actually asked, concepts they can explain, and the time/format available. If that evidence is absent, record motivation and familiarity as unknown and propose a simple message test. Do not infer intelligence or mental capacity from demographic labels.
+*Planning hypothesis (verify before presenting as research): the central route works when involvement and ability are high; otherwise peripheral cues dominate (Quick et al., 2018; SanJose-Cabezudo et al., 2009).*
 
 **Step 3 - Select the persuasion route**
 Choose educational framing for unaware/problem aware audiences and comparative proof for later-stage audiences.
-*Research basis: premature solution pitching can trigger reactance and weak processing (Lavoie & Quick, 2013; Grandpre et al., 2003).*
+*Planning hypothesis (verify before presenting as research): premature solution pitching can trigger reactance and weak processing (Lavoie & Quick, 2013; Grandpre et al., 2003).*
 
 **Step 4 - Calibrate language register**
 Match vocabulary depth, jargon, and specificity to the stage.
-*Research basis: familiarity and self-relevance shape attention and acceptance (Zhang et al., 2024; Moyer-Gusé et al., 2022).*
+*Planning hypothesis (verify before presenting as research): familiarity and self-relevance shape attention and acceptance (Zhang et al., 2024; Moyer-Gusé et al., 2022).*
 
 **Step 5 - Choose the entry point**
 Recommend the best first touchpoint for downstream content: education, proof, demo, comparison, or direct offer.
-*Research basis: stage-appropriate sequencing improves narrative transportation and belief change (Green & Brock, 2000; Chen & Bell, 2022).*
+*Planning hypothesis (verify before presenting as research): stage-appropriate sequencing improves narrative transportation and belief change (Green & Brock, 2000; Chen & Bell, 2022).*
 
 ## DECISION MATRIX
 
@@ -96,7 +102,7 @@ The line between persuasion and manipulation is using stage-appropriate language
 
 ## SKILL CHAINING
 
-Before invoking this skill, the agent should have completed:
+Optional context from related skills (equivalent supplied research is sufficient; do not create a prerequisite cycle):
 - [ ] `@customer-psychographic-profiler`
 - [ ] `@jobs-to-be-done-analyst`
 
@@ -122,6 +128,8 @@ Before finalizing output, the agent asks:
 
 > Identify how aware an audience already is before writing messaging or offers.
 
+**Illustrative output:** Given an interview where buyers name the problem but no solution, label problem-aware as a provisional inference; propose an explanatory message and list what evidence would change the classification.
+
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

package/bundled-skills/aws-cdk-development/SKILL.md

@@ -9,6 +9,13 @@ date_added: 2026-07-01
 license: MIT
 license_source: https://github.com/zxkane/aws-skills/blob/main/LICENSE
 ---
+## Bundled upstream support
+
+Supporting files are included at skill-relative paths. See [UPSTREAM-NOTICE.md](UPSTREAM-NOTICE.md) for their pinned sources, licenses, hashes, and import changes.
+
+## Restored helper safety
+
+`scripts/validate-stack.sh` runs `cdk synth` from the caller-selected project root, which executes that project's CDK application and dependencies, can write `cdk.out`, and may contact AWS context providers if the project requires lookups. Review the project and AWS context before invoking it. The helper does not deploy; deployment needs separate user authorization.
 
 # AWS CDK Development
 

package/bundled-skills/aws-cdk-development/UPSTREAM-LICENSE.txt

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Mengxin Zhu
+
+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/bundled-skills/aws-cdk-development/UPSTREAM-NOTICE.md

@@ -0,0 +1,14 @@
+# Upstream helpers for aws-cdk-development
+
+The files listed below were recovered from [zxkane/aws-skills](https://github.com/zxkane/aws-skills) at commit `68530c6f296ccd2f5e99c79782f3e0fbf962c51a`. The repository ID is `1080226559`.
+
+They retain the upstream **MIT** license reproduced in [UPSTREAM-LICENSE.txt](UPSTREAM-LICENSE.txt). This notice applies to the listed support files; it does not replace the license metadata of other catalog files. Preserve the upstream license and this attribution when redistributing them.
+
+License wording is unchanged; text-only trailing whitespace and EOF blank lines are normalized. Original license: https://github.com/zxkane/aws-skills/blob/68530c6f296ccd2f5e99c79782f3e0fbf962c51a/LICENSE
+
+| Local file | Original upstream path | Original Git blob SHA | Import changes |
+| --- | --- | --- | --- |
+| `references/cdk-patterns.md` | `plugins/aws-iac/skills/aws-cdk-development/references/cdk-patterns.md` | `7c533a80e548956cc50e69233bdc2d1617175c47` | text-only trailing whitespace and EOF blank lines normalized |
+| `scripts/validate-stack.sh` | `plugins/aws-iac/skills/aws-cdk-development/scripts/validate-stack.sh` | `54f9e0512b1b8a3e5aa54b3dd76e3bc56f0814c1` | stored without executable bit; invoke via its interpreter; AAS correctness and scope adaptation: resolves and synthesizes only the caller-selected CDK project root instead of the installed skill catalog |
+
+`scripts/validate-stack.sh` runs the project's `cdk synth` and executes CDK application code; synthesis can write `cdk.out`, execute project dependencies, and contact AWS context providers if the project requires lookups. It now uses the caller's current directory or `CDK_PROJECT_ROOT` as the project root. Review the project and AWS context first. It does not deploy; deployment requires separate user authorization.