@mohammadhprp/system-prompt 0.10.1

package/framework/agents/security-auditor.md

@@ -0,0 +1,131 @@
+---
+description: Conduct security audits for REST APIs and identify vulnerabilities. Use PROACTIVELY for authentication reviews, authorization checks, or security compliance validation.
+mode: subagent
+temperature: 0.1
+permission:
+  bash: allow
+  read: allow
+  edit: deny
+  write: deny
+  patch: deny
+  grep: allow
+  glob: allow
+  list: allow
+  webfetch: allow
+  todoread: deny
+  todowrite: deny
+---
+
+You audit REST API security and identify vulnerabilities. You are authoritative, precise, and practical — you find real threats, not theoretical ones.
+
+## Scope
+
+Focus on REST API security across these areas:
+
+### 1. Authentication
+- Is identity verified at every entry point (not just the main endpoint)?
+- Token validation: signature, expiration (`exp`), issuer (`iss`), audience (`aud`) — all checked?
+- Are short-lived access tokens (15-60 min) and refresh tokens used?
+- Are password reset, MFA enrollment, and token refresh endpoints equally protected?
+
+### 2. Authorization
+- Are permission checks enforced at the service layer, not just the API gateway or UI?
+- Is access checked against the specific resource (object-level), not assumed from the caller?
+- Horizontal privilege escalation: can User A access User B's resources by changing an ID?
+- Vertical privilege escalation: can a low-privilege user call admin-only endpoints?
+
+### 3. Input Validation & Injection
+- Are all inputs validated, sanitized, and type-checked at the API boundary?
+- SQL injection: parameterized queries everywhere (no string concatenation)?
+- NoSQL injection, command injection, LDAP injection, XML injection?
+- Is there a size/type allowlist for file uploads? Are uploaded files stored outside the web root?
+- SSRF: does the API fetch user-supplied URLs without allowlist validation?
+
+### 4. Secrets & Credentials
+- Any secrets in source code, config files, .env files, CI variables, or container images?
+- Are API keys, tokens, and passwords in logs, error responses, or stack traces?
+- Secrets manager (Vault, AWS Secrets Manager, etc.) used for production secrets?
+- Are database connection strings, signing keys, and third-party tokens managed securely?
+
+### 5. Data Protection
+- TLS 1.2+ enforced for all API traffic? Is HTTP redirected to HTTPS?
+- Sensitive data encrypted at rest (AES-256)?
+- Are credit cards, PII, or credentials in API request/response bodies (including logs)?
+- Is sensitive data exposed in URLs (e.g., `/api/user/email=foo@bar.com`)?
+
+### 6. Rate Limiting & Abuse
+- Are authentication, password reset, and expensive endpoints rate-limited?
+- Are rate limits per-user or per-IP (and can IP-rotation bypass them)?
+- Request size limits on POST/PUT bodies?
+- Webhook endpoints protected (HMAC verification, IP allowlist)?
+
+### 7. Security Headers
+- `Content-Security-Policy`, `X-Content-Type-Options: nosniff`, `Strict-Transport-Security`, `X-Frame-Options: DENY`?
+- CORS: is `Access-Control-Allow-Origin` too permissive (e.g., `*` with credentials)?
+- Is `Access-Control-Allow-Credentials: true` only when needed and paired with a specific origin?
+
+### 8. Logging & Monitoring
+- Are authentication failures and authorization denials logged for audit?
+- Are logs free of secrets, tokens, and PII?
+- Is there an alert on brute-force patterns (N failures in M minutes)?
+
+## Audit Process
+
+### Step 1: Map the Attack Surface
+Identify: entry points (all routes), data assets (what each endpoint handles), trust boundaries, authentication mechanisms, third-party integrations.
+
+### Step 2: Review Code and Config
+- Load [`skills/backend-best-practices/references/security.md`](../skills/backend-best-practices/references/security.md) and [`references/standards/security.md`](../references/standards/security.md).
+- Read route definitions, middleware, auth guards, service-layer authorization, input validation logic.
+- Read config files for CORS, rate limiting, TLS settings, secrets.
+
+### Step 3: Test for Common Vulnerabilities
+Run controlled tests where safe:
+- Attempt IDOR by modifying IDs in requests
+- Check for missing auth on non-obvious endpoints
+- Verify rate limits on auth endpoints
+- Check error responses for stack traces or internal details
+
+### Step 4: Document Findings
+For each finding include:
+- **Severity**: Critical / High / Medium / Low
+- **Location**: file:line or endpoint
+- **Risk**: realistic scenario where exploited
+- **Fix**: concrete remediation steps
+
+## Output Format
+
+```
+## Summary
+[Overall risk level and key finding count]
+
+## Critical/High Findings
+[Highest priority issues]
+
+### [TITLE]
+- **Severity**: Critical
+- **Location**: path/file.php:line
+- **Risk**: what an attacker could do
+- **Fix**: specific remediation
+
+[Repeat...]
+
+## Medium/Low Findings
+[Lower priority but still relevant]
+
+## Security Posture
+- What's done well
+- What's missing
+- Recommended priority actions
+
+## Non-Findings (Notable)
+Items explicitly checked and found secure — demonstrates thoroughness.
+```
+
+## Tone
+
+- **Authoritative but practical** — flag real threats, not compliance checkbox items
+- **Specific** — exact file:line, curl examples, concrete fixes
+- **Risk-driven** — prioritize by exploitability and impact, not theoretical severity
+
+Return findings in response. Do not modify any files.

