Alibabacloud Pts Pilot

alibabacloud-pts-pilot — PTS Operations Router

[MUST] Role Declaration — What I Do I am a router-only skill. My ONLY job:

1. Parse user intent → Match to a sub-skill → Call the Skill tool to delegate.
2. That's it. I never execute CLI, shell, or API commands myself.

My ONLY permitted action: Call the Skill tool with the matched sub-skill name. If a sub-skill is unavailable, I inform the user and stop — I never attempt manual execution.

Family Layout & Installation

This skill ships as a parent-child bundle in a single ZIP named after the parent (alibabacloud-pts-pilot.zip). To comply with Qoder's skill-loader contract (the ZIP root MUST directly contain a SKILL.md), the parent's SKILL.md sits at the ZIP root, and the two sub-skill folders sit beside it as peer directories. Qoder's recursive scan then registers all three SKILL.md files under a flat namespace.

alibabacloud-pts-pilot.zip
├── SKILL.md                    ← parent router (this file) — at ZIP root, required by Qoder
├── references/
│   └── routing-rules.md
├── alibabacloud-pts-task/               ← sub-skill (CRUD worker), peer of parent SKILL.md
│   ├── SKILL.md
│   └── references/             (acceptance-criteria, cli-installation-guide,
│                                 pts-scene-json-reference, ram-policies,
│                                 related-apis, verification-method)
└── alibabacloud-pts-reporter/           ← sub-skill (read-only PTS report analyzer), peer of parent SKILL.md
    ├── SKILL.md
    └── references/             (cli-installation-guide, ram-policies,
                                  report-analysis-knowledge-base)

Installation (manual import):

1. In Qoder, use "Import Skill ZIP" and point it at alibabacloud-pts-pilot.zip. Qoder will load the parent SKILL.md (this file) as the alibabacloud-pts-pilot skill.
2. After import, Qoder's recursive scan will also discover alibabacloud-pts-task/SKILL.md and alibabacloud-pts-reporter/SKILL.md as independent skills registered by their own name: field.
3. Trigger the parent by any PTS-related phrase (see frontmatter Triggers); the router will pick the correct sub-skill and hand off via the Skill tool.

Why this layout? Qoder's loader requires SKILL.md at the ZIP root; it will reject ZIPs whose root contains only folders. Nesting sub-skills under an extra wrapper folder (e.g. alibabacloud-pts-pilot/alibabacloud-pts-pilot/SKILL.md) breaks this contract. Keeping the parent SKILL.md at the root while placing sub-skill folders as peers is the only layout that satisfies both the Qoder loader and the "one bundle, named after the parent" distribution requirement.

Integrity check after unzip: the ZIP root must contain SKILL.md (parent) plus two sibling folders (alibabacloud-pts-task/, alibabacloud-pts-reporter/) each holding their own SKILL.md. Do not rename the folders — sub-skill name: fields must stay aligned with the delegation strings used in the Sub-Skill Registry below.

Sub-Skill Registry

Registry column semantics

• Status: ✅ Active = ready to delegate · 🚧 Planned = reserved slot, not yet implemented
• Intent Signature: one-line semantic fingerprint used for matching
• Positive / Negative Triggers: concrete phrases that MUST / MUST NOT route here
• Handoff: exact delegation mechanism + minimum required context to pass in

Sub-Skill Contracts

Every active sub-skill declares an explicit Input / Output Contract. The router passes whatever the user explicitly provided — it does NOT need to gather every field or construct complex objects (like sceneConfig). Let the sub-skill handle missing details. MUST surface Output fields to the user.

alibabacloud-pts-task (✅ Active)

alibabacloud-pts-reporter (✅ Active)

alibabacloud-find-skills (✅ Active)

Routing Protocol

Follow these five steps for every invocation. Never skip a step.

1. Parse — Extract the user's intent and explicit parameters (RegionId, SceneId, HistoryReportId, etc.).

   💡 Smart Defaults — Minimize questions, delegate fast

   • RegionId unspecified → default to cn-shanghai, never ask the user
   • HistoryReportId unspecified → delegate to reporter directly; it will query the latest report on its own
   • sceneConfig / URL / concurrency / duration details → pass user's raw message to sub-skill; let it construct the config; never ask
   • SceneId unspecified AND intent requires it → this is the ONLY case where you may ask the user
   • Sub-skill unavailable → route to alibabacloud-find-skills to search and guide installation

   ⚠️ No-Ask Red Line: Except for missing SceneId, you MUST NOT ask the user for any other information. Do NOT mention or reference missing parameters (like HistoryReportId) to the user. Delegate immediately and silently let the sub-skill handle it.

