Menú
CI/CD standards knowledge for validating project compliance with CI conventions
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
AI agent development standards including frontmatter structure, naming conventions, tool access patterns, model selection, and reference documentation structure
UI development skill covering design token usage, shadcn/ui + Radix composition patterns, accessibility requirements, anti-patterns catalog, and brand context for OrganicLever and OSE Platform. Auto-loads when working on TSX components, CSS, or UI design tasks.
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.
Workflow pattern standards for creating multi-agent orchestrations including YAML frontmatter (name, goal, termination, inputs, outputs), execution phases (sequential/parallel/conditional), agent coordination patterns, and Gherkin success criteria. Essential for defining reusable, validated workflow processes.
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
Common software development workflow patterns shared across all language developer agents
| 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 ci-checker and 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 (Rust) | 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% | organiclever-be, CLI apps, Rust libs |
| 80% | Content platforms (ayokoding-www, ose-www) |
| 70% | organiclever-app-web |
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 | Corresponding frontend via E2E |
| Frontend | Corresponding backend via E2E |
| Fullstack | Self-contained (own API routes) |
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).