@mohammadhprp/system-prompt 0.12.0 → 0.12.2

package/framework/skills/gitlab-mcp/references/work-items.md

@@ -1,50 +0,0 @@
-# Work Item Operations
-
-> **Opt-in toolset**: Enable with `GITLAB_TOOLSETS=workitems`
-
-Work items are GraphQL-based and cover issues, tasks, incidents, epics, objectives, requirements, tickets, and related hierarchy/status fields. Some status and custom field features require GitLab Premium/Ultimate.
-
-## Read
-
-```
-list_work_items              -> list work items with filters
-get_work_item                -> full details with status, hierarchy, type, labels, assignees, widgets
-list_work_item_notes         -> notes and discussions on a work item
-list_work_item_statuses      -> available statuses for a work item type
-list_custom_field_definitions -> custom field definitions for a work item type
-```
-
-## Create & Update
-
-```
-create_work_item
-  project_id: "my-group/my-project"
-  title: "Investigate checkout failure"
-  work_item_type: "issue"
-  description: "Steps to reproduce..."
-```
-
-```
-update_work_item             -> title, description, labels, assignees, state, parent, children, health, dates, custom fields
-convert_work_item_type       -> convert issue/task/incident/etc.
-move_work_item               -> move a work item to another project
-create_work_item_note        -> add a note, threaded reply, or internal note
-```
-
-## Emoji Reactions
-
-```
-list_work_item_emoji_reactions       -> list reactions on a work item
-create_work_item_emoji_reaction      -> add reaction to a work item
-delete_work_item_emoji_reaction      -> remove reaction from a work item
-list_work_item_note_emoji_reactions  -> list reactions on a work item note or thread reply
-create_work_item_note_emoji_reaction -> add reaction to a work item note or thread reply
-delete_work_item_note_emoji_reaction -> remove reaction from a work item note or thread reply
-```
-
-## Incident Timeline
-
-```
-get_timeline_events     -> list timeline events for an incident
-create_timeline_event   -> create an incident timeline event
-```

package/framework/skills/jira-mcp/SKILL.md

@@ -1,57 +0,0 @@
----
-name: jira-mcp
-description: Use this skill when working with the Jira MCP server tools for issue management, project management, comments, search, and related Jira workflows.
----
-
-# jira-mcp
-
-Jira MCP server providing 12 tools for interacting with your self-hosted Jira instance via the REST API v2.
-
-## Tools
-
-| Category           | Tools                                                                                                                                          | Default |
-|--------------------|------------------------------------------------------------------------------------------------------------------------------------------------|---------|
-| Issues (9 tools)   | `create_issue`, `get_issue`, `update_issue`, `delete_issue`, `search_issues`, `assign_issue`, `get_issue_types`, `add_comment`, `get_comments` | yes     |
-| Projects (2 tools) | `get_projects`, `get_project`                                                                                                                  | yes     |
-| Users (1 tool)     | `get_current_user`                                                                                                                             | yes     |
-
-All tools are available by default — there are no opt-in toolsets for this server.
-
-## Key Workflows
-
-### Issue Lifecycle
-
-`search_issues` → `get_issue` → `update_issue` / `assign_issue`
-
-### Create Issue (see references/issues.md)
-
-`get_project` → `get_issue_types` → `create_issue`
-
-### Comment Thread (see references/comments.md)
-
-`add_comment` → `get_comments`
-
-### Project Discovery (see references/projects.md)
-
-`get_projects` → `get_project` → `get_issue_types`
-
-## Parameter Hints
-
-- **projectKey**: uppercase project key (e.g., `PROJ`, `SCRUM`, `SUP`). Use `get_projects` to discover available keys.
-- **issueKey**: format `PROJECT-123` (e.g., `CHI-42`, `DEV-1337`)
-- **issueType**: varies by project — use `get_issue_types` to list valid types before creating. Common types: `Bug`, `Task`, `Story`, `Epic`, `Sub-task`
-- **search_issues**: uses JQL (Jira Query Language). Complex values (spaces, special chars) must be quoted: `status = "In Progress"`, `project = PROJ`
-- **Jql**: provide a raw JQL query string (not single-quoted — use double quotes inside for string values)
-- **maxResults**: `search_issues` defaults to 50. Increase for larger result sets.
-- **assignee**: Jira username (not display name or email). Use `get_current_user` to find your own username.
-- **Custom fields**: Pass custom field values directly as parameters (e.g., `customfield_10211: "Sprint 1"`). Discover field IDs via Jira REST API.
-
-## Destructive Tools
-
-`delete_issue` — permanently deletes an issue. Cannot be undone.
-
-## Advanced
-
-- **JQL Search**: full Jira Query Language support — combine operators (`AND`, `OR`, `NOT`), functions (`currentUser()`, `now()`, `startOfDay()`), and ordering (`ORDER BY created DESC`)
-- **Status transitions**: use `update_issue` with `status` to transition issues (e.g., `"In Progress"`, `"Done"`, `"Closed"`). Valid statuses depend on the project's workflow configuration.
-- **Custom fields**: map Jira custom field IDs to values via the `customFields` object or direct parameter names