package/framework/commands/README.md

@@ -0,0 +1,43 @@
+# Command Catalog
+
+A catalog of slash commands for AI coding agents.
+
+Commands define repeatable workflows that agents execute on demand, triggered by a slash command and optional arguments. Each command describes the process steps, references the relevant skill and standards, and produces a structured deliverable.
+
+## Available Commands
+
+| Command | Purpose | Loads |
+| --- | --- | --- |
+| [`/changelog`](./changelog.md) | Create, add, or update CHANGELOG.md entries. | — |
+| [`/commit`](./commit.md) | Create atomic git commits with conventional messages. | — |
+| [`/learn`](./learn.md) | Distill a reusable skill from any source — directory, URL, workflow, or pasted notes. | skill-creator skill |
+| [`/pr`](./pr.md) | Create a GitHub PR for the current branch. | pull-requests standard |
+| [`/mr`](./mr.md) | Create a GitLab MR for the current branch. | pull-requests standard |
+| [`/release`](./release.md) | Create a release by tagging, generating changelog, and bumping version. | — |
+| [`/review`](./review.md) | Perform comprehensive code quality review. | code-review skill, naming/testing/security/performance standards |
+| [`/summarize-changes`](./summarize-changes.md) | Summarize uncommitted changes and flag risky patterns. | — |
+
+## Command Entry Structure
+
+```text
+commands/<command-name>.md
+```
+
+Each command file uses frontmatter with a `description` field, the command signature with `$ARGUMENTS` placeholder, and a `## Process` section with numbered steps.
+
+## How to Contribute a New Command
+
+1. Create `commands/<command-name>.md` following the existing format.
+2. Write a clear `description` in the frontmatter.
+3. Define the command signature with `$ARGUMENTS` for optional arguments.
+4. Break the workflow into numbered steps under `## Process`.
+5. Reference related skills and standards with relative links.
+6. Add the command to the table in this README.
+
+## Related Repository Areas
+
+- [`skills/`](../skills/) contains skill definitions loaded by commands.
+- [`mcps/`](../mcps/) contains the MCP server catalog.
+- [`plugins/`](../plugins/) contains the OpenCode plugin catalog.
+- [`references/standards/`](../references/standards/) contains canonical engineering rules.
+- [`references/templates/`](../references/templates/) contains reusable engineering deliverables.

package/framework/commands/changelog.md

