القائمة
CI/CD standards knowledge for validating project compliance with CI conventions
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
AI agent development standards including frontmatter structure, naming conventions, tool access patterns, model selection, and reference documentation structure
Comprehensive project planning standards for plans/ directory including folder structure (ideas/, backlog/, in-progress/, done/), stage-aware naming convention (done uses YYYY-MM-DD__identifier/; backlog and in-progress use identifier/ with no date prefix), five-document file organization (README.md, brd.md, prd.md, tech-docs.md, delivery.md for multi-file default; single README.md for trivially-small single-file exception), BRD/PRD content-placement rules, Gherkin acceptance criteria, and the mandatory structured multiple-choice grilling gates (pre-write and post-write) for resolving design decisions with the user. Essential for creating structured, executable project plans.
Trunk Based Development workflow - all development on main branch with small frequent commits, minimal branching, and continuous integration. Covers when branches are justified (exceptional cases only), commit patterns, feature flag usage for incomplete work, environment branch rules (deployment only), and AI agent default behavior (the repo-wide default delivery mode is `worktree-to-pr` -- a short-lived plan branch in a disposable worktree pushed to a draft PR; direct push to main remains available as an explicit selection). Essential for understanding repository git workflow and keeping branches short-lived
Workflow pattern standards for creating multi-agent orchestrations including YAML frontmatter (name, description, tags, status, agents, parameters), execution phases (sequential/parallel/conditional), agent coordination patterns, and Gherkin success criteria. Essential for defining reusable, validated workflow processes.
Common software development workflow patterns shared across all language developer agents
Three-stage content quality workflow pattern (Maker creates, Checker validates, Fixer remediates) with detailed execution workflows. Use when working with content quality workflows, validation processes, audit reports, or implementing maker/checker/fixer agent roles.
| name | ci-standards |
| description | CI/CD standards knowledge for validating project compliance with CI conventions |
| context | inline |
Inline skill providing CI/CD standards knowledge from the governance documentation. Used by swe-*-dev agents to set up new projects correctly and by ci-checker/ci-fixer agents to validate compliance.
| App Type | Required Targets |
|---|---|
| Demo-be backend | codegen, typecheck, lint, build, test:unit, test:quick, test:integration, specs:coverage |
| Demo-fe frontend | codegen, typecheck, lint, build, test:unit, test:quick, specs:coverage |
| Fullstack app | codegen, typecheck, lint, build, test:unit, test:quick, test:integration, specs:coverage |
| CLI app (Go) | typecheck, lint, build, test:unit, test:quick, test:integration, specs:coverage |
| Content platform | typecheck, lint, build, test:unit, test:quick, test:integration, specs:coverage |
| Library | lint, build, test:unit, test:quick |
| E2E runner | lint, test:e2e, test:e2e:ui, specs:coverage |
| Threshold | Projects |
|---|---|
| 90% | Demo-be backends, CLI apps, Go libs, TS backend (ts-effect) |
| 75% | Fullstack (crud-fs-ts-nextjs) |
| 70% | FE apps, crud-fe-ts-nextjs, Dart FE |
Every app with a dev or test:integration target must have:
infra/dev/{app}/docker-compose.yml — Dev environmentinfra/dev/{app}/docker-compose.ci.yml — CI overlay (backends only)infra/dev/{app}/.env.example — Environment variable templateapps/{app}/docker-compose.integration.yml — Integration tests (backends only)| Variant Type | Pairs With |
|---|---|
| Backend (crud-be-*) | Default frontend (crud-fe-ts-nextjs) |
| Frontend (crud-fe-*) | Default backend (crud-be-golang-gin) |
| Fullstack (crud-fs-*) | Self-contained |
All testable projects must consume Gherkin specs at ALL test levels. Unit tests are a superset of Gherkin — they MUST implement ALL Gherkin scenarios plus additional non-Gherkin tests.
Each demo backend/frontend must have a per-variant test workflow (test-{app-name}.yml) calling reusable workflows with CRON schedule (2x daily at WIB 06:00 and 18:00).