diff --git a/PLUGINS/ClaudeCode/skills/asp-alert/SKILL.md b/PLUGINS/ClaudeCode/skills/asp-alert/SKILL.md new file mode 100644 index 0000000..689fb18 --- /dev/null +++ b/PLUGINS/ClaudeCode/skills/asp-alert/SKILL.md @@ -0,0 +1,122 @@ +--- +name: asp-alert +description: 'Manage ASP alerts. Use when users ask to review alerts, find alerts by status or severity, inspect alert discussions, update AI triage fields, append artifacts, or attach enrichments to alerts.' +argument-hint: 'review alert | list alerts [filters] | update alert | append artifact to alert ' +compatibility: connect to asp mcp server +metadata: + author: Funnywolf + version: 0.1.0 + mcp-server: asp + category: cyber security + tags: [ alert-management, soc, triage, investigation ] + documentation: https://asp.viperrtp.com/ +--- + +# ASP Alert + +Use this skill for alert-centric SOC work on ASP. + +## When to Use + +- The user gives an alert ID and wants a quick review or triage summary. +- The user wants to find alerts by status, severity, confidence, or correlation UID. +- The user wants analyst discussion context on an alert. +- The user wants to update AI triage fields on an alert. +- The user wants to append a new artifact to an alert. +- The user wants to attach enrichment to an alert after analysis. + +## Operating Rules + +- Do not ask the user to choose an operation if the request already implies one. +- Collect only missing required inputs. +- Prefer `list_alerts(alert_id=..., limit=1)` for single-alert retrieval because there is no separate `get_alert` tool on the current MCP surface. +- Keep the response focused on triage value rather than raw schema output. +- For updates, change only the fields the user explicitly requested. +- For append actions, confirm the target alert ID and the minimum required payload before writing. + +## Decision Flow + +1. If the user provides a specific alert ID or says "open", "show", "review", or "summarize" an alert, call `list_alerts(alert_id=, limit=1)`. +2. If the user asks for discussion context, call `get_alert_discussions(alert_id)` after retrieving the alert. +3. If the user asks to browse or compare alerts, call `list_alerts` with supported filters. +4. If the user asks to update AI severity, AI confidence, or AI comment, call `update_alert`. +5. If the user asks to add an IOC, host, user, URL, or hash to the alert, call `append_artifact`. +6. If the user asks to attach analysis results, intel, or structured context to the alert, call `append_enrichment(target_type=alert, target_id=, ...)`. + +## SOP + +### Review One Alert + +1. Call `list_alerts(alert_id=, limit=1)`. +2. If the result is empty, state that the alert was not found. +3. Parse the first JSON record. +4. If the user asked for analyst context, call `get_alert_discussions(alert_id)`. +5. Present only the most useful triage fields. + +Preferred response structure: + +- `Alert`: alert ID, title or name if present, severity, status, confidence, correlation UID. +- `Timeline`: created or updated times when present. +- `Key Context`: source, rule, category, owner, or similar high-signal fields. +- `Discussions`: only the most relevant analyst or system notes when needed. +- `Assessment`: short triage interpretation. + +### List Alerts + +1. Extract supported filters: `alert_id`, `status`, `severity`, `confidence`, `correlation_uid`, `limit`. +2. Normalize natural-language filter lists before calling MCP. +3. Call `list_alerts`. +4. Parse returned JSON strings. +5. Present a compact comparison view. + +Preferred response structure: + +| Alert ID | Severity | Status | Confidence | Correlation UID | Summary | +|----------|----------|--------|------------|-----------------|---------| + +Then add one short interpretation line when useful. + +### Update Alert AI Fields + +1. Require `alert_id`. +2. Extract only supported AI fields: `severity_ai`, `confidence_ai`, `comment_ai`. +3. Call `update_alert` with only changed fields. +4. If the result is `None`, state that the alert was not found. +5. Confirm only the changed fields. + +### Append Artifact To Alert + +1. Require `alert_id`. +2. Collect the smallest useful artifact payload first: usually `value`, and when possible `type` or `role`. +3. Call `append_artifact`. +4. Confirm that a new artifact was created and attached. +5. If the artifact is likely to need context, suggest attaching enrichment next. + +### Append Enrichment To Alert + +1. Require `alert_id`. +2. Convert the user's analysis into a compact structured enrichment payload. +3. Call `append_enrichment(target_type=alert, target_id=, ...)`. +4. Confirm the created enrichment record. + +## Clarification Rules + +- Ask for `alert_id` only when missing for alert-specific actions. +- Ask for enum clarification only when the requested value does not map cleanly to ASP values. +- If the user asks to "lower confidence", "raise severity", or "leave a note", map directly to the matching AI fields when intent is clear. +- If the user asks to add an artifact but the value is missing, ask for the artifact value before writing. + +## Output Rules + +- Be concise. +- Do not dump raw JSON unless the user explicitly asks for it. +- Prefer triage wording over schema wording. +- Merge alert data and discussion context into one coherent view when both are used. +- Surface blockers clearly: alert not found, unsupported filter, invalid enum value, or incomplete append payload. + +## Failure Handling + +- If the alert is missing, say so directly. +- If filters return no results, state that and suggest the most useful refinement. +- If the requested update field is unsupported, say which alert fields are actually writable. +- If enrichment or artifact input is incomplete, ask one focused follow-up instead of guessing. \ No newline at end of file diff --git a/PLUGINS/ClaudeCode/skills/asp-case/SKILL.md b/PLUGINS/ClaudeCode/skills/asp-case/SKILL.md index ab4bb58..137a98d 100644 --- a/PLUGINS/ClaudeCode/skills/asp-case/SKILL.md +++ b/PLUGINS/ClaudeCode/skills/asp-case/SKILL.md @@ -1,11 +1,11 @@ --- name: asp-case -description: 'Manage ASP security cases. Use when users ask to get a case, review a case, list cases, find cases by status or severity, or update case status, verdict, severity, or AI analysis fields.' -argument-hint: 'get case | list cases [filters] | update case ' +description: 'Manage ASP security cases. Use when users ask to review a case, list cases, inspect case discussions, check related alerts or playbook runs for a case, or update case workflow and AI analysis fields.' +argument-hint: 'review case | list cases [filters] | update case | run playbook for case ' compatibility: connect to asp mcp server metadata: author: Funnywolf - version: 0.2.0 + version: 0.3.0 mcp-server: asp category: cyber security tags: [ case-management, soc, triage, investigation ] @@ -18,52 +18,64 @@ Use this skill for case-centric SOC work on ASP. ## When to Use -- The user gives a case ID and wants details, triage context, or a quick summary. -- The user wants to find cases by status, severity, or confidence. +- The user gives a case ID and wants a review, triage context, or quick summary. +- The user wants to find cases by status, severity, confidence, verdict, correlation UID, title, or tags. +- The user wants case discussion context. +- The user wants to check related alerts or playbook runs from a case view. - The user wants to update case workflow fields or AI analysis fields. -- The user wants help deciding what case to inspect next. +- The user wants to run a playbook against a case. ## Operating Rules - Do not start by asking which operation they want if the request already implies it. - Collect only missing required inputs. -- Prefer one MCP call when the user request is specific enough. +- Prefer one MCP call when the user request is specific enough, but use a short multi-step flow when the user asks for a real case review. - Do not repeat MCP field descriptions back to the user unless needed to clarify an enum or missing input. - Summarize case data for actionability, not as raw schema output. - If an update request is ambiguous, ask a targeted clarification before writing. - After updates, confirm only the fields that were changed. +- For single-case retrieval, use `list_cases(case_id=...)` because the current MCP surface does not expose a separate `get_case` tool. +- Keep case as the primary user view. Pull alerts, discussions, or playbook runs only when they help answer the case question. ## Decision Flow -1. If the user provides a specific case ID or says "open", "show", "review", or "summarize" a case, use `get_case`. -2. If the user asks to find, browse, or compare cases, use `list_cases`. -3. If the user asks to change status, verdict, severity, or AI fields, use `update_case`. -4. If the user asks to update a case but does not provide a case ID, ask for it. -5. If the user gives multiple possible filters, apply the ones ASP supports directly and mention any unsupported filters explicitly. +1. If the user provides a specific case ID or says "open", "show", "review", or "summarize" a case, call `list_cases` with `case_id` and `limit=1`. +2. If the user wants discussion history or analyst context, call `get_case_discussions` after retrieving the case. +3. If the user wants related alert context, use the case's `correlation_uid` and call `list_alerts`. +4. If the user wants case automation status, call `list_playbook_runs(source_id=case_id, type=[CASE])`. +5. If the user wants to run automation on the case, use `list_available_playbook_definitions` only when the playbook name is missing, then call `execute_playbook(type=CASE, record_id=case_id, name=...)`. +6. If the user asks to find, browse, or compare cases, use `list_cases`. +7. If the user asks to change status, verdict, severity, or AI fields, use `update_case`. +8. If the user asks to update a case but does not provide a case ID, ask for it. +9. If the user gives multiple possible filters, apply the ones ASP supports directly and mention any unsupported filters explicitly. ## SOP ### Review One Case -1. Call `get_case` with the case ID. -2. If the result is `None`, state that the case was not found. -3. Parse the JSON. -4. Present only the most useful sections for the request. -5. Highlight missing or suspicious fields only if they matter to the user's goal. +1. Call `list_cases(case_id=, limit=1)`. +2. If the result is empty, state that the case was not found. +3. Parse the first JSON record. +4. If the user asks for analyst context, call `get_case_discussions(case_id)`. +5. If the case contains a useful `correlation_uid` and the user needs alert context, call `list_alerts(correlation_uid=...)`. +6. If the user asks whether automation has run or is pending, call `list_playbook_runs(source_id=case_id, type=[CASE])`. +7. Present only the most useful sections for the request. +8. Highlight missing or suspicious fields only if they matter to the user's goal. Preferred response structure: - `Case`: case ID, title, severity, status, verdict, confidence, priority, category. - `Timeline`: created, acknowledged, closed, calculated start/end if present. - `Key Alerts`: only the most relevant alerts, not every alert by default. -- `Key Artifacts`: only high-signal artifacts such as IP, user, host, hash, URL. +- `Discussions`: only the key analyst or system discussion points when relevant. +- `Playbook Runs`: only current or recent runs when relevant. - `Analyst / AI Notes`: comment, summary, AI fields when relevant. Use concise incident-review language. Prefer a short analytical summary before structured details when the user asks for "what happened" or "help me understand this case". ### List Cases -1. Extract supported filters: `status`, `severity`, `confidence`, `limit`. +1. Extract supported filters: `case_id`, `status`, `severity`, `confidence`, `verdict`, `correlation_uid`, `title`, `tags`, `limit`. 2. If the user gives comma-separated or natural-language lists, normalize them before calling MCP. 3. Call `list_cases`. 4. Parse the returned JSON strings. @@ -81,6 +93,22 @@ Then add one short line of interpretation when useful, for example: - "High-severity cases are concentrated in one category." - "No matching cases were found." +### Run A Case Playbook + +1. Require `case_id`. +2. If the user has not named a playbook definition, call `list_available_playbook_definitions` and suggest the most relevant options instead of guessing. +3. Call `execute_playbook(type=CASE, record_id=case_id, name=, user_input=)`. +4. Confirm that a pending playbook run record was created. +5. If the user wants follow-up status, call `list_playbook_runs(source_id=case_id, type=[CASE])`. + +Preferred response structure: + +- `Case`: case ID +- `Playbook`: definition name +- `Run status`: usually pending at creation time +- `User input`: only if provided +- `Next useful step`: optional, usually to query case-related runs + ### Update a Case 1. Require `case_id`. @@ -113,6 +141,7 @@ Preferred response structure: - Ask for `case_id` only when missing. - Ask for enum clarification only when the requested value does not map cleanly to ASP values. - If the user asks for "close", "resolve", or "mark suspicious", you may map directly to the corresponding status or verdict when the intent is unambiguous. +- If the user asks for case automation but does not provide a playbook definition name, show available definitions instead of inventing one. - If the user asks for a broad review like "show recent important cases", start with `list_cases` instead of forcing them to choose an operation. ## Output Rules @@ -121,10 +150,12 @@ Preferred response structure: - Do not dump raw JSON unless the user explicitly asks for it. - Prefer analyst-facing wording over schema wording. - Keep tables small; when many rows match, show the best subset and state the total count. +- When using multiple MCP calls for one review, merge the result into one coherent case narrative instead of showing call-by-call output. - Surface blockers clearly: case not found, unsupported filter, invalid enum value. ## Failure Handling - If the case is missing, say so directly. - If filters return no results, state that and suggest the most likely useful refinement. +- If the playbook definition name does not match available definitions, say that directly and offer the closest available options. - If an update target is unclear, ask one focused question instead of guessing. diff --git a/PLUGINS/ClaudeCode/skills/asp-knowledge/SKILL.md b/PLUGINS/ClaudeCode/skills/asp-knowledge/SKILL.md new file mode 100644 index 0000000..b52d3c6 --- /dev/null +++ b/PLUGINS/ClaudeCode/skills/asp-knowledge/SKILL.md @@ -0,0 +1,91 @@ +--- +name: asp-knowledge +description: 'Manage ASP knowledge records. Use when users ask to find internal knowledge, search by title, body, tags, action, or source, or update knowledge content, usage state, lifecycle action, or tags.' +argument-hint: 'search knowledge [filters] | update knowledge ' +compatibility: connect to asp mcp server +metadata: + author: Funnywolf + version: 0.1.0 + mcp-server: asp + category: cyber security + tags: [ knowledge, memory, rag, investigation ] + documentation: https://asp.viperrtp.com/ +--- + +# ASP Knowledge + +Use this skill for internal knowledge retrieval and maintenance on ASP. + +## When to Use + +- The user wants to find existing internal knowledge by title, body, tags, action, source, or usage state. +- The user wants to review whether a knowledge item should remain active or be removed. +- The user wants to update the content, tags, or lifecycle state of a knowledge record. +- The user wants to inspect reusable analyst knowledge before deciding the next case, alert, or hunt action. + +## Operating Rules + +- Treat this as knowledge retrieval and curation, not general free-form chat memory. +- Prefer the narrowest useful search filters first. +- Use fuzzy title or body matching when the user gives phrases, symptoms, or partial wording. +- Use tags when the user is operating by scenario, technique, or topic. +- For updates, modify only the fields the user explicitly wants changed. +- If the user needs semantic search rather than field-based filtering, say that the current MCP surface is still filter-oriented. + +## Decision Flow + +1. If the user wants to find or browse knowledge, call `list_knowledge` with the narrowest useful filters. +2. If the user asks to revise content, status, source, action, or tags for a known record, call `update_knowledge`. +3. If the user asks whether some knowledge already exists but gives only partial wording, start with fuzzy `title` and `body` filters. +4. If the user asks to manage lifecycle or storage state, use `action` and `using` rather than inventing a separate workflow. + +## SOP + +### Search Knowledge + +1. Extract supported filters: `action`, `source`, `using`, `title`, `body`, `tags`, `limit`. +2. Use fuzzy title or body filters when the user gives partial text. +3. Use tags when the user is really asking for a topic or scenario bucket. +4. Call `list_knowledge`. +5. Parse returned JSON strings. +6. Present a small, useful shortlist instead of every field. + +Preferred response structure: + +| Knowledge ID | Title | Source | Action | Using | Tags | +|--------------|-------|--------|--------|-------|------| + +Then add one short interpretation line when useful. + +### Update Knowledge + +1. Require `knowledge_id`. +2. Extract only fields the user explicitly wants to change: `title`, `body`, `using`, `action`, `source`, `tags`. +3. Call `update_knowledge` with only changed fields. +4. If the result is `None`, state that the knowledge record was not found. +5. Confirm only the changed fields. + +Preferred response structure: + +- `Updated knowledge`: knowledge ID or returned row ID +- `Changed fields`: only the fields sent in the request +- `Next useful step`: optional, usually to query similar knowledge or verify the updated record through a narrowed search + +## Clarification Rules + +- Ask for `knowledge_id` only when the user wants to update a specific record and did not provide it. +- Ask for lifecycle clarification only when the requested state does not map cleanly to `action` or `using`. +- If the user asks to "disable", "archive", or "stop using" a knowledge record, prefer clarifying whether they mean `using=false`, a lifecycle `action`, or both. + +## Output Rules + +- Be concise. +- Do not dump full knowledge bodies unless the user explicitly asks. +- Prefer reusable analyst wording over raw storage wording. +- When many records match, show the best subset and explain the pattern briefly. + +## Failure Handling + +- If no knowledge records match, say that directly and suggest the most likely useful refinement. +- If the record to update is missing, say so directly. +- If the requested lifecycle change is ambiguous, ask one focused question instead of guessing. \ No newline at end of file diff --git a/PLUGINS/ClaudeCode/skills/asp-playbook/SKILL.md b/PLUGINS/ClaudeCode/skills/asp-playbook/SKILL.md new file mode 100644 index 0000000..ecd7a4f --- /dev/null +++ b/PLUGINS/ClaudeCode/skills/asp-playbook/SKILL.md @@ -0,0 +1,107 @@ +--- +name: asp-playbook +description: 'Operate ASP playbook definitions and playbook run records. Use when users ask which playbooks can run, want to execute a playbook on a case, alert, or artifact, or want to inspect existing playbook runs.' +argument-hint: 'list playbook definitions | run playbook for | list playbook runs [filters]' +compatibility: connect to asp mcp server +metadata: + author: Funnywolf + version: 0.1.0 + mcp-server: asp + category: cyber security + tags: [ playbook, automation, soar, investigation ] + documentation: https://asp.viperrtp.com/ +--- + +# ASP Playbook + +Use this skill for playbook automation work on ASP. + +## When to Use + +- The user wants to know which playbook definitions are currently available to run. +- The user wants to execute a playbook against a case, alert, or artifact. +- The user wants to inspect playbook run records by target object, type, or job status. +- The user wants to check whether automation has already run for a target object. + +## Operating Rules + +- Keep playbook definitions and playbook run records strictly separated in language and workflow. +- Use `list_available_playbook_definitions` only for runnable definitions. +- Use `list_playbook_runs` only for run records. +- Use `execute_playbook` only when the user has named a runnable definition and identified the target object. +- Do not invent a playbook definition name. If missing, list or suggest from available definitions first. +- Treat `user_input` as optional, per-run natural-language guidance for the selected playbook, not as a generic chat prompt. + +## Decision Flow + +1. If the user asks what can run, call `list_available_playbook_definitions`. +2. If the user asks whether automation has run for a case, alert, or artifact, call `list_playbook_runs(source_id=, type=[])`. +3. If the user asks to run automation and already provides definition name plus target object, call `execute_playbook`. +4. If the user asks to run automation but does not know the playbook definition name, call `list_available_playbook_definitions` first. +5. If the user asks for general automation history, call `list_playbook_runs` with the narrowest useful filters. + +## SOP + +### List Runnable Playbook Definitions + +1. Call `list_available_playbook_definitions`. +2. Parse the returned JSON. +3. Present only the most relevant definitions for the user's target object or goal. +4. Make it explicit that these are definitions, not run records. + +Preferred response structure: + +| Definition Name | Likely Target | Purpose | +|-----------------|---------------|---------| + +### Run A Playbook + +1. Require `target_type`, `target_id`, and playbook definition `name`. +2. If the definition name is missing or uncertain, call `list_available_playbook_definitions` first. +3. Pass `user_input` only when the user wants extra guidance for that run. +4. Call `execute_playbook(type=, record_id=, name=, user_input=)`. +5. Confirm that a pending playbook run record was created. + +Preferred response structure: + +- `Target`: type and ID +- `Playbook Definition`: selected name +- `Run Status`: pending at creation time unless the platform reports otherwise +- `User Input`: only if provided +- `Next Useful Step`: usually to query related playbook runs + +### Review Playbook Runs + +1. Extract supported filters: `playbook_id`, `job_status`, `type`, `source_id`, `limit`. +2. Use `source_id` when the user is asking from the perspective of one case, alert, or artifact. +3. Call `list_playbook_runs`. +4. Parse the returned JSON strings. +5. Present a short run-oriented view. + +Preferred response structure: + +| Run ID | Type | Target ID | Job Status | Definition Name | Updated | +|--------|------|-----------|------------|-----------------|---------| + +Then add one short interpretation line when useful. + +## Clarification Rules + +- Ask for `target_type` and `target_id` only when missing for run requests. +- Ask for the playbook definition name only when missing or ambiguous. +- If the user names something that sounds like a run ID instead of a definition, clarify before executing. +- If the user asks to "check the run" without a run ID, prefer `list_playbook_runs` with object context instead of guessing a specific run. + +## Output Rules + +- Be concise. +- Do not blur the words definition, run, record, and target object. +- Do not dump all playbook definitions if only a shortlist is relevant. +- Prefer operational wording: what can run, what ran, what is pending, what should be checked next. + +## Failure Handling + +- If no matching playbook definitions exist, say that directly and suggest the closest relevant options. +- If no run records exist for the target, say that directly. +- If execution prerequisites are missing, ask one focused clarification instead of guessing. +- If the user asks for something only run records can answer, do not answer from definitions alone. \ No newline at end of file diff --git a/PLUGINS/ClaudeCode/skills/asp-siem/SKILL.md b/PLUGINS/ClaudeCode/skills/asp-siem/SKILL.md index df6d2d2..3b2d9c5 100644 --- a/PLUGINS/ClaudeCode/skills/asp-siem/SKILL.md +++ b/PLUGINS/ClaudeCode/skills/asp-siem/SKILL.md @@ -1,11 +1,11 @@ --- name: asp-siem -description: 'Investigate ASP SIEM data with keyword search. Use when users ask to search logs, pivot on IOC values, check activity in a time range, hunt related events, or refine SIEM evidence across ELK or Splunk.' -argument-hint: 'search from to [index_name] [time_field]' +description: 'Investigate ASP SIEM data with schema exploration, keyword search, and adaptive field queries. Use when users ask to find the right index, inspect available fields, search logs by IOC, or run structured hunts with exact filters and aggregations.' +argument-hint: 'explore schema [index] | search from to | adaptive query