@@ -0,0 +1,44 @@
+---
+description: Create, add, or update entries in CHANGELOG.md
+agent: build
+---
+
+Changelog $ARGUMENTS
+
+Maintain CHANGELOG.md entries for my changes.
+
+## Process
+
+1. **Review and categorize** - Review conversation history, read current `CHANGELOG.md`, determine if changes are `Added`, `Changed`, `Fixed`, `Removed`, `Deprecated`, or `Security`. Read the existing `## Unreleased` section.
+
+2. **Group related changes** - Combine related changes into single bullet points. Use past tense ("Added...", "Fixed..."). Include file paths or component names in backticks when helpful. Match existing style and tone.
+
+3. **Add entries** - Insert new bullet points under the correct heading within `## Unreleased`. Create the `## Unreleased` section with relevant headings if it does not exist. Preserve all existing entries.
+
+4. **Verify** - Read the final `CHANGELOG.md` to confirm entries are in the right section, correctly formatted, and no existing entries were altered or removed.
+
+## Entry Format
+
+```markdown
+## Unreleased
+
+### Added
+- New features, entries, additions.
+
+### Changed
+- Changes in existing functionality, refactors, renames.
+
+### Fixed
+- Bug fixes, corrections.
+
+### Removed
+- Removed features, files, entries.
+
+### Deprecated
+- Soon-to-be-removed features.
+
+### Security
+- Vulnerabilities, security fixes.
+```
+
+**Note:** Group entries by section. Order sections: Added, Changed, Fixed, Removed, Deprecated, Security. Within each section, entries are reverse-chronological (newest first). Keep descriptions concise but informative — include the file path or component name when it adds clarity.

package/framework/commands/commit.md

@@ -0,0 +1,31 @@
+---
+description: Create atomic git commits with conventional messages
+agent: build
+---
+
+Commit $ARGUMENTS
+
+Create git commits for my changes.
+
+## Process
+
+1. **Analyze and plan** - Review conversation history, run `git status -s` and `git diff`, determine if changes should be one or multiple logical commits, group related files, draft conventional commit messages (`type: description`) in imperative mood focusing on why
+2. **Present plan** - List files for each commit, show commit messages with type prefix, ask: "I plan to create [N] commit(s) with these changes. Shall I proceed?"
+3. **Execute upon confirmation** - Use `git add` with specific files (never `-A` or `.`), create commits with planned messages, show result with `git log --oneline -n [N]`
+
+## Commit Message Format
+
+Use conventional commit format: `type: description`
+
+**Types:**
+- `feat:` - New feature (user-facing)
+- `fix:` - Bug fix (user-facing)
+- `docs:` - Documentation only
+- `chore:` - Maintenance, tooling, dependencies
+- `refactor:` - Code restructuring without behavior change
+- `test:` - Adding or updating tests
+- `perf:` - Performance improvement
+- `ci:` - CI/CD changes
+
+**Note:** During release generation, `chore:`, `docs:`, and `ci:` commits are filtered from changelog. Only user-facing changes (`fix:`, `feat:`, etc.) are included.
+

package/framework/commands/learn.md

@@ -0,0 +1,24 @@
+---
+description: Distill a reusable skill from any source — directory, URL, workflow, or pasted notes
+agent: build
+---
+
+Learn $ARGUMENTS
+
+Distill a reusable skill from anything the user describes. The agent gathers sources with its own tools, analyzes the pattern, and authors a SKILL.md with examples.
+
+## Process
+
+1. **Understand the source** — If the user provides a directory path, explore its structure and read key files. If a URL, fetch and analyze its content. If "the workflow we just did", review conversation history for tools used, step sequence, and corrections. If pasted notes, analyze them for structure, rules, and intent. Load [`skills/skill-creator/SKILL.md`](../skills/skill-creator/SKILL.md) for skill writing guidance.
+
+2. **Capture intent and confirm** — Determine: what should this skill enable? When should it trigger (what user phrases/contexts)? What's the expected output format? Should test cases be created? Ask the user to confirm before proceeding.
+
+3. **Research and gather context** — Search for similar existing skills in the catalog. Check for relevant MCPs, standards, or references. Identify edge cases, input/output formats, and dependencies.
+
+4. **Author the skill** — Create `skills/<name>/SKILL.md` with: frontmatter (name, description optimized for triggering), purpose, when to activate, step-by-step workflow, rules, deliverables, and checklist. Follow skill-creator principles: use imperative form, explain the *why*, keep under 500 lines, avoid over-constraining with MUSTs.
+
+5. **Write examples** — Create `skills/<name>/examples.md` with 3+ realistic examples. Each should show the trigger context, input, and expected output or workflow.
+
+6. **Register in catalog** — Add the skill to `skills/README.md` in the correct alphabetical position in the table.
+
+7. **Present result** — Show the user what was created (path, structure, description). Offer to create test cases, iterate on the skill, or run the description optimizer.

package/framework/commands/mr.md

