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