@neuravim/aiden 0.12.0

package/templates/skills/hipaa-guard/skill.yaml

@@ -0,0 +1,23 @@
+name: hipaa-guard
+version: 1.0.0
+description: Enforce HIPAA compliance for Protected Health Information handling
+agents:
+  - analyst
+  - dev
+  - qa
+modes:
+  - enterprise
+priority: 25
+enabled: true
+config:
+  phiFields:
+    - name
+    - dob
+    - ssn
+    - mrn
+    - address
+    - phone
+    - email
+    - insurance_id
+  encryptionRequired: AES-256
+  auditLogRetention: 2190

package/templates/skills/iso-27001/instructions.md

@@ -0,0 +1,54 @@
+# ISO 27001 Controls Assessment
+
+## For Analyst Agent
+
+Evaluate the feature against relevant ISO 27001 Annex A controls. Flag any controls that the feature impacts or must comply with:
+
+- **A.5 — Information Security Policies**: Does the feature align with documented security policies?
+- **A.6 — Organization of Information Security**: Are responsibilities and segregation of duties clear?
+- **A.8 — Asset Management**: Are information assets (data, configs, keys) classified and handled appropriately?
+- **A.9 — Access Control**: Is access limited to authorized users with least privilege?
+
+Include an `## ISO 27001 Impact` section in your analysis listing affected controls.
+
+## For QA Agent
+
+Assess the implementation against the following ISO 27001 Annex A control domains:
+
+### A.9 — Access Control
+- Verify authentication is required for all sensitive operations
+- Verify authorization follows least-privilege principle
+- Check for proper session management and timeout
+
+### A.10 — Cryptography
+- Verify encryption is used for sensitive data at rest and in transit
+- Check key management practices (no hardcoded keys, proper rotation)
+- Verify hashing algorithms are current (bcrypt, argon2 for passwords)
+
+### A.12 — Operations Security
+- Verify logging captures security-relevant events
+- Check for protection against malware (input validation, sanitization)
+- Verify change management controls (no direct production modifications)
+
+### A.13 — Communications Security
+- Verify network communications use TLS
+- Check for proper API authentication (tokens, certificates)
+- Verify data transfer controls between systems
+
+### A.14 — System Acquisition, Development, and Maintenance
+- Verify secure coding practices are followed
+- Check for input validation on all external inputs
+- Verify separation of development, test, and production environments
+
+### Output Format
+
+```
+ISO27001_FINDING:
+- control: A.5 | A.6 | A.8 | A.9 | A.10 | A.12 | A.13 | A.14
+- severity: critical | high | medium | low
+- description: <what control is not satisfied>
+- evidence: <file and line or architectural concern>
+- remediation: <specific action to achieve compliance>
+```
+
+Summarize with a compliance score: number of controls assessed vs. number with findings.

package/templates/skills/iso-27001/skill.yaml

@@ -0,0 +1,10 @@
+name: iso-27001
+version: 1.0.0
+description: Assess code against ISO 27001 information security controls
+agents:
+  - analyst
+  - qa
+modes:
+  - enterprise
+priority: 20
+enabled: true

package/templates/skills/jira-sync/instructions.md

@@ -0,0 +1,10 @@
+# Jira Sync
+
+## For Lead Agent
+- When analyzing a feature request, check if a Jira ticket reference is mentioned
+- Include the Jira ticket ID in the feature slug if available (e.g., PROJ-123-feature-name)
+
+## For Planner Agent
+- Each story should map to a potential Jira sub-task
+- Include estimated story points in story descriptions
+- Reference the parent Jira ticket in the spec header

package/templates/skills/jira-sync/skill.yaml

@@ -0,0 +1,18 @@
+name: jira-sync
+version: 1.0.0
+description: Sync AIDEN features with Jira tickets
+agents:
+  - lead
+  - planner
+hooks:
+  on_feature_created:
+    - command: "echo 'TODO: Create Jira ticket for {{feature}}'"
+      onFailure: warn
+  on_feature_completed:
+    - command: "echo 'TODO: Close Jira ticket for {{feature}}'"
+      onFailure: ignore
+config:
+  jira_url: https://your-company.atlassian.net
+  project_key: PROJ
+priority: 5
+enabled: false

