@archznn/crewloop-skills 0.1.0 → 0.2.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 +22 -0
- package/package.json +1 -1
- package/skills/architect/SKILL.md +302 -302
- package/skills/architect/references/templates/design-template.md +58 -58
- package/skills/architect/references/templates/proposal-template.md +30 -30
- package/skills/architect/references/templates/spec-delta-template.md +23 -23
- package/skills/architect/references/templates/tasks-template.md +28 -28
- package/skills/designer/SKILL.md +245 -245
- package/skills/docs-writer/SKILL.md +192 -192
- package/skills/engineer/SKILL.md +302 -302
- package/skills/maintainer/SKILL.md +102 -102
- package/skills/obsidian-second-brain/SKILL.md +263 -263
- package/skills/orchestrator/SKILL.md +346 -346
- package/skills/product-manager/SKILL.md +98 -98
- package/skills/researcher/SKILL.md +99 -99
- package/skills/reviewer/SKILL.md +297 -297
- package/skills/shipper/SKILL.md +433 -433
- package/skills/tester/SKILL.md +98 -98
|
@@ -1,58 +1,58 @@
|
|
|
1
|
-
# Design: [Change Name]
|
|
2
|
-
|
|
3
|
-
## Overview
|
|
4
|
-
[High-level summary of the approach]
|
|
5
|
-
|
|
6
|
-
## Proposed Directory & File Structure
|
|
7
|
-
```
|
|
8
|
-
[Insert a complete ASCII tree of the proposed directories and files to be added, modified, or removed.
|
|
9
|
-
Example:
|
|
10
|
-
my-project/
|
|
11
|
-
├── src/
|
|
12
|
-
│ ├── components/
|
|
13
|
-
│ │ └── NewComponent.tsx (New)
|
|
14
|
-
│ └── hooks/
|
|
15
|
-
│ │ └── useHook.ts (Modified)
|
|
16
|
-
└── tests/
|
|
17
|
-
└── NewComponent.test.tsx (New)
|
|
18
|
-
]
|
|
19
|
-
```
|
|
20
|
-
|
|
21
|
-
## Code Architecture & Design Patterns
|
|
22
|
-
- **Architecture Model:** [Describe the architecture of the solution, clean code boundaries, separation of concerns, e.g. Clean Architecture, Modular, DDD context]
|
|
23
|
-
- **Design Patterns Used:** [Name and justify the design patterns applied, e.g. Factory, Strategy, Observer, Repository pattern]
|
|
24
|
-
|
|
25
|
-
## Data Model
|
|
26
|
-
```typescript
|
|
27
|
-
// Core entities, value objects, types
|
|
28
|
-
interface Example {
|
|
29
|
-
id: string;
|
|
30
|
-
name: string;
|
|
31
|
-
}
|
|
32
|
-
```
|
|
33
|
-
|
|
34
|
-
## API Contracts
|
|
35
|
-
```typescript
|
|
36
|
-
// Interfaces, function signatures, schemas
|
|
37
|
-
interface ServiceContract {
|
|
38
|
-
method(input: Input): Promise<Output>;
|
|
39
|
-
}
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
## Flow Diagrams
|
|
43
|
-
### [Flow Name]
|
|
44
|
-
1. Step 1
|
|
45
|
-
2. Step 2
|
|
46
|
-
3. Step 3
|
|
47
|
-
|
|
48
|
-
## State Management
|
|
49
|
-
[Where state lives, how it flows]
|
|
50
|
-
|
|
51
|
-
## Error Handling
|
|
52
|
-
[Expected errors, fallback strategies]
|
|
53
|
-
|
|
54
|
-
## Performance Considerations
|
|
55
|
-
[Budgets, caching, optimization strategies]
|
|
56
|
-
|
|
57
|
-
## Security Considerations
|
|
58
|
-
[Auth, validation, sanitization]
|
|
1
|
+
# Design: [Change Name]
|
|
2
|
+
|
|
3
|
+
## Overview
|
|
4
|
+
[High-level summary of the approach]
|
|
5
|
+
|
|
6
|
+
## Proposed Directory & File Structure
|
|
7
|
+
```
|
|
8
|
+
[Insert a complete ASCII tree of the proposed directories and files to be added, modified, or removed.
|
|
9
|
+
Example:
|
|
10
|
+
my-project/
|
|
11
|
+
├── src/
|
|
12
|
+
│ ├── components/
|
|
13
|
+
│ │ └── NewComponent.tsx (New)
|
|
14
|
+
│ └── hooks/
|
|
15
|
+
│ │ └── useHook.ts (Modified)
|
|
16
|
+
└── tests/
|
|
17
|
+
└── NewComponent.test.tsx (New)
|
|
18
|
+
]
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## Code Architecture & Design Patterns
|
|
22
|
+
- **Architecture Model:** [Describe the architecture of the solution, clean code boundaries, separation of concerns, e.g. Clean Architecture, Modular, DDD context]
|
|
23
|
+
- **Design Patterns Used:** [Name and justify the design patterns applied, e.g. Factory, Strategy, Observer, Repository pattern]
|
|
24
|
+
|
|
25
|
+
## Data Model
|
|
26
|
+
```typescript
|
|
27
|
+
// Core entities, value objects, types
|
|
28
|
+
interface Example {
|
|
29
|
+
id: string;
|
|
30
|
+
name: string;
|
|
31
|
+
}
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## API Contracts
|
|
35
|
+
```typescript
|
|
36
|
+
// Interfaces, function signatures, schemas
|
|
37
|
+
interface ServiceContract {
|
|
38
|
+
method(input: Input): Promise<Output>;
|
|
39
|
+
}
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
## Flow Diagrams
|
|
43
|
+
### [Flow Name]
|
|
44
|
+
1. Step 1
|
|
45
|
+
2. Step 2
|
|
46
|
+
3. Step 3
|
|
47
|
+
|
|
48
|
+
## State Management
|
|
49
|
+
[Where state lives, how it flows]
|
|
50
|
+
|
|
51
|
+
## Error Handling
|
|
52
|
+
[Expected errors, fallback strategies]
|
|
53
|
+
|
|
54
|
+
## Performance Considerations
|
|
55
|
+
[Budgets, caching, optimization strategies]
|
|
56
|
+
|
|
57
|
+
## Security Considerations
|
|
58
|
+
[Auth, validation, sanitization]
|
|
@@ -1,30 +1,30 @@
|
|
|
1
|
-
# Proposal: [Change Name]
|
|
2
|
-
|
|
3
|
-
## Status
|
|
4
|
-
- **State:** draft | active | completed | cancelled
|
|
5
|
-
- **Created:** YYYY-MM-DD
|
|
6
|
-
- **Author:** @username
|
|
7
|
-
|
|
8
|
-
## Problem Statement
|
|
9
|
-
[What problem are we solving? Why does this matter?]
|
|
10
|
-
|
|
11
|
-
## Goals
|
|
12
|
-
1. [Primary goal]
|
|
13
|
-
2. [Secondary goal]
|
|
14
|
-
|
|
15
|
-
## Non-Goals
|
|
16
|
-
[What is explicitly out of scope?]
|
|
17
|
-
|
|
18
|
-
## Constraints
|
|
19
|
-
- [Technical constraint]
|
|
20
|
-
- [Business constraint]
|
|
21
|
-
- [Time constraint]
|
|
22
|
-
|
|
23
|
-
## Risks
|
|
24
|
-
| Risk | Impact | Mitigation |
|
|
25
|
-
|------|--------|------------|
|
|
26
|
-
| [Risk description] | High/Med/Low | [How we avoid or handle it] |
|
|
27
|
-
|
|
28
|
-
## Success Criteria
|
|
29
|
-
- [ ] [Measurable outcome 1]
|
|
30
|
-
- [ ] [Measurable outcome 2]
|
|
1
|
+
# Proposal: [Change Name]
|
|
2
|
+
|
|
3
|
+
## Status
|
|
4
|
+
- **State:** draft | active | completed | cancelled
|
|
5
|
+
- **Created:** YYYY-MM-DD
|
|
6
|
+
- **Author:** @username
|
|
7
|
+
|
|
8
|
+
## Problem Statement
|
|
9
|
+
[What problem are we solving? Why does this matter?]
|
|
10
|
+
|
|
11
|
+
## Goals
|
|
12
|
+
1. [Primary goal]
|
|
13
|
+
2. [Secondary goal]
|
|
14
|
+
|
|
15
|
+
## Non-Goals
|
|
16
|
+
[What is explicitly out of scope?]
|
|
17
|
+
|
|
18
|
+
## Constraints
|
|
19
|
+
- [Technical constraint]
|
|
20
|
+
- [Business constraint]
|
|
21
|
+
- [Time constraint]
|
|
22
|
+
|
|
23
|
+
## Risks
|
|
24
|
+
| Risk | Impact | Mitigation |
|
|
25
|
+
|------|--------|------------|
|
|
26
|
+
| [Risk description] | High/Med/Low | [How we avoid or handle it] |
|
|
27
|
+
|
|
28
|
+
## Success Criteria
|
|
29
|
+
- [ ] [Measurable outcome 1]
|
|
30
|
+
- [ ] [Measurable outcome 2]
|
|
@@ -1,23 +1,23 @@
|
|
|
1
|
-
# Spec Delta: [Domain Name]
|
|
2
|
-
|
|
3
|
-
## Current State
|
|
4
|
-
[What exists today]
|
|
5
|
-
|
|
6
|
-
## Changes
|
|
7
|
-
|
|
8
|
-
### ADDED
|
|
9
|
-
- [New component/function/feature]
|
|
10
|
-
- [New component/function/feature]
|
|
11
|
-
|
|
12
|
-
### MODIFIED
|
|
13
|
-
- [Existing thing] → [How it changes]
|
|
14
|
-
- [Existing thing] → [How it changes]
|
|
15
|
-
|
|
16
|
-
### REMOVED
|
|
17
|
-
- [Thing being deleted]
|
|
18
|
-
|
|
19
|
-
## Migration Notes
|
|
20
|
-
[How to migrate existing code/data]
|
|
21
|
-
|
|
22
|
-
## Backward Compatibility
|
|
23
|
-
[Breaking or non-breaking? How handled?]
|
|
1
|
+
# Spec Delta: [Domain Name]
|
|
2
|
+
|
|
3
|
+
## Current State
|
|
4
|
+
[What exists today]
|
|
5
|
+
|
|
6
|
+
## Changes
|
|
7
|
+
|
|
8
|
+
### ADDED
|
|
9
|
+
- [New component/function/feature]
|
|
10
|
+
- [New component/function/feature]
|
|
11
|
+
|
|
12
|
+
### MODIFIED
|
|
13
|
+
- [Existing thing] → [How it changes]
|
|
14
|
+
- [Existing thing] → [How it changes]
|
|
15
|
+
|
|
16
|
+
### REMOVED
|
|
17
|
+
- [Thing being deleted]
|
|
18
|
+
|
|
19
|
+
## Migration Notes
|
|
20
|
+
[How to migrate existing code/data]
|
|
21
|
+
|
|
22
|
+
## Backward Compatibility
|
|
23
|
+
[Breaking or non-breaking? How handled?]
|
|
@@ -1,28 +1,28 @@
|
|
|
1
|
-
# Tasks: [Change Name]
|
|
2
|
-
|
|
3
|
-
## Setup
|
|
4
|
-
- [ ] Create spec folder structure
|
|
5
|
-
- [ ] Initialize `.spec.yaml`
|
|
6
|
-
|
|
7
|
-
## Implementation
|
|
8
|
-
- [ ] [Task 1]
|
|
9
|
-
- [ ] [Task 2]
|
|
10
|
-
- [ ] [Task 3]
|
|
11
|
-
|
|
12
|
-
## Testing
|
|
13
|
-
- [ ] Unit tests for [component]
|
|
14
|
-
- [ ] Integration tests for [flow]
|
|
15
|
-
- [ ] Edge case: [case]
|
|
16
|
-
|
|
17
|
-
## Verification
|
|
18
|
-
- [ ] Run test suite: `[command]`
|
|
19
|
-
- [ ] Manual verification: [steps]
|
|
20
|
-
|
|
21
|
-
## Documentation
|
|
22
|
-
- [ ] Update living specs
|
|
23
|
-
- [ ] Update README if needed
|
|
24
|
-
- [ ] Add ADR if architectural decision made
|
|
25
|
-
|
|
26
|
-
## Completion
|
|
27
|
-
- [ ] Archive change folder
|
|
28
|
-
- [ ] Update `.spec.yaml` status to completed
|
|
1
|
+
# Tasks: [Change Name]
|
|
2
|
+
|
|
3
|
+
## Setup
|
|
4
|
+
- [ ] Create spec folder structure
|
|
5
|
+
- [ ] Initialize `.spec.yaml`
|
|
6
|
+
|
|
7
|
+
## Implementation
|
|
8
|
+
- [ ] [Task 1]
|
|
9
|
+
- [ ] [Task 2]
|
|
10
|
+
- [ ] [Task 3]
|
|
11
|
+
|
|
12
|
+
## Testing
|
|
13
|
+
- [ ] Unit tests for [component]
|
|
14
|
+
- [ ] Integration tests for [flow]
|
|
15
|
+
- [ ] Edge case: [case]
|
|
16
|
+
|
|
17
|
+
## Verification
|
|
18
|
+
- [ ] Run test suite: `[command]`
|
|
19
|
+
- [ ] Manual verification: [steps]
|
|
20
|
+
|
|
21
|
+
## Documentation
|
|
22
|
+
- [ ] Update living specs
|
|
23
|
+
- [ ] Update README if needed
|
|
24
|
+
- [ ] Add ADR if architectural decision made
|
|
25
|
+
|
|
26
|
+
## Completion
|
|
27
|
+
- [ ] Archive change folder
|
|
28
|
+
- [ ] Update `.spec.yaml` status to completed
|