prjct-cli 0.10.9 → 0.10.11
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/CHANGELOG.md +88 -0
- package/CLAUDE.md +121 -996
- package/core/__tests__/agentic/prompt-builder.test.js +7 -3
- package/core/agentic/prompt-builder.js +57 -56
- package/core/commands.js +29 -452
- package/core/domain/architecture-generator.js +51 -519
- package/core/domain/task-analyzer.js +11 -36
- package/package.json +1 -1
- package/templates/analysis/bug-severity.md +74 -0
- package/templates/analysis/complexity.md +54 -0
- package/templates/analysis/health.md +66 -0
- package/templates/analysis/intent.md +66 -0
- package/templates/analysis/patterns.md +27 -173
- package/templates/analysis/task-breakdown.md +53 -0
- package/templates/architect/discovery.md +67 -0
- package/templates/architect/phases.md +59 -0
- package/templates/commands/done.md +129 -15
- package/templates/commands/feature.md +262 -21
- package/templates/commands/ship.md +244 -23
- package/templates/commands/sync.md +235 -44
- package/templates/design/api.md +95 -0
- package/templates/design/architecture.md +77 -0
- package/templates/design/component.md +89 -0
- package/templates/design/database.md +78 -0
- package/templates/design/flow.md +94 -0
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: architecture-design
|
|
3
|
+
description: Design system architecture
|
|
4
|
+
allowed-tools: [Read, Glob, Grep]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Architecture Design
|
|
8
|
+
|
|
9
|
+
Design the system architecture for the given requirements.
|
|
10
|
+
|
|
11
|
+
## Input
|
|
12
|
+
- Target: {{target}}
|
|
13
|
+
- Requirements: {{requirements}}
|
|
14
|
+
- Project context
|
|
15
|
+
|
|
16
|
+
## Analysis Steps
|
|
17
|
+
|
|
18
|
+
1. **Understand Requirements**
|
|
19
|
+
- What problem are we solving?
|
|
20
|
+
- What are the constraints?
|
|
21
|
+
- What scale do we need?
|
|
22
|
+
|
|
23
|
+
2. **Review Existing Architecture**
|
|
24
|
+
- Read current codebase structure
|
|
25
|
+
- Identify existing patterns
|
|
26
|
+
- Note integration points
|
|
27
|
+
|
|
28
|
+
3. **Design Components**
|
|
29
|
+
- Core modules and responsibilities
|
|
30
|
+
- Data flow between components
|
|
31
|
+
- External dependencies
|
|
32
|
+
|
|
33
|
+
4. **Define Interfaces**
|
|
34
|
+
- API contracts
|
|
35
|
+
- Data structures
|
|
36
|
+
- Event/message formats
|
|
37
|
+
|
|
38
|
+
## Output Format
|
|
39
|
+
|
|
40
|
+
Generate markdown document:
|
|
41
|
+
|
|
42
|
+
```markdown
|
|
43
|
+
# Architecture: {target}
|
|
44
|
+
|
|
45
|
+
## Overview
|
|
46
|
+
Brief description of the architecture.
|
|
47
|
+
|
|
48
|
+
## Components
|
|
49
|
+
- **Component A**: Responsibility
|
|
50
|
+
- **Component B**: Responsibility
|
|
51
|
+
|
|
52
|
+
## Data Flow
|
|
53
|
+
```
|
|
54
|
+
[Diagram using ASCII or mermaid]
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
## Interfaces
|
|
58
|
+
### API Endpoints
|
|
59
|
+
- `GET /resource` - Description
|
|
60
|
+
- `POST /resource` - Description
|
|
61
|
+
|
|
62
|
+
### Data Models
|
|
63
|
+
- `Model`: { field: type }
|
|
64
|
+
|
|
65
|
+
## Dependencies
|
|
66
|
+
- External service X
|
|
67
|
+
- Library Y
|
|
68
|
+
|
|
69
|
+
## Decisions
|
|
70
|
+
- Decision 1: Rationale
|
|
71
|
+
- Decision 2: Rationale
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
## Guidelines
|
|
75
|
+
- Match existing project patterns
|
|
76
|
+
- Keep it simple - avoid over-engineering
|
|
77
|
+
- Document decisions and trade-offs
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: component-design
|
|
3
|
+
description: Design UI/code component
|
|
4
|
+
allowed-tools: [Read, Glob, Grep]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Component Design
|
|
8
|
+
|
|
9
|
+
Design a reusable component for the given requirements.
|
|
10
|
+
|
|
11
|
+
## Input
|
|
12
|
+
- Target: {{target}}
|
|
13
|
+
- Requirements: {{requirements}}
|
|
14
|
+
|
|
15
|
+
## Analysis Steps
|
|
16
|
+
|
|
17
|
+
1. **Understand Purpose**
|
|
18
|
+
- What does this component do?
|
|
19
|
+
- Where will it be used?
|
|
20
|
+
- What inputs/outputs?
|
|
21
|
+
|
|
22
|
+
2. **Review Existing Components**
|
|
23
|
+
- Read similar components
|
|
24
|
+
- Match project patterns
|
|
25
|
+
- Use existing utilities
|
|
26
|
+
|
|
27
|
+
3. **Design Interface**
|
|
28
|
+
- Props/parameters
|
|
29
|
+
- Events/callbacks
|
|
30
|
+
- State management
|
|
31
|
+
|
|
32
|
+
4. **Plan Implementation**
|
|
33
|
+
- File structure
|
|
34
|
+
- Dependencies
|
|
35
|
+
- Testing approach
|
|
36
|
+
|
|
37
|
+
## Output Format
|
|
38
|
+
|
|
39
|
+
```markdown
|
|
40
|
+
# Component: {ComponentName}
|
|
41
|
+
|
|
42
|
+
## Purpose
|
|
43
|
+
Brief description of what this component does.
|
|
44
|
+
|
|
45
|
+
## Props/Interface
|
|
46
|
+
| Prop | Type | Required | Default | Description |
|
|
47
|
+
|------|------|----------|---------|-------------|
|
|
48
|
+
| id | string | yes | - | Unique identifier |
|
|
49
|
+
| onClick | function | no | - | Click handler |
|
|
50
|
+
|
|
51
|
+
## State
|
|
52
|
+
- `isLoading`: boolean - Loading state
|
|
53
|
+
- `data`: array - Fetched data
|
|
54
|
+
|
|
55
|
+
## Events
|
|
56
|
+
- `onChange(value)`: Fired when value changes
|
|
57
|
+
- `onSubmit(data)`: Fired on form submit
|
|
58
|
+
|
|
59
|
+
## Usage Example
|
|
60
|
+
```jsx
|
|
61
|
+
<ComponentName
|
|
62
|
+
id="example"
|
|
63
|
+
onClick={handleClick}
|
|
64
|
+
/>
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
## File Structure
|
|
68
|
+
```
|
|
69
|
+
components/
|
|
70
|
+
└── ComponentName/
|
|
71
|
+
├── index.js
|
|
72
|
+
├── ComponentName.jsx
|
|
73
|
+
├── ComponentName.test.js
|
|
74
|
+
└── styles.css
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
## Dependencies
|
|
78
|
+
- Library X for Y
|
|
79
|
+
- Utility Z
|
|
80
|
+
|
|
81
|
+
## Testing
|
|
82
|
+
- Unit tests for logic
|
|
83
|
+
- Integration test for interactions
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
## Guidelines
|
|
87
|
+
- Match project component patterns
|
|
88
|
+
- Keep components focused
|
|
89
|
+
- Document all props
|
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: database-design
|
|
3
|
+
description: Design database schema
|
|
4
|
+
allowed-tools: [Read, Glob, Grep]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Database Design
|
|
8
|
+
|
|
9
|
+
Design database schema for the given requirements.
|
|
10
|
+
|
|
11
|
+
## Input
|
|
12
|
+
- Target: {{target}}
|
|
13
|
+
- Requirements: {{requirements}}
|
|
14
|
+
|
|
15
|
+
## Analysis Steps
|
|
16
|
+
|
|
17
|
+
1. **Identify Entities**
|
|
18
|
+
- What data needs to be stored?
|
|
19
|
+
- What are the relationships?
|
|
20
|
+
- What queries will be common?
|
|
21
|
+
|
|
22
|
+
2. **Review Existing Schema**
|
|
23
|
+
- Read current models/migrations
|
|
24
|
+
- Match naming conventions
|
|
25
|
+
- Use consistent patterns
|
|
26
|
+
|
|
27
|
+
3. **Design Tables/Collections**
|
|
28
|
+
- Fields and types
|
|
29
|
+
- Indexes for queries
|
|
30
|
+
- Constraints and defaults
|
|
31
|
+
|
|
32
|
+
4. **Plan Migrations**
|
|
33
|
+
- Order of operations
|
|
34
|
+
- Data transformations
|
|
35
|
+
- Rollback strategy
|
|
36
|
+
|
|
37
|
+
## Output Format
|
|
38
|
+
|
|
39
|
+
```markdown
|
|
40
|
+
# Database Design: {target}
|
|
41
|
+
|
|
42
|
+
## Entities
|
|
43
|
+
|
|
44
|
+
### users
|
|
45
|
+
| Column | Type | Constraints | Description |
|
|
46
|
+
|--------|------|-------------|-------------|
|
|
47
|
+
| id | uuid | PK | Unique identifier |
|
|
48
|
+
| email | varchar(255) | UNIQUE, NOT NULL | User email |
|
|
49
|
+
| created_at | timestamp | NOT NULL, DEFAULT now() | Creation time |
|
|
50
|
+
|
|
51
|
+
### posts
|
|
52
|
+
| Column | Type | Constraints | Description |
|
|
53
|
+
|--------|------|-------------|-------------|
|
|
54
|
+
| id | uuid | PK | Unique identifier |
|
|
55
|
+
| user_id | uuid | FK(users.id) | Author reference |
|
|
56
|
+
| title | varchar(255) | NOT NULL | Post title |
|
|
57
|
+
|
|
58
|
+
## Relationships
|
|
59
|
+
- users 1:N posts (one user has many posts)
|
|
60
|
+
|
|
61
|
+
## Indexes
|
|
62
|
+
- `users_email_idx` on users(email)
|
|
63
|
+
- `posts_user_id_idx` on posts(user_id)
|
|
64
|
+
|
|
65
|
+
## Migrations
|
|
66
|
+
1. Create users table
|
|
67
|
+
2. Create posts table with FK
|
|
68
|
+
3. Add indexes
|
|
69
|
+
|
|
70
|
+
## Queries (common)
|
|
71
|
+
- Get user by email: `SELECT * FROM users WHERE email = ?`
|
|
72
|
+
- Get user posts: `SELECT * FROM posts WHERE user_id = ?`
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## Guidelines
|
|
76
|
+
- Normalize appropriately
|
|
77
|
+
- Add indexes for common queries
|
|
78
|
+
- Document relationships clearly
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: flow-design
|
|
3
|
+
description: Design user/data flow
|
|
4
|
+
allowed-tools: [Read, Glob, Grep]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Flow Design
|
|
8
|
+
|
|
9
|
+
Design the user or data flow for the given feature.
|
|
10
|
+
|
|
11
|
+
## Input
|
|
12
|
+
- Target: {{target}}
|
|
13
|
+
- Requirements: {{requirements}}
|
|
14
|
+
|
|
15
|
+
## Analysis Steps
|
|
16
|
+
|
|
17
|
+
1. **Identify Actors**
|
|
18
|
+
- Who initiates the flow?
|
|
19
|
+
- What systems are involved?
|
|
20
|
+
- What are the touchpoints?
|
|
21
|
+
|
|
22
|
+
2. **Map Steps**
|
|
23
|
+
- Start to end journey
|
|
24
|
+
- Decision points
|
|
25
|
+
- Error scenarios
|
|
26
|
+
|
|
27
|
+
3. **Define States**
|
|
28
|
+
- Initial state
|
|
29
|
+
- Intermediate states
|
|
30
|
+
- Final state(s)
|
|
31
|
+
|
|
32
|
+
4. **Plan Error Handling**
|
|
33
|
+
- What can go wrong?
|
|
34
|
+
- Recovery paths
|
|
35
|
+
- User feedback
|
|
36
|
+
|
|
37
|
+
## Output Format
|
|
38
|
+
|
|
39
|
+
```markdown
|
|
40
|
+
# Flow: {target}
|
|
41
|
+
|
|
42
|
+
## Overview
|
|
43
|
+
Brief description of this flow.
|
|
44
|
+
|
|
45
|
+
## Actors
|
|
46
|
+
- **User**: Primary actor
|
|
47
|
+
- **System**: Backend services
|
|
48
|
+
- **External**: Third-party APIs
|
|
49
|
+
|
|
50
|
+
## Flow Diagram
|
|
51
|
+
```
|
|
52
|
+
[Start] → [Step 1] → [Decision?]
|
|
53
|
+
↓ Yes
|
|
54
|
+
[Step 2] → [End]
|
|
55
|
+
↓ No
|
|
56
|
+
[Error] → [Recovery]
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
## Steps
|
|
60
|
+
|
|
61
|
+
### 1. User Action
|
|
62
|
+
- User does X
|
|
63
|
+
- System validates Y
|
|
64
|
+
- **Success**: Continue to step 2
|
|
65
|
+
- **Error**: Show message, allow retry
|
|
66
|
+
|
|
67
|
+
### 2. Processing
|
|
68
|
+
- System processes data
|
|
69
|
+
- Calls external API
|
|
70
|
+
- Updates database
|
|
71
|
+
|
|
72
|
+
### 3. Completion
|
|
73
|
+
- Show success message
|
|
74
|
+
- Update UI state
|
|
75
|
+
- Log event
|
|
76
|
+
|
|
77
|
+
## Error Scenarios
|
|
78
|
+
| Error | Cause | Recovery |
|
|
79
|
+
|-------|-------|----------|
|
|
80
|
+
| Invalid input | Bad data | Show validation |
|
|
81
|
+
| API timeout | Network | Retry with backoff |
|
|
82
|
+
| Auth failed | Token expired | Redirect to login |
|
|
83
|
+
|
|
84
|
+
## States
|
|
85
|
+
- `idle`: Initial state
|
|
86
|
+
- `loading`: Processing
|
|
87
|
+
- `success`: Completed
|
|
88
|
+
- `error`: Failed
|
|
89
|
+
```
|
|
90
|
+
|
|
91
|
+
## Guidelines
|
|
92
|
+
- Cover happy path first
|
|
93
|
+
- Document all error cases
|
|
94
|
+
- Keep flows focused
|