package/templates/skills/linear-sync/instructions.md

@@ -0,0 +1,39 @@
+# Linear Sync
+
+## For Lead Agent
+
+When creating a new feature:
+
+1. Include a Linear-compatible identifier in the feature slug when a Linear issue ID is provided (e.g., `ENG-123-user-auth`)
+2. Reference the Linear issue URL in the feature brief under a `## Tracking` section
+3. If no Linear issue exists, note that one should be created (the `on_feature_created` hook handles this)
+
+When summarizing feature status, include the Linear issue reference for traceability.
+
+## For Planner Agent
+
+When decomposing a feature into stories:
+
+1. **Map stories to sub-issues**: Each story should correspond to a potential Linear sub-issue
+2. **Include story points**: Estimate story points (1, 2, 3, 5, 8) for each story based on complexity
+3. **Set priority**: Map story priority to Linear priority levels (Urgent, High, Medium, Low)
+4. **Label mapping**: Suggest Linear labels based on story type (feature, bug, chore, spike)
+
+### Story format for Linear sync
+
+In each story, include a metadata block:
+
+```
+STORY_METADATA:
+- linearParent: <parent issue ID if known>
+- storyPoints: <1|2|3|5|8>
+- priority: <urgent|high|medium|low>
+- labels: [<label1>, <label2>]
+```
+
+This metadata will be used by the sync hooks to create properly attributed Linear sub-issues.
+
+### Hooks
+
+- `on_feature_created`: Creates a Linear issue for the feature (configured via team/project settings)
+- `on_feature_completed`: Closes the Linear issue and its sub-issues

package/templates/skills/linear-sync/skill.yaml

@@ -0,0 +1,22 @@
+name: linear-sync
+version: 1.0.0
+description: Sync AIDEN features and stories with Linear issues
+agents:
+  - lead
+  - planner
+modes:
+  - standard
+  - enterprise
+priority: 5
+enabled: true
+config:
+  teamId: ""
+  projectId: ""
+  apiKeyEnv: LINEAR_API_KEY
+hooks:
+  on_feature_created:
+    - command: "echo TODO Create Linear issue"
+      onFailure: warn
+  on_feature_completed:
+    - command: "echo TODO Close Linear issue"
+      onFailure: ignore

package/templates/skills/naming-conventions/instructions.md

@@ -0,0 +1,45 @@
+# Naming Conventions
+
+## For Dev Agent
+
+Apply the following naming conventions to all generated code:
+
+| Element        | Convention         | Example                    |
+|----------------|--------------------|----------------------------|
+| Files          | kebab-case         | `user-service.ts`          |
+| Functions      | camelCase          | `getUserById()`            |
+| Classes        | PascalCase         | `UserService`              |
+| Constants      | UPPER_SNAKE_CASE   | `MAX_RETRY_COUNT`          |
+| Types/Interfaces | PascalCase       | `UserProfile`, `ApiResponse` |
+| Enums          | PascalCase (name), UPPER_SNAKE_CASE (members) | `Status.ACTIVE` |
+| Test files     | kebab-case         | `user-service.test.ts`     |
+| Variables      | camelCase          | `currentUser`              |
+| Boolean vars   | camelCase with prefix | `isActive`, `hasPermission`, `canEdit` |
+| Private fields | camelCase (no `_` prefix unless framework requires) | `private userId` |
+
+### Rules
+
+1. Acronyms in names: treat as a word — `HttpClient`, not `HTTPClient`; `apiUrl`, not `APIUrl`
+2. Event handlers: prefix with `handle` or `on` — `handleSubmit`, `onUserCreated`
+3. Factory functions: prefix with `create` — `createLogger`, `createConnection`
+4. Type guards: prefix with `is` or `has` — `isString`, `hasRole`
+
+## For QA Agent
+
+Verify all new and modified code follows the naming conventions above. Check:
+
+1. File names match kebab-case
+2. Exported symbols match their expected convention
+3. No inconsistencies between similar constructs
+
+### Output Format
+
+```
+NAMING_VIOLATION:
+- file: <path>
+- line: <line number>
+- symbol: <name>
+- expected: <convention>
+- actual: <what was found>
+- suggestion: <corrected name>
+```

package/templates/skills/naming-conventions/skill.yaml

@@ -0,0 +1,16 @@
+name: naming-conventions
+version: 1.0.0
+description: Enforce consistent naming conventions across the codebase
+agents:
+  - dev
+  - qa
+priority: 5
+enabled: true
+config:
+  files: kebab-case
+  functions: camelCase
+  classes: PascalCase
+  constants: UPPER_SNAKE_CASE
+  types: PascalCase
+  testFiles: kebab-case
+  enforcePrefix: false

package/templates/skills/nestjs-patterns/instructions.md

@@ -0,0 +1,55 @@
+# NestJS Patterns
+
+## For Dev Agent
+
+Follow NestJS architectural patterns and conventions strictly:
+
+### Module structure
+- Every feature MUST have its own module (`*.module.ts`)
+- Module structure: `controller` -> `service` -> `repository/provider`
+- Use `forRoot()`/`forRootAsync()` for configurable modules
+- Use `forFeature()` for feature-specific registrations (e.g., TypeORM entities)
+
+### Dependency injection
+- All services MUST be `@Injectable()` and provided through modules
+- Use constructor injection, not property injection
+- Use custom providers (`useFactory`, `useClass`, `useValue`) for complex dependencies
+- Use `@Inject()` with tokens for interface-based injection
+
+### Controllers
+- All controllers MUST have at least one guard (`@UseGuards()`) when `requireGuardsOnControllers` is enabled
+- Use `@UsePipes(ValidationPipe)` or global validation pipe when `requireValidationPipe` is enabled
+- Use DTOs with `class-validator` decorators for all request bodies
+- Return consistent response shapes — use interceptors for transformation
+
+### Error handling
+- Use NestJS built-in exceptions (`NotFoundException`, `BadRequestException`, etc.)
+- Create custom exceptions extending `HttpException` for domain-specific errors
+- Use exception filters for global error handling
+
+### Patterns
+- Use interceptors for cross-cutting concerns (logging, caching, transformation)
+- Use pipes for input validation and transformation
+- Use guards for authorization logic
+- Use middleware for request-level concerns (CORS, rate limiting)
+
+## For QA Agent
+
+Verify the implementation follows NestJS patterns:
+
+1. Each feature has a proper module with declarations
+2. Controllers have guards attached (if configured)
+3. DTOs use class-validator decorators
+4. Services are injectable and properly scoped
+5. No circular dependencies between modules
+
+### Output Format
+
+```
+NESTJS_VIOLATION:
+- rule: module-structure | dependency-injection | controller-guard | validation-pipe | error-handling | pattern
+- file: <path>
+- line: <line number>
+- description: <what violates the pattern>
+- fix: <how to correct it>
+```

package/templates/skills/nestjs-patterns/skill.yaml

@@ -0,0 +1,12 @@
+name: nestjs-patterns
+version: 1.0.0
+description: Enforce NestJS architectural patterns and best practices
+agents:
+  - dev
+  - qa
+priority: 10
+enabled: true
+config:
+  enforceModuleStructure: true
+  requireGuardsOnControllers: true
+  requireValidationPipe: true

package/templates/skills/owasp-check/instructions.md