@@ -0,0 +1,46 @@
+---
+description: Create a merge request from the current branch
+---
+
+Create $ARGUMENTS merge request
+
+Create a merge request for the current branch.
+
+## Process
+
+1. **Collect information**
+   - Get current branch name: `git branch --show-current`
+   - Read MR template from `.gitlab/merge_request_templates/default.md` of exsits
+
+2. **Format MR title**
+   - Take the branch name, replace all `-` with spaces, capitalize first character
+
+3. **Collect commits and build summary**
+   - List commits on the branch that are not on `dev`: `git log dev..HEAD --oneline`
+   - Read each commit message, convert to a bullet list summarizing user-facing changes
+   - Merge/squash related commits (e.g. multiple commits for the same change)
+   - Keep concise, one bullet per logical change
+
+4. **Fill template**
+   - Set Summary to the bullet list from step 3
+   - Keep the Checklist section as-is
+
+5. **Present plan and confirm** - Show:
+   - Source branch
+   - Target branch: `develop`
+   - Title
+   - Filled description
+   - Ask: "Shall I create this MR?"
+   - Push the changes if user says Yes
+
+6. **Create upon confirmation** - Use `gitlab_create_merge_request`:
+   - `project_id`: `group/repo`
+   - `title`: Prepend "Draft: " to the formatted branch name
+   - `source_branch`: Current branch
+   - `target_branch`: `develop`
+   - `description`: Filled template content
+   - `assignee_ids`: `[1]`
+   - `squash`: `true`
+   - `remove_source_branch`: `true`
+
+7. **Show the resulting URL.**

package/framework/commands/pr.md

@@ -0,0 +1,39 @@
+---
+description: Create a GitHub PR for the current branch
+agent: build
+---
+
+PR $ARGUMENTS
+
+Create or update a pull request for the current branch using `gh` cli.
+
+## Process
+
+1. **Collect information**
+   - Get current branch name: `git branch --show-current`
+   - Read PR template from `.github/pull_request_template.md` of exsits
+
+2. **Format PR title**
+   - Take the branch name, replace all `-` with spaces, capitalize first character
+
+3. **Collect commits and build summary**
+   - List commits on the branch that are not on `dev`: `git log dev..HEAD --oneline`
+   - Read each commit message, convert to a bullet list summarizing user-facing changes
+   - Merge/squash related commits (e.g. multiple commits for the same change)
+   - Keep concise, one bullet per logical change
+
+4. **Fill template**
+   - Set Summary to the bullet list from step 3
+   - Keep the Checklist section as-is
+
+5. **Present plan and confirm** - Show:
+   - Source branch
+   - Target branch: `develop`
+   - Title
+   - Filled description
+   - Ask: "Shall I create this PR?"
+   - Push the changes if user says Yes
+
+6. **Create upon confirmation** - Use `gh` cli:
+   - `gh pr create --title "<title>" --body "<body>" --base <target>`
+   - Show the resulting URL.

package/framework/commands/release.md

@@ -0,0 +1,34 @@
+---
+description: Create a release by tagging the current state, generating changelog, and bumping version
+agent: build
+---
+
+Release $ARGUMENTS
+
+Create a release from the current branch state.
+
+## Process
+
+1. **Review recent commits** - Run `git fetch --tags`, `git describe --tags --abbrev=0` to find the latest tag. Run `git log <latest-tag>..HEAD --oneline --format="%s"` to collect all conventional commits since the last release. Read any existing `CHANGELOG.md`.
+
+2. **Categorize commits** - Group commits by conventional commit type:
+   - `feat!:` or `BREAKING CHANGE:` → breaking change
+   - `feat:` → minor feature
+   - `fix:` → patch fix
+   - `perf:`, `refactor:`, `test:` → patch (if no features)
+   - `chore:`, `docs:`, `ci:` → filtered from changelog
+
+3. **Determine next version** - Based on the [`commit.md`](./commit.md) semver convention:
+   - Breaking changes → increment major version (e.g., `1.2.3` → `2.0.0`)
+   - New features → increment minor version (e.g., `1.2.3` → `1.3.0`)
+   - Only fixes/refactors → increment patch version (e.g., `1.2.3` → `1.3.4`)
+   - If no previous tag exists, propose `0.1.0`
+
+4. **Present release plan** - Show: current version, new version, categorized changelog entries, and ask: "Shall I create this release (tag vX.Y.Z and update CHANGELOG.md)?"
+
+5. **Execute on confirmation**:
+   - Update `CHANGELOG.md`: create a new `## [vX.Y.Z]` section under `## Unreleased`, move categorized entries (excluding chore/docs/ci) into it, add the release date, keep the `## Unreleased` section empty for future work
+   - Run `git add CHANGELOG.md && git commit -m "chore: release vX.Y.Z"`
+   - Run `git tag -a vX.Y.Z -m "vX.Y.Z"`
+
+6. **Verify** - Run `git log --oneline -n 3` and `git tag --list --sort=-v:refname -n5` to confirm the release tag and commit are in place.

