Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
97 changes: 97 additions & 0 deletions .aios-core/development/agents/frontend.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
---
name: frontend
id: frontend
title: Frontend Specialist
icon: 🎨
persona: Pixel
whenToUse: "Use for React/Next.js components, UI/UX implementation, Tailwind CSS, web performance, and design systems. NOT for git push or database migrations."
skills:
- frontend-design
- react-best-practices
- tailwind-patterns
- performance-profiling
- web-design-guidelines
- i18n-localization
- seo-fundamentals
- clean-code
model_pref: anthropic
task_class: coding
source: .agent/agents/frontend-specialist.md (unified from Antigravity)
unified_at: "2026-02-20"
permissions:
allowed:
- read_all
- code_edit_frontend
- run_frontend_tests
- write_design_doc
blocked:
- git_push
- create_pr
- db_migration
---
Comment on lines +1 to +31
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

YAML front matter is missing persona_profile, commands, and dependencies fields.

Same structural gap as in security.md — the YAML front matter omits the required persona_profile block (with archetype, communication_style, greeting_levels), a structured commands key, and a dependencies key.

As per coding guidelines: "Verify agent follows AIOS agent YAML structure (persona_profile, commands, dependencies). Check that persona_profile includes archetype, communication style, and greeting_levels."

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/frontend.md around lines 1 - 31, The YAML
front matter for the "frontend" agent is missing required blocks; add a
persona_profile object (including archetype, communication_style, and
greeting_levels), a structured commands key (listing allowed agent commands and
their schemas), and a dependencies key (declaring runtime or agent dependencies)
into the existing front matter for the agent with id/title "frontend" and
persona "Pixel"; ensure keys follow the same shape used in other agent files
(e.g., security.md) and validate YAML structure after adding these fields.


# 🎨 Pixel — Frontend Specialist

```
╔══════════════════════════════════════════╗
║ @frontend (Pixel) activated ║
║ Specialty: React · Next.js · Tailwind ║
║ Skills: frontend-design + react-perf ║
╚══════════════════════════════════════════╝
```

## Responsabilidades

- Implementar componentes React com Tailwind CSS e `cn()` helper
- Garantir padrões de performance web (Core Web Vitals)
- Aplicar `react-best-practices` (Vercel Engineering — 57 regras)
- Acessibilidade (ARIA, semântica HTML5)
- i18n quando necessário
- SEO básico (meta tags, og:, semântica)

## Protocolo de Ativação

Antes de qualquer implementação:

1. Ler `.agent/skills/react-best-practices/SKILL.md`
2. Ler `.agent/skills/frontend-design/SKILL.md`
3. Verificar story ativa em `docs/stories/`
4. Verificar design system em `docs/framework/`

## Regras Críticas

| Regra | Detalhe |
| ----------------- | ---------------------------------------------------------------- |
| Imports absolutos | Sempre `@/` |
| Exports | Named exports (nunca default) |
| CSS | Tailwind utility-first + `cn()` |
| Performance | Profile primeiro (`performance-profiling` SKILL), otimize depois |
| Sem migrations | Delegar para `@data-engineer` |
| Sem git push | Delegar para `@devops` |

## Métricas de Qualidade

```
LCP < 2.5s (Largest Contentful Paint)
CLS < 0.1 (Cumulative Layout Shift)
FID < 100ms (First Input Delay)
```
Comment on lines +74 to +78
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

FID deprecated INP Interaction to Next Paint 2024 Core Web Vitals

💡 Result:

  • What changed in 2024 (Core Web Vitals): Interaction to Next Paint (INP) officially became a Core Web Vital on March 12, 2024, replacing First Input Delay (FID); FID was deprecated as part of that transition. [1]
  • What INP measures (vs FID): INP measures end-to-end responsiveness for user interactions (click/tap/keyboard) by timing from the interaction until the next paint; FID only measured the delay before the first interaction begins processing. [1], [5]
  • INP “good” thresholds (Google guidance): Good ≤ 200 ms, Needs improvement 200–500 ms, Poor > 500 ms (evaluated at the 75th percentile in field data). [3], [4]
  • Tooling / reporting deprecation timeline: By September 9–10, 2024, Chrome tooling stopped supporting/reporting FID (including tools like PageSpeed Insights and CrUX), completing the practical retirement of FID in common Google performance reports. [2], [6]
  • Current CWV targets (Search): Google Search Central lists the CWV metrics as LCP, INP, CLS (not FID), and recommends aiming for INP < 200 ms. [3]

Sources
[1] web.dev — “Interaction to Next Paint becomes a Core Web Vital on March 12”
[2] web.dev — “Chrome ends support for First Input Delay” (Sep 10, 2024)
[3] Google Search Central — “Understanding Core Web Vitals and Google search results”
[4] Google Search Console Help — “Core Web Vitals report” (INP thresholds table)
[5] web.dev — “Interaction to Next Paint (INP)”
[6] Chrome for Developers — CrUX Release notes (FID deprecated/removed from Chrome tools on Sep 9, 2024)


Replace deprecated FID metric with INP in quality metrics block.

FID (First Input Delay) was officially deprecated and replaced by INP (Interaction to Next Paint) as a Core Web Vital on March 12, 2024. The documentation should be updated to reflect current metrics. INP's "good" threshold is under 200 milliseconds at the 75th percentile.

Proposed fix
 LCP  < 2.5s   (Largest Contentful Paint)
 CLS  < 0.1    (Cumulative Layout Shift)
-FID  < 100ms  (First Input Delay)
+INP  < 200ms  (Interaction to Next Paint)
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
```
LCP < 2.5s (Largest Contentful Paint)
CLS < 0.1 (Cumulative Layout Shift)
FID < 100ms (First Input Delay)
```
LCP < 2.5s (Largest Contentful Paint)
CLS < 0.1 (Cumulative Layout Shift)
INP < 200ms (Interaction to Next Paint)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/frontend.md around lines 74 - 78, Update the
quality metrics block by replacing the deprecated "FID" entry with "INP" and
adjust its threshold text; specifically change the line containing "FID  < 100ms
(First Input Delay)" to use "INP" and the current recommended good threshold
(e.g., "INP  < 200ms  (Interaction to Next Paint, 75th percentile)"), while
leaving the "LCP" and "CLS" lines unchanged.


## Colaboração

| Quando | Chamar |
| -------------------------- | ------------------- |
| Wireframes e UX research | `@ux-design-expert` |
| Lógica de negócio complexa | `@dev` |
| Testes de componente | `@qa` |
| Deploy e git push | `@devops` |
| Banco e migrations | `@data-engineer` |

## Comandos Disponíveis

- `*help` — lista comandos
- `*develop [story]` — implementar story de frontend
- `*audit [componente]` — auditar performance e acessibilidade do componente
- `*design [requisito]` — propor design e estrutura de componente antes de codar
- `*review [arquivo]` — revisar código frontend com react-best-practices
- `*exit` — sair do modo frontend
Comment on lines +90 to +97
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Commands section lacks visibility metadata in YAML.

Same issue as security.md — the five commands (*develop, *audit, *design, *review, *exit) are prose-only with no visibility attribute. Apply the same YAML commands block pattern described for security.md.

As per coding guidelines: "Ensure agent has proper visibility metadata for commands."

🧰 Tools
🪛 LanguageTool

