feat: Add 3 specialized agents (frontend, mobile, security)#488
feat: Add 3 specialized agents (frontend, mobile, security)#488adm-toolsmm-ia wants to merge 1 commit intoSynkraAI:mainfrom
Conversation
- Added @frontend (Pixel) — React/Next.js specialist for web performance and accessibility - Added @mobile (Zion) — React Native/Flutter/Expo specialist for cross-platform mobile - Added @security (Shade) — Security auditor for OWASP, RLS policies, and vulnerability scanning These agents extend the AIOS framework with specialized expertise for fullstack projects. Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
adm-toolsmm-ia
requested review from
Pedrovaleriolopez and
oalanicolas
as code owners
|
@adm-toolsmm-ia is attempting to deploy a commit to the Pedro Valério Lopez's projects Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughThis pull request introduces three new agent specification markdown files that define role-based agent profiles within the aios-core development system: a Frontend Specialist, Mobile Developer, and Security Auditor. Each file contains metadata, responsibilities, activation protocols, critical rules, quality metrics, and available commands to guide agent behavior and collaboration workflows. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Suggested labels
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Welcome to aios-core! Thanks for your first pull request.
What happens next?
- Automated checks will run on your PR
- A maintainer will review your changes
- Once approved, we'll merge your contribution!
PR Checklist:
- Tests pass (
npm test) - Linting passes (
npm run lint) - Commit messages follow Conventional Commits
Thanks for contributing!
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Nitpick comments (3)
.aios-core/development/agents/security.md (1)
33-89: Fenced code blocks are missing language specifiers (MD040).Three decorative/plain-text code blocks (banner at line 33, audit protocol at line 52, severity levels at line 84) are flagged by markdownlint (MD040). Use
textorplaintextas the language identifier for plain/decorative blocks.♻️ Proposed fix
-``` +```text ╔══════════════════════════════════════════╗-``` +```text 1. RECONHECIMENTO-``` +```text CRITICAL → Secret exposto...🤖 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 33 - 89, The markdown lint MD040 flags three plain/decorative fenced blocks: the banner block starting with "╔══════════════════════════════════════════╗", the audit protocol block starting with "1. RECONHECIMENTO", and the severity block starting with "CRITICAL →". Fix by adding a language specifier (use "text" or "plaintext") to each fence (i.e., change ``` to ```text) so the banner, protocol list, and severity list are treated as plain text; update the fences around those three blocks accordingly..aios-core/development/agents/mobile.md (1)
32-89: Fenced code blocks without language specifiers (MD040) — banner (line 32) and checklist (line 75).Both the activation banner and the pre-code checkpoint block are missing a language identifier. Use
textorplaintextfor decorative/plain-text blocks.🤖 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 32 - 89, The markdown lint MD040 warns that the two fenced code blocks — the decorative activation banner starting with "╔══════════════════════════════════════════╗" (the `@mobile` (Zion) banner) and the pre-code checkpoint block beginning with "🧠 CHECKPOINT MOBILE:" — lack a language specifier; fix by adding a plain-text language tag (e.g., replace ``` with ```text or ```plaintext) for both the banner and the checklist code fences so they are treated as non-code decorative blocks and satisfy the linter..aios-core/development/agents/frontend.md (1)
35-78: Fenced code blocks without language specifiers (MD040) — same pattern assecurity.md.Lines 35, 52, and 74 all open untagged code blocks. Add
textorplaintextto the banner (line 35), activation protocol (line 52), and quality metrics (line 74) blocks.🤖 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 35 - 78, The markdown contains three untagged fenced code blocks (the ASCII banner under the top section, the activation protocol example under "## Protocolo de Ativação", and the metrics block under "## Métricas de Qualidade") which trigger MD040; edit each triple-backtick fence that opens those blocks and add a language label such as `text` or `plaintext` (e.g., replace ``` with ```text) so the banner, activation protocol, and quality metrics blocks are tagged properly; locate the blocks by the ASCII banner, the "## Protocolo de Ativação" heading, and the "## Métricas de Qualidade" heading to make the changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.aios-core/development/agents/frontend.md:
- Around line 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.
- Around line 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.
- Around line 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.
In @.aios-core/development/agents/mobile.md:
- Around line 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)").
- Around line 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).
- Around line 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.
- Around line 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.
- 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.
In @.aios-core/development/agents/security.md:
- Around line 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.
- Around line 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.
---
Nitpick comments:
In @.aios-core/development/agents/frontend.md:
- Around line 35-78: The markdown contains three untagged fenced code blocks
(the ASCII banner under the top section, the activation protocol example under
"## Protocolo de Ativação", and the metrics block under "## Métricas de
Qualidade") which trigger MD040; edit each triple-backtick fence that opens
those blocks and add a language label such as `text` or `plaintext` (e.g.,
replace ``` with ```text) so the banner, activation protocol, and quality
metrics blocks are tagged properly; locate the blocks by the ASCII banner, the
"## Protocolo de Ativação" heading, and the "## Métricas de Qualidade" heading
to make the changes.
In @.aios-core/development/agents/mobile.md:
- Around line 32-89: The markdown lint MD040 warns that the two fenced code
blocks — the decorative activation banner starting with
"╔══════════════════════════════════════════╗" (the `@mobile` (Zion) banner) and
the pre-code checkpoint block beginning with "🧠 CHECKPOINT MOBILE:" — lack a
language specifier; fix by adding a plain-text language tag (e.g., replace ```
with ```text or ```plaintext) for both the banner and the checklist code fences
so they are treated as non-code decorative blocks and satisfy the linter.
In @.aios-core/development/agents/security.md:
- Around line 33-89: The markdown lint MD040 flags three plain/decorative fenced
blocks: the banner block starting with
"╔══════════════════════════════════════════╗", the audit protocol block
starting with "1. RECONHECIMENTO", and the severity block starting with
"CRITICAL →". Fix by adding a language specifier (use "text" or "plaintext") to
each fence (i.e., change ``` to ```text) so the banner, protocol list, and
severity list are treated as plain text; update the fences around those three
blocks accordingly.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.aios-core/development/agents/frontend.md.aios-core/development/agents/mobile.md.aios-core/development/agents/security.md
| --- | ||
| 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 | ||
| --- |
There was a problem hiding this comment.
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.
| ``` | ||
| LCP < 2.5s (Largest Contentful Paint) | ||
| CLS < 0.1 (Cumulative Layout Shift) | ||
| FID < 100ms (First Input Delay) | ||
| ``` |
There was a problem hiding this comment.
🧩 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.
| ``` | |
| 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.
| ## 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 |
There was a problem hiding this comment.
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.
| --- | ||
| 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." | ||
| 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 | ||
| --- |
There was a problem hiding this comment.
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.
| 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." |
There was a problem hiding this comment.
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.
| 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.
| ## 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). |
There was a problem hiding this comment.
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)").
| ```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'; | ||
| ``` |
There was a problem hiding this comment.
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.
| ## 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 |
There was a problem hiding this comment.
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).
| --- | ||
| 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 | ||
| --- |
There was a problem hiding this comment.
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_profileblock containingarchetype,communication_style, andgreeting_levels - A
commandskey (structured in YAML, not only as markdown prose) - A
dependencieskey
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.
| --- | |
| 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.
| ## 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/ |
There was a problem hiding this comment.
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.
nikolasdehor
left a comment
nikolasdehor
left a comment
There was a problem hiding this comment.
The three agent definitions (frontend, mobile, security) are well-structured with clear responsibilities, collaboration tables, and permission boundaries — nice use of the blocked permissions to enforce separation of concerns (e.g., no git_push for any of them).
Two concerns: (1) The mobile agent has a hardcoded project_context: "App mobile do portal tech-arauz para apresentação à diretoria" in its frontmatter — this is a project-specific reference that should not live in the shared .aios-core/ directory. Per the engine/client separation principle that the project itself advocates, this belongs in a clients/ folder or should be removed from the generic agent definition. (2) The source fields reference paths like .agent/agents/frontend-specialist.md and .agent/agents/security-auditor.md + penetration-tester.md — are these existing files in the repo? If not, the provenance metadata could be confusing for future maintainers.
Good addition to the agent catalog. Cleaning up the project-specific context from the mobile agent would make this ready to merge.
nikolasdehor
left a comment
nikolasdehor
left a comment
There was a problem hiding this comment.
Re-review — os pontos anteriores continuam sem endereçar. Vou expandir com análise mais profunda:
Problema principal: formato incompatível com os agents existentes
Os 12 agents existentes (dev.md, qa.md, architect.md, etc.) seguem uma estrutura bem definida:
ACTIVATION-NOTICEno topo- Bloco YAML completo dentro de
```yaml ```(não YAML frontmatter---) - Campos obrigatórios:
activation-instructions,agent,persona_profile(comgreeting_levels),persona,core_principles,commands(com arraysvisibility: [full, quick, key]),dependencies
Os 3 novos agents usam YAML frontmatter (---) com uma estrutura completamente diferente. Na prática, isso significa que:
- O
unified-activation-pipeline.jsnão consegue parsear esses agents - Não há
activation-instructions— os agents não sabem como se ativar - Os comandos
*listados são apenas prosa, sem conexão a task files em.aios-core/development/tasks/ - O greeting flow (steps 1-6 definidos nos agents existentes) não funciona
Esses agents são documentação, não agents operacionais. Para serem funcionais, precisam ser reestruturados no formato dos agents existentes (usar dev.md ou qa.md como template).
Bugs factuais
frontend.md: FID foi depreciado em março 2024, substituído por INP (Interaction to Next Paint). O threshold correto é INP < 200ms, não FID < 100msmobile.md:useCallbackno escopo de módulo (fora de componente React) viola Rules of Hooks e causa erro de runtime
Pontos da review anterior (não endereçados)
project_context: "App mobile do portal tech-arauz"— referência de cliente específico num agent genéricosourcefields apontam para paths inexistentes (.agent/agents/frontend-specialist.md)whenToUsedo mobile lista Flutter, mas zero conteúdo sobre Flutter
O conteúdo dos agents é bom (responsabilidades claras, tabelas de colaboração), mas o formato impede que sejam operacionais no framework.
Follow-up review (3a revisão)@adm-toolsmm-ia, passaram 4 dias desde a minha segunda review detalhada (25/fev) e não houve resposta nem novos commits. Entendo que pode estar ocupado — sem pressa — mas quero deixar o status claro para os maintainers. Situação atual: nenhum ponto foi endereçado. Os problemas são:
O conteúdo (responsabilidades, tabelas de colaboração, permissões) está bom. O problema é estrutural — precisa ser reestruturado no formato dos agents existentes para ser funcional. Se precisar de ajuda com a reestruturação, posso compartilhar um esqueleto baseado nos agents existentes. |
2 participants
Summary
Add three new specialized agents to expand AIOS framework capabilities across frontend, mobile, and security domains.
What's New
🎨 @frontend (Pixel) — Frontend Specialist
📱 @mobile (Zion) — Mobile Developer
🔐 @security (Shade) — Security Auditor
Impact
Files Added
Summary by CodeRabbit