mirror of
https://github.com/FunnyWolf/agentic-soc-platform.git
synced 2026-08-22 13:12:56 +02:00
update skills
This commit is contained in:
rootkit
@@ -40,8 +40,8 @@ Use this skill for alert-centric SOC work on ASP.
|
||||
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=<alert_id>, ...)`.
|
||||
5. If the user asks to add an IOC, host, user, URL, or hash to the alert, first call `create_artifact`, then call `attach_artifact_to_alert(alert_id=<alert_id>, artifact_rowid=<created_rowid>)`.
|
||||
6. If the user asks to attach analysis results, intel, or structured context to the alert, first call `create_enrichment`, then call `attach_enrichment_to_target(target_type=alert, target_id=<alert_id>, enrichment_rowid=<created_rowid>)`.
|
||||
|
||||
## SOP
|
||||
|
||||
@@ -87,17 +87,19 @@ Then add one short interpretation line when useful.
|
||||
### 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.
|
||||
2. Collect the smallest useful artifact payload first: usually `value`, and when possible `name`, `type`, or `role`.
|
||||
3. Call `create_artifact` and keep the returned artifact row ID.
|
||||
4. Call `attach_artifact_to_alert(alert_id=<alert_id>, artifact_rowid=<created_rowid>)`.
|
||||
5. Confirm that a new artifact was created and attached.
|
||||
6. If the artifact is likely to need context, suggest creating enrichment for the artifact or the alert 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=<alert_id>, ...)`.
|
||||
4. Confirm the created enrichment record.
|
||||
3. Call `create_enrichment` and keep the returned enrichment row ID.
|
||||
4. Call `attach_enrichment_to_target(target_type=alert, target_id=<alert_id>, enrichment_rowid=<created_rowid>)`.
|
||||
5. Confirm that the enrichment was created and attached.
|
||||
|
||||
## Clarification Rules
|
||||
|
||||
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
name: asp-artifact
|
||||
description: 'Manage ASP artifacts. Use when users ask to find artifacts, create a new artifact, attach an artifact to an alert, review artifact-centered pivots, or attach enrichment to an artifact.'
|
||||
argument-hint: 'review artifact <artifact_id> | list artifacts [filters] | create artifact <value> | attach artifact to alert <alert_id> | enrich artifact <artifact_id>'
|
||||
compatibility: connect to asp mcp server
|
||||
metadata:
|
||||
author: Funnywolf
|
||||
version: 0.1.0
|
||||
mcp-server: asp
|
||||
category: cyber security
|
||||
tags: [ artifact, pivot, enrichment, investigation ]
|
||||
documentation: https://asp.viperrtp.com/
|
||||
---
|
||||
|
||||
# ASP Artifact
|
||||
|
||||
Use this skill for artifact-centric investigation work on ASP.
|
||||
|
||||
## When to Use
|
||||
|
||||
- The user wants to find artifacts by value, type, role, owner, or reputation.
|
||||
- The user wants to create a new artifact record.
|
||||
- The user wants to attach an existing or newly created artifact to an alert.
|
||||
- The user wants to pivot investigation from an artifact value into other systems or follow-up workflows.
|
||||
- The user wants to attach enrichment or structured analysis to an artifact.
|
||||
|
||||
## Operating Rules
|
||||
|
||||
- Treat artifacts as the smallest pivot objects in the platform.
|
||||
- Do not ask the user to choose an operation if the request already implies one.
|
||||
- Collect only missing required inputs.
|
||||
- Use `list_artifacts` for lookup and review.
|
||||
- Use `create_artifact` when the user wants to add a new artifact record.
|
||||
- Use `attach_artifact_to_alert` only after you already have an artifact row ID.
|
||||
- Use `create_enrichment` plus `attach_enrichment_to_target` when the user wants to save analysis on the artifact itself.
|
||||
- Keep artifact responses short and investigation-oriented.
|
||||
|
||||
## Decision Flow
|
||||
|
||||
1. If the user asks to find or review artifacts, call `list_artifacts`.
|
||||
2. If the user asks to create a new artifact, call `create_artifact`.
|
||||
3. If the user asks to add an artifact to an alert, first call `create_artifact` when needed, then call `attach_artifact_to_alert`.
|
||||
4. If the user asks to attach intel, analyst notes, or structured analysis to an artifact, first call `create_enrichment`, then call `attach_enrichment_to_target(target_type=artifact, target_id=<artifact_id>, enrichment_rowid=<created_rowid>)`.
|
||||
5. If the user is investigating from an artifact, use the artifact as a pivot and suggest the next useful hop only when needed.
|
||||
|
||||
## SOP
|
||||
|
||||
### List Artifacts
|
||||
|
||||
1. Extract the narrowest useful filters from the request.
|
||||
2. Call `list_artifacts`.
|
||||
3. Parse the returned JSON strings.
|
||||
4. Present a compact artifact-oriented view.
|
||||
|
||||
Preferred response structure:
|
||||
|
||||
| Artifact ID | Value | Type | Role | Owner | Reputation | Summary |
|
||||
|-------------|-------|------|------|-------|------------|---------|
|
||||
|
||||
Then add one short interpretation line when useful.
|
||||
|
||||
### Create Artifact
|
||||
|
||||
1. Collect the minimum useful artifact information.
|
||||
2. Call `create_artifact`.
|
||||
3. Confirm the created artifact row ID.
|
||||
4. If the artifact should belong to an alert, suggest attaching it next.
|
||||
|
||||
Preferred response structure:
|
||||
|
||||
- `Artifact`: created artifact row ID
|
||||
- `Value`: the main artifact value when useful
|
||||
- `Next useful step`: optional, usually attach it to an alert or enrich it
|
||||
|
||||
### Attach Artifact To Alert
|
||||
|
||||
1. Require `alert_id`.
|
||||
2. If the user does not already have an artifact row ID, call `create_artifact` first.
|
||||
3. Call `attach_artifact_to_alert(alert_id=<alert_id>, artifact_rowid=<artifact_rowid>)`.
|
||||
4. Confirm that the artifact is attached.
|
||||
|
||||
### Enrich Artifact
|
||||
|
||||
1. Require `artifact_id`.
|
||||
2. Convert the user's analysis into a compact enrichment payload.
|
||||
3. Call `create_enrichment` and keep the returned enrichment row ID.
|
||||
4. Call `attach_enrichment_to_target(target_type=artifact, target_id=<artifact_id>, enrichment_rowid=<created_rowid>)`.
|
||||
5. Confirm that the enrichment was created and attached.
|
||||
|
||||
Preferred response structure:
|
||||
|
||||
- `Artifact`: artifact ID
|
||||
- `Enrichment`: created enrichment row ID
|
||||
- `Attachment`: attached to artifact
|
||||
- `Next useful step`: optional, usually to pivot into SIEM or review the parent alert
|
||||
|
||||
## Clarification Rules
|
||||
|
||||
- Ask for `alert_id` only when the user wants alert attachment and did not provide it.
|
||||
- Ask for `artifact_id` only when the user wants to enrich an existing artifact and did not provide it.
|
||||
- If the user wants to add an artifact but does not clearly want it attached anywhere, create it without assuming a parent object.
|
||||
- If the user asks for a pivot but not a specific tool path, start from artifact review and then suggest the next hop.
|
||||
|
||||
## Output Rules
|
||||
|
||||
- Be concise.
|
||||
- Do not dump raw JSON unless the user explicitly asks for it.
|
||||
- Prefer pivot-oriented language over storage wording.
|
||||
- When many artifacts match, show the best subset and state the pattern briefly.
|
||||
|
||||
## Failure Handling
|
||||
|
||||
- If no artifacts match, say that directly and suggest the most useful refinement.
|
||||
- If the target alert is missing, say that directly.
|
||||
- If the target artifact is missing, say that directly.
|
||||
- If the enrichment request is incomplete, ask one focused follow-up instead of guessing.
|
||||
@@ -23,6 +23,8 @@ Use this skill for case-centric SOC work on ASP.
|
||||
- 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 to attach enrichment or structured analysis to a case.
|
||||
- The user wants to attach an external ticket record to a case.
|
||||
- The user wants to run a playbook against a case.
|
||||
|
||||
## Operating Rules
|
||||
@@ -44,10 +46,12 @@ Use this skill for case-centric SOC work on ASP.
|
||||
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.
|
||||
6. If the user asks to attach enrichment or structured analysis to the case, first call `create_enrichment`, then call `attach_enrichment_to_target(target_type=case, target_id=<case_id>, enrichment_rowid=<created_rowid>)`.
|
||||
7. If the user asks to attach an external ticket to the case, first call `create_ticket`, then call `attach_ticket_to_case(case_id=<case_id>, ticket_rowid=<created_rowid>)`.
|
||||
8. If the user asks to find, browse, or compare cases, use `list_cases`.
|
||||
9. If the user asks to change status, verdict, severity, or AI fields, use `update_case`.
|
||||
10. If the user asks to update a case but does not provide a case ID, ask for it.
|
||||
11. If the user gives multiple possible filters, apply the ones ASP supports directly and mention any unsupported filters explicitly.
|
||||
|
||||
## SOP
|
||||
|
||||
@@ -109,6 +113,36 @@ Preferred response structure:
|
||||
- `User input`: only if provided
|
||||
- `Next useful step`: optional, usually to query case-related runs
|
||||
|
||||
### Attach Enrichment To Case
|
||||
|
||||
1. Require `case_id`.
|
||||
2. Convert the user's analysis into a compact structured enrichment payload.
|
||||
3. Call `create_enrichment` and keep the returned enrichment row ID.
|
||||
4. Call `attach_enrichment_to_target(target_type=case, target_id=<case_id>, enrichment_rowid=<created_rowid>)`.
|
||||
5. Confirm that the enrichment was created and attached to the case.
|
||||
|
||||
Preferred response structure:
|
||||
|
||||
- `Case`: case ID
|
||||
- `Enrichment`: created enrichment row ID
|
||||
- `Attachment`: attached to case
|
||||
- `Next useful step`: optional, usually to review the case again or continue the investigation from the enriched summary
|
||||
|
||||
### Attach Ticket To Case
|
||||
|
||||
1. Require `case_id`.
|
||||
2. Collect the external ticket details the user wants to sync.
|
||||
3. Call `create_ticket` and keep the returned ticket row ID.
|
||||
4. Call `attach_ticket_to_case(case_id=<case_id>, ticket_rowid=<created_rowid>)`.
|
||||
5. Confirm that the ticket was created and attached to the case.
|
||||
|
||||
Preferred response structure:
|
||||
|
||||
- `Case`: case ID
|
||||
- `Ticket`: created ticket row ID or external ticket identifier when useful
|
||||
- `Attachment`: attached to case
|
||||
- `Next useful step`: optional, usually to review the case again or update the synced ticket later
|
||||
|
||||
### Update a Case
|
||||
|
||||
1. Require `case_id`.
|
||||
|
||||
@@ -33,17 +33,19 @@ Use this skill for SIEM investigation on ASP. This skill should guide search str
|
||||
- Use `siem_explore_schema` when the user does not know the right index or fields.
|
||||
- Use `siem_keyword_search` when the user has one or more strong keywords and needs matching events.
|
||||
- Use `siem_adaptive_query` when the user already knows the target index and wants exact field filters or statistics.
|
||||
- If the user gives a relative time window, call `get_current_time` first and convert it into a workable UTC range.
|
||||
- Optimize for useful evidence, not maximum raw output.
|
||||
|
||||
## Decision Flow
|
||||
|
||||
1. If the user asks which index to use, which fields exist, or how the SIEM source is structured, use `siem_explore_schema`.
|
||||
2. If the user already provides keyword and time range, use `siem_keyword_search` immediately.
|
||||
3. If the user gives only an IOC or keyword, ask for the narrowest workable UTC time range.
|
||||
4. If the user wants exact field filters, grouped statistics, or controlled aggregations, use `siem_adaptive_query`.
|
||||
5. If the user knows the data source, pass `index_name`; otherwise search broadly first or explore schema.
|
||||
6. If the source likely uses a non-default time field, ask for it; otherwise use `@timestamp`.
|
||||
7. After each search, decide whether to stop, narrow, or expand based on hit volume, result quality, and user goal.
|
||||
3. If the user gives a relative time window, call `get_current_time`, derive a workable UTC range, then continue.
|
||||
4. If the user gives only an IOC or keyword, ask for the narrowest workable UTC time range.
|
||||
5. If the user wants exact field filters, grouped statistics, or controlled aggregations, use `siem_adaptive_query`.
|
||||
6. If the user knows the data source, pass `index_name`; otherwise search broadly first or explore schema.
|
||||
7. If the source likely uses a non-default time field, ask for it; otherwise use `@timestamp`.
|
||||
8. After each search, decide whether to stop, narrow, expand, or write the useful result back as enrichment.
|
||||
|
||||
## SOP
|
||||
|
||||
@@ -135,6 +137,7 @@ Preferred response structure:
|
||||
- Remove one restrictive keyword
|
||||
- Search a specific index
|
||||
- Switch to adaptive query with exact filters
|
||||
- Save the useful SIEM result as enrichment on the relevant case, alert, or artifact
|
||||
- Stop because evidence is already sufficient
|
||||
|
||||
## Clarification Rules
|
||||
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
name: asp-ticket
|
||||
description: 'Manage ASP ticket sync records. Use when users ask to create synced tickets, attach tickets to cases, list tickets, or update synced ticket fields.'
|
||||
argument-hint: 'list tickets [filters] | create ticket <uid> | attach ticket to case <case_id> | update ticket <ticket_id> <fields>'
|
||||
compatibility: connect to asp mcp server
|
||||
metadata:
|
||||
author: Funnywolf
|
||||
version: 0.1.0
|
||||
mcp-server: asp
|
||||
category: cyber security
|
||||
tags: [ ticket, case, sync, workflow ]
|
||||
documentation: https://asp.viperrtp.com/
|
||||
---
|
||||
|
||||
# ASP Ticket
|
||||
|
||||
Use this skill for external ticket sync work on ASP.
|
||||
|
||||
## When to Use
|
||||
|
||||
- The user wants to create a synced external ticket record.
|
||||
- The user wants to attach a ticket to a case.
|
||||
- The user wants to list tickets by status, type, or external UID.
|
||||
- The user wants to update synced ticket fields.
|
||||
|
||||
## Operating Rules
|
||||
|
||||
- Treat tickets as synced external workflow records, not as the platform's main investigation object.
|
||||
- Do not ask the user to choose an operation if the request already implies one.
|
||||
- Collect only missing required inputs.
|
||||
- Use `create_ticket` to create the synced ticket record.
|
||||
- Use `attach_ticket_to_case` to link an existing ticket record to a case.
|
||||
- Use `list_tickets` for browsing and lookup.
|
||||
- Use `update_ticket` only for fields the user explicitly wants changed.
|
||||
|
||||
## Decision Flow
|
||||
|
||||
1. If the user wants to create a synced ticket record, call `create_ticket`.
|
||||
2. If the user wants to attach a ticket to a case, first create the ticket when needed, then call `attach_ticket_to_case`.
|
||||
3. If the user wants to browse or compare synced tickets, call `list_tickets`.
|
||||
4. If the user wants to revise synced ticket fields, call `update_ticket`.
|
||||
|
||||
## SOP
|
||||
|
||||
### List Tickets
|
||||
|
||||
1. Extract the narrowest useful filters from the request.
|
||||
2. Call `list_tickets`.
|
||||
3. Parse the returned JSON strings.
|
||||
4. Present a compact workflow-oriented view.
|
||||
|
||||
Preferred response structure:
|
||||
|
||||
| Ticket ID | External UID | Type | Status | Title | Summary |
|
||||
|-----------|--------------|------|--------|-------|---------|
|
||||
|
||||
Then add one short interpretation line when useful.
|
||||
|
||||
### Create Ticket
|
||||
|
||||
1. Collect the external ticket details the user wants to sync.
|
||||
2. Call `create_ticket`.
|
||||
3. Confirm the created ticket row ID.
|
||||
4. If the ticket should be linked to a case, suggest attaching it next.
|
||||
|
||||
### Attach Ticket To Case
|
||||
|
||||
1. Require `case_id`.
|
||||
2. If the user does not already have a ticket row ID, call `create_ticket` first.
|
||||
3. Call `attach_ticket_to_case(case_id=<case_id>, ticket_rowid=<ticket_rowid>)`.
|
||||
4. Confirm that the ticket is attached.
|
||||
|
||||
### Update Ticket
|
||||
|
||||
1. Require `ticket_id`.
|
||||
2. Extract only the fields the user explicitly wants to change.
|
||||
3. Call `update_ticket` with only changed fields.
|
||||
4. If the result is `None`, state that the ticket was not found.
|
||||
5. Confirm only the changed fields.
|
||||
|
||||
Preferred response structure:
|
||||
|
||||
- `Updated ticket`: ticket ID or returned row ID
|
||||
- `Changed fields`: only the fields sent in the request
|
||||
- `Next useful step`: optional, usually to attach it to a case or review the refreshed ticket
|
||||
|
||||
## Clarification Rules
|
||||
|
||||
- Ask for `case_id` only when the user wants case attachment and did not provide it.
|
||||
- Ask for `ticket_id` only when the user wants to update a specific synced ticket and did not provide it.
|
||||
- If the user wants to create a ticket and attach it in one request, do both steps without forcing them to separate the workflow.
|
||||
|
||||
## Output Rules
|
||||
|
||||
- Be concise.
|
||||
- Do not dump raw JSON unless the user explicitly asks for it.
|
||||
- Prefer workflow wording over storage wording.
|
||||
- When many tickets match, show the best subset and explain the pattern briefly.
|
||||
|
||||
## Failure Handling
|
||||
|
||||
- If no tickets match, say that directly and suggest the most useful refinement.
|
||||
- If the target case is missing, say that directly.
|
||||
- If the target ticket is missing, say that directly.
|
||||
- If the requested update is incomplete, ask one focused follow-up instead of guessing.
|
||||
Reference in New Issue
Block a user