القائمة
follow spec-driven development, enforce SDD workflow, implement from spec, generate code from plan and tasks, use spec kit plus, run full SDD loop
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Generate Helm 3+ chart structure for todo/task applications. Use for: creating Chart.yaml, values.yaml, and templates/ directory with Deployment and Service manifests. Triggers: "helm chart", "helm template", "helm values", "create helm chart", "helm install", "helm upgrade", "package as helm chart". NOT for: plain Kubernetes YAML (use kubernetes-yaml-best-practices), Kustomize, or kubectl commands. NOT for: CRDs, hooks, subcharts, or advanced Helm features unless explicitly requested.
Apply Kubernetes pod security hardening with securityContext, Pod Security Standards, and container isolation. Use for: adding runAsNonRoot, readOnlyRootFilesystem, dropping capabilities, seccomp profiles, and privilege escalation prevention. Triggers: "secure pod", "pod security", "non-root container", "security context", "k8s security", "harden deployment", "pod security standards", "restricted PSS". NOT for: NetworkPolicies, RBAC, Secrets management, or service mesh security. Use alongside kubernetes-yaml-best-practices for complete manifests.
Generate production-ready Kubernetes YAML manifests following best practices. Use when creating or reviewing: Deployments, Services, ConfigMaps, Secrets, Ingress, PersistentVolumeClaims, or any k8s resource YAML. Triggers: "kubernetes manifest", "deployment yaml", "service yaml", "write k8s resource", "create kubernetes", "k8s yaml", "pod spec", "container spec". NOT for Helm charts, Kustomize overlays, or kubectl commands.
Deploy and test applications on local Minikube Kubernetes cluster. Use for: loading local Docker images to Minikube, exposing services locally via port-forward or minikube service, debugging pods (logs, describe, exec), troubleshooting CrashLoopBackOff/ImagePullBackOff errors. Triggers: "deploy to minikube", "minikube image load", "port-forward", "minikube service", "debug pod", "why is pod crashing", "minikube dashboard", "local kubernetes testing". NOT for: minikube installation, minikube start/stop, cloud Kubernetes, Helm charts, or writing YAML manifests (use kubernetes-yaml-best-practices for YAML).
OCI & OKE specialist for the Todo app hackathon project. Provides infrastructure context, authentication patterns, and deployment guidance for Oracle Kubernetes Engine in me-dubai-1. Use when working with: OKE cluster operations, kubectl commands, oci CLI, Helm deploys to OKE, Dapr/Kafka on OKE, Ingress/LoadBalancer setup, Kubernetes secrets, cloud deployment, OCI networking, node pool management, or troubleshooting OKE auth errors. Triggers: "OKE", "oci", "kubectl", "deploy to cloud", "cluster", "OCI", "oracle kubernetes", "ingress on OKE", "secrets on OKE", "Dapr on OKE", "Kafka on OKE", "node pool", "DOKS alternative".
Dapr service invocation pattern for FastAPI Todo app. Use DaprClient.invoke_method to call other services with user_id propagated via metadata. Use when implementing service-to-service communication in FastAPI applications with user context propagation.
| name | sdd-workflow-enforcer |
| description | follow spec-driven development, enforce SDD workflow, implement from spec, generate code from plan and tasks, use spec kit plus, run full SDD loop |
This skill enforces the complete Spec-Driven Development (SDD) process by ensuring all development follows the prescribed workflow from constitution through implementation. It prevents skipping steps and ensures all code generation traces back to specification artifacts.
Always follow the full Spec-Driven Development process in this exact order:
.specify/memory/constitution.md/sp.specify for WHAT (feature specification)/sp.clarify to ask questions and resolve ambiguities/sp.plan for technical HOW (architecture and implementation plan)/sp.tasks for atomic breakdown (executable tasks)/sp.implement to generate codeThis skill strictly enforces the following rules:
1. Review constitution from .specify/memory/constitution.md
2. Run /sp.specify to define WHAT the feature should do
3. Run /sp.clarify to resolve any ambiguities in the spec
4. Run /sp.plan to design the technical implementation
5. Run /sp.tasks to break down implementation into atomic tasks
6. Run /sp.implement to generate code based on tasks
1. Reference existing specification if available
2. Update /sp.specify if requirements have changed
3. Run /sp.clarify if changes introduce ambiguity
4. Update /sp.plan if architecture needs adjustment
5. Regenerate /sp.tasks if implementation changes
6. Run /sp.implement based on updated tasks
1. Document bug in specification if not already covered
2. Run /sp.specify to clarify correct behavior
3. Run /sp.clarify if edge cases need resolution
4. Run /sp.plan for fix approach
5. Run /sp.tasks for fix implementation steps
6. Run /sp.implement to generate corrected code
⚠️ These actions are forbidden when using SDD workflow:
/sp.clarify when requirements are ambiguous/sp.plan for technical decisions⚠️ All code must trace back to a specification artifact - Every line of code generated must be linked to a specific task derived from the SDD process to maintain traceability and quality.
Before proceeding with any development: