Subagents

CLAUDE.md

@@ -8,33 +8,33 @@ afyapowers is a deterministic, phase-gated development workflow plugin for Claud
 
 ## Build / Sync
 
-There is no traditional build system. The project uses a single bash script (`sync.sh`) to generate per-agent distributions from a shared source:
+There is no traditional build system. The project uses a Python script (`sync.py`) to generate per-agent distributions from a shared source:
 
 ```bash
-./sync.sh                  # Sync all agents (stale files removed automatically)
-./sync.sh claude           # Sync specific agent
-./sync.sh --clean          # Nuke output directories before syncing
-./sync.sh cursor --clean   # Nuke + specific agent
+python3 sync.py                  # Sync all agents (stale files removed automatically)
+python3 sync.py claude           # Sync specific agent
+python3 sync.py --clean          # Nuke output directories before syncing
+python3 sync.py cursor --clean   # Nuke + specific agent
 ```
 
-The script reads JSON configs from `src/config/` and produces customized output in `dist/<agent>/`. It handles agent-specific file prefixes, directory prefixes, frontmatter injection, and plugin manifest copying. Requires `jq` (falls back to Python 3 if unavailable).
+The script reads JSON configs from `src/config/` and produces customized output in `dist/<agent>/`. It handles agent-specific file prefixes, directory prefixes, frontmatter extraction, and plugin manifest copying. Requires Python 3.9+ (stdlib only, no pip dependencies).
 
 There are no tests or linting configured for this repository.
 
 ## Architecture
 
 ### Source → Distribution Pipeline
 
-All canonical content lives in `src/`. The `sync.sh` script transforms it into agent-specific distributions in `dist/`:
+All canonical content lives in `src/`. The `sync.py` script transforms it into agent-specific distributions in `dist/`:
 
 - **`src/config/<agent>.json`** — Per-agent config controlling prefixes, output paths, and which features to include
-- **`src/commands/*.md`** + **`*.frontmatter.yaml`** — Slash commands with per-agent frontmatter overrides
-- **`src/skills/*/SKILL.md`** + **`frontmatter.yaml`** — Phase and cross-cutting skills with per-agent frontmatter
+- **`src/commands/*.md`** — Slash commands with embedded multi-agent frontmatter
+- **`src/skills/*/SKILL.md`** — Phase and cross-cutting skills with embedded multi-agent frontmatter
 - **`src/templates/*.md`** — Markdown artifact templates (copied as-is)
 - **`src/hooks/`** — Session-start hook for context restoration (copied with execute permissions preserved)
 - **`src/manifests/<agent>/`** — Plugin manifests per IDE
 
-The frontmatter system uses `.frontmatter.yaml` files with top-level keys matching agent names. Each agent's section becomes the `---` delimited YAML frontmatter in that distribution's output. If an agent has no section, the source file is copied unchanged.
+Each source `.md` file contains `---` delimited YAML frontmatter with agent names as top-level keys (e.g., `claude:`, `cursor:`, `github-copilot:`). The sync script extracts each agent's section and outputs it as the file's frontmatter in the corresponding distribution. If an agent has no section, the file is output without frontmatter.
 
 ### Feature State (Runtime)
 
@@ -51,8 +51,8 @@ The hook at `src/hooks/session-start` is a bash script that detects the active f
 
 ## Key Conventions
 
-- **Never edit files in `dist/`** — they are generated. Always edit the source in `src/` and run `./sync.sh`.
-- When adding a new command: create `src/commands/<name>.md` and `src/commands/<name>.frontmatter.yaml` with sections for each agent that needs custom frontmatter.
-- When adding a new skill: create `src/skills/<name>/SKILL.md` and `src/skills/<name>/frontmatter.yaml`. Supporting prompt files go alongside SKILL.md.
-- When adding a new agent/IDE: create `src/config/<agent>.json`, add `<agent>:` sections to relevant frontmatter files, optionally add a manifest in `src/manifests/<agent>/`, then run `./sync.sh <agent>`.
+- **Never edit files in `dist/`** — they are generated. Always edit the source in `src/` and run `python3 sync.py`.
+- When adding a new command: create `src/commands/<name>.md` with multi-agent frontmatter (agent names as top-level YAML keys within `---` delimiters).
+- When adding a new skill: create `src/skills/<name>/SKILL.md` with multi-agent frontmatter. Supporting prompt files go alongside SKILL.md.
+- When adding a new agent/IDE: create `src/config/<agent>.json`, add `<agent>:` sections to the frontmatter in relevant source files, optionally add a manifest in `src/manifests/<agent>/`, then run `python3 sync.py <agent>`.
 - Plugin version is maintained in `src/manifests/*/plugin.json` files (currently 0.5.0).

