feat(skills): add shared task workflows
This commit is contained in:
@@ -0,0 +1,17 @@
|
|||||||
|
---
|
||||||
|
name: debugging
|
||||||
|
description: Investigate and resolve software defects using evidence.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Debugging
|
||||||
|
|
||||||
|
Use when behavior is incorrect, failing, or unexpectedly slow.
|
||||||
|
|
||||||
|
1. Reproduce or isolate the problem.
|
||||||
|
2. Gather evidence and identify the likely cause.
|
||||||
|
3. Apply the smallest complete fix.
|
||||||
|
4. Run relevant verification.
|
||||||
|
|
||||||
|
Return the cause, change, and verification result.
|
||||||
|
|
||||||
|
Do not guess when evidence can be collected.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: answer-pull-request
|
||||||
|
description: Prepare a clear response to pull request feedback.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Answer Pull Request
|
||||||
|
|
||||||
|
Understand each comment, make authorized changes, and respond with evidence.
|
||||||
|
|
||||||
|
Separate completed actions, explanations, and unresolved questions.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: review-pull-request
|
||||||
|
description: Review a pull request for correctness, risk, and readiness.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Review Pull Request
|
||||||
|
|
||||||
|
Inspect the change and its context independently.
|
||||||
|
|
||||||
|
Report actionable findings first, followed by verification status and open risks.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: integration-test-write
|
||||||
|
description: Add focused integration tests for connected system behavior.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Integration Test Write
|
||||||
|
|
||||||
|
Identify the integration boundary, required setup, and meaningful success and failure cases.
|
||||||
|
|
||||||
|
Keep the test deterministic and limited to the behavior under change.
|
||||||
@@ -0,0 +1,12 @@
|
|||||||
|
---
|
||||||
|
name: sql-write
|
||||||
|
description: Implement a focused SQL change safely.
|
||||||
|
---
|
||||||
|
|
||||||
|
# SQL Write
|
||||||
|
|
||||||
|
Understand the schema and affected data before writing SQL.
|
||||||
|
|
||||||
|
Use the smallest complete change, preserve data safety, and run relevant verification.
|
||||||
|
|
||||||
|
Do not execute destructive operations without explicit authorization.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: unit-test-write
|
||||||
|
description: Add focused unit tests for isolated behavior.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Unit Test Write
|
||||||
|
|
||||||
|
Identify the behavior and important boundary cases, then add focused deterministic tests.
|
||||||
|
|
||||||
|
Prefer observable behavior over implementation details. Report the checks that were run.
|
||||||
@@ -0,0 +1,12 @@
|
|||||||
|
---
|
||||||
|
name: change-impact-analysis
|
||||||
|
description: Determine what a proposed change may affect.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Change Impact Analysis
|
||||||
|
|
||||||
|
Use when the blast radius or compatibility impact is uncertain.
|
||||||
|
|
||||||
|
Inspect callers, dependencies, configuration, tests, and affected workflows.
|
||||||
|
|
||||||
|
Return affected areas, risks, and recommended verification. Separate facts from assumptions.
|
||||||
@@ -0,0 +1,12 @@
|
|||||||
|
---
|
||||||
|
name: implementation-planner
|
||||||
|
description: Create a concise plan for implementing an understood change.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Implementation Planner
|
||||||
|
|
||||||
|
Use before implementation when a change has multiple meaningful steps.
|
||||||
|
|
||||||
|
Identify the goal, affected areas, sequence, risks, and verification.
|
||||||
|
|
||||||
|
Return a short actionable plan. Do not implement the change.
|
||||||
@@ -0,0 +1,12 @@
|
|||||||
|
---
|
||||||
|
name: work-item-definition
|
||||||
|
description: Turn an unclear request into a bounded technical work item.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Work Item Definition
|
||||||
|
|
||||||
|
Use when requirements, scope, or acceptance criteria are incomplete.
|
||||||
|
|
||||||
|
Clarify the objective, boundaries, assumptions, acceptance criteria, and open questions.
|
||||||
|
|
||||||
|
Do not invent business requirements.
|
||||||
@@ -0,0 +1,12 @@
|
|||||||
|
---
|
||||||
|
name: repository-research
|
||||||
|
description: Investigate an existing repository to find relevant code and established patterns.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Repository Research
|
||||||
|
|
||||||
|
Use before changing an unfamiliar repository area.
|
||||||
|
|
||||||
|
Inspect relevant files, callers, tests, configuration, and established patterns.
|
||||||
|
|
||||||
|
Return evidence, affected areas, unknowns, and useful implementation context. Avoid modifying implementation code.
|
||||||
@@ -0,0 +1,12 @@
|
|||||||
|
---
|
||||||
|
name: technical-research
|
||||||
|
description: Investigate technical options and relevant evidence before implementation.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Technical Research
|
||||||
|
|
||||||
|
Use when an implementation depends on unfamiliar technology, APIs, tools, or trade-offs.
|
||||||
|
|
||||||
|
Gather relevant evidence, compare viable options, and identify unknowns.
|
||||||
|
|
||||||
|
Return concise findings with sources, assumptions, and a recommendation when appropriate. Do not implement the change.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: api-review
|
||||||
|
description: Review API changes for compatibility and contract clarity.
|
||||||
|
---
|
||||||
|
|
||||||
|
# API Review
|
||||||
|
|
||||||
|
Inspect request and response contracts, validation, errors, authorization, compatibility, and documentation.
|
||||||
|
|
||||||
|
Return concrete findings and affected consumers. Keep detailed API standards for future customization.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: business-review
|
||||||
|
description: Review a change against stated business intent and workflows.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Business Review
|
||||||
|
|
||||||
|
Check actors, workflows, domain concepts, invariants, edge cases, and acceptance criteria.
|
||||||
|
|
||||||
|
Separate stated requirements, evidence, and assumptions. Do not invent business requirements.
|
||||||
@@ -0,0 +1,12 @@
|
|||||||
|
---
|
||||||
|
name: code-review
|
||||||
|
description: Review code for correctness, maintainability, and regressions.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Code Review
|
||||||
|
|
||||||
|
Inspect the change independently and report concrete findings with severity and evidence.
|
||||||
|
|
||||||
|
Check behavior, regressions, maintainability, unnecessary complexity, and verification.
|
||||||
|
|
||||||
|
Do not modify code unless explicitly asked.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: efcore-review
|
||||||
|
description: Review Entity Framework Core changes for correctness and data access risks.
|
||||||
|
---
|
||||||
|
|
||||||
|
# EF Core Review
|
||||||
|
|
||||||
|
Inspect queries, relationships, tracking, migrations, transactions, and performance-sensitive access.
|
||||||
|
|
||||||
|
Return concrete findings and relevant verification. Keep detailed EF Core standards for future customization.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: performance-review
|
||||||
|
description: Review changes for meaningful performance risks.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Performance Review
|
||||||
|
|
||||||
|
Identify measurable or plausible bottlenecks in the changed paths.
|
||||||
|
|
||||||
|
Return evidence, expected impact, and proportionate recommendations. Avoid speculative optimization.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: security-review
|
||||||
|
description: Review changes for concrete security weaknesses.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Security Review
|
||||||
|
|
||||||
|
Inspect trust boundaries, input handling, authorization, secrets, permissions, and sensitive data.
|
||||||
|
|
||||||
|
Return evidence, impact, and actionable findings. Do not invent vulnerabilities without evidence.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: ui-ux-review
|
||||||
|
description: Review user interface changes for usability and consistency.
|
||||||
|
---
|
||||||
|
|
||||||
|
# UI UX Review
|
||||||
|
|
||||||
|
Inspect states, feedback, accessibility basics, consistency, and error handling.
|
||||||
|
|
||||||
|
Return concrete findings with affected user flows. Keep detailed design standards for future customization.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: wpf-review
|
||||||
|
description: Review WPF changes for correctness and maintainability.
|
||||||
|
---
|
||||||
|
|
||||||
|
# WPF Review
|
||||||
|
|
||||||
|
Inspect the changed WPF views, bindings, resources, commands, and lifecycle behavior.
|
||||||
|
|
||||||
|
Return concrete findings and relevant verification. Keep detailed WPF standards for future customization.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: facts-verification
|
||||||
|
description: Verify factual claims against available evidence.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Facts Verification
|
||||||
|
|
||||||
|
Check important claims against source code, documentation, commands, or other appropriate evidence.
|
||||||
|
|
||||||
|
Return the claim, evidence, and confidence. Mark unknowns explicitly.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: regression-verification
|
||||||
|
description: Check that existing behavior was not unintentionally broken.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Regression Verification
|
||||||
|
|
||||||
|
Identify the affected existing behavior and run proportionate regression checks.
|
||||||
|
|
||||||
|
Report results and any unverified areas. Do not claim checks that were not run.
|
||||||
@@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
name: work-item-verification
|
||||||
|
description: Verify that a work item meets its stated acceptance criteria.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Work Item Verification
|
||||||
|
|
||||||
|
Compare the completed change with its requirements and acceptance criteria.
|
||||||
|
|
||||||
|
Return passed criteria, failed criteria, checks run, and remaining limitations.
|
||||||
Reference in New Issue
Block a user