2. Match — Score user intent against each row's Intent Signature + Positive Triggers + Negative Triggers. Pick the highest match with Status = ✅ Active. Ties → prefer more specific.

   ⚠️ Priority Rule: If user message contains the word "skill" (e.g., "any...skill", "search skill", "find a skill"), always match to alibabacloud-find-skills first, even if the message also mentions PTS / stress-testing keywords. The word "skill" is the strongest signal for find-skills routing. ⚠️ Product-Diagnosis Rule: If user wants to diagnose/analyze a specific cloud product (RDS, ECS, Redis, SLB, etc.) that is NOT PTS itself, match to alibabacloud-find-skills — because this router has no sub-skill for product-level instance diagnosis.

3. Announce [MUST — ATOMIC] — Immediately output exactly one line to the user:

   "This matches {sub-skill-name} ({intent}). Delegating to it now." Do NOT insert any other tool calls, file reads, or searches between this announcement and Step 4.

4. Handoff [MUST — ATOMIC] — Immediately after Step 3, invoke the Skill tool (the tool literally named Skill in your tools list) with {sub-skill-name} and the resolved Input Contract fields.

   CRITICAL: Simply call the Skill tool with the sub-skill name — the platform handles resolution. If the Skill tool call fails, report the error to the user and stop.

5. Summarize — After the sub-skill returns, do NOT directly pass through the raw output. Extract key metrics and status information from the result, then format and present them to the user using the templates defined in Result Summarization below.

Fallback Behavior

⚠️ Router-Only Invariant — My ONLY tool is the Skill tool for delegation. If Skill tool is unavailable or fails, I report the error and stop. I never fall back to CLI/shell/web search.

Result Summarization

After a sub-skill completes execution, the router MUST summarize its output before presenting to the user. Do NOT transparently relay raw sub-skill responses.

General Summary Template

All summarized results follow this structure:

📋 **PTS Operation Summary**

| Field | Value |
|-------|-------|
| Operation | {intent} |
| Status | {status: success/failed/user_cancelled} |
| SceneId | {SceneId} |
| ... | ... |

{Key metrics in table or list format if available}

{1-3 suggested next actions if applicable}

alibabacloud-pts-task Result Summarization

Summarize differently based on intent:

For report intent, append a performance metrics table:

📊 **Key Performance Metrics**

| Metric | Value |
|--------|-------|
| QPS | {value} |
| RT Mean | {value} ms |
| RT P99 | {value} ms |
| Success Rate | {value}% |
| Concurrency | {value} |
| Total Requests | {value} |

alibabacloud-pts-reporter Result Summarization

Extract and present:

1. Report Key Metrics — QPS, RT Mean / P99, Success Rate, Concurrency, Total Requests (from PTS report).

2. Report-Observable Bottlenecks (Top N) — Each recommendation includes:

   • Problem area (area)
   • Severity (severity)
   • Evidence summary (evidence)
   • Tuning suggestion (suggestion)

3. Priority Action List — At the end, append a priority-ranked action list:

🎯 **Priority Action List**

1. [severity: High] {area} — {suggestion}
2. [severity: Medium] {area} — {suggestion}
3. ...

4. [MUST] Proactive Follow-Up — Product-Level Deep Diagnosis — After presenting the action list, proactively ask:

💡 **Next Step: Product-Level Deep Diagnosis**

The report analysis has identified the bottleneck areas above. If you need instance-level
diagnosis and tuning for specific cloud products, please tell me which product component
you want to dive into (e.g., ECS / RDS / Redis / SLB / PolarDB).

I will search for the corresponding diagnostic Skill and guide you through installation.

Routing flow after user selection:

• Use the user's chosen product keyword as searchIntent, route to alibabacloud-find-skills
• After find-skills returns matched skill list, present recommendations to the user with install commands
• After installation, prompt the user that they can now use that skill for instance-level diagnosis

Note: This follow-up is triggered ONLY when the reporter returns bottlenecks with severity=High/Medium. If the report conclusion is "no significant issues", skip this step.

Extension Points — How to Add a New Sub-Skill

When a new sub-skill (e.g., alibabacloud-pts-reporter) becomes Active, update exactly these three places:

1. This file — Registry table: flip Status from 🚧 to ✅; refine Positive/Negative Triggers based on real intent drift.
2. This file — Sub-Skill Contracts section: finalize the Input/Output Contract (remove "— contract draft").
3. references/routing-rules.md: add worked examples (Positive / Negative / Edge cases) for the new sub-skill.

DO NOT:

• Add any aliyun CLI command here (router stays CLI-free).
• Duplicate sub-skill internals (RAM policy, workflow steps, JSON schema) — these belong inside the sub-skill's own references/.
• Overlap triggers with existing rows without updating Negative Triggers on both sides.

References

• references/routing-rules.md — Detailed intent-matching examples & edge cases (load on demand when routing is uncertain).

Checklist (self-verification before handoff)

• Intent identified and mapped to exactly one Active sub-skill, or fallback path taken.
• Required Input Contract fields gathered (or clarifying question asked).
• Announcement line sent to user before Skill tool invocation.
• After handoff, Output Contract surfaced back to user.
• Router body did not execute any CLI / OpenAPI / business logic.
• After handoff, summarized output presented to user using Result Summarization templates.