[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C0S7YEF9KQ0NFFYVB219PT":3,"skill-same:01M6C0S7YEF9KQ0NFFYVB219PT":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":14,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":54,"updatedAt":55,"install":56,"resources":69},"01M6C0S7YEF9KQ0NFFYVB219PT","ci-github-actions",null,"CI\u002FCD do AS v2 (GitHub Actions). Use ao editar workflows, destravar checks [required], preparar PR para o staging gate, debugar CI vermelha, ou mexer no deploy. Cobre os gates obrigatorios, os 3 marcadores do staging-gate, pytest --no-migrations e os flakes recorrentes.","matheusnorjosa\u002Faprender_sistema","matheusnorjosa","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F117673804?v=4","01M6C0S19FG12BDFBTRWY9TTEQ","Matheus Norjosa","01M6C0S1DF0YB17TKGEYC70GSP",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fci-github-actions\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"actions","ci","github actions","ci github actions","github","ao","flakes","CI\u002FCD","os","as","cd","do","pytest","migrations","gate","use","para","pr","deploy","workflows","2026-11-10 10:12:30",false,"---\nname: ci-github-actions\ndescription: CI\u002FCD do AS v2 (GitHub Actions). Use ao editar workflows, destravar checks [required], preparar PR para o staging gate, debugar CI vermelha, ou mexer no deploy. Cobre os gates obrigatorios, os 3 marcadores do staging-gate, pytest --no-migrations e os flakes recorrentes.\n---\n\n# CI\u002FCD — Aprender Sistema v2 (GitHub Actions)\n\n> **Merge na `main` NÃO deploya** (ADR-018, 2026-07-10). O merge produz um artefato assinado e\n> *promovível*; produção só muda por promoção humana (`promote.yml` + Environment `production`).\n> CI verde continua não sendo burocracia — é o que decide se existe artefato promovível.\n> ~~\"Merge na `main` = deploy direto pra prod via Portainer\"~~ era o **ADR-010**, **revogado**: os\n> jobs `deploy` e `validate_existing_tag` foram **deletados** no **#1516**.\n> SSOT do fluxo: [`v2\u002Fdocs\u002Fspecs\u002Finfra\u002Fci.spec.md`](..\u002F..\u002F..\u002Fv2\u002Fdocs\u002Fspecs\u002Finfra\u002Fci.spec.md). Detalhe por-workflow: [reference\u002Fworkflows.md](reference\u002Fworkflows.md).\n\n## Arquitetura\n\n- **`ci.yaml`** orquestra o backend: `backend-impact` decide se a suíte roda (PR sem impacto em backend pula os jobs pesados); chama o reusable **`_backend-test.yml`** para `backend-tests-core` e `backend-tests-ingest-devtools` (`-n auto --dist loadscope`), faz `coverage combine` (gate **≥85%**) e roda `backend-migrate-integrity`.\n- **`frontend-ci.yml`**: build\u002Flint, react-doctor (exige `--offline`), checklist (meta\u002Fa11y\u002Fsecurity), `[info] e2e journeys`.\n- Segurança\u002Finfra: `security-scan.yml`, `dependency-review-scorecard.yml`, `strict-security-headers.yml`, `architecture-guardrails.yml`, `docs-quality.yml`, `staging-gate-audit.yml`.\n- **`deploy.yaml`** (*Build, sign and release*): pós-merge, **não deploya** — build\u002Fscan\u002Fpush + cosign + tag\u002Frelease. Prod muda por `promote.yml` (gate `production`) + agente pull-based na VM01 (ADR-018).\n- Monitoramento agendado (não bloqueia): `backend-xdist-canary.yml`.\n\n## Checks `[required]` (precisam estar verdes p\u002F merge)\n\n`backend impact` · `backend tests (runner)` · `backend typecheck (pyright)` · `backend rbac-lint` · `docker parity (backend)` · `tests` (agregador) · `docs quality (links + frontmatter)` · `staging gate evidence` · `lint` · `build\u002Flint do frontend` · `checklist tests` · `react doctor quality gate` · `Container Scan` · `Secret Detection` · `Python\u002FFrontend Dependencies` · `dependency review`.\n\n> Se `backend-impact` der `backend_changed=false`, os jobs de teste backend ficam **skipping** (correto p\u002F PR que não toca `v2\u002Fbackend\u002F`) e o agregador `tests` fica verde.\n\n## Procedimento: deixar um PR verde\n\n1. **Localize a falha:** `gh run view \u003Cid> --log-failed` (ou `gh pr checks \u003CPR>`).\n2. **Reproduza local** (CP-01, Docker): `docker exec aprender_dev-web-1 pytest apps\u002Fcore\u002Ftests\u002F -q`; pyright via `cd v2\u002Fbackend && pyright apps\u002Fcore config`; lint com black+isort+flake8 nos arquivos tocados.\n3. **Staging gate** (se tocar `v2\u002Fbackend\u002Fapps\u002F`): ver abaixo — exige marcadores literais no corpo do PR.\n4. **Base mudou →** `gh pr update-branch \u003CPR>` e **esperar o re-run** (~5-15min) antes de mergear; \"N of N required checks expected\" some sozinho.\n5. **Done quando:** `gh pr view \u003CPR> --json mergeStateStatus` = `CLEAN` e 0 checks `FAILURE`\u002Fpending.\n\n## Staging gate — marcadores EXATOS (literais)\n\n`staging-gate-audit.yml` dispara em mudanças sob `v2\u002Fbackend\u002Fapps\u002F` e exige no **corpo do PR** os 3 marcadores **literais** (regex sem acento):\n\n- `- [x] make staging-full executado com sucesso (8\u002F8 PASS)`\n- `- [x] Evidencia anexada no PR`  ← **\"Evidencia\" SEM acento**\n- texto `ALL 8 CHECKS PASSED`\n\nCheckboxes precisam estar **marcados** (`- [x]`). Editar o body re-roda o gate (`on: edited`). PR draft pula o gate.\n\n## Procedimento: levar uma versão a produção\n\n1. **Merge na `main`** → `deploy.yaml` builda, escaneia e faz push das imagens, dispara o `sign` (cosign keyless + SLSA) e gera a tag imutável `vYYYY.MM.DD-\u003Csha7>` + GitHub Release. `gh release list --limit 3` mostra a tag. **A tag não prova assinatura:** `tag_and_release` tem `needs: [prepare, build_and_push]` e o `sign` está fora do `needs` **e** fora do `if` (`.github\u002Fworkflows\u002Fdeploy.yaml:231-235`) — tag e Release nascem mesmo com o `sign` falhando. O gate **duro** de assinatura é o `promote.yml` (`.github\u002Fworkflows\u002Fpromote.yml:139`, *“Gate duro — imagens DEVEM estar assinadas (cosign)”*), e o agente da VM01 recusa digest que não passe no `cosign verify`.\n2. **Promover:** `gh workflow run promote.yml -f release=v2026.MM.DD-\u003Csha7>`.\n3. **Aprovar** no GitHub Environment `production` (*required reviewer*). Enquanto isso o run fica `status: waiting` — não é falha.\n4. **A VM01 puxa** (systemd, ~60s) e aplica **por digest**; o `PUT` é do `aprender-applier` em `127.0.0.1:9443`. Cada degrau é **fail-closed** — `REFUSE` significa que produção não mudou.\n5. **Verificar:** `\u002Fapi\u002Fversion\u002F` devolve a **release (tag)**, **não** o digest — payload `{\"version\": ...}`, com `git_sha`\u002F`build_date` só para `is_staff` (`v2\u002Fbackend\u002Fapps\u002Fcore\u002Fviews_health.py:93-99`). Compare com o `release` do `production.json`; mais `\u002Fapi\u002Freadyz\u002F`. A cor do job **não** é evidência.\n\n**Rollback** = promover a tag anterior com `-f rollback=true` (ainda exige `sequence` > selo). Não existe `deploy.yaml -f rollback_tag=...`, e não há auto-rollback — migrations são forward-only.\n\n## Gotchas recorrentes (já nos morderam)\n\n- **`pytest --no-migrations`** no gate (M4 #1404): seeds RBAC vêm de fixtures (`ensure_base_groups` + `seed_functional_permissions`), não das RunPython. Testes que exercitam data-migrations levam `@pytest.mark.migrations` e rodam no job `backend-migrate-integrity`.\n- **`blob unknown to registry`** no buildx `--push` = **flake transitório** do Docker Hub; `gh run rerun \u003Cid> --failed`. Prod intacta (nem foi tocada).\n- **Rajada de merges** = N builds, **não** N deploys. Nenhum deles muda produção; o que interessa é a tag do HEAD existir e estar assinada. ~~\"alguns falham `curl 28` no Portainer 9443 mas o último vence\"~~ era do job `deploy`, **deletado** (#1516) — o *false-red* do `:9443` deixou de aparecer no CI porque a confirmação passou a ser feita de dentro da VM.\n- **`promote.yml` parado em `waiting`** = gate do Environment `production` esperando reviewer. Não é falha de CI.\n- **`REFUSE compose_drift`** no applier = `docker-compose.prod.yml` mudou sem re-captura do `trust\u002Fcompose.pinned.yml` na VM. É o comportamento desejado, não um bug.\n- **Gate Trivy travando por CVE de SO** (não da app): cache-bust do `apt\u002Fapk upgrade` por `GIT_SHA` no `Dockerfile.prod` (#1407).\n- **Codecov**: upload só roda `if: env.CODECOV_TOKEN != ''` (tokenless é rejeitado) — sem o secret, é pulado; cobertura é enforçada no gate, não no Codecov.\n- **react-doctor**: score depende de telemetria remota → exige `--offline` para ser determinístico.\n- **Duração de job**: medir sob demanda (`gh run list --workflow \u003Carquivo> --event pull_request` + `gh run view \u003Cid> --json jobs`). A telemetria agendada foi removida: 38 execuções vermelhas seguidas sem ação, e a janela congelou quando o gatilho `push` saiu.\n\n## NÃO fazer\n\n- Nunca `git push` direto na `main` (CP-07, enforce por hook) — sempre branch + PR.\n- Nunca `systemctl restart docker` na VM01 (Kaspersky\u002FKESL derruba o site) — usar `systemctl restart kesl`.\n- Mudança em `docker-compose.prod.yml` **não** viaja pelo pipeline: exige update manual no Editor do Portainer **e** re-captura do `trust\u002Fcompose.pinned.yml` na VM01 (o applier reenvia o pinado, e recusa se o vivo divergir).\n- Nunca tratar merge na `main` como deploy, nem procurar um job `deploy` no `deploy.yaml` — ele não existe desde o #1516.\n","# CI\u002FCD — Aprender Sistema v2 (GitHub Actions)\n\n> **Merge na `main` NÃO deploya** (ADR-018, 2026-07-10). O merge produz um artefato assinado e\n> *promovível*; produção só muda por promoção humana (`promote.yml` + Environment `production`).\n> CI verde continua não sendo burocracia — é o que decide se existe artefato promovível.\n> ~~\"Merge na `main` = deploy direto pra prod via Portainer\"~~ era o **ADR-010**, **revogado**: os\n> jobs `deploy` e `validate_existing_tag` foram **deletados** no **#1516**.\n> SSOT do fluxo: [`v2\u002Fdocs\u002Fspecs\u002Finfra\u002Fci.spec.md`](..\u002F..\u002F..\u002Fv2\u002Fdocs\u002Fspecs\u002Finfra\u002Fci.spec.md). Detalhe por-workflow: [reference\u002Fworkflows.md](reference\u002Fworkflows.md).\n\n## Arquitetura\n\n- **`ci.yaml`** orquestra o backend: `backend-impact` decide se a suíte roda (PR sem impacto em backend pula os jobs pesados); chama o reusable **`_backend-test.yml`** para `backend-tests-core` e `backend-tests-ingest-devtools` (`-n auto --dist loadscope`), faz `coverage combine` (gate **≥85%**) e roda `backend-migrate-integrity`.\n- **`frontend-ci.yml`**: build\u002Flint, react-doctor (exige `--offline`), checklist (meta\u002Fa11y\u002Fsecurity), `[info] e2e journeys`.\n- Segurança\u002Finfra: `security-scan.yml`, `dependency-review-scorecard.yml`, `strict-security-headers.yml`, `architecture-guardrails.yml`, `docs-quality.yml`, `staging-gate-audit.yml`.\n- **`deploy.yaml`** (*Build, sign and release*): pós-merge, **não deploya** — build\u002Fscan\u002Fpush + cosign + tag\u002Frelease. Prod muda por `promote.yml` (gate `production`) + agente pull-based na VM01 (ADR-018).\n- Monitoramento agendado (não bloqueia): `backend-xdist-canary.yml`.\n\n## Checks `[required]` (precisam estar verdes p\u002F merge)\n\n`backend impact` · `backend tests (runner)` · `backend typecheck (pyright)` · `backend rbac-lint` · `docker parity (backend)` · `tests` (agregador) · `docs quality (links + frontmatter)` · `staging gate evidence` · `lint` · `build\u002Flint do frontend` · `checklist tests` · `react doctor quality gate` · `Container Scan` · `Secret Detection` · `Python\u002FFrontend Dependencies` · `dependency review`.\n\n> Se `backend-impact` der `backend_changed=false`, os jobs de teste backend ficam **skipping** (correto p\u002F PR que não toca `v2\u002Fbackend\u002F`) e o agregador `tests` fica verde.\n\n## Procedimento: deixar um PR verde\n\n1. **Localize a falha:** `gh run view \u003Cid> --log-failed` (ou `gh pr checks \u003CPR>`).\n2. **Reproduza local** (CP-01, Docker): `docker exec aprender_dev-web-1 pytest apps\u002Fcore\u002Ftests\u002F -q`; pyright via `cd v2\u002Fbackend && pyright apps\u002Fcore config`; lint com black+isort+flake8 nos arquivos tocados.\n3. **Staging gate** (se tocar `v2\u002Fbackend\u002Fapps\u002F`): ver abaixo — exige marcadores literais no corpo do PR.\n4. **Base mudou →** `gh pr update-branch \u003CPR>` e **esperar o re-run** (~5-15min) antes de mergear; \"N of N required checks expected\" some sozinho.\n5. **Done quando:** `gh pr view \u003CPR> --json mergeStateStatus` = `CLEAN` e 0 checks `FAILURE`\u002Fpending.\n\n## Staging gate — marcadores EXATOS (literais)\n\n`staging-gate-audit.yml` dispara em mudanças sob `v2\u002Fbackend\u002Fapps\u002F` e exige no **corpo do PR** os 3 marcadores **literais** (regex sem acento):\n\n- `- [x] make staging-full executado com sucesso (8\u002F8 PASS)`\n- `- [x] Evidencia anexada no PR`  ← **\"Evidencia\" SEM acento**\n- texto `ALL 8 CHECKS PASSED`\n\nCheckboxes precisam estar **marcados** (`- [x]`). Editar o body re-roda o gate (`on: edited`). PR draft pula o gate.\n\n## Procedimento: levar uma versão a produção\n\n1. **Merge na `main`** → `deploy.yaml` builda, escaneia e faz push das imagens, dispara o `sign` (cosign keyless + SLSA) e gera a tag imutável `vYYYY.MM.DD-\u003Csha7>` + GitHub Release. `gh release list --limit 3` mostra a tag. **A tag não prova assinatura:** `tag_and_release` tem `needs: [prepare, build_and_push]` e o `sign` está fora do `needs` **e** fora do `if` (`.github\u002Fworkflows\u002Fdeploy.yaml:231-235`) — tag e Release nascem mesmo com o `sign` falhando. O gate **duro** de assinatura é o `promote.yml` (`.github\u002Fworkflows\u002Fpromote.yml:139`, *“Gate duro — imagens DEVEM estar assinadas (cosign)”*), e o agente da VM01 recusa digest que não passe no `cosign verify`.\n2. **Promover:** `gh workflow run promote.yml -f release=v2026.MM.DD-\u003Csha7>`.\n3. **Aprovar** no GitHub Environment `production` (*required reviewer*). Enquanto isso o run fica `status: waiting` — não é falha.\n4. **A VM01 puxa** (systemd, ~60s) e aplica **por digest**; o `PUT` é do `aprender-applier` em `127.0.0.1:9443`. Cada degrau é **fail-closed** — `REFUSE` significa que produção não mudou.\n5. **Verificar:** `\u002Fapi\u002Fversion\u002F` devolve a **release (tag)**, **não** o digest — payload `{\"version\": ...}`, com `git_sha`\u002F`build_date` só para `is_staff` (`v2\u002Fbackend\u002Fapps\u002Fcore\u002Fviews_health.py:93-99`). Compare com o `release` do `production.json`; mais `\u002Fapi\u002Freadyz\u002F`. A cor do job **não** é evidência.\n\n**Rollback** = promover a tag anterior com `-f rollback=true` (ainda exige `sequence` > selo). Não existe `deploy.yaml -f rollback_tag=...`, e não há auto-rollback — migrations são forward-only.\n\n## Gotchas recorrentes (já nos morderam)\n\n- **`pytest --no-migrations`** no gate (M4 #1404): seeds RBAC vêm de fixtures (`ensure_base_groups` + `seed_functional_permissions`), não das RunPython. Testes que exercitam data-migrations levam `@pytest.mark.migrations` e rodam no job `backend-migrate-integrity`.\n- **`blob unknown to registry`** no buildx `--push` = **flake transitório** do Docker Hub; `gh run rerun \u003Cid> --failed`. Prod intacta (nem foi tocada).\n- **Rajada de merges** = N builds, **não** N deploys. Nenhum deles muda produção; o que interessa é a tag do HEAD existir e estar assinada. ~~\"alguns falham `curl 28` no Portainer 9443 mas o último vence\"~~ era do job `deploy`, **deletado** (#1516) — o *false-red* do `:9443` deixou de aparecer no CI porque a confirmação passou a ser feita de dentro da VM.\n- **`promote.yml` parado em `waiting`** = gate do Environment `production` esperando reviewer. Não é falha de CI.\n- **`REFUSE compose_drift`** no applier = `docker-compose.prod.yml` mudou sem re-captura do `trust\u002Fcompose.pinned.yml` na VM. É o comportamento desejado, não um bug.\n- **Gate Trivy travando por CVE de SO** (não da app): cache-bust do `apt\u002Fapk upgrade` por `GIT_SHA` no `Dockerfile.prod` (#1407).\n- **Codecov**: upload só roda `if: env.CODECOV_TOKEN != ''` (tokenless é rejeitado) — sem o secret, é pulado; cobertura é enforçada no gate, não no Codecov.\n- **react-doctor**: score depende de telemetria remota → exige `--offline` para ser determinístico.\n- **Duração de job**: medir sob demanda (`gh run list --workflow \u003Carquivo> --event pull_request` + `gh run view \u003Cid> --json jobs`). A telemetria agendada foi removida: 38 execuções vermelhas seguidas sem ação, e a janela congelou quando o gatilho `push` saiu.\n\n## NÃO fazer\n\n- Nunca `git push` direto na `main` (CP-07, enforce por hook) — sempre branch + PR.\n- Nunca `systemctl restart docker` na VM01 (Kaspersky\u002FKESL derruba o site) — usar `systemctl restart kesl`.\n- Mudança em `docker-compose.prod.yml` **não** viaja pelo pipeline: exige update manual no Editor do Portainer **e** re-captura do `trust\u002Fcompose.pinned.yml` na VM01 (o applier reenvia o pinado, e recusa se o vivo divergir).\n- Nunca tratar merge na `main` como deploy, nem procurar um job `deploy` no `deploy.yaml` — ele não existe desde o #1516.\n",{"name":5,"description":7},"main","9e3a882d83e0853bdc570ae9d89c02d2a53bed82",".agents\u002Fskills\u002Fci-github-actions","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa","Dev Python | IA | Automation | HTML | CSS | Data | Process | Projects","2026-11-13 03:21:06",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add matheusnorjosa\u002Faprender_sistema --skill ci-github-actions",{"tool":62,"command":63},"bunx","bunx skills add matheusnorjosa\u002Faprender_sistema --skill ci-github-actions",{"tool":65,"command":66},"pnpm","pnpm dlx skills add matheusnorjosa\u002Faprender_sistema --skill ci-github-actions","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fci-github-actions\u002FSKILL.md",true,[70],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"reference\u002Fworkflows.md","REFERENCE","参考文档",4245,"https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fci-github-actions\u002Freference\u002Fworkflows.md",[77,112,134,155,165,197],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":91,"publishedAt":44},"01M6C0WHSP7S2QMJGGMQRXJ6PD","writing-standards","Apply AS v2 technical-writing standards (clarity, brevity, active voice, Python\u002FDjango conventions). Use when writing a README, a docstring (PEP 257), a commit message, a PR description, an error message, or any technical doc.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwriting-standards\u002FSKILL.md",[83,86],{"categoryNo":84,"categoryName":85,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[92,93,94,95,96,41,97,98,99,100,101,102,103,104,105,106,33,107,108,109,110,111],"writing","writing standards","standards","python","commit","pr description","commit message","doc","voice","clarity","django","technical","README","message","active","error","technical-writing","brevity","docstring","when",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":44},"01M6C0WG2SBP9PJG1YQFGGVJAR","verification-gate","Verify before claiming success. Use when about to say something works\u002Fis done, after implementing a feature, after a bugfix, or before pushing — run the proof command and confirm output first.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fverification-gate\u002FSKILL.md",[],[119,120,38,121,122,123,124,39,125,126,127,128,129,130,131,132,133,111],"verification","verification gate","run","first","verify","command","verify before claiming","say","done","feature","proof","bugfix","output","about","implementing",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":143,"publishedAt":44},"01M6C0WE010G12KH45YZW6M7K5","test-driven-development","Write the failing test before the implementation in AS v2 (pytest + Django\u002FDRF). Use when implementing a feature or fixing a bug, before any production code is written.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[140],{"categoryNo":141,"categoryName":142,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[144,145,146,147,148,149,102,150,39,151,152,36,128,33,153,133,111,154],"test","test driven development","development","driven","code","Production","write","bug","implementation","drf","failing",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":44},"01M6C0WC6Y81XRVBJQSTKA96XQ","subagent-development","Orquestra subagents no AS v2 — decompõe a tarefa em domínios independentes, paraleliza e revisa em 2 estágios. Use ao delegar exploração, implementação ou validação cross-arquivo para acelerar o trabalho e poupar o contexto principal.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsubagent-development\u002FSKILL.md",[],[146,162,163,40,164,39,29,33],"subagent","subagent development","subagents",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":44},"01M6C0W9W8D6JJWXW28Q7ZHAC9","security-scan","Automated security scanning for AS v2. Use before commits or when reviewing changes for vulnerabilities. Runs dependency audit (pip-audit, npm audit), secret detection (grep patterns), and code pattern scanning (SQL injection, XSS, eval, pickle, hardcoded secrets). Integrates with project hooks system.","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fsecurity-scan\u002FSKILL.md",[],[172,173,174,175,176,148,177,178,179,180,181,182,183,184,185,186,187,188,39,189,190,191,33,192,193,194,195,196,111],"security","security scan","scan","vulnerabilities","sql","npm","audit","dependency audit","detection","injection","xss","secrets","pip-audit","commits","system","grep","eval","hooks","security scanning","project","with","true","pip","for","changes",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":206,"publishedAt":44},"01M6C0W7RE3G3C2852YXQKR5J9","resume-handoff","Resume work from a saved handoff document, validating its state against the current codebase before continuing. Use when resuming work from a saved handoff after a context clear or in a new session (path, session name, or GitHub issue).","https:\u002F\u002Fgithub.com\u002Fmatheusnorjosa\u002Faprender_sistema\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fresume-handoff\u002FSKILL.md",[203],{"categoryNo":204,"categoryName":205,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000038","人力资源",[207,208,209,28,210,211,212,213,214,39,215,216,217,218,219,220,221,222,111,223],"handoff","resume handoff","resume","state","new session","work","context","session","github issue","issue","document","clear","name","saved","codebase","resuming","new"]