package/framework/skills/jira-mcp/examples.md

@@ -1,31 +0,0 @@
-# Jira MCP Examples
-
-## Example 1: Create and Assign a Bug
-
-A production bug is discovered and needs to be tracked. Good agent behavior:
-
-- Use `jira_get_projects` to find the correct project key.
-- Use `jira_get_issue_types` to confirm valid types for the project.
-- Use `jira_create_issue` with project key, summary, description, priority, and labels.
-- Use `jira_assign_issue` to assign the bug to the responsible developer.
-- Use `jira_add_comment` to include reproduction steps and environment details.
-
-## Example 2: Find and Update Issues
-
-Search for all high-priority unresolved issues assigned to the user. Good agent behavior:
-
-- Use `jira_search_issues` with a JQL query like `assignee = currentUser() AND priority = High AND status != Done`.
-- Use `jira_get_issue` on each result to review full details.
-- Use `jira_update_issue` to transition the status to "In Progress".
-- Use `jira_add_comment` to log what work is being started.
-- Summarize the findings in a structured report grouped by status.
-
-## Example 3: Close a Sprint Task
-
-A task is complete and ready to close. Good agent behavior:
-
-- Use `jira_get_current_user` to verify authentication is working.
-- Use `jira_search_issues` to find the task by key or summary.
-- Use `jira_get_issue` to review current status, assignee, and description.
-- Use `jira_update_issue` to set status to "Done" and add a resolution note.
-- Use `jira_add_comment` to document what was completed and any follow-ups.

package/framework/skills/jira-mcp/references/comments.md

