Shadow Performance Engineer
Purpose
Performance and benchmarking — budgets, profiling mindset, and regression detection.
This skill provides operational guidance for Shadow Performance Engineer, including tool usage patterns, workflows, and quality expectations aligned with Syncolab skill standards.
When to Use
- Use when the user needs help with Shadow Performance Engineer.
- When integrations for this domain are available and the task matches the workflows below.
When NOT to Use
- When the task is unrelated to Shadow Performance Engineer or covered by a more specific skill.
- When required integrations or credentials are unavailable.
Expected Outcome
- Correct use of domain tools with verified results (not fabricated).
- Clear summary of actions taken, data returned, and recommended next steps.
- Errors and missing permissions reported explicitly.
Inputs to Gather
- User goal, constraints, and any identifiers (URLs, IDs, project keys).
- Available tool sets and connection status.
- Relevant context from related systems before destructive writes.
Workflow
- Confirm the request maps to Shadow Performance Engineer and required tools are available.
- Gather identifiers and scope (project, channel, repo, date range, etc.).
- Follow the domain guidance below; prefer list/search before get/update when applicable.
- Execute tool calls using schemas from the integration; never invent tool output.
- Summarize results and offer logical follow-ups.
Shadow Performance Engineer
- Set perf budgets (p95 latency, LCP, bundle size) when relevant
- Before/after for hot paths; avoid premature micro-opts
- Call out N+1, blocking IO, cache misses, oversized payloads
Output: findings with measured or estimated impact.
Tool Availability Rules
| Access |
Behavior |
| Full tool access |
Execute workflows, verify outputs, report errors. |
| Read-only |
Inspect and plan; provide exact commands or dispatch request for writes. |
| No integration |
State limitation; do not fabricate API results. |
Related tool sets
lighthousechrome-devtools
Review / Decision / Execution Criteria
- Prefer smallest safe change; confirm destructive actions with the user.
- Use evidence from tool responses; cite IDs and links when present.
- Match integration-specific conventions (JQL, RFC3339, A1 notation, etc.).
Output Format
Report:
- What was requested and what was done.
- Key results (tables or bullets).
- Errors, blockers, or missing permissions.
- Suggested next steps.
Quality Bar
- Specific, actionable, and grounded in tool output.
- Concise unless the user asked for detail.
- Respect rate limits, pagination, and API semantics.
Safety and Boundaries
- Do not commit secrets, tokens, or PII into skills or user-visible logs.
- Do not fabricate validation, send, or write confirmations.
- Confirm destructive operations (delete, destroy, mass update) when appropriate.
Escalation / Dispatch Rules
- If the task spans multiple domains, use or suggest related skills via
relationships.skills.
- If write access is required but unavailable, dispatch or ask the user to enable tools.
References
- Legacy content migrated from
skills/old_skills.json (shadow-perf-engineer).
skills/skill.instruction.md, skills/meta.instructions.md
1---2name: shadow-perf-engineer3description: Performance and benchmarking — budgets, profiling mindset, and regression detection.4---56# Shadow Performance Engineer78## Purpose910Performance and benchmarking — budgets, profiling mindset, and regression detection.1112This skill provides operational guidance for Shadow Performance Engineer, including tool usage patterns, workflows, and quality expectations aligned with Syncolab skill standards.1314## When to Use1516- Use when the user needs help with Shadow Performance Engineer.17- When integrations for this domain are available and the task matches the workflows below.1819## When NOT to Use2021- When the task is unrelated to Shadow Performance Engineer or covered by a more specific skill.22- When required integrations or credentials are unavailable.2324## Expected Outcome2526- Correct use of domain tools with verified results (not fabricated).27- Clear summary of actions taken, data returned, and recommended next steps.28- Errors and missing permissions reported explicitly.2930## Inputs to Gather3132- User goal, constraints, and any identifiers (URLs, IDs, project keys).33- Available tool sets and connection status.34- Relevant context from related systems before destructive writes.3536## Workflow37381. Confirm the request maps to Shadow Performance Engineer and required tools are available.392. Gather identifiers and scope (project, channel, repo, date range, etc.).403. Follow the domain guidance below; prefer list/search before get/update when applicable.414. Execute tool calls using schemas from the integration; never invent tool output.425. Summarize results and offer logical follow-ups.4344# Shadow Performance Engineer4546- Set perf budgets (p95 latency, LCP, bundle size) when relevant47- Before/after for hot paths; avoid premature micro-opts48- Call out N+1, blocking IO, cache misses, oversized payloads4950Output: findings with measured or estimated impact.5152## Tool Availability Rules5354| Access | Behavior |55|--------|----------|56| Full tool access | Execute workflows, verify outputs, report errors. |57| Read-only | Inspect and plan; provide exact commands or dispatch request for writes. |58| No integration | State limitation; do not fabricate API results. |5960### Related tool sets6162- `lighthouse`63- `chrome-devtools`64656667## Review / Decision / Execution Criteria6869- Prefer smallest safe change; confirm destructive actions with the user.70- Use evidence from tool responses; cite IDs and links when present.71- Match integration-specific conventions (JQL, RFC3339, A1 notation, etc.).7273## Output Format7475Report:76771. What was requested and what was done.782. Key results (tables or bullets).793. Errors, blockers, or missing permissions.804. Suggested next steps.8182## Quality Bar8384- Specific, actionable, and grounded in tool output.85- Concise unless the user asked for detail.86- Respect rate limits, pagination, and API semantics.8788## Safety and Boundaries8990- Do not commit secrets, tokens, or PII into skills or user-visible logs.91- Do not fabricate validation, send, or write confirmations.92- Confirm destructive operations (delete, destroy, mass update) when appropriate.9394## Escalation / Dispatch Rules9596- If the task spans multiple domains, use or suggest related skills via `relationships.skills`.97- If write access is required but unavailable, dispatch or ask the user to enable tools.9899## References100101- Legacy content migrated from `skills/old_skills.json` (`shadow-perf-engineer`).102- `skills/skill.instruction.md`, `skills/meta.instructions.md`
poly-gents