package/framework/commands/review.md

@@ -0,0 +1,24 @@
+---
+description: Perform comprehensive code quality review
+agent: plan
+---
+
+Review $ARGUMENTS
+
+Perform comprehensive code quality review.
+
+## Process
+
+1. **Review conversation and diff** - Read conversation history, run `git diff` for staged/unstaged changes, identify the problem being solved and the behavior being modified. Load [`skills/code-review/SKILL.md`](../skills/code-review/SKILL.md) and related standards: [`references/standards/naming.md`](../references/standards/naming.md), [`references/standards/testing.md`](../references/standards/testing.md), [`references/standards/security.md`](../references/standards/security.md), [`references/standards/performance.md`](../references/standards/performance.md).
+
+2. **Check correctness** - Edge cases, concurrency, error handling, state transitions, backward compatibility. Read contracts and interfaces before implementation.
+
+3. **Check maintainability** - Naming reflects business meaning, structure matches project conventions, comments explain why not what.
+
+4. **Check testing** - Do tests prove the behavior change? Missing edge cases or failure paths? Tests should verify behavior, not mirror implementation.
+
+5. **Check performance** - N+1 queries, unbounded loops, unnecessary allocations, caching opportunities.
+
+6. **Check security** - Input validation, authentication enforcement, secrets exposure, least privilege.
+
+7. **Present findings** - Distinguish blockers from suggestions, explain reasoning for each, summarize overall risk and production readiness.

package/framework/commands/summarize-changes.md

@@ -0,0 +1,49 @@
+---
+description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff.
+agent: plan
+---
+
+Summarize Changes $ARGUMENTS
+
+Summarize uncommitted changes and flag risky patterns.
+
+## Process
+
+1. **Inspect working tree** - Run `git status` (staged and unstaged), `git diff --stat`, `git diff` (and `git diff --cached` for staged). Count files changed, insertions, deletions.
+
+2. **Categorize changes** - Group files by type of change:
+   - New files vs modifications vs deletions vs renames
+   - By layer: config, migrations, controllers, models, views, tests, infrastructure
+
+3. **Analyze risk** - Scan diffs for specific risk signals:
+   - **Secrets**: API keys, tokens, passwords, connection strings in any file
+   - **TODOs/FIXMEs**: incomplete work left behind
+   - **Debug code**: `console.log`, `dd()`, `var_dump`, `print`, debug breakpoints
+   - **Large diffs**: files with >100 changed lines (hard to review)
+   - **Generated files**: lockfiles, compiled assets, build outputs in the diff
+   - **Migration changes**: database migrations without corresponding model changes (or vice versa)
+   - **Config changes**: environment config, .env, CI config changes
+   - **Comment-only changes**: files changed only in comments (suspicious)
+   - **Permission changes**: executable bit changes, ownership changes
+
+4. **Summarize** - Present a clear summary: files changed, insertion/deletion counts, categorized by risk level.
+
+## Output Format
+
+```
+## Summary
+N files changed, +X/-Y lines
+
+## Changes by Category
+- **New**: file1, file2
+- **Modified**: file3, file4
+- **Deleted**: file5
+
+## Risks
+🔴 HIGH: [risk description] — file:line
+🟡 MEDIUM: [risk description] — file:line
+🔵 LOW: [risk description] — file:line
+
+## Suggested Commit(s)
+feat: description
+```

package/framework/mcps/README.md

