@northbridge-security/secureai 0.1.13
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/.claude/README.md +122 -0
- package/.claude/commands/architect/clean.md +978 -0
- package/.claude/commands/architect/kiss.md +762 -0
- package/.claude/commands/architect/review.md +704 -0
- package/.claude/commands/catchup.md +90 -0
- package/.claude/commands/code.md +115 -0
- package/.claude/commands/commit.md +1218 -0
- package/.claude/commands/cover.md +1298 -0
- package/.claude/commands/fmea.md +275 -0
- package/.claude/commands/kaizen.md +312 -0
- package/.claude/commands/pr.md +503 -0
- package/.claude/commands/todo.md +99 -0
- package/.claude/commands/worktree.md +738 -0
- package/.claude/commands/wrapup.md +103 -0
- package/LICENSE +183 -0
- package/README.md +108 -0
- package/dist/cli.js +75634 -0
- package/docs/agents/devops-reviewer.md +889 -0
- package/docs/agents/kiss-simplifier.md +1088 -0
- package/docs/agents/typescript.md +8 -0
- package/docs/guides/README.md +109 -0
- package/docs/guides/agents.clean.arch.md +244 -0
- package/docs/guides/agents.clean.arch.ts.md +1314 -0
- package/docs/guides/agents.gotask.md +1037 -0
- package/docs/guides/agents.markdown.md +1209 -0
- package/docs/guides/agents.onepassword.md +285 -0
- package/docs/guides/agents.sonar.md +857 -0
- package/docs/guides/agents.tdd.md +838 -0
- package/docs/guides/agents.tdd.ts.md +1062 -0
- package/docs/guides/agents.typesript.md +1389 -0
- package/docs/guides/github-mcp.md +1075 -0
- package/package.json +130 -0
- package/packages/secureai-cli/src/cli.ts +21 -0
- package/tasks/README.md +880 -0
- package/tasks/aws.yml +64 -0
- package/tasks/bash.yml +118 -0
- package/tasks/bun.yml +738 -0
- package/tasks/claude.yml +183 -0
- package/tasks/docker.yml +420 -0
- package/tasks/docs.yml +127 -0
- package/tasks/git.yml +1336 -0
- package/tasks/gotask.yml +132 -0
- package/tasks/json.yml +77 -0
- package/tasks/markdown.yml +95 -0
- package/tasks/onepassword.yml +350 -0
- package/tasks/security.yml +102 -0
- package/tasks/sonar.yml +437 -0
- package/tasks/template.yml +74 -0
- package/tasks/vscode.yml +103 -0
- package/tasks/yaml.yml +121 -0
|
@@ -0,0 +1,109 @@
|
|
|
1
|
+
# Best Practice Guides
|
|
2
|
+
|
|
3
|
+
Best practices and integration guides for AI agents working with development tools and workflows. These guides ensure consistent, high-quality output across AI tools (Claude Code, Cursor, Codex CLI, GitHub Copilot).
|
|
4
|
+
|
|
5
|
+
## Available Guides
|
|
6
|
+
|
|
7
|
+
| Guide | Purpose | Target Audience | When to Apply |
|
|
8
|
+
| ---------------------------------------------- | ------------------------------------------------------------ | ---------------------------------------------- | ----------------------------------------------------------------------------- |
|
|
9
|
+
| [agents.sonar.md](agents.sonar.md) | SonarQube/SonarCloud integration for automated code quality | AI agents, code reviewers | Projects using SonarQube for quality gates and security scanning |
|
|
10
|
+
| [agents.markdown.md](agents.markdown.md) | Markdown formatting standards for AI-generated documentation | AI agents, documentation reviewers | Documentation >50 lines (READMEs, guides, API docs, troubleshooting) |
|
|
11
|
+
| [agents.gotask.md](agents.gotask.md) | GoTask usage guide for task automation workflows | AI agents, task developers | Any project using Taskfile.yml for build automation and development workflows |
|
|
12
|
+
| [agents.task-master.md](agents.task-master.md) | Task Master AI integration for structured development cycles | AI agents, project managers | Projects using Task Master for iterative task management via MCP |
|
|
13
|
+
| [github-mcp.md](github-mcp.md) | GitHub MCP server integration for repository operations | AI agents, developers configuring GitHub tools | Projects requiring GitHub integration (PRs, issues, repo management) |
|
|
14
|
+
|
|
15
|
+
## Guide Summaries
|
|
16
|
+
|
|
17
|
+
### agents.sonar.md
|
|
18
|
+
|
|
19
|
+
Enables automated SonarQube/SonarCloud integration for code quality and security analysis. Teaches AI agents to download analysis results programmatically, review security hotspots, fix issues automatically, and integrate with `/pr:fix` workflow without requiring manual UI access.
|
|
20
|
+
|
|
21
|
+
### agents.markdown.md
|
|
22
|
+
|
|
23
|
+
Teaches AI agents to create readable documentation by showing structure and concepts upfront while hiding implementation details in collapsible sections. Applies to READMEs, API docs, and technical guides over 50 lines.
|
|
24
|
+
|
|
25
|
+
### agents.gotask.md
|
|
26
|
+
|
|
27
|
+
Establishes GoTask as the standard for build automation and development workflows. Covers task namespacing, dependencies, variables, and integration with secret management. Used for build/test automation and code quality checks.
|
|
28
|
+
|
|
29
|
+
### agents.task-master.md
|
|
30
|
+
|
|
31
|
+
Provides structured task management through MCP integration. Guides AI agents on breaking down complex features, tracking implementation progress, managing task dependencies, and enabling research-backed planning for technical decisions.
|
|
32
|
+
|
|
33
|
+
### github-mcp.md
|
|
34
|
+
|
|
35
|
+
Defines controlled GitHub access through MCP server with limited permissions. Ensures AI agents can read repositories and create pull requests while protecting sensitive operations. Covers token management and secure configuration.
|
|
36
|
+
|
|
37
|
+
## Usage by AI Agents
|
|
38
|
+
|
|
39
|
+
These guides are automatically installed and configured by the AI Toolkit installer. The installer references these guides in AI tool configuration files, ensuring consistent best practices across all supported agents.
|
|
40
|
+
|
|
41
|
+
### Claude Code
|
|
42
|
+
|
|
43
|
+
**Auto-Configured**: Referenced in `CLAUDE.md` and loaded automatically.
|
|
44
|
+
|
|
45
|
+
**How It Helps**:
|
|
46
|
+
|
|
47
|
+
- Generates well-structured documentation following markdown standards
|
|
48
|
+
- Uses GoTask commands for build automation instead of direct shell commands
|
|
49
|
+
- Integrates Task Master MCP for structured task management
|
|
50
|
+
- Accesses GitHub via MCP with limited permissions (read repos, create PRs)
|
|
51
|
+
|
|
52
|
+
### Cursor IDE
|
|
53
|
+
|
|
54
|
+
**Auto-Configured**: Installer adds rules to `.cursor/settings.json`.
|
|
55
|
+
|
|
56
|
+
**How It Helps**:
|
|
57
|
+
|
|
58
|
+
- Applies markdown standards when generating documentation
|
|
59
|
+
- Suggests GoTask commands for common development tasks
|
|
60
|
+
- Integrates with Task Master for project planning
|
|
61
|
+
- Restricts GitHub operations to safe, limited scope
|
|
62
|
+
|
|
63
|
+
### Codex CLI
|
|
64
|
+
|
|
65
|
+
**Auto-Configured**: Installer adds references to Codex configuration.
|
|
66
|
+
|
|
67
|
+
**How It Helps**:
|
|
68
|
+
|
|
69
|
+
- Maintains consistent documentation format across CLI sessions
|
|
70
|
+
- Recommends GoTask over ad-hoc shell scripts
|
|
71
|
+
- Connects to Task Master MCP for task tracking
|
|
72
|
+
- Uses GitHub MCP with controlled permissions
|
|
73
|
+
|
|
74
|
+
### GitHub Copilot
|
|
75
|
+
|
|
76
|
+
**Auto-Configured**: Referenced in `.github/copilot-instructions.md` if available.
|
|
77
|
+
|
|
78
|
+
**How It Helps**:
|
|
79
|
+
|
|
80
|
+
- Suggests markdown formatting that matches project standards
|
|
81
|
+
- Recommends GoTask commands in inline suggestions
|
|
82
|
+
- Limited integration (no native MCP support)
|
|
83
|
+
- Follows GitHub best practices from guide
|
|
84
|
+
|
|
85
|
+
## Creating New Guides
|
|
86
|
+
|
|
87
|
+
When adding a new best practice guide:
|
|
88
|
+
|
|
89
|
+
1. Create a new `agents.<topic>.md` file in this directory
|
|
90
|
+
2. Include clear sections:
|
|
91
|
+
- Purpose and target audience
|
|
92
|
+
- Core principles
|
|
93
|
+
- Key guidelines
|
|
94
|
+
- Example use cases
|
|
95
|
+
- When to apply / when NOT to apply
|
|
96
|
+
- Practical examples
|
|
97
|
+
3. Update this README:
|
|
98
|
+
- Add entry to Available Guides table
|
|
99
|
+
- Add Quick Reference section
|
|
100
|
+
- Add to "When to Apply These Guides" section
|
|
101
|
+
4. Reference in [CLAUDE.md](../../CLAUDE.md) if applicable
|
|
102
|
+
|
|
103
|
+
## Related Documentation
|
|
104
|
+
|
|
105
|
+
- [Slash Commands](../commands/README.md) - Reusable command templates for AI agents
|
|
106
|
+
- [Task Library](../../tasks/README.md) - GoTask automation scripts and utilities
|
|
107
|
+
- [QA Standards](../QA.md) - Quality assurance guidelines and testing practices
|
|
108
|
+
- [Installation Guide](../installer.md) - AI Toolkit installation and configuration
|
|
109
|
+
- [1Password Integration](../1password.md) - Secret management setup
|
|
@@ -0,0 +1,244 @@
|
|
|
1
|
+
# Clean Architecture for AI Agents
|
|
2
|
+
|
|
3
|
+
This guide establishes clean architecture principles for AI agents refactoring codebases. These patterns apply across all languages and frameworks, ensuring testable, maintainable, and scalable code.
|
|
4
|
+
|
|
5
|
+
## Target Audience
|
|
6
|
+
|
|
7
|
+
AI agents (Claude Code, Cursor, GitHub Copilot, etc.) working with any codebase that needs improved testability, separation of concerns, and better test coverage.
|
|
8
|
+
|
|
9
|
+
## Core Principles
|
|
10
|
+
|
|
11
|
+
### Separation of Concerns
|
|
12
|
+
|
|
13
|
+
**The Dependency Rule**: Source code dependencies must point inward toward higher-level policies. Inner layers should not depend on outer layers.
|
|
14
|
+
|
|
15
|
+
```text
|
|
16
|
+
┌─────────────────────────────────────────────┐
|
|
17
|
+
│ Frameworks & Drivers (UI, DB, Web, CLI) │ ← Outer layer
|
|
18
|
+
├─────────────────────────────────────────────┤
|
|
19
|
+
│ Interface Adapters (Controllers, Gateways) │
|
|
20
|
+
├─────────────────────────────────────────────┤
|
|
21
|
+
│ Application Business Rules (Use Cases) │
|
|
22
|
+
├─────────────────────────────────────────────┤
|
|
23
|
+
│ Enterprise Business Rules (Entities) │ ← Inner layer
|
|
24
|
+
└─────────────────────────────────────────────┘
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
**For system interaction refactoring**, we focus on the boundary between:
|
|
28
|
+
|
|
29
|
+
- **Business Logic** (inner) - Pure functions, domain logic, validation
|
|
30
|
+
- **Infrastructure** (outer) - System calls, I/O, external services
|
|
31
|
+
|
|
32
|
+
### Interface-Based Boundaries
|
|
33
|
+
|
|
34
|
+
Use interfaces (or protocols, traits, abstract classes) to define contracts between layers:
|
|
35
|
+
|
|
36
|
+
**Benefits:**
|
|
37
|
+
|
|
38
|
+
- Business logic depends on abstractions, not implementations
|
|
39
|
+
- Multiple implementations (production, test, mock)
|
|
40
|
+
- Easy to swap infrastructure without changing business logic
|
|
41
|
+
- Clear contracts documented in code
|
|
42
|
+
|
|
43
|
+
### Dependency Injection
|
|
44
|
+
|
|
45
|
+
Pass dependencies through constructors or function parameters, not global singletons or imports:
|
|
46
|
+
|
|
47
|
+
**Good:**
|
|
48
|
+
|
|
49
|
+
```typescript
|
|
50
|
+
class UserService {
|
|
51
|
+
constructor(private api: IUserAPI) {}
|
|
52
|
+
async getUser(id: string) {
|
|
53
|
+
return this.api.fetch(id);
|
|
54
|
+
}
|
|
55
|
+
}
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
**Bad:**
|
|
59
|
+
|
|
60
|
+
```typescript
|
|
61
|
+
import { realAPI } from "./real-api";
|
|
62
|
+
class UserService {
|
|
63
|
+
async getUser(id: string) {
|
|
64
|
+
return realAPI.fetch(id);
|
|
65
|
+
} // Hardcoded dependency
|
|
66
|
+
}
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
### Testability First
|
|
70
|
+
|
|
71
|
+
Design for testability from the start:
|
|
72
|
+
|
|
73
|
+
**Unit Tests** - Test business logic in isolation with mocks
|
|
74
|
+
|
|
75
|
+
- Fast (< 1ms per test)
|
|
76
|
+
- Deterministic (no flakiness)
|
|
77
|
+
- No external dependencies
|
|
78
|
+
|
|
79
|
+
**Integration Tests** - Test real system interactions
|
|
80
|
+
|
|
81
|
+
- Slower (seconds per test)
|
|
82
|
+
- May require setup/teardown
|
|
83
|
+
- Test against real systems
|
|
84
|
+
|
|
85
|
+
## Common Patterns
|
|
86
|
+
|
|
87
|
+
### Pattern 1: Repository Pattern
|
|
88
|
+
|
|
89
|
+
Separate data access from business logic:
|
|
90
|
+
|
|
91
|
+
```text
|
|
92
|
+
IRepository (interface)
|
|
93
|
+
↑
|
|
94
|
+
├─ DatabaseRepository (production)
|
|
95
|
+
├─ InMemoryRepository (testing)
|
|
96
|
+
└─ MockRepository (unit tests)
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
**Use when:**
|
|
100
|
+
|
|
101
|
+
- Accessing databases
|
|
102
|
+
- Reading/writing files
|
|
103
|
+
- Caching systems
|
|
104
|
+
|
|
105
|
+
### Pattern 2: Service Pattern
|
|
106
|
+
|
|
107
|
+
Encapsulate external service calls:
|
|
108
|
+
|
|
109
|
+
```text
|
|
110
|
+
INotificationService (interface)
|
|
111
|
+
↑
|
|
112
|
+
├─ EmailService (production)
|
|
113
|
+
├─ SMSService (production)
|
|
114
|
+
└─ MockNotificationService (testing)
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
**Use when:**
|
|
118
|
+
|
|
119
|
+
- Calling external APIs
|
|
120
|
+
- Sending notifications
|
|
121
|
+
- Third-party integrations
|
|
122
|
+
|
|
123
|
+
### Pattern 3: Gateway Pattern
|
|
124
|
+
|
|
125
|
+
Abstract system operations:
|
|
126
|
+
|
|
127
|
+
```text
|
|
128
|
+
ISystemGateway (interface)
|
|
129
|
+
↑
|
|
130
|
+
├─ ShellGateway (production - executes commands)
|
|
131
|
+
└─ MockGateway (testing - returns canned responses)
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
**Use when:**
|
|
135
|
+
|
|
136
|
+
- Executing shell commands
|
|
137
|
+
- File system operations
|
|
138
|
+
- Network calls
|
|
139
|
+
|
|
140
|
+
### Pattern 4: Strategy Pattern
|
|
141
|
+
|
|
142
|
+
Interchangeable algorithms or behaviors:
|
|
143
|
+
|
|
144
|
+
```text
|
|
145
|
+
IAuthStrategy (interface)
|
|
146
|
+
↑
|
|
147
|
+
├─ OAuth2Strategy
|
|
148
|
+
├─ JWTStrategy
|
|
149
|
+
└─ MockAuthStrategy
|
|
150
|
+
```
|
|
151
|
+
|
|
152
|
+
**Use when:**
|
|
153
|
+
|
|
154
|
+
- Multiple implementations of same behavior
|
|
155
|
+
- Algorithm selection at runtime
|
|
156
|
+
- Platform-specific implementations
|
|
157
|
+
|
|
158
|
+
## Folder Organization
|
|
159
|
+
|
|
160
|
+
### Module-Based Structure (Recommended)
|
|
161
|
+
|
|
162
|
+
Organize by feature/module rather than by architectural layer:
|
|
163
|
+
|
|
164
|
+
```text
|
|
165
|
+
src/
|
|
166
|
+
├── auth/
|
|
167
|
+
│ ├── index.ts # Public API exports
|
|
168
|
+
│ ├── auth-interface.ts # IAuthService interface
|
|
169
|
+
│ ├── auth.system.ts # System implementation (LDAP, OAuth)
|
|
170
|
+
│ ├── session.ts # Business logic
|
|
171
|
+
│ └── tokens.ts # Business logic
|
|
172
|
+
├── users/
|
|
173
|
+
│ ├── index.ts
|
|
174
|
+
│ ├── user-repository-interface.ts
|
|
175
|
+
│ ├── user-repository.system.ts
|
|
176
|
+
│ └── user-service.ts
|
|
177
|
+
└── payments/
|
|
178
|
+
├── index.ts
|
|
179
|
+
├── payment-gateway-interface.ts
|
|
180
|
+
├── payment-gateway.system.ts
|
|
181
|
+
└── payment-processor.ts
|
|
182
|
+
|
|
183
|
+
tests/mocks/
|
|
184
|
+
├── auth/
|
|
185
|
+
│ └── auth-mock.ts
|
|
186
|
+
├── users/
|
|
187
|
+
│ └── user-repository-mock.ts
|
|
188
|
+
└── payments/
|
|
189
|
+
└── payment-gateway-mock.ts
|
|
190
|
+
```
|
|
191
|
+
|
|
192
|
+
**Benefits:**
|
|
193
|
+
|
|
194
|
+
- Related code co-located (easy to find)
|
|
195
|
+
- Clear module boundaries
|
|
196
|
+
- Import from module: `import { authenticate } from '@/auth'`
|
|
197
|
+
- Easy to test (all module code in one place)
|
|
198
|
+
- Scales well (add modules without restructuring)
|
|
199
|
+
- Easier to extract to microservices if needed
|
|
200
|
+
|
|
201
|
+
### Layer-Based Structure (Academic)
|
|
202
|
+
|
|
203
|
+
Traditional Clean Architecture organizes by layer:
|
|
204
|
+
|
|
205
|
+
```text
|
|
206
|
+
src/
|
|
207
|
+
├── entities/ # Enterprise business rules
|
|
208
|
+
├── use-cases/ # Application business rules
|
|
209
|
+
├── adapters/ # Interface adapters
|
|
210
|
+
└── frameworks/ # External frameworks
|
|
211
|
+
|
|
212
|
+
# NOT RECOMMENDED for most projects
|
|
213
|
+
```
|
|
214
|
+
|
|
215
|
+
**Problems:**
|
|
216
|
+
|
|
217
|
+
- Code for one feature scattered across directories
|
|
218
|
+
- Hard to find related files
|
|
219
|
+
- Doesn't scale (hundreds of files in one directory)
|
|
220
|
+
- Violates co-location principle
|
|
221
|
+
|
|
222
|
+
### Hybrid Approach
|
|
223
|
+
|
|
224
|
+
For large codebases, combine both:
|
|
225
|
+
|
|
226
|
+
```text
|
|
227
|
+
src/
|
|
228
|
+
├── modules/
|
|
229
|
+
│ ├── auth/ # Feature module
|
|
230
|
+
│ ├── users/ # Feature module
|
|
231
|
+
│ └── payments/ # Feature module
|
|
232
|
+
└── shared/
|
|
233
|
+
├── interfaces/ # Shared contracts
|
|
234
|
+
└── utils/ # Shared utilities
|
|
235
|
+
```
|
|
236
|
+
|
|
237
|
+
## Language-Specific Guides
|
|
238
|
+
|
|
239
|
+
For implementation details in specific languages, see:
|
|
240
|
+
|
|
241
|
+
- [Clean Architecture in TypeScript](./agents.clean.arch.ts.md)
|
|
242
|
+
- Python (Coming soon)
|
|
243
|
+
- Ruby (Coming soon)
|
|
244
|
+
- Go (Coming soon)
|