aigent-team 0.2.0 → 0.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +150 -13
- package/dist/{chunk-U3NGK2UZ.js → chunk-OMO7OMKB.js} +264 -22
- package/dist/cli.js +1750 -217
- package/dist/index.d.ts +54 -0
- package/dist/index.js +1 -1
- package/package.json +1 -1
- package/templates/teams/ba/assets/story-template.md +49 -0
- package/templates/teams/ba/examples/acceptance-criteria.md +39 -0
- package/templates/teams/ba/output-contracts/user-story-rubric.md +33 -0
- package/templates/teams/ba/references/acceptance-criteria.md +7 -0
- package/templates/teams/ba/references/api-contract-design.md +7 -0
- package/templates/teams/ba/references/requirements-analysis.md +7 -0
- package/templates/teams/ba/references/user-story-mapping.md +7 -0
- package/templates/teams/ba/skills/requirement-validation.md +11 -0
- package/templates/teams/ba/skills/story-decomposition.md +16 -0
- package/templates/teams/be/references/api-design.md +7 -0
- package/templates/teams/be/references/async-processing.md +7 -0
- package/templates/teams/be/references/auth-security.md +7 -0
- package/templates/teams/be/references/caching.md +7 -0
- package/templates/teams/be/references/database.md +7 -0
- package/templates/teams/be/references/error-handling.md +7 -0
- package/templates/teams/be/references/observability.md +7 -0
- package/templates/teams/be/references/review-checklist.md +7 -0
- package/templates/teams/be/references/testing.md +7 -0
- package/templates/teams/be/skills/api-load-test.md +11 -0
- package/templates/teams/be/skills/database-migration.md +11 -0
- package/templates/teams/devops/references/ci-cd.md +7 -0
- package/templates/teams/devops/references/cost-optimization.md +7 -0
- package/templates/teams/devops/references/disaster-recovery.md +7 -0
- package/templates/teams/devops/references/docker.md +7 -0
- package/templates/teams/devops/references/infrastructure-as-code.md +7 -0
- package/templates/teams/devops/references/kubernetes.md +7 -0
- package/templates/teams/devops/references/monitoring.md +7 -0
- package/templates/teams/devops/references/review-checklist.md +7 -0
- package/templates/teams/devops/references/security.md +7 -0
- package/templates/teams/devops/scripts/health-check.sh +35 -0
- package/templates/teams/devops/skills/health-check.md +11 -0
- package/templates/teams/devops/skills/rollback-procedure.md +15 -0
- package/templates/teams/fe/examples/component-audit.md +35 -0
- package/templates/teams/fe/references/accessibility.md +7 -0
- package/templates/teams/fe/references/component-architecture.md +7 -0
- package/templates/teams/fe/references/css-styling.md +7 -0
- package/templates/teams/fe/references/forms.md +7 -0
- package/templates/teams/fe/references/performance.md +7 -0
- package/templates/teams/fe/references/review-checklist.md +7 -0
- package/templates/teams/fe/references/security.md +7 -0
- package/templates/teams/fe/references/state-management.md +7 -0
- package/templates/teams/fe/references/testing.md +7 -0
- package/templates/teams/fe/skills/analyze-bundle.md +16 -0
- package/templates/teams/fe/skills/component-audit.md +11 -0
- package/templates/teams/lead/references/cross-team-coordination.md +7 -0
- package/templates/teams/lead/references/quality-gates.md +7 -0
- package/templates/teams/lead/references/task-decomposition.md +7 -0
- package/templates/teams/lead/skills/parallel-orchestration.md +11 -0
- package/templates/teams/lead/skills/sprint-review.md +11 -0
- package/templates/teams/qa/assets/test-report-template.md +63 -0
- package/templates/teams/qa/output-contracts/test-plan-rubric.md +36 -0
- package/templates/teams/qa/references/ci-integration.md +7 -0
- package/templates/teams/qa/references/e2e-testing.md +7 -0
- package/templates/teams/qa/references/mocking.md +7 -0
- package/templates/teams/qa/references/performance-testing.md +7 -0
- package/templates/teams/qa/references/review-checklist.md +7 -0
- package/templates/teams/qa/references/security-testing.md +7 -0
- package/templates/teams/qa/references/test-data.md +7 -0
- package/templates/teams/qa/references/test-strategy.md +7 -0
- package/templates/teams/qa/skills/flaky-test-diagnosis.md +11 -0
- package/templates/teams/qa/skills/generate-test-data.md +15 -0
package/dist/index.d.ts
CHANGED
|
@@ -10,6 +10,15 @@ interface ReferenceFile {
|
|
|
10
10
|
description: string;
|
|
11
11
|
whenToRead: string;
|
|
12
12
|
content: string;
|
|
13
|
+
tags?: string[];
|
|
14
|
+
}
|
|
15
|
+
type GovernanceStatus = 'draft' | 'active' | 'review-needed' | 'deprecated';
|
|
16
|
+
interface GovernanceMetadata {
|
|
17
|
+
version?: string;
|
|
18
|
+
owner?: string;
|
|
19
|
+
status?: GovernanceStatus;
|
|
20
|
+
lastReviewedAt?: string;
|
|
21
|
+
deprecatedReason?: string;
|
|
13
22
|
}
|
|
14
23
|
interface SkillFile {
|
|
15
24
|
id: string;
|
|
@@ -17,6 +26,42 @@ interface SkillFile {
|
|
|
17
26
|
description: string;
|
|
18
27
|
trigger: string;
|
|
19
28
|
content: string;
|
|
29
|
+
useCases?: string[];
|
|
30
|
+
tags?: string[];
|
|
31
|
+
governance?: GovernanceMetadata;
|
|
32
|
+
}
|
|
33
|
+
interface ExampleFile {
|
|
34
|
+
id: string;
|
|
35
|
+
name: string;
|
|
36
|
+
description: string;
|
|
37
|
+
skillRef?: string;
|
|
38
|
+
content: string;
|
|
39
|
+
tags?: string[];
|
|
40
|
+
}
|
|
41
|
+
interface OutputContract {
|
|
42
|
+
id: string;
|
|
43
|
+
name: string;
|
|
44
|
+
description: string;
|
|
45
|
+
skillRef?: string;
|
|
46
|
+
format?: string;
|
|
47
|
+
content: string;
|
|
48
|
+
tags?: string[];
|
|
49
|
+
}
|
|
50
|
+
interface ScriptFile {
|
|
51
|
+
id: string;
|
|
52
|
+
name: string;
|
|
53
|
+
description: string;
|
|
54
|
+
language: string;
|
|
55
|
+
content: string;
|
|
56
|
+
tags?: string[];
|
|
57
|
+
}
|
|
58
|
+
interface AssetFile {
|
|
59
|
+
id: string;
|
|
60
|
+
name: string;
|
|
61
|
+
description: string;
|
|
62
|
+
format: string;
|
|
63
|
+
content: string;
|
|
64
|
+
tags?: string[];
|
|
20
65
|
}
|
|
21
66
|
interface TechStackConfig {
|
|
22
67
|
languages: string[];
|
|
@@ -49,6 +94,10 @@ interface AgentDefinition {
|
|
|
49
94
|
references: ReferenceFile[];
|
|
50
95
|
rulesContent: string;
|
|
51
96
|
skills: SkillFile[];
|
|
97
|
+
examples: ExampleFile[];
|
|
98
|
+
outputContracts: OutputContract[];
|
|
99
|
+
scripts: ScriptFile[];
|
|
100
|
+
assets: AssetFile[];
|
|
52
101
|
globs?: string[];
|
|
53
102
|
}
|
|
54
103
|
declare const ConfigSchema: z.ZodObject<{
|
|
@@ -141,10 +190,13 @@ declare const ConfigSchema: z.ZodObject<{
|
|
|
141
190
|
}>>;
|
|
142
191
|
output: z.ZodOptional<z.ZodObject<{
|
|
143
192
|
directory: z.ZodOptional<z.ZodString>;
|
|
193
|
+
pluginDir: z.ZodOptional<z.ZodString>;
|
|
144
194
|
}, "strip", z.ZodTypeAny, {
|
|
145
195
|
directory?: string | undefined;
|
|
196
|
+
pluginDir?: string | undefined;
|
|
146
197
|
}, {
|
|
147
198
|
directory?: string | undefined;
|
|
199
|
+
pluginDir?: string | undefined;
|
|
148
200
|
}>>;
|
|
149
201
|
}, "strip", z.ZodTypeAny, {
|
|
150
202
|
projectName: string;
|
|
@@ -176,6 +228,7 @@ declare const ConfigSchema: z.ZodObject<{
|
|
|
176
228
|
} | undefined;
|
|
177
229
|
output?: {
|
|
178
230
|
directory?: string | undefined;
|
|
231
|
+
pluginDir?: string | undefined;
|
|
179
232
|
} | undefined;
|
|
180
233
|
}, {
|
|
181
234
|
projectName: string;
|
|
@@ -207,6 +260,7 @@ declare const ConfigSchema: z.ZodObject<{
|
|
|
207
260
|
} | undefined;
|
|
208
261
|
output?: {
|
|
209
262
|
directory?: string | undefined;
|
|
263
|
+
pluginDir?: string | undefined;
|
|
210
264
|
} | undefined;
|
|
211
265
|
}>;
|
|
212
266
|
type AigentTeamConfig = z.infer<typeof ConfigSchema>;
|
package/dist/index.js
CHANGED
package/package.json
CHANGED
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: User Story Template
|
|
3
|
+
description: Standard template for writing user stories with acceptance criteria
|
|
4
|
+
format: markdown
|
|
5
|
+
tags: [ba, requirements, template]
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# User Story Template
|
|
9
|
+
|
|
10
|
+
## Story: [STORY-ID] [Title]
|
|
11
|
+
|
|
12
|
+
**Priority:** P0 / P1 / P2 / P3
|
|
13
|
+
**Complexity:** S / M / L / XL
|
|
14
|
+
**Epic:** [Epic name or link]
|
|
15
|
+
|
|
16
|
+
### Description
|
|
17
|
+
|
|
18
|
+
**As a** [user role]
|
|
19
|
+
**I want to** [goal or action]
|
|
20
|
+
**So that** [business value or benefit]
|
|
21
|
+
|
|
22
|
+
### Context
|
|
23
|
+
[Background information, business motivation, or technical context]
|
|
24
|
+
|
|
25
|
+
### Acceptance Criteria
|
|
26
|
+
|
|
27
|
+
#### AC-1: [Short description]
|
|
28
|
+
- **Given** [precondition]
|
|
29
|
+
- **When** [action]
|
|
30
|
+
- **Then** [expected result]
|
|
31
|
+
|
|
32
|
+
#### AC-2: [Short description]
|
|
33
|
+
- **Given** [precondition]
|
|
34
|
+
- **When** [action]
|
|
35
|
+
- **Then** [expected result]
|
|
36
|
+
|
|
37
|
+
### Out of Scope
|
|
38
|
+
- [Explicitly excluded items]
|
|
39
|
+
|
|
40
|
+
### Dependencies
|
|
41
|
+
- [Related stories, APIs, or external systems]
|
|
42
|
+
|
|
43
|
+
### Non-Functional Requirements
|
|
44
|
+
- **Performance:** [if applicable]
|
|
45
|
+
- **Security:** [if applicable]
|
|
46
|
+
- **Accessibility:** [if applicable]
|
|
47
|
+
|
|
48
|
+
### Notes
|
|
49
|
+
[Additional context, design links, or discussion points]
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Acceptance Criteria Example
|
|
3
|
+
description: Example of well-structured acceptance criteria for a user story
|
|
4
|
+
skillRef: story-decomposition
|
|
5
|
+
tags: [ba, requirements]
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Example: Acceptance Criteria
|
|
9
|
+
|
|
10
|
+
## User Story
|
|
11
|
+
|
|
12
|
+
**As a** logged-in user
|
|
13
|
+
**I want to** filter search results by date range
|
|
14
|
+
**So that** I can find relevant content from a specific time period
|
|
15
|
+
|
|
16
|
+
## Acceptance Criteria
|
|
17
|
+
|
|
18
|
+
### AC-1: Date range picker is displayed
|
|
19
|
+
- **Given** the user is on the search results page
|
|
20
|
+
- **When** they click the "Filter" button
|
|
21
|
+
- **Then** a date range picker appears with "Start Date" and "End Date" fields
|
|
22
|
+
|
|
23
|
+
### AC-2: Valid date range filters results
|
|
24
|
+
- **Given** the date range picker is visible
|
|
25
|
+
- **When** the user selects a start date of "2025-01-01" and end date of "2025-06-30"
|
|
26
|
+
- **And** clicks "Apply"
|
|
27
|
+
- **Then** only results within that date range are displayed
|
|
28
|
+
- **And** the active filter is shown as a chip/tag
|
|
29
|
+
|
|
30
|
+
### AC-3: Invalid date range shows error
|
|
31
|
+
- **Given** the date range picker is visible
|
|
32
|
+
- **When** the user selects a start date after the end date
|
|
33
|
+
- **Then** an inline error message reads "Start date must be before end date"
|
|
34
|
+
- **And** the "Apply" button is disabled
|
|
35
|
+
|
|
36
|
+
### AC-4: Clear filter restores all results
|
|
37
|
+
- **Given** a date range filter is active
|
|
38
|
+
- **When** the user clicks the "×" on the filter chip
|
|
39
|
+
- **Then** the filter is removed and all results are displayed again
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: User Story Quality Rubric
|
|
3
|
+
description: Self-validation checklist for BA agent user story output
|
|
4
|
+
format: checklist
|
|
5
|
+
tags: [ba, quality]
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Output Contract: User Story
|
|
9
|
+
|
|
10
|
+
Before delivering a user story, validate against this rubric:
|
|
11
|
+
|
|
12
|
+
## Structure (all required)
|
|
13
|
+
- [ ] Follows "As a [role], I want [goal], so that [benefit]" format
|
|
14
|
+
- [ ] Has a unique story ID
|
|
15
|
+
- [ ] Includes priority (P0/P1/P2/P3)
|
|
16
|
+
- [ ] Includes estimated complexity (S/M/L/XL)
|
|
17
|
+
|
|
18
|
+
## Acceptance Criteria (all required)
|
|
19
|
+
- [ ] At least 2 acceptance criteria per story
|
|
20
|
+
- [ ] Each AC uses Given/When/Then format
|
|
21
|
+
- [ ] Covers the happy path
|
|
22
|
+
- [ ] Covers at least one error/edge case
|
|
23
|
+
- [ ] No implementation details in AC (behavior only)
|
|
24
|
+
|
|
25
|
+
## Completeness
|
|
26
|
+
- [ ] Dependencies on other stories are listed
|
|
27
|
+
- [ ] Out-of-scope items are explicitly noted
|
|
28
|
+
- [ ] Non-functional requirements are included if applicable (performance, security)
|
|
29
|
+
|
|
30
|
+
## Quality Signals
|
|
31
|
+
- [ ] Story is independently testable
|
|
32
|
+
- [ ] Story delivers user-visible value
|
|
33
|
+
- [ ] AC are specific enough that two developers would implement the same behavior
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Writing Acceptance Criteria
|
|
3
|
+
description: Patterns and frameworks for writing testable, unambiguous acceptance criteria in Given/When/Then format.
|
|
4
|
+
whenToRead: When writing or reviewing acceptance criteria for user stories
|
|
5
|
+
tags: [ba, acceptance-criteria, given-when-then, testing]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Writing Acceptance Criteria
|
|
2
9
|
|
|
3
10
|
## Format: Given / When / Then
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: API Contract Design
|
|
3
|
+
description: Guidelines for defining API contracts between frontend and backend before implementation begins.
|
|
4
|
+
whenToRead: When designing or reviewing API contracts for FE/BE alignment
|
|
5
|
+
tags: [ba, api-contract, integration, specification]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# API Contract Design
|
|
2
9
|
|
|
3
10
|
## Purpose
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Requirements Analysis
|
|
3
|
+
description: Structured framework for breaking down business requirements into scope, assumptions, and dependencies.
|
|
4
|
+
whenToRead: When analyzing a new feature request or breaking down business requirements
|
|
5
|
+
tags: [ba, requirements, analysis, scoping]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Requirements Analysis
|
|
2
9
|
|
|
3
10
|
## Analysis Framework
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: User Story Mapping
|
|
3
|
+
description: Techniques for organizing user stories into activity hierarchies and prioritizing MVP scope.
|
|
4
|
+
whenToRead: When mapping user journeys, decomposing epics, or prioritizing stories for MVP
|
|
5
|
+
tags: [ba, user-stories, story-mapping, prioritization]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# User Story Mapping
|
|
2
9
|
|
|
3
10
|
## Story Map Structure
|
|
@@ -1,3 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Requirement Validation
|
|
3
|
+
description: Validate that requirements are complete, consistent, feasible, and testable before development begins
|
|
4
|
+
trigger: When validating that requirements are complete, consistent, and implementable before development starts.
|
|
5
|
+
useCases:
|
|
6
|
+
- BA Agent reviewing a new feature spec before handing off to engineering
|
|
7
|
+
- Lead Agent gating a sprint to ensure all stories meet quality criteria
|
|
8
|
+
- QA Agent verifying that acceptance criteria are testable and unambiguous
|
|
9
|
+
tags: [ba, requirements, validation, quality]
|
|
10
|
+
---
|
|
11
|
+
|
|
1
12
|
# Skill: Requirement Validation
|
|
2
13
|
|
|
3
14
|
**Trigger**: When validating that requirements are complete, consistent, and implementable before development starts.
|
|
@@ -1,3 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Story Decomposition
|
|
3
|
+
description: Break epics into implementable user stories using vertical slicing and INVEST criteria
|
|
4
|
+
trigger: When breaking an epic or large feature into implementable user stories.
|
|
5
|
+
useCases:
|
|
6
|
+
- BA Agent decomposing epics for sprint planning
|
|
7
|
+
- Lead Agent requesting story breakdown for a feature
|
|
8
|
+
- BA Agent preparing a backlog refinement session with the team
|
|
9
|
+
tags: [ba, planning, user-stories, decomposition]
|
|
10
|
+
governance:
|
|
11
|
+
version: "1.1.0"
|
|
12
|
+
owner: ba-team
|
|
13
|
+
status: review-needed
|
|
14
|
+
lastReviewedAt: "2025-01-10"
|
|
15
|
+
---
|
|
16
|
+
|
|
1
17
|
# Skill: Story Decomposition
|
|
2
18
|
|
|
3
19
|
**Trigger**: When breaking an epic or large feature into implementable user stories.
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: API Design
|
|
3
|
+
description: Standards for RESTful URL structure, HTTP status codes, and API endpoint conventions.
|
|
4
|
+
whenToRead: When designing or implementing REST API endpoints
|
|
5
|
+
tags: [be, api, rest, http]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# API Design
|
|
2
9
|
|
|
3
10
|
## RESTful URL Structure
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Async Processing
|
|
3
|
+
description: Guidelines for queue-based job design, idempotency, and handling long-running background tasks.
|
|
4
|
+
whenToRead: When implementing background jobs, message queues, or asynchronous workflows
|
|
5
|
+
tags: [be, async, queues, jobs]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Async Processing
|
|
2
9
|
|
|
3
10
|
## When to Use Queues
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Authentication & Security
|
|
3
|
+
description: Standards for JWT authentication, authorization, password storage, and common security hardening practices.
|
|
4
|
+
whenToRead: When implementing authentication, authorization, or reviewing security concerns
|
|
5
|
+
tags: [be, security, authentication, authorization]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Authentication & Security
|
|
2
9
|
|
|
3
10
|
## Authentication
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Caching
|
|
3
|
+
description: Cache strategy selection, key design patterns, and invalidation approaches for backend services.
|
|
4
|
+
whenToRead: When adding or reviewing caching layers for performance optimization
|
|
5
|
+
tags: [be, caching, performance, redis]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Caching
|
|
2
9
|
|
|
3
10
|
## Strategy Selection
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Database
|
|
3
|
+
description: Schema standards, indexing rules, query optimization, and migration best practices for relational databases.
|
|
4
|
+
whenToRead: When designing schemas, writing migrations, or optimizing database queries
|
|
5
|
+
tags: [be, database, schema, indexing]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Database
|
|
2
9
|
|
|
3
10
|
## Schema Standards
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Error Handling & Resilience
|
|
3
|
+
description: Patterns for domain error hierarchies, HTTP status mapping, and building resilient backend services.
|
|
4
|
+
whenToRead: When implementing error handling, retry logic, or resilience patterns
|
|
5
|
+
tags: [be, error-handling, resilience, reliability]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Error Handling & Resilience
|
|
2
9
|
|
|
3
10
|
## Domain Error Hierarchy
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Observability
|
|
3
|
+
description: Standards for structured logging, distributed tracing, and metrics collection across backend services.
|
|
4
|
+
whenToRead: When adding logging, tracing, metrics, or setting up monitoring for a service
|
|
5
|
+
tags: [be, observability, logging, monitoring]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Observability
|
|
2
9
|
|
|
3
10
|
## Three Pillars
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Backend Review Checklist
|
|
3
|
+
description: Comprehensive checklist covering API contracts, data layer, security, and performance for backend code reviews.
|
|
4
|
+
whenToRead: When reviewing backend pull requests or performing pre-merge quality checks
|
|
5
|
+
tags: [be, code-review, checklist, quality]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Backend Review Checklist
|
|
2
9
|
|
|
3
10
|
### API Contract
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Backend Testing
|
|
3
|
+
description: Test level guidelines covering unit, integration, and end-to-end testing strategies for backend services.
|
|
4
|
+
whenToRead: When writing or reviewing backend tests at any level of the test pyramid
|
|
5
|
+
tags: [be, testing, unit-tests, integration-tests]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Backend Testing
|
|
2
9
|
|
|
3
10
|
## Test Levels
|
|
@@ -1,3 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: API Load Test
|
|
3
|
+
description: Validate endpoint performance under load using k6, autocannon, or hey and analyze bottlenecks
|
|
4
|
+
trigger: When validating endpoint performance under load, before a release with traffic expectations, or investigating latency issues.
|
|
5
|
+
useCases:
|
|
6
|
+
- BE Agent benchmarking a new endpoint before production release
|
|
7
|
+
- QA Agent running performance regression tests in CI
|
|
8
|
+
- DevOps Agent investigating latency spikes in a production service
|
|
9
|
+
tags: [be, performance, load-testing, benchmarking]
|
|
10
|
+
---
|
|
11
|
+
|
|
1
12
|
# Skill: API Load Test
|
|
2
13
|
|
|
3
14
|
**Trigger**: When validating endpoint performance under load, before a release with traffic expectations, or investigating latency issues.
|
|
@@ -1,3 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Database Migration
|
|
3
|
+
description: Safely execute schema changes including new tables, column modifications, index additions, and data migrations
|
|
4
|
+
trigger: When schema changes are needed — new tables, column changes, index additions, or data migrations.
|
|
5
|
+
useCases:
|
|
6
|
+
- BE Agent adding a new table or column for a feature
|
|
7
|
+
- Lead Agent reviewing a migration plan for a large-table schema change
|
|
8
|
+
- DevOps Agent coordinating a zero-downtime migration in production
|
|
9
|
+
tags: [be, database, migration, schema]
|
|
10
|
+
---
|
|
11
|
+
|
|
1
12
|
# Skill: Database Migration
|
|
2
13
|
|
|
3
14
|
**Trigger**: When schema changes are needed — new tables, column changes, index additions, or data migrations.
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: CI/CD Pipeline Design
|
|
3
|
+
description: Pipeline architecture patterns, stage ordering, caching strategies, and deployment automation.
|
|
4
|
+
whenToRead: When designing, reviewing, or troubleshooting CI/CD pipelines
|
|
5
|
+
tags: [devops, ci-cd, automation, deployment]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# CI/CD Reference
|
|
2
9
|
|
|
3
10
|
## Pipeline Stages
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Cost Optimization
|
|
3
|
+
description: Right-sizing strategies, reserved capacity planning, storage lifecycle policies, and budget alerting.
|
|
4
|
+
whenToRead: When reviewing cloud spend, right-sizing resources, or setting up cost controls
|
|
5
|
+
tags: [devops, cost, cloud, optimization]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Cost Optimization Reference
|
|
2
9
|
|
|
3
10
|
## Right-Sizing
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Disaster Recovery
|
|
3
|
+
description: RPO/RTO tier definitions, backup strategies, failover procedures, and chaos engineering practices.
|
|
4
|
+
whenToRead: When planning DR strategy, configuring backups, or running failover tests
|
|
5
|
+
tags: [devops, disaster-recovery, backups, failover]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Disaster Recovery Reference
|
|
2
9
|
|
|
3
10
|
## RPO / RTO Tiers
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Docker Best Practices
|
|
3
|
+
description: Base image selection, multi-stage builds, layer optimization, and container security hardening.
|
|
4
|
+
whenToRead: When writing or reviewing Dockerfiles and container configurations
|
|
5
|
+
tags: [devops, docker, containers, images]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Docker Reference
|
|
2
9
|
|
|
3
10
|
## Base Image Selection
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Infrastructure as Code
|
|
3
|
+
description: Terraform directory structure, state management, module design, and resource tagging standards.
|
|
4
|
+
whenToRead: When writing or reviewing Terraform/IaC configurations and modules
|
|
5
|
+
tags: [devops, terraform, iac, modules]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Infrastructure as Code Reference
|
|
2
9
|
|
|
3
10
|
## Terraform Directory Structure
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Kubernetes Operations
|
|
3
|
+
description: Namespace strategy, resource management, probes, PodDisruptionBudgets, network policies, and secrets handling.
|
|
4
|
+
whenToRead: When creating or reviewing Kubernetes manifests and cluster configurations
|
|
5
|
+
tags: [devops, kubernetes, orchestration, manifests]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Kubernetes Reference
|
|
2
9
|
|
|
3
10
|
## Namespace Strategy
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Monitoring and Observability
|
|
3
|
+
description: Metrics, logs, and traces instrumentation with golden signal alerting and runbook standards.
|
|
4
|
+
whenToRead: When setting up monitoring, defining alerts, or instrumenting services
|
|
5
|
+
tags: [devops, monitoring, observability, alerting]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Monitoring and Observability Reference
|
|
2
9
|
|
|
3
10
|
## Three Pillars
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: DevOps Review Checklist
|
|
3
|
+
description: Comprehensive PR review checklist covering IaC, Docker, Kubernetes, CI/CD, security, and monitoring changes.
|
|
4
|
+
whenToRead: When reviewing pull requests that include infrastructure or deployment changes
|
|
5
|
+
tags: [devops, review, checklist, quality]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# DevOps Review Checklist
|
|
2
9
|
|
|
3
10
|
Use this checklist when reviewing infrastructure, deployment, and platform
|
|
@@ -1,3 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Infrastructure Security
|
|
3
|
+
description: Least-privilege IAM patterns, network segmentation, secrets rotation, image scanning, and audit logging.
|
|
4
|
+
whenToRead: When configuring IAM policies, network rules, secrets management, or security scanning
|
|
5
|
+
tags: [devops, security, iam, secrets]
|
|
6
|
+
---
|
|
7
|
+
|
|
1
8
|
# Security Reference
|
|
2
9
|
|
|
3
10
|
## Least Privilege IAM
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Service Health Check
|
|
3
|
+
description: Script to verify service health endpoints after deployment
|
|
4
|
+
language: bash
|
|
5
|
+
tags: [devops, deployment, monitoring]
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
#!/usr/bin/env bash
|
|
9
|
+
# Service Health Check Script
|
|
10
|
+
# Usage: ./health-check.sh <base-url> [timeout-seconds]
|
|
11
|
+
|
|
12
|
+
set -euo pipefail
|
|
13
|
+
|
|
14
|
+
BASE_URL="${1:?Usage: $0 <base-url> [timeout-seconds]}"
|
|
15
|
+
TIMEOUT="${2:-30}"
|
|
16
|
+
INTERVAL=2
|
|
17
|
+
ELAPSED=0
|
|
18
|
+
|
|
19
|
+
echo "Checking health at: ${BASE_URL}/health"
|
|
20
|
+
|
|
21
|
+
while [ "$ELAPSED" -lt "$TIMEOUT" ]; do
|
|
22
|
+
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "${BASE_URL}/health" 2>/dev/null || echo "000")
|
|
23
|
+
|
|
24
|
+
if [ "$STATUS" = "200" ]; then
|
|
25
|
+
echo "Service is healthy (HTTP 200) after ${ELAPSED}s"
|
|
26
|
+
exit 0
|
|
27
|
+
fi
|
|
28
|
+
|
|
29
|
+
echo "Status: ${STATUS} — retrying in ${INTERVAL}s (${ELAPSED}/${TIMEOUT}s)"
|
|
30
|
+
sleep "$INTERVAL"
|
|
31
|
+
ELAPSED=$((ELAPSED + INTERVAL))
|
|
32
|
+
done
|
|
33
|
+
|
|
34
|
+
echo "ERROR: Service did not become healthy within ${TIMEOUT}s"
|
|
35
|
+
exit 1
|
|
@@ -1,3 +1,14 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Health Check Verification
|
|
3
|
+
description: Verify service health after deployment by checking endpoints, dependencies, resources, and critical paths
|
|
4
|
+
trigger: When verifying service health after deployment, setting up monitoring, or debugging availability issues.
|
|
5
|
+
useCases:
|
|
6
|
+
- DevOps Agent running post-deployment verification checks
|
|
7
|
+
- QA Agent confirming service readiness before running E2E tests
|
|
8
|
+
- DevOps Agent triaging an availability alert in production
|
|
9
|
+
tags: [devops, monitoring, health-check, deployment]
|
|
10
|
+
---
|
|
11
|
+
|
|
1
12
|
# Skill: Health Check Verification
|
|
2
13
|
|
|
3
14
|
**Trigger**: When verifying service health after deployment, setting up monitoring, or debugging availability issues.
|
|
@@ -1,3 +1,18 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: Rollback Procedure
|
|
3
|
+
description: Revert a deployment due to errors, performance regression, or unexpected behavior in production
|
|
4
|
+
trigger: When a deployment needs to be reverted due to errors, performance regression, or unexpected behavior in production.
|
|
5
|
+
useCases:
|
|
6
|
+
- DevOps Agent reverting a broken deployment in production
|
|
7
|
+
- Lead Agent coordinating an emergency rollback during an incident
|
|
8
|
+
- DevOps Agent executing a planned rollback after failed canary analysis
|
|
9
|
+
tags: [devops, rollback, deployment, incident-response]
|
|
10
|
+
governance:
|
|
11
|
+
version: "0.9.0"
|
|
12
|
+
owner: devops-team
|
|
13
|
+
status: draft
|
|
14
|
+
---
|
|
15
|
+
|
|
1
16
|
# Skill: Rollback Procedure
|
|
2
17
|
|
|
3
18
|
**Trigger**: When a deployment needs to be reverted due to errors, performance regression, or unexpected behavior in production.
|