@@ -0,0 +1,78 @@
+# MCP Catalog
+
+A curated catalog of Model Context Protocol (MCP) servers for AI coding agents.
+
+This catalog is framework-agnostic: each entry documents what the server does, when to use it, how to install it, how to configure it across common AI clients, and how to troubleshoot it.
+
+## Available MCPs
+
+| MCP | Purpose | Best fit |
+| --- | --- | --- |
+| [Excalidraw MCP](./excalidraw/README.md) | Stream hand-drawn Excalidraw diagrams with interactive fullscreen editing — architecture diagrams, flowcharts, wireframes. | Any project that benefits from visual diagrams, architecture visualization, or design sketching. |
+| [Figma MCP Go](./figma-mcp-go/README.md) | Full read/write access to Figma designs via plugin bridge — no API token or rate limits. | Any project that works with Figma designs. |
+| [GitLab MCP](./gitlab-mcp/README.md) | Comprehensive GitLab integration — projects, MRs, issues, pipelines, wiki, milestones, and more. | Any project hosted on GitLab (SaaS or self-hosted). |
+| [GitHub MCP](./github-mcp/README.md) | Connect AI tools to GitHub — browse repos, manage issues and PRs, monitor Actions workflows. | Any project hosted on GitHub. |
+| [Jira MCP](./jira-mcp/README.md) | Interact with self-hosted Jira instances — issues, JQL search, comments, assignments, and projects. | Any project using self-hosted Jira for issue tracking. |
+| [Laravel Boost](./laravel-boost/README.md) | Gives AI agents Laravel application context, Laravel ecosystem documentation search, and safe local inspection tools. | Laravel applications. |
+| [Notion MCP](./notion-mcp/README.md) | Search, read, and write content in a Notion workspace — pages, databases, views, comments, and more via remote HTTP MCP. | Any project that uses Notion for documentation, tracking, or collaboration. |
+| [Playwright MCP](./playwright-mcp/README.md) | Cross-browser automation via accessibility snapshots — navigate, click, type, screenshot, evaluate, network control, storage management. | Any project needing browser automation or end-to-end testing. |
+| [Supabase MCP](./supabase-mcp/README.md) | Manage Supabase projects, query databases, design schema, run migrations, deploy Edge Functions, manage Auth/Storage/Realtime, and search docs. | Any project using Supabase as backend. |
+
+## Why MCPs Are Useful
+
+MCP servers give AI clients a standard way to connect to project-aware tools and data sources. For coding agents, this can improve:
+
+- **Context accuracy**: agents can inspect real application state instead of relying only on static files.
+- **Tool consistency**: one server can work across many clients that support MCP.
+- **Operational safety**: capabilities and permissions are explicit in configuration.
+- **Repeatability**: teams can document the same install and verification steps for every developer.
+
+## How to Choose an MCP
+
+Use an MCP when it provides concrete project context or a controlled tool that the AI client cannot reliably infer from source code alone.
+
+Before installing one, check:
+
+- **Scope**: Does it match the framework, platform, or workflow in the project?
+- **Capabilities**: Does it expose tools that materially improve the agent's work?
+- **Permissions**: Can it read or modify sensitive data, run commands, or query databases?
+- **Client support**: Does your AI client support local stdio MCP servers or the server's required transport?
+- **Maintenance**: Is the server actively maintained and documented by an authoritative source?
+
+## Catalog Entry Structure
+
+Every MCP entry must use this structure:
+
+```text
+mcps/<mcp-slug>/
+├── README.md
+├── install.md
+├── capabilities.md
+├── troubleshooting.md
+└── configs/
+    ├── opencode.json
+    └── .env.example
+```
+
+## Naming Conventions
+
+- Use lowercase kebab-case directory names, for example `laravel-boost`.
+- Use the upstream MCP name in page titles, for example `# Laravel Boost`.
+- Use stable MCP server names in configuration examples, for example `laravel-boost`.
+- Keep file names exactly as shown in the catalog structure.
+
+## How to Contribute a New MCP
+
+1. Create `mcps/<mcp-slug>/` using the standard structure.
+2. Prefer official documentation for install commands, requirements, capabilities, and configuration.
+3. Include client-specific config examples even when multiple clients share the same JSON schema.
+4. Document where each config file belongs in the MCP's `install.md`.
+5. Add limitations and permission notes in `capabilities.md`.
+6. Add common startup, authentication, permission, and version issues in `troubleshooting.md`.
+7. Add the MCP to the table in this README.
+
+## Related Repository Areas
+
+- [`skills/`](../skills/) contains task-specific procedures for AI coding agents.
+- [`references/standards/`](../references/standards/) contains canonical engineering rules.
+- [`references/templates/`](../references/templates/) contains reusable engineering deliverables.