WORKFLOW.md

@@ -674,9 +674,10 @@ src/                           →    dist/<ide>/
 
 ### Frontmatter por IDE
 
-Cada comando e skill tem um `.frontmatter.yaml` com configuracoes por IDE:
+Cada comando e skill tem frontmatter multi-agente embutido no proprio arquivo `.md`:
 
-```yaml
+```markdown
+---
 claude:
   name: afyapowers:new
   description: Start a New Feature
@@ -686,6 +687,7 @@ cursor:
 github-copilot:
   name: new
   description: Start a New Feature
+---
 ```
 
 ### Configuracao por IDE
@@ -697,16 +699,16 @@ github-copilot:
 | Gemini | Nenhum | Nenhum | — |
 | GitHub Copilot | Nenhum | Nenhum | `plugin.json` |
 
-### Usando o sync.sh
+### Usando o sync.py
 
 ```bash
-./sync.sh                  # Sincronizar todos os agentes
-./sync.sh claude           # Sincronizar um agente especifico
-./sync.sh --clean          # Limpar antes de sincronizar
-./sync.sh cursor --clean   # Limpar + agente especifico
+python3 sync.py                  # Sincronizar todos os agentes
+python3 sync.py claude           # Sincronizar um agente especifico
+python3 sync.py --clean          # Limpar antes de sincronizar
+python3 sync.py cursor --clean   # Limpar + agente especifico
 ```
 
-> 💡 **Requisito:** `jq` instalado (com fallback para Python 3 se indisponivel).
+> 💡 **Requisito:** Python 3.9+ (stdlib apenas, sem dependencias pip).
 
 ---
 

dist/claude/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "afyapowers",
   "description": "Deterministic, phase-gated development workflow with persistent state and auditability",
-  "version": "0.5.0",
+  "version": "1.0.0",
   "author": {
     "name": "Rafael Papastamatiou",
     "email": "rafael.rodrigues@afya.com.br"

dist/cursor/skills/afyapowers-reviewing/code-reviewer.md → dist/claude/agents/code-quality-reviewer.md

@@ -1,4 +1,10 @@
-# Code Review Agent
+---
+name: code-quality-reviewer
+description: Code quality reviewer — checks implementation for clean code, architecture, testing, and production readiness.
+model: claude-opus-4-6
+effort: high
+---
+# Code Quality Review Agent
 
 You are reviewing code changes for production readiness.
 
@@ -60,6 +66,12 @@ git diff {BASE_SHA}..{HEAD_SHA}
 - Documentation complete?
 - No obvious bugs?
 
+**Code Organization (additional criteria):**
+- Does each file have one clear responsibility with a well-defined interface?
+- Are units decomposed so they can be understood and tested independently?
+- Is the implementation following the file structure from the plan?
+- Did this implementation create new files that are already large, or significantly grow existing files? (Don't flag pre-existing file sizes — focus on what this change contributed.)
+
 ## Output Format
 
 ### Strengths

dist/claude/agents/design-reviewer.md

@@ -0,0 +1,43 @@
+---
+name: design-reviewer
+description: Design document reviewer — validates that a design spec is complete, consistent, and ready for implementation planning.
+model: claude-opus-4-6
+effort: high
+---
+You are reviewing whether a design document is complete and ready for implementation planning.
+
+## Design Document to Review
+
+[DESIGN_FILE_PATH]
+
+## What to Check
+
+| Category | What to Look For |
+|----------|------------------|
+| Completeness | TODOs, placeholders, "TBD", incomplete sections |
+| Coverage | Missing error handling, edge cases, integration points |
+| Consistency | Internal contradictions, conflicting requirements |
+| Clarity | Ambiguous requirements |
+| YAGNI | Unrequested features, over-engineering |
+| Scope | Focused enough for a single plan — not covering multiple independent subsystems |
+| Architecture | Units with clear boundaries, well-defined interfaces, independently understandable and testable |
+
+## CRITICAL
+
+Look especially hard for:
+- Any TODO markers or placeholder text
+- Sections saying "to be defined later" or "will spec when X is done"
+- Sections noticeably less detailed than others
+- Units that lack clear boundaries or interfaces — can you understand what each unit does without reading its internals?
+
+## Output Format
+
+## Design Review
+
+**Status:** ✅ Approved | ❌ Issues Found
+
+**Issues (if any):**
+- [Section X]: [specific issue] - [why it matters]
+
+**Recommendations (advisory):**
+- [suggestions that don't block approval]