Imported from asheeshsahu7300/AI-based-engineering-skills-library (070-database-performance/SKILL.md). Install upstream with npx skills add asheeshsahu7300/AI-based-engineering-skills-library --skill 070-database-performance. Copyright stays with the author.

Database Performance

Routing Description

Design, implement, analyze, optimize, test, troubleshoot, and verify database performance. Use this skill when the objective materially involves database performance, including architecture, implementation, integration, performance, reliability, security, compatibility, and operational tradeoffs relevant to the task.

Use When

• Building, changing, reviewing, debugging, or optimizing database performance.
• Evaluating architecture, implementation choices, tradeoffs, or failure modes involving database performance.
• Testing, measuring, validating, or productionizing work related to database performance.

Capabilities

• Database Performance architecture and design
• Database Performance implementation and integration
• Database Performance troubleshooting and debugging
• Database Performance testing and verification
• Database Performance performance and scalability analysis
• Database Performance security and reliability considerations
• Database Performance optimization and production readiness

Inputs

• User objective and constraints.
• Relevant repository, files, runtime, APIs, data, or design context.
• Existing conventions, dependencies, and acceptance criteria.
• Quality, security, performance, compatibility, cost, and delivery constraints when applicable.

Dependencies

• 050-10-foot-ui-design
• 072-database-observability
• 186-load-testing

Portable Execution Contract

1. Understand the objective and definition of done.
2. Inspect the current context before changing anything.
3. Select the smallest sufficient approach and activate only relevant dependencies.
4. Execute concrete actions and preserve observable evidence.
5. Verify behavior, edge cases, integration points, and quality attributes.
6. Diagnose failures from evidence, apply the narrowest robust fix, and retest.
7. Optimize only when the improvement is material and does not weaken correctness.
8. Finish when acceptance criteria are met or a genuine external blocker requires escalation.

Output Contract

Return the requested artifact/result plus concise evidence of what was changed or concluded, important assumptions, validation performed, remaining risks, and any required next action. Prefer structured output when the host supports schemas; otherwise use stable Markdown headings and bullets.

Autonomous Loop

Analyze → Inspect → Plan → Execute → Test → Measure → Diagnose → Fix → Retest → Verify → Deliver. Do not stop merely because the first implementation step succeeded. Continue until the definition of done is satisfied or a real blocker requires user input.

LLM Portability Rules

• Use plain language and Markdown; do not depend on hidden reasoning or provider-specific prompt syntax.
• Treat tools as capabilities supplied by the host; never assume a particular SDK, API, model, or tool name unless the task requires it.
• Pass observable decisions, artifacts, measurements, errors, and acceptance status between skills rather than private chain-of-thought.
• Prefer explicit inputs, outputs, decision rules, and verification criteria.
• When structured output is supported by the host, validate against the declared schema; otherwise fall back to deterministic Markdown.
• Keep provider-specific adapters outside the core skill.

Safety / Escalation

Do not perform destructive or irreversible actions without the authorization required by the host or task. Escalate when required credentials/resources are unavailable, ambiguity materially changes the outcome, or competing choices have materially different consequences.

Detailed Skill Playbook

Database Performance

Purpose

Apply this skill as a focused, composable capability. Treat the user's request as the objective, not as permission to stop after the first step. Inspect available context, choose the smallest sufficient approach, execute, verify, and iterate until the stated definition of done is satisfied.

Inputs

• User objective and constraints.
• Relevant repository, files, runtime, APIs, data, or design context when available.
• Existing conventions and dependencies.
• Required quality, security, performance, compatibility, and delivery constraints.

Workflow

1. Understand — identify the objective, constraints, assumptions, stakeholders, inputs, outputs, and definition of done.
2. Inspect — examine the existing implementation/context before changing anything; reuse established conventions where appropriate.
3. Plan — decompose the work into independently verifiable steps and activate only relevant dependent skills.
4. Execute — make the smallest coherent change or produce the requested artifact.
5. Verify — test behavior, edge cases, integration points, quality attributes, and regressions appropriate to the task.
6. Diagnose — if verification fails, identify the root cause rather than merely treating the symptom.
7. Fix — apply the narrowest robust correction and rerun affected checks.
8. Optimize — improve correctness, maintainability, performance, security, cost, and simplicity when materially relevant.
9. Finish — stop only when the definition of done is met or a genuine external blocker requires user input.

Decision Rules

• Prefer simple, composable solutions over unnecessary complexity.
• Preserve compatibility unless a breaking change is explicitly required.
• Do not invent unavailable facts, APIs, tool results, test results, or measurements.
• Distinguish verified facts, assumptions, estimates, and recommendations.
• For destructive, irreversible, security-sensitive, financial, or production-impacting actions, apply an appropriate safety/approval gate.
• When multiple technologies are viable, compare them against the actual workload instead of choosing by popularity.
• Optimize for the user's stated constraints before optimizing secondary concerns.

Dependency Activation

Potential upstream/downstream skills: 050, 072, 186.

Activate a dependency only when its expertise is actually needed. Pass compact structured handoffs: context, objective, constraints, artifacts, findings, requested action, acceptance criteria. Do not duplicate large context unnecessarily.

Verification

Before completion, verify as applicable:

• Functional correctness
• Edge cases and failure paths
• Integration compatibility
• Security and privacy
• Performance and scalability
• Accessibility/usability
• Maintainability and clarity
• Tests and regression risk
• Deployment/operational impact

LLM Portability

This skill is intentionally model-neutral. Do not depend on hidden chain-of-thought, proprietary prompt syntax, a specific model name, or a specific agent framework. Use explicit observable instructions, structured inputs/outputs, tool-neutral language, and concise state handoffs. If the host supports tools, use its native tool interface; otherwise provide executable steps or artifacts.

The skill should work with capable instruction-following models from different providers. Prefer deterministic schemas, clear success criteria, examples when ambiguity is likely, and progressive context loading.

Output Contract

Return or create the requested artifact/result, followed by a concise verification summary when useful:

• Result
• Changes/artifacts
• Verification
• Known limitations/blockers
• Recommended next action only when it is genuinely needed

Autonomous Loop

Do not ask “should I continue?” after a normal intermediate step. Continue through inspect → execute → verify → fix → verify until complete. Ask the user only when a missing decision or external dependency materially changes the correct outcome.