package/framework/mcps/excalidraw/README.md

@@ -0,0 +1,37 @@
+# Excalidraw MCP
+
+## Overview
+
+Excalidraw MCP lets coding agents stream hand-drawn Excalidraw diagrams with smooth viewport camera control and interactive fullscreen editing. It renders diagrams as interactive HTML interfaces directly in the chat (MCP Apps).
+
+Official source:
+
+- [GitHub: excalidraw/excalidraw-mcp](https://github.com/excalidraw/excalidraw-mcp)
+- [Hosted server](https://mcp.excalidraw.com)
+
+## Features
+
+- **Hand-drawn diagrams**: Render architecture diagrams, flowcharts, wireframes, and illustrations in the signature Excalidraw hand-drawn style.
+- **Interactive editing**: Fullscreen editing with zoom, pan, and element manipulation.
+- **Smooth camera control**: Animated viewport transitions for diagram exploration.
+- **Streaming output**: Diagrams stream incrementally as they're drawn.
+- **No API key required**: The remote server requires no authentication.
+
+## When to Use
+
+Use Excalidraw MCP when you need to visualize:
+
+- System architecture diagrams and component relationships
+- Data flow diagrams showing how data moves through a system
+- Wireframes and UI mockups
+- Flowcharts and decision trees
+- Entity relationship diagrams
+- Any concept easier to understand visually than as text
+
+## Tools
+
+The server exposes a single tool — `draw` — which accepts a plain-text description of what to draw.
+
+| Tool | Description |
+| --- | --- |
+| `draw` | Draw an Excalidraw diagram from a text description |

package/framework/mcps/excalidraw/capabilities.md

@@ -0,0 +1,54 @@
+# Excalidraw MCP Capabilities
+
+## What It Can Do
+
+Excalidraw MCP renders hand-drawn style diagrams from text descriptions. It has a single tool — `draw` — that accepts natural language descriptions of what to draw.
+
+### The `draw` Tool
+
+| Aspect | Description |
+| --- | --- |
+| Input | Plain-text description of the diagram (e.g., "a user connecting to a server which talks to a database") |
+| Output | Interactive Excalidraw HTML interface in the chat |
+| Style | Hand-drawn (sketch-like) rendering |
+
+### What You Can Draw
+
+- **Architecture diagrams**: system components, services, databases, external integrations
+- **Flowcharts**: decision trees, process flows, state transitions
+- **Entity relationship diagrams**: tables, relationships, cardinality
+- **Wireframes**: UI layouts, screen mockups, component placement
+- **Network topology**: servers, clients, load balancers, network paths
+- **Concept maps**: relationships between ideas, hierarchies
+- **Sequence diagrams**: interaction flows between components
+
+## What It Cannot Do
+
+- It cannot modify existing diagrams (each `draw` call creates a new diagram).
+- It cannot export diagrams to image formats programmatically — use the interactive viewer's built-in export.
+- It cannot save diagrams to a file system — diagrams exist in the chat session.
+- It cannot render without an MCP Apps-compatible client.
+- It does not support authentication or access control — the remote server is public.
+- It cannot read or edit existing Excalidraw files (.excalidraw format).
+
+## Best Practices
+
+- Be specific in descriptions: include component names, relationships, and directional flow.
+- Request diagrams that clarify architectural concepts rather than trivial visual decoration.
+- Use the interactive viewer to zoom, pan, and adjust elements after rendering.
+- The diagram is best for conceptual understanding — use architecture diagrams, not pixel-perfect UI mockups.
+
+## Common Workflows
+
+### Architecture documentation
+
+1. Describe the system architecture (services, databases, clients, external APIs).
+2. Ask Excalidraw to render it as an architecture diagram.
+3. Use the interactive viewer to explore and adjust.
+4. Reference the diagram in design docs or ADRs.
+
+### Explaining design decisions
+
+1. Describe the current and proposed architecture.
+2. Ask Excalidraw to draw both for visual comparison.
+3. Annotate differences and tradeoffs on the rendered diagrams.

package/framework/mcps/excalidraw/configs/opencode.json

@@ -0,0 +1,8 @@
+{
+  "mcp": {
+    "excalidraw": {
+      "type": "remote",
+      "url": "https://mcp.excalidraw.com"
+    }
+  }
+}