Develop, modify, debug, and maintain the next-generation SRS media server written in Go — including the proxy, origin, and edge servers. This is the AI-maintained successor to the first-generation C++ SRS server. Use for all development tasks, for example, adding features, fixing bugs, refactoring code, understanding code architecture, reviewing changes, and writing tests for the Go codebase. NOT for end-user support, usage questions, configuration help, or learning how to use SRS — use the srs-support skill for those. Only activate when the task is explicitly about developing or modifying the Go SRS codebase.
Code and documents are the only truth. Issue descriptions may be inaccurate. Pull requests may be misleading. Feature descriptions may be insufficient. Always ground your understanding in the actual source code and project documentation. Documents capture design intent, architecture rationale, and complex background that code alone cannot express — they are another form of code. When code and documents conflict, investigate rather than assume one is wrong.
⚠️ MANDATORY — Always execute this step first. Never skip the Task Router. Never jump directly to a task. Every request must be routed through this table before any work begins.
Route the user's request to exactly ONE task type. Follow that task only. Do not combine tasks.
| Task | When | Route To | Status |
|---|---|---|---|
| Develop Code | User wants to add, modify, refactor code, or update docs — any planned change | → Develop Code |
| ✅ Supported |
| Fix a Bug | User reports something broken, unexpected behavior, or an error | → Fix a Bug | ❌ Not yet supported |
| Learn Code | User wants to understand how code works — no changes intended | → Learn Code | ❌ Not yet supported |
| Review a PR | User wants to review an existing pull request | → Review a PR | ❌ Not yet supported |
If the routed task is not yet supported, stop and tell the user:
Do NOT attempt unsupported tasks.
Prerequisite: You must arrive here via the Task Router. Do not execute this task directly — always complete the Task Router first to confirm this is the correct task type.
Not yet supported. Will be added in a future update.
Prerequisite: You must arrive here via the Task Router. Do not execute this task directly — always complete the Task Router first to confirm this is the correct task type.
Not yet supported. Will be added in a future update.
Prerequisite: You must arrive here via the Task Router. Do not execute this task directly — always complete the Task Router first to confirm this is the correct task type.
Not yet supported. Will be added in a future update.
Prerequisite: You must arrive here via the Task Router. Do not execute this task directly — always complete the Task Router first to confirm this is the correct task type.
Scope: This task covers any planned code or documentation change — adding new features, modifying existing functionality, refactoring code, and updating documentation.
Important: The C++ media server (origin + edge) is in maintenance mode — only bug fixes are accepted, no new features. All new feature development happens in the next-generation Go server. You may reference the C++ server's code to understand how things were done before, but do not add features to it.
Service Router — Determine which Go service the feature targets. Route to exactly ONE service. Do not guess — if unclear, ask the user to clarify.
| Service | Route To | Status |
|---|---|---|
| Proxy server | → Proxy Server | ✅ Supported |
| Origin server | → Origin Server | ✅ Supported |
| Edge server | → Edge Server | ❌ Not yet supported |
If the routed service is not yet supported, stop and tell the user:
The proxy server is a complex, growing product — not a small app. It has many modules, and more will be added over time. You cannot load all the code into context at once. The key to working on it is routing to the correct module first.
Step 1: Module Routing (MANDATORY)
memory/srs-codebase-map.md — both the Next-Generation Server Code section (code modules: cmd/ + internal/) and the Next-Generation Server Docs section (documentation: docs/proxy/).Only after the user confirms the routing do you proceed to Step 2.
Step 2: Understand the Module
Step 3: Implement and Verify
bash scripts/proxy-utest.sh
bash scripts/proxy-e2e-test.sh
All script paths are relative to this skill's directory.
(workflow steps to be defined)
Not yet supported. Will be added in a future update.