@@ -0,0 +1,71 @@
+# OWASP Top 10 Security Check
+
+## For QA Agent
+
+Review all new and modified code against the OWASP Top 10 (2021) categories. For each category, perform the specific checks listed below.
+
+### A01 — Broken Access Control
+- Missing authorization checks on endpoints or functions
+- Direct object references without ownership validation
+- Missing CORS configuration or overly permissive CORS
+- Path traversal in file operations
+
+### A02 — Cryptographic Failures (Sensitive Data)
+- Hardcoded secrets, passwords, or API keys
+- Weak hashing algorithms (MD5, SHA1 for passwords)
+- Missing encryption for PII or sensitive data at rest/in transit
+- Insufficient key management
+
+### A03 — Injection
+- SQL/NoSQL injection via string concatenation or template literals
+- Command injection through `exec`, `spawn` with unsanitized input
+- LDAP, XPath, or expression language injection
+- Missing parameterized queries
+
+### A04 — Insecure Design
+- Missing rate limiting on sensitive operations
+- Missing input validation on business logic
+- Race conditions in state-changing operations
+
+### A05 — Security Misconfiguration
+- Debug mode enabled in production configs
+- Default credentials or unnecessary features enabled
+- Missing security headers (CSP, X-Frame-Options, HSTS)
+- Verbose error messages exposing internals
+
+### A06 — Vulnerable and Outdated Components
+- Known vulnerable dependency versions
+- Unmaintained or deprecated packages
+
+### A07 — Identification and Authentication Failures
+- Weak password policies or missing MFA hooks
+- Session tokens in URLs, missing session expiry
+- Missing brute-force protection
+
+### A08 — Software and Data Integrity Failures
+- Deserialization of untrusted data (`JSON.parse` on raw user input without schema validation)
+- Missing integrity checks on downloads or CI/CD pipelines
+
+### A09 — Security Logging and Monitoring Failures
+- Missing audit logs for authentication events, access control failures, input validation failures
+- Sensitive data in logs (tokens, passwords, PII)
+
+### A10 — Server-Side Request Forgery (SSRF)
+- User-controlled URLs passed to `fetch`, `http.get`, or similar without allowlist validation
+- Missing URL scheme restrictions
+
+### Output Format
+
+For each finding, emit:
+
+```
+OWASP_FINDING:
+- category: A01 | A02 | A03 | A04 | A05 | A06 | A07 | A08 | A09 | A10
+- severity: critical | high | medium | low
+- file: <path>
+- line: <line number>
+- description: <what the vulnerability is>
+- remediation: <specific fix recommendation>
+```
+
+Flag at least the `high` and `critical` severity findings. Any `critical` finding MUST cause QA to fail.

package/templates/skills/owasp-check/skill.yaml

@@ -0,0 +1,20 @@
+name: owasp-check
+version: 1.0.0
+description: Check code against OWASP Top 10 vulnerability categories
+agents:
+  - qa
+priority: 90
+enabled: true
+config:
+  severity: high
+  categories:
+    - injection
+    - broken-auth
+    - sensitive-data
+    - xxe
+    - broken-access
+    - misconfig
+    - xss
+    - deserialization
+    - components
+    - logging

package/templates/skills/react-best-practices/instructions.md

@@ -0,0 +1,59 @@
+# React Best Practices
+
+## For Dev Agent
+
+Follow React best practices and conventions:
+
+### Hooks rules
+- Never call hooks inside conditions, loops, or nested functions
+- Custom hooks MUST start with `use` prefix
+- Use `useCallback` for functions passed as props to child components
+- Use `useMemo` for expensive computations, not for every value
+- Prefer `useReducer` over `useState` for complex state logic
+
+### Component design
+- Components MUST be under the configured `maxComponentLines` (default: 150 lines)
+- Prefer composition over inheritance — use children, render props, or custom hooks
+- Extract reusable logic into custom hooks
+- Use named exports for components, not default exports
+- Colocate related files: `Component.tsx`, `Component.test.tsx`, `Component.module.css`
+
+### Performance
+- Wrap expensive child components with `React.memo()` when props are stable
+- Use `key` prop on all list-rendered elements (no array index as key for dynamic lists)
+- Avoid creating objects/arrays inline in JSX props (creates new references each render)
+- Use lazy loading (`React.lazy` + `Suspense`) for route-level code splitting
+
+### Accessibility (when `enforceAccessibility` is enabled)
+- All interactive elements MUST be keyboard accessible
+- All images MUST have `alt` attributes (empty string for decorative images)
+- Use semantic HTML elements (`button`, `nav`, `main`, `article`) over generic `div`
+- Form inputs MUST have associated `label` elements or `aria-label`
+- Color MUST NOT be the only means of conveying information
+- Focus management: modals must trap focus, route changes must announce
+
+### State management
+- Keep state as close to where it is used as possible
+- Lift state up only when needed by sibling components
+- Use context for truly global state (theme, auth, locale), not for all shared state
+
+## For QA Agent
+
+Verify React best practices compliance:
+
+1. Hooks usage follows the Rules of Hooks
+2. Components are within size limits
+3. Key props are present on list items
+4. Accessibility requirements are met (if enabled)
+5. No common anti-patterns (prop drilling > 3 levels, state in wrong component)
+
+### Output Format
+
+```
+REACT_VIOLATION:
+- rule: hooks | composition | performance | accessibility | state-management
+- file: <path>
+- line: <line number>
+- description: <what violates the practice>
+- fix: <how to correct it>
+```

package/templates/skills/react-best-practices/skill.yaml

@@ -0,0 +1,12 @@
+name: react-best-practices
+version: 1.0.0
+description: Enforce React best practices including hooks, composition, and accessibility
+agents:
+  - dev
+  - qa
+priority: 10
+enabled: true
+config:
+  enforceAccessibility: true
+  maxComponentLines: 150
+  requireKeyProp: true

package/templates/skills/secret-scan/instructions.md

@@ -0,0 +1,44 @@
+# Secret Scan
+
+## For Dev Agent
+
+Before finalizing any code, scan all new and modified files for hardcoded secrets. You MUST NOT commit code containing any of the following:
+
+### Patterns to detect
+
+1. **API keys**: strings matching `sk-`, `pk-`, `api_key`, `apiKey`, `API_KEY` assignments with literal values
+2. **Tokens**: `ghp_`, `gho_`, `github_pat_`, `xoxb-`, `xoxp-`, Bearer tokens as string literals
+3. **Passwords**: variables named `password`, `passwd`, `secret`, `credential` assigned to string literals
+4. **Private keys**: `-----BEGIN (RSA|EC|DSA|OPENSSH) PRIVATE KEY-----`
+5. **Connection strings**: `postgres://`, `mongodb://`, `redis://`, `mysql://` with embedded credentials
+6. **AWS credentials**: `AKIA`, `aws_secret_access_key`, `aws_access_key_id` with literal values
+7. **Generic high-entropy strings**: 32+ character hex or base64 strings assigned to secret-sounding variables
+
+### What to do
+
+- Replace hardcoded values with environment variable references: `process.env.API_KEY`
+- Add the variable name to `.env.example` with a placeholder
+- Never log secret values, even at debug level
+
+## For QA Agent
+
+Scan the entire diff for secrets that the Dev agent may have missed:
+
+1. Check all string literals, template literals, and config objects
+2. Look for Base64-encoded secrets that might evade simple pattern matching
+3. Check test fixtures and mock data for real credentials
+4. Verify `.env` files are in `.gitignore`
+
+### Output Format
+
+```
+SECRET_FINDING:
+- type: api-key | token | password | private-key | connection-string | aws-credential | high-entropy
+- file: <path>
+- line: <line number>
+- pattern: <what matched, redacted>
+- risk: critical
+- remediation: Move to environment variable
+```
+
+When `blockOnFind` is enabled (default), ANY secret finding MUST cause QA to fail with `passed: false`.

package/templates/skills/secret-scan/skill.yaml

@@ -0,0 +1,11 @@
+name: secret-scan
+version: 1.0.0
+description: Detect hardcoded secrets, API keys, tokens, and credentials in code
+agents:
+  - dev
+  - qa
+priority: 95
+enabled: true
+config:
+  blockOnFind: true
+  customPatterns: []

package/templates/skills/slack-notify/instructions.md

@@ -0,0 +1,45 @@
+# Slack Notify
+
+## For Lead Agent
+
+Generate a `SLACK_NOTIFICATION` block for each significant workflow event. The hook system will use this to send Slack messages via the configured webhook.
+
+### Events to notify
+
+1. **Phase complete**: When an agent finishes its phase successfully
+2. **QA failure**: When QA rejects the implementation (include failure reason)
+3. **Blocked**: When a feature is blocked (include blocking reason and required action)
+4. **Feature complete**: When the entire workflow finishes successfully
+
+### Notification format
+
+For each event, include in your output:
+
+```
+SLACK_NOTIFICATION:
+- event: phase_complete | qa_fail | blocked | feature_complete
+- channel: #aiden-notifications
+- feature: <feature slug>
+- summary: <1-2 sentence description of what happened>
+- severity: info | warning | error | success
+- details:
+    agent: <agent that completed/failed>
+    mode: <flash|standard|enterprise>
+    duration: <estimated time if available>
+```
+
+### Severity mapping
+
+| Event            | Severity | Emoji  |
+|------------------|----------|--------|
+| phase_complete   | info     | :gear: |
+| qa_fail          | warning  | :warning: |
+| blocked          | error    | :red_circle: |
+| feature_complete | success  | :white_check_mark: |
+
+### Guidelines
+
+- Keep summaries concise — Slack messages should be scannable
+- Include actionable information: what happened, what needs attention
+- For QA failures, include the top 3 issues found
+- For blocked features, include who or what can unblock it

package/templates/skills/slack-notify/skill.yaml

@@ -0,0 +1,19 @@
+name: slack-notify
+version: 1.0.0
+description: Send Slack notifications for AIDEN workflow events
+agents:
+  - lead
+priority: 5
+enabled: true
+config:
+  webhookUrlEnv: SLACK_WEBHOOK_URL
+  channel: "#aiden-notifications"
+  notifyOn:
+    - phase_complete
+    - qa_fail
+    - blocked
+    - feature_complete
+hooks:
+  on_phase_complete:
+    - command: "echo TODO Slack notify"
+      onFailure: ignore

package/templates/skills/test-coverage-enforcer/instructions.md

@@ -0,0 +1,42 @@
+# Test Coverage Enforcer
+
+## For Dev Agent
+
+When generating or modifying code, you MUST also generate corresponding tests that cover:
+
+- **All branches**: every `if/else`, `switch` case, ternary, and `??`/`||` fallback
+- **All error paths**: catch blocks, thrown exceptions, rejected promises, validation failures
+- **Edge cases**: empty inputs, null/undefined, boundary values, large datasets
+- **Integration points**: any function that calls external services or other modules
+
+### Rules
+
+1. Every new file with logic MUST have a corresponding `.test.ts` file
+2. Every new public function MUST have at least one happy-path and one error-path test
+3. Exclude from coverage enforcement: files matching `*.d.ts`, `index.ts` (barrel exports), `types.ts`
+4. Use descriptive test names: `it('should throw ValidationError when email is empty')`
+5. Mock external dependencies — tests must be deterministic
+
+## For QA Agent
+
+Estimate the test coverage ratio for all new and modified files:
+
+1. List every branch, function, and code path in the changed files
+2. Check which ones are covered by the generated tests
+3. Compute an estimated coverage percentage (lines covered / total lines with logic)
+4. **FAIL the review** if estimated coverage is below the configured `minCoverage` threshold (default: 80%)
+
+### Output Format
+
+For each file reviewed, emit:
+
+```
+COVERAGE_REPORT:
+- file: <path>
+- estimatedCoverage: <percentage>
+- uncoveredPaths:
+  - <description of untested branch or function>
+- status: pass | fail
+```
+
+If any file has `status: fail`, the overall QA verdict MUST be `passed: false` with a clear explanation of what tests are missing.

package/templates/skills/test-coverage-enforcer/skill.yaml

@@ -0,0 +1,18 @@
+name: test-coverage-enforcer
+version: 1.0.0
+description: Enforce minimum test coverage on new and modified code
+agents:
+  - dev
+  - qa
+modes:
+  - standard
+  - enterprise
+priority: 15
+enabled: true
+config:
+  minCoverage: 80
+  enforceOnNewFiles: true
+  excludePatterns:
+    - "*.d.ts"
+    - "index.ts"
+    - "types.ts"