@@ -1,27 +0,0 @@
-# Comments
-
-## Add Comment
-
-```
-add_comment
-  issueKey: "PROJ-123"
-  comment: "Fixed in latest deployment (v2.4.1)"
-```
-
-Adds a text comment to a Jira issue. No support for rich text or attachments via this server.
-
-## Read Comments
-
-```
-get_comments
-  issueKey: "PROJ-123"
-```
-
-Returns all comments on an issue, ordered by creation date (ascending). Each comment includes `body`, `author`, `created`, and `updated` timestamps.
-
-## Limitations
-
-- **No edit/update** — the current Jira MCP server does not provide an edit-comment tool
-- **No delete** — comments cannot be removed via this server
-- **No threading/replies** — comments are flat (Jira Cloud's threading is not exposed via this API)
-- **No rich text** — plain text only; HTML/markdown in bodies may be rendered by Jira's API

package/framework/skills/jira-mcp/references/issues.md

@@ -1,97 +0,0 @@
-# Issue Management
-
-## Create
-
-```
-create_issue
-  projectKey: "PROJ"
-  summary: "Login page returns 500"
-  issueType: "Bug"
-  description: "Steps to reproduce..."
-  priority: "High"
-  labels: ["bug", "critical"]
-  assignee: "john.doe"
-  components: ["frontend"]
-  customfield_10211: "Sprint 1"    # optional custom fields
-```
-
-Always verify project and issue types first:
-
-1. `get_projects` → find project key
-2. `get_issue_types` with `projectKey: "PROJ"` → find valid types
-3. `create_issue` with valid `projectKey` and `issueType`
-
-## Read
-
-```
-get_issue
-  issueKey: "PROJ-123"
-```
-
-Returns full issue details: summary, description, status, priority, assignee, reporter, labels, components, custom fields, timestamps.
-
-## Search (JQL)
-
-```
-search_issues
-  jql: "project = PROJ AND status = Open"
-  maxResults: 50
-```
-
-### Common JQL Patterns
-
-| Purpose | JQL |
-| ------- | --- |
-| My open issues | `assignee = currentUser() AND status != Done` |
-| High priority recent | `priority = High AND created >= -7d` |
-| By status | `status IN (Open, "In Progress", "Reopened")` |
-| By label | `labels = "bug" OR labels = "critical"` |
-| By reporter | `reporter = john.doe AND status NOT IN (Closed, Done)` |
-| Unassigned | `assignee IS NULL AND status NOT IN (Closed, Done, Resolved)` |
-| Sprints (custom field) | `cf[10211] = "Sprint 1"` |
-| Date range | `created >= "2025-01-01" AND created <= "2025-06-01"` |
-| Order by | `project = PROJ ORDER BY priority DESC, created ASC` |
-| Text search | `text ~ "error message"` |
-| Across all projects | `status = Open AND assignee = currentUser()` |
-
-`search_issues` defaults to showing issues across **all projects** the user has access to. Scope to a specific project with `project = KEY`.
-
-## Update
-
-```
-update_issue
-  issueKey: "PROJ-123"
-  summary: "Updated title"
-  description: "New description"
-  priority: "Low"
-  assignee: "jane.doe"
-  labels: ["bug", "resolved"]
-  status: "In Progress"           # transition to new status
-  customfield_10211: "Sprint 2"
-```
-
-### Status Transitions
-
-- Issue workflow statuses depend on the project's configuration
-- Common transitions: `Open → "In Progress" → "In Review" → "Done" | "Closed"`
-- Use `get_issue` to check current status and `update_issue` with `status` to transition
-- Invalid transitions return an error — check the project's available workflow transitions in Jira
-
-## Assign
-
-```
-assign_issue
-  issueKey: "PROJ-123"
-  assignee: "john.doe"
-```
-
-`assign_issue` is a dedicated tool. You can also assign via `update_issue` with `assignee`.
-
-## Delete
-
-```
-delete_issue
-  issueKey: "PROJ-123"
-```
-
-**Warning**: `delete_issue` is destructive — permanently deletes the issue. Cannot be undone.

package/framework/skills/jira-mcp/references/projects.md

@@ -1,39 +0,0 @@
-# Project Management
-
-## List Projects
-
-```
-get_projects
-```
-
-Returns all Jira projects the authenticated user can access. Each entry includes `key`, `name`, `projectTypeKey`, `lead`, and `avatarUrls`.
-
-Use this to discover available `projectKey` values for issue operations.
-
-## Project Details
-
-```
-get_project
-  projectKey: "PROJ"
-```
-
-Returns detailed information: name, key, description, lead, components, versions (releases), project type, and category.
-
-Verify a project exists and inspect its components/versions before creating issues:
-
-1. `get_project` → check components, versions
-2. `get_issue_types` → check valid issue types
-3. `create_issue` with verified data
-
-## Issue Types
-
-```
-get_issue_types
-  projectKey: "PROJ"
-```
-
-Returns available issue types for a project. Each type includes `name`, `id`, `description`, `iconUrl`, and `subtask` flag.
-
-Common types across most projects: `Bug`, `Task`, `Story`, `Epic`, `Sub-task`, `Improvement`, `New Feature`.
-
-Always call this **before** creating an issue to ensure the `issueType` value is valid for the target project.

package/framework/skills/lavish/SKILL.md

@@ -1,67 +0,0 @@
----
-name: lavish
-description: Turn complex or visual agent responses into rich, reviewable HTML artifacts the user can annotate and send feedback on, using the lavish-axi CLI. Use when about to give a plan, comparison, diagram, table, code diff, report, or anything easier to grasp visually than as prose.
-argument-hint: <what the artifact should show>
-author: Kun Chen (kunchenguid)
----
-
-# Lavish Editor
-
-Lavish Editor helps agents turn rich HTML artifacts into collaborative human review surfaces. Whenever you are about to give user a complex response that will be easier to understand via a rich / interactive page, consider using Lavish Editor. First generate an interactive HTML artifact according to user request, then run `npx -y lavish-axi <html-file>` so the user can visually review it, annotate elements or selected text, queue prompts, and send feedback back through `npx -y lavish-axi poll`.
-
-You do not need lavish-axi installed globally - invoke it with `npx -y lavish-axi <html-file>`.
-If lavish-axi output shows a follow-up command starting with `lavish-axi`, run it as `npx -y lavish-axi ...` instead.
-
-## Request
-
-$ARGUMENTS
-
-If the request above is non-empty, the user invoked `/lavish` explicitly - build an HTML artifact for that request now, following the workflow below.
-If it is empty, infer what to visualize from the conversation.
-
-## When to use
-
-Use lavish-axi when the user asks for a visual artifact, HTML explainer, interactive prototype, review surface, product or technical plan, comparison, report, or browser-based feedback loop
-
-## Workflow
-
-1. Create the HTML artifact (default location `.opencode/output/lavish/<name>.html` in the working directory).
-2. Run `npx -y lavish-axi <html-file>` to open or resume a review session in the browser.
-3. Run `npx -y lavish-axi poll <html-file>` to long-poll for the user's annotations, queued prompts, and browser-reported `layout_warnings`.
-   The poll stays silent until the user acts or the real browser reports fresh layout warnings - leave it running, never kill it.
-   If your harness limits how long a foreground command may run, run the poll as a background task; if it gets killed or times out anyway, just re-run it - queued feedback is never lost.
-4. If poll returns `layout_warnings`, fix overflow, clipped text, or overlapping unreadable content and re-check before involving the human.
-5. Apply human feedback, then poll again with `--agent-reply "<message>"` to reply in the browser and keep the loop going.
-6. Run `npx -y lavish-axi end <html-file>` when the review is finished.
-
-## Visual guidance
-
-- Use visual hierarchy to make the most important decisions, risks, tradeoffs, and next actions obvious at a glance
-- Use visual structure such as sections, cards, tables, diagrams, annotated snippets, and side-by-side comparisons instead of long prose
-- Choose typography, spacing, color, and layout deliberately so the artifact has a clear point of view
-- Prevent horizontal overflow at every nesting level: nested grid/flex children also need minmax(0, 1fr) tracks and min-width: 0, especially when badges, labels, or status text use wide pixel or monospace fonts; wrap, truncate, or contain long unbreakable text deliberately
-
-## Playbooks
-
-Run `npx -y lavish-axi playbook <id>` for focused, detailed guidance on any of these.
-One artifact often combines several playbooks (for example a plan that includes a comparison and a diagram), so read every playbook relevant to your artifact, not just one, for the best quality:
-
-- `diagram` - Map relationships, flows, state, and architecture
-- `table` - Turn dense records into scan-friendly review surfaces
-- `comparison` - Show options, tradeoffs, and current vs target behavior
-- `plan` - Explain a product or technical plan before implementation
-- `code` - Render source code, code files, patches, PR diffs, and before/after code inside Lavish artifacts
-- `input` - Must be used when the agent needs to collect user input on decisions, choices, preferences, triage, scope, or other structured feedback from within the artifact
-- `slides` - Create a deliberate presentation when slides are requested
-
-## Commands & rules
-
-- Run `npx -y lavish-axi <html-file>` to open or resume a Lavish Editor session
-- Unless the user specifies another location, create HTML artifacts in the current working directory under `.opencode/output/lavish/`
-- Lavish serves the html file through a local express.js server. If your html needs to reference other filesystem assets such as images, CSS, fonts, and local scripts, copy them into the same directory as the HTML file, then reference them with relative paths from that directory. Never prepend `/` to those asset paths - root paths won't work
-- Run `npx -y lavish-axi poll <html-file>` to wait for user feedback or browser-reported layout_warnings. It long-polls and stays silent until the user sends feedback, ends the session, or the real browser reports fresh layout_warnings, so leave it running - never kill it. Fix layout_warnings before involving the human. If your harness limits how long a foreground command may run, run the poll as a background task; if it gets killed or times out anyway, just re-run it - queued feedback is never lost
-- Run `npx -y lavish-axi end <html-file>` to end a session
-- Run `npx -y lavish-axi stop` to shut down the background server (it also self-stops when idle or after the last session ends with nothing connected)
-- Run `npx -y lavish-axi playbook <playbook_id>` for focused artifact guidance. One artifact often combines several playbooks (for example a plan that includes a comparison and a diagram), so read every playbook relevant to the artifact, not just one, for the best quality
-- Lavish does not auto-inject any design system - artifacts stay portable so they render identically when opened directly without lavish-axi running. Before writing any HTML, decide the design direction in this strict priority order, and only move to the next step when the current one truly yields nothing: (1) if the user asked for a specific look or named design system, use that; (2) otherwise you must first inspect the project the artifact is about - the subject or product whose content or UI it represents, which may differ from your current working directory - and match that project's design system: Tailwind or theme config, shared CSS variables or design tokens, component library, brand assets, or existing styled pages. If the artifact previews, proposes, or mocks a specific app's UI, render it in that app's own design system so it faithfully shows the product, even when you are running in a different repo; (3) only when both steps come up empty, use the Lavish-recommended Tailwind CSS browser runtime v4 + DaisyUI v5, available via CDN - run `npx -y lavish-axi design` for a copy-pasteable CDN snippet plus component reference, and prefer that CDN snippet over hand-writing styles unless explicitly instructed otherwise by the user. When you deliver the artifact, state which of the three design sources you used and why.
-- Use lavish-axi when the user asks for a visual artifact, HTML explainer, interactive prototype, review surface, product or technical plan, comparison, report, or browser-based feedback loop

package/framework/skills/lavish/examples.md

@@ -1,31 +0,0 @@
-# Lavish Examples
-
-## Example 1: Architecture Diagram
-
-Visualize a proposed microservices migration for team review. Good agent behavior:
-
-- Generate an HTML artifact with a clear SVG or Mermaid diagram showing the current monolith, proposed services, and data flow arrows.
-- Use color coding: blue for existing components, green for new services, orange for shared infrastructure.
-- Include a legend and numbered annotations explaining each architectural decision.
-- Annotate key interfaces and data contracts at each boundary.
-- Run `npx -y lavish-axi <html-file>` to let the team review and leave feedback on specific elements.
-
-## Example 2: Code Diff Comparison
-
-Present a side-by-side comparison of refactored code for review. Good agent behavior:
-
-- Generate an HTML artifact with two panels showing before and after code with syntax highlighting.
-- Highlight changed lines in yellow, added lines in green, removed lines in red.
-- Add inline annotations explaining why each change was made.
-- Include a summary section at the top listing the number of files changed, lines added, and lines removed.
-- Run `npx -y lavish-axi <html-file>` so reviewers can annotate specific code sections.
-
-## Example 3: Performance Benchmark Report
-
-Display benchmark results comparing caching strategies. Good agent behavior:
-
-- Generate an HTML artifact with a bar chart comparing response times across strategies (no cache, Redis, in-memory, database).
-- Include a table with exact measurements: p50, p95, p99 latency, throughput, and memory usage.
-- Add a recommendation section with the preferred strategy highlighted and a rationale.
-- Include interactive tooltips showing sample size and confidence intervals.
-- Run `npx -y lavish-axi <html-file>` so the team can annotate concerns or ask questions about specific benchmarks.