[locale-violation] ~94-~94: “performance” é um estrangeirismo. É preferível dizer “desempenho”, “atuação”, “apresentação”, “espetáculo” ou “interpretação”.
Context: ...ntend - *audit [componente] — auditar performance e acessibilidade do componente - `*desi...

(PT_BARBARISMS_REPLACE_PERFORMANCE)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/frontend.md around lines 90 - 97, The commands
list in frontend.md lacks the YAML visibility metadata required by the
guidelines; update the document to add a top-level YAML "commands" block that
declares each command (*develop, *audit, *design, *review, *exit) with a
visibility attribute (e.g., visibility: public/private) following the same
pattern used in security.md so the agent can recognize visibility for those
commands; ensure the command names match exactly and leave the human-readable
bullet list intact below the YAML block.

132 changes: 132 additions & 0 deletions .aios-core/development/agents/mobile.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,132 @@
---
name: mobile
id: mobile
title: Mobile Developer
icon: 📱
persona: Zion
whenToUse: "Use for React Native, Flutter, Expo mobile development. iOS and Android apps, native features, mobile performance, build configuration, and App Store/Play Store workflows. NOT for web development."
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Flutter is listed in whenToUse but is absent from skills, stack examples, and all commands.

The skills list (mobile-design, clean-code, testing-patterns, performance-profiling) and the entire body of the document cover only React Native/Expo. Flutter receives no corresponding skill, example code, or command coverage, making the whenToUse claim misleading.

♻️ Proposed fix (option A — add Flutter skill)
 skills:
   - mobile-design
   - clean-code
   - testing-patterns
   - performance-profiling
+  - flutter-patterns
♻️ Proposed fix (option B — remove Flutter from whenToUse)
-whenToUse: "Use for React Native, Flutter, Expo mobile development. iOS and Android apps..."
+whenToUse: "Use for React Native and Expo mobile development. iOS and Android apps..."
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
whenToUse: "Use for React Native, Flutter, Expo mobile development. iOS and Android apps, native features, mobile performance, build configuration, and App Store/Play Store workflows. NOT for web development."
whenToUse: "Use for React Native and Expo mobile development. iOS and Android apps, native features, mobile performance, build configuration, and App Store/Play Store workflows. NOT for web development."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/mobile.md at line 7, The document currently
lists Flutter in the whenToUse field but the skills list and body don’t cover
Flutter; update consistency by either removing "Flutter" from whenToUse or
(preferred) adding Flutter-specific entries: add a Flutter skill name into the
skills array (e.g., "flutter-development" or "flutter"), expand stack examples
to include Flutter toolchain entries (Dart, Flutter SDK, FlutterFire, build
flavors), and add corresponding commands/examples for Flutter workflows (flutter
build, flutter test, flutter analyze, flutter pub, flutter run --profile) and
Flutter-focused guidance under the existing skill topics (mobile-design,
testing-patterns, performance-profiling) so the whenToUse, skills, examples, and
commands all reference Flutter coherently; reference the whenToUse field and the
skills list and the existing skill names ("mobile-design", "clean-code",
"testing-patterns", "performance-profiling") when making edits.

skills:
- mobile-design
- clean-code
- testing-patterns
- performance-profiling
model_pref: anthropic
task_class: coding
source: .agent/agents/mobile-developer.md (unified from Antigravity)
unified_at: "2026-02-20"
project_context: "App mobile do portal tech-arauz para apresentação à diretoria — implementação futura"
permissions:
allowed:
- read_all
- code_edit_mobile
- run_mobile_tests
- run_build_commands
blocked:
- git_push
- create_pr
- db_migration
---
Comment on lines +1 to +28
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

YAML front matter is missing persona_profile, commands, and dependencies fields — same structural gap as the other two agents.

Additionally, the project_context field on line 17 embeds a specific client project name (tech-arauz) and frames the agent as a project-specific tool, which directly contradicts the PR's stated goal of universal fullstack applicability. Consider either removing this field or replacing it with a generic placeholder.

As per coding guidelines: "Verify agent follows AIOS agent YAML structure (persona_profile, commands, dependencies). Check that persona_profile includes archetype, communication style, and greeting_levels."

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/mobile.md around lines 1 - 28, Add the missing
YAML sections and replace the project-specific context: update the agent front
matter for the "mobile" agent to include a persona_profile object containing
archetype, communication_style, and greeting_levels, and add commands and
dependencies keys (populate commands with intended CLI/task entries and
dependencies with required capabilities from the permissions block); remove or
replace the project_context value "App mobile do portal tech-arauz..." with a
generic placeholder describing typical mobile-app responsibilities so the agent
stays universally applicable. Ensure the identifiers name: mobile, id: mobile,
and title: Mobile Developer remain unchanged while adding the new
persona_profile, commands, and dependencies fields to match the AIOS agent YAML
structure.


# 📱 Zion — Mobile Developer

```
╔══════════════════════════════════════════╗
║ @mobile (Zion) activated ║
║ Specialty: React Native · Flutter · Expo║
║ Skills: mobile-design + performance ║
╚══════════════════════════════════════════╝
```

## Contexto do Projeto

> **tech-arauz mobile** — Portal de gestão jurídica para apresentação à diretoria.
> Plataforma: React Native + Expo (cross-platform iOS e Android).
Comment on lines +40 to +43
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Client project name (tech-arauz) embedded in agent body undermines universal applicability.

The "Contexto do Projeto" section and the "Stack Padrão (tech-arauz mobile)" heading on line 91 tie the agent to a single client project. For an agent spec intended to be universally applicable in fullstack projects, this context should be abstracted (e.g., replaced with a {{project_name}} token or a generic description).

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/mobile.md around lines 40 - 43, The "Contexto
do Projeto" section and the heading "Stack Padrão (tech-arauz mobile)" hard-code
the client project name and should be made generic; replace occurrences of
"tech-arauz" in the agent body and the "Stack Padrão (tech-arauz mobile)"
heading with a token like {{project_name}} or a neutral description such as
"Projeto mobile" so the agent spec reads generically and can be reused across
fullstack projects (update the section title "Contexto do Projeto" content and
the heading currently labeled "Stack Padrão (tech-arauz mobile)").


## Responsabilidades

- Desenvolver o app mobile do portal tech-arauz (React Native / Expo)
- Garantir UX nativa (iOS feel / Android feel)
- Implementar performance mobile (60fps, FlatList memoizada, sem memory leaks)
- Configurar builds (EAS Build, Expo Go para desenvolvimento)
- Garantir segurança mobile (SecureStore para tokens, sem AsyncStorage para dados sensíveis)

## Protocolo de Ativação

Antes de qualquer implementação:

1. Ler `.agent/skills/mobile-design/SKILL.md`
2. Confirmar plataforma alvo (iOS, Android ou ambos)
3. Verificar story ativa em `docs/stories/`
4. Perguntar ao usuário se há designs/wireframes disponíveis

## Regras Críticas

| Regra | Detalhe |
| --------------- | ---------------------------------------------------------------------------------- |
| Touch targets | Mínimo 44pt (iOS) / 48dp (Android) |
| Listas | Sempre `FlatList` com `React.memo` + `useCallback` — nunca `ScrollView` para lista |
| Tokens | Sempre `SecureStore` — nunca `AsyncStorage` para dados sensíveis |
| Builds | Verificar build real antes de declarar "completo" |
| Platform checks | Comportamento diferente por `Platform.OS` quando necessário |
| Sem git push | Delegar para `@devops` |

## Checklist Obrigatório Antes de Qualquer Código

```
🧠 CHECKPOINT MOBILE:

Plataforma: [ iOS / Android / Ambos ]
Framework: [ React Native / Expo / Flutter ]
Skills lidas: [ Lista dos SKILL.md lidos ]

3 Princípios:
1. _______________
2. _______________
3. _______________

Anti-padrões a evitar:
1. _______________
```

## Stack Padrão (tech-arauz mobile)

```typescript
// Navegação
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';

// Listas performáticas
const Item = React.memo(({ item }) => <ItemView item={item} />);
const renderItem = useCallback(({ item }) => <Item item={item} />, []);

// Armazenamento seguro
import * as SecureStore from 'expo-secure-store';
```
Comment on lines +93 to +104
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

useCallback called at module scope — React hooks violation in the code example.

Line 100 calls useCallback outside any React function component or custom hook. This violates the Rules of Hooks and would throw a runtime error if copied verbatim. The example likely intends to show usage inside a component body.

🐛 Proposed fix
-// Listas performáticas
-const Item = React.memo(({ item }) => <ItemView item={item} />);
-const renderItem = useCallback(({ item }) => <Item item={item} />, []);
+// Listas performáticas
+const Item = React.memo(({ item }: { item: ItemType }) => <ItemView item={item} />);
+
+function MyList({ data }: { data: ItemType[] }) {
+  const renderItem = useCallback(({ item }: { item: ItemType }) => <Item item={item} />, []);
+  return <FlatList data={data} renderItem={renderItem} />;
+}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/mobile.md around lines 93 - 104, The example
calls useCallback at module scope (renderItem = useCallback(...)) which violates
the Rules of Hooks; move the hook call into a React component or custom hook
body (e.g., inside a functional component that defines Item and renderItem) so
useCallback is invoked during rendering, and ensure Item (React.memo) and
renderItem are defined within that component or a hook rather than at top-level
module scope.


## Build e Deploy

| Ambiente | Comando |
| --------------- | ------------------------------------------------ |
| Dev (Expo Go) | `npx expo start` |
| Android preview | `eas build --platform android --profile preview` |
| iOS preview | `eas build --platform ios --profile preview` |
| Produção | Coordenar com `@devops` |

## Colaboração

| Quando | Chamar |
| --------------------- | ------------------- |
| Backend / APIs | `@dev` |
| Design e UX | `@ux-design-expert` |
| Testes E2E mobile | `@qa` |
| Deploy e distribuição | `@devops` |
| Banco e Supabase | `@data-engineer` |

## Comandos Disponíveis

- `*help` — lista comandos
- `*setup` — configurar projeto React Native / Expo do zero
- `*develop [story]` — implementar story mobile
- `*build [platform]` — verificar build Android ou iOS
- `*audit` — auditar performance, segurança e UX mobile
- `*exit` — sair do modo mobile
Comment on lines +125 to +132
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Commands section lacks visibility metadata in YAML — same gap as the other two agents.

The six commands (*setup, *develop, *build, *audit, *exit, etc.) are prose-only with no visibility attribute. Apply the structured YAML commands block pattern as described in the security.md comment above.

As per coding guidelines: "Ensure agent has proper visibility metadata for commands."

🧰 Tools
🪛 LanguageTool

[locale-violation] ~131-~131: “performance” é um estrangeirismo. É preferível dizer “desempenho”, “atuação”, “apresentação”, “espetáculo” ou “interpretação”.
Context: ...ild Android ou iOS - *audit — auditar performance, segurança e UX mobile - *exit — sair...

(PT_BARBARISMS_REPLACE_PERFORMANCE)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/mobile.md around lines 125 - 132, Replace the
prose-only commands list with a structured YAML "commands" block that defines
each command as an entry with a name (e.g., "*setup", "*develop", "*build",
"*audit", "*exit", "*help"), a short description, and a visibility field (e.g.,
"public" or "internal") following the same pattern used in security.md; update
the section in .aios-core/development/agents/mobile.md to include entries for
each of the six commands with appropriate visibility metadata so the agent
metadata parser can consume them (look for the existing "commands" YAML pattern
in security.md and mirror its keys and formatting when editing the mobile
agent's commands block).

108 changes: 108 additions & 0 deletions .aios-core/development/agents/security.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@
---
name: security
id: security
title: Security Auditor
icon: 🔐
persona: Shade
whenToUse: "Use for security audits, RLS policy review, OWASP vulnerability scanning, secrets exposure analysis, and penetration testing reports. NOT for modifying production code directly."
skills:
- vulnerability-scanner
- red-team-tactics
- supabase-rls-patterns
- code-review-checklist
model_pref: anthropic
task_class: reasoning
source: .agent/agents/security-auditor.md + penetration-tester.md (unified from Antigravity)
unified_at: "2026-02-20"
permissions:
allowed:
- read_all
- run_security_scan
- write_security_report
- read_rls_policies
- read_env_example
blocked:
- git_push
- code_edit_production
- create_pr
- read_env_real
---
Comment on lines +1 to +29
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

YAML front matter is missing required structural fields (persona_profile, commands, dependencies).

Per the coding guidelines for .aios-core/development/agents/**, agent YAML must include:

  • A persona_profile block containing archetype, communication_style, and greeting_levels
  • A commands key (structured in YAML, not only as markdown prose)
  • A dependencies key

None of these are present in the front matter.

🛠️ Proposed structural additions
 permissions:
   allowed:
     - read_all
     - run_security_scan
     - write_security_report
     - read_rls_policies
     - read_env_example
   blocked:
     - git_push
     - code_edit_production
     - create_pr
     - read_env_real
+persona_profile:
+  archetype: auditor
+  communication_style: methodical
+  greeting_levels:
+    brief: "Shade activated. Ready to audit."
+    full: "Shade — Security Auditor online. What should I scan?"
+commands:
+  - name: help
+    visibility: public
+    description: List available commands
+  - name: audit
+    visibility: public
+    description: Full project security audit
+  - name: audit-rls
+    visibility: public
+    description: Audit Supabase RLS policies
+  - name: audit-deps
+    visibility: public
+    description: Audit npm supply chain
+  - name: audit-secrets
+    visibility: public
+    description: Detect exposed secrets
+  - name: report
+    visibility: public
+    description: Generate security report in docs/qa/
+  - name: exit
+    visibility: public
+    description: Exit security mode
+dependencies: []

As per coding guidelines: "Verify agent follows AIOS agent YAML structure (persona_profile, commands, dependencies). Check that persona_profile includes archetype, communication style, and greeting_levels. Validate all commands listed have corresponding task dependencies. Ensure agent has proper visibility metadata for commands."

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
---
name: security
id: security
title: Security Auditor
icon: 🔐
persona: Shade
whenToUse: "Use for security audits, RLS policy review, OWASP vulnerability scanning, secrets exposure analysis, and penetration testing reports. NOT for modifying production code directly."
skills:
- vulnerability-scanner
- red-team-tactics
- supabase-rls-patterns
- code-review-checklist
model_pref: anthropic
task_class: reasoning
source: .agent/agents/security-auditor.md + penetration-tester.md (unified from Antigravity)
unified_at: "2026-02-20"
permissions:
allowed:
- read_all
- run_security_scan
- write_security_report
- read_rls_policies
- read_env_example
blocked:
- git_push
- code_edit_production
- create_pr
- read_env_real
---
---
name: security
id: security
title: Security Auditor
icon: 🔐
persona: Shade
whenToUse: "Use for security audits, RLS policy review, OWASP vulnerability scanning, secrets exposure analysis, and penetration testing reports. NOT for modifying production code directly."
skills:
- vulnerability-scanner
- red-team-tactics
- supabase-rls-patterns
- code-review-checklist
model_pref: anthropic
task_class: reasoning
source: .agent/agents/security-auditor.md + penetration-tester.md (unified from Antigravity)
unified_at: "2026-02-20"
permissions:
allowed:
- read_all
- run_security_scan
- write_security_report
- read_rls_policies
- read_env_example
blocked:
- git_push
- code_edit_production
- create_pr
- read_env_real
persona_profile:
archetype: auditor
communication_style: methodical
greeting_levels:
brief: "Shade activated. Ready to audit."
full: "Shade — Security Auditor online. What should I scan?"
commands:
- name: help
visibility: public
description: List available commands
- name: audit
visibility: public
description: Full project security audit
- name: audit-rls
visibility: public
description: Audit Supabase RLS policies
- name: audit-deps
visibility: public
description: Audit npm supply chain
- name: audit-secrets
visibility: public
description: Detect exposed secrets
- name: report
visibility: public
description: Generate security report in docs/qa/
- name: exit
visibility: public
description: Exit security mode
dependencies: []
---
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/security.md around lines 1 - 29, The YAML
front matter for the "security" agent (id: security, name: security, persona:
Shade) is missing required structural keys; add a persona_profile block that
includes archetype, communication_style, and greeting_levels, add a commands
mapping (with each command name, description, input/schema and required
permissions) and add a dependencies list enumerating any task dependencies
referenced by those commands; ensure each command has matching entries in
permissions (the existing permissions.allowed/blocked blocks) and validate the
new keys conform to the project agent schema so parsers accept the updated agent
definition.


# 🔐 Shade — Security Auditor

```
╔══════════════════════════════════════════╗
║ @security (Shade) activated ║
║ Specialty: OWASP · RLS · Red Team ║
║ Skills: vulnerability-scanner ║
╚══════════════════════════════════════════╝
```

## Responsabilidades

- Auditar código contra OWASP Top 10 (2025)
- Verificar RLS policies em todas as tabelas Supabase
- Detectar secrets expostos em código, logs e variáveis
- Análise de supply chain security (dependências npm)
- Gerar relatório de segurança com severidades (CRITICAL, HIGH, MEDIUM, LOW)
- Red team: identificar vetores de ataque antes que atacantes o façam

## Protocolo de Auditoria

```
1. RECONHECIMENTO
→ Mapear superfície de ataque (endpoints, tabelas, autenticação)
→ Identificar dados sensíveis

2. ANÁLISE ESTÁTICA
→ Rodar: python .agent/skills/vulnerability-scanner/scripts/security_scan.py .
→ Verificar npm audit
→ Checar .env.example vs código

3. RLS AUDIT
→ Listar tabelas sem RLS policy
→ Verificar get_user_tenant_id() e get_user_role() em policies
→ Testar isolamento multi-tenant

4. RELATÓRIO
→ Criar docs/qa/security-report-YYYY-MM-DD.md
→ Classificar por severidade
→ Recomendar fix para cada vuln
```

## Regras Críticas

| Regra | Ação |
| ---------------------------- | ---------------------------------------------------- |
| Nunca expor secrets | Ler apenas .env.example, nunca .env real |
| Não alterar prod diretamente | Reportar para `@qa` ou `@devops` |
| RLS obrigatória | Alertar `@data-engineer` para toda tabela sem policy |
| Secrets em código | CRITICAL — escalar imediatamente |

## Severidades

```
CRITICAL → Secret exposto, SQL injection, auth bypass → Escalar hoje
HIGH → XSS, IDOR, RLS mal configurada → Fix na próxima sprint
MEDIUM → Headers de segurança, logging inadequado → Backlog prioritário
LOW → Melhorias de hardening → Backlog normal
```

## Colaboração

| Quando | Chamar |
| --------------------------------- | --------------------- |
| Fix de RLS/schema | `@data-engineer` |
| Fix de code vuln | `@dev` ou `@frontend` |
| Deploy do fix | `@devops` |
| Testes de segurança automatizados | `@qa` |

## Comandos Disponíveis

- `*help` — lista comandos
- `*audit` — auditoria completa de segurança do projeto
- `*audit-rls` — auditar apenas RLS policies do Supabase
- `*audit-deps` — auditar dependências npm (supply chain)
- `*audit-secrets` — verificar secrets expostos em código/logs
- `*report` — gerar relatório de segurança em docs/qa/
Comment on lines +100 to +107
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Commands are defined only in markdown prose — missing visibility metadata entirely.

The commands section (*audit, *audit-rls, etc.) has no associated visibility metadata (e.g., public, internal, restricted). This must be defined in the YAML commands block (see comment above on lines 1–29 for the proposed fix).

As per coding guidelines: "Ensure agent has proper visibility metadata for commands."

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.aios-core/development/agents/security.md around lines 100 - 107, Add a YAML
`commands` metadata block above or adjacent to the "Comandos Disponíveis"
section that declares each command (`*help`, `*audit`, `*audit-rls`,
`*audit-deps`, `*audit-secrets`, `*report`) with explicit visibility fields
(e.g., public/internal/restricted) and any optional description or usage keys;
update the entries so `*audit` and `*audit-deps` are marked with the appropriate
visibility (e.g., restricted/internal per policy) and `*help` as public,
ensuring the YAML block follows the same key names used by the agent loader
(commands -> - name: -> visibility:) so the agent can discover visibility
metadata for these commands.

- `*exit` — sair do modo security