القائمة
Guide complete software development lifecycle from requirements through production. Tech stack selection, ADR templates, branching strategy, testing pyramid, CI/CD, release management, observability setup, and architectural onboarding for new codebases.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Continue iterative work from the last ACCEPTED result plus only the new requested change, instead of replaying the conversation. Use during long multi-turn editing of a document, config, or code file; when the user says "keep going from what we had", asks for a follow-up change to something already approved, or is near plan/token limits in an iterative session. Saves one integrity-checked accepted result, builds a minimal continuation prompt, and never carries rejected drafts or transcript history forward.
Use this when: my tests keep failing randomly, write tests for this code, tests pass locally but fail in CI, how do I mock an HTTP call, my test suite is too slow, debug a failing test, increase test coverage, how do I test a database query, write e2e tests for a user journey, run load tests against my API, set up a test framework, add TDD to my workflow, pytest, Vitest, evaluate my agent, LLM eval, agent flaky, RAG eval, prompt regression, hallucination test, Pass@N, LLM-as-Judge, trace agent execution, test my LangGraph agent, agent guardrails, eval dataset, mock agent tools, agent cost ceiling
Use this when: my API keeps returning 401 or 403, getting 429 rate limit errors, integrate a third-party API, my requests keep timing out, add retry logic with backoff, design a REST API, handle OAuth2 authentication, paginate API responses, CORS errors blocking my requests, secure API keys properly, build consistent error responses, my webhook isn't receiving events, OpenAPI, JWT, circuit breaker, idempotency key, API versioning, rate limiting, token refresh
Use this when: my pipeline is failing, set up CI, speed up my build, why is CI slow, cache miss every build, automate releases, set up GitHub Actions, self-hosted runner not connecting, fix my build, run jobs in parallel, deploy on every merge, build and push Docker image, my workflow is flaky, release automation, test pipeline locally before pushing, OIDC auth in CI, semantic versioning
Use this when: review my code, what's wrong with this function, find bugs before they hit production, is this code secure, check for SQL injection, my error handling is wrong, find edge cases I missed, improve this messy code, this PR needs a review, catch performance problems, my code might have a security vulnerability, refactor this for readability, is this logic doing the right thing, N+1 query, race condition, resource leak, mutable default args, unhandled promise
Use this when: build a data pipeline, my pipeline is not idempotent, clean messy data, convert CSV to Parquet, my data has duplicates, validate schema at ingestion, pipeline fails on re-run, process files larger than memory, schedule a recurring job, upstream schema changed and broke my pipeline, migrate data between systems, query Parquet without loading it, deduplicate records, batch vs stream processing, DuckDB for analytics, choose an orchestrator, slow pandas pipeline
| name | full-sdlc |
| description | Guide complete software development lifecycle from requirements through production. Tech stack selection, ADR templates, branching strategy, testing pyramid, CI/CD, release management, observability setup, and architectural onboarding for new codebases. |
| triggers | ["design a new system","help me architect this project","start a new codebase","what's the right stack for","set up branching strategy","document architecture decision","plan release process","onboard to this codebase"] |
| tags | ["sdlc","architecture","adr","testing","release","ci-cd","onboarding"] |
| author | merged |
Guide every phase of software development without skipping steps. Always document decisions as ADRs. Default to trunk-based development and the test pyramid. Prefer boring technology unless there's a specific reason not to.
| Phase | Default | Notes |
|---|---|---|
| Language | Python / TypeScript | Match team's existing skills |
| Database | PostgreSQL | Unless time-series → TimescaleDB |
| API framework | FastAPI / Express | Matches language default |
| Auth | JWT + refresh tokens | Or managed: Clerk, Auth0 |
| Branching | Trunk-based | Feature branches ≤ 3 days |
| CI | GitHub Actions | Or GitLab CI |
| IaC | Terraform + Ansible | Terraform for infra, Ansible for config |
| Observability | Prometheus + Grafana + Loki | → See grafana-prometheus-monitoring |
IF choosing tech stack:
1. List non-negotiables (language, compliance, team skills)
2. Evaluate 3 options against: performance, scalability, maintainability, cost
3. Document as ADR before writing code
4. Prefer what the team already knows unless gap is critical
IF structuring project:
→ apps/ | packages/ | tooling/ for monorepos
→ src/ | tests/ | docs/ | config/ per service
IF writing tests:
→ 70% unit (fast, isolated)
→ 20% integration (real dependencies, transaction rollback)
→ 10% E2E (critical user flows only)
→ Never skip tests for "speed" — they pay back immediately
IF deploying:
→ semver tags: MAJOR.MINOR.PATCH
→ staging always before production
→ blue-green or canary for zero-downtime
→ automated rollback if error rate > 2% post-deploy
IF something is slow/broken in production:
→ Logs (what happened) → Metrics (how often) → Traces (why slow)
| Anti-Pattern | Use Instead |
|---|---|
| No ADR for major decisions | ADR in docs/adr/ before coding |
| Long-lived feature branches | Trunk-based, feature flags for incomplete features |
| "We'll add tests later" | Test pyramid from day one |
| Manual deployments | CI/CD pipeline with required checks |
| No monitoring until it breaks | Observability before first production deploy |
| Monolith vs microservices by default | Monolith first, split when clear boundary emerges |
→ See cicd-pipeline for GitHub Actions / GitLab CI patterns
→ See code-reviewer for review checklist
→ See grafana-prometheus-monitoring for observability stack
→ See github-workflow for branch/PR strategy details
Must Have (M): Non-negotiable. Project fails without these.
Should Have (S): Important but deferrable under timeline pressure.
Could Have (C): Nice-to-have. Implement if time allows.
Won't Have (W): Explicitly out of scope this release.
Example — User Auth feature:
M: Email/password login, email verification
S: Social login (GitHub, Google)
C: Profile picture upload
W: Video onboarding tutorial (defer to v2)
M+S = 3 weeks | M+S+C = 5 weeks → cut C if shipping at 3 weeks
As a <user> I want <capability> so that <business value>
Acceptance Criteria:
Given <precondition>
When <action>
Then <outcome>
Edge cases:
- Empty/null input behavior
- Concurrent operation behavior
- Permission boundary behavior
# ADR-NNN: <Decision Title>
## Status: [Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
## Context
- What is the problem?
- What constraints apply? (team size, SLA, compliance)
## Decision
We will use <X> because <Y>.
## Consequences
- Benefits: ...
- Risks: ...
- Mitigation: ...
## Alternatives Considered
- Option B: <why rejected>
- Option C: <why rejected>
Example populated:
# ADR-001: PostgreSQL + TypeScript + Turborepo
## Status: Accepted
## Context
- 5 services sharing domain logic
- Team experienced in Node.js
- Complex data relationships
## Decision
PostgreSQL (ACID, JSON, extensions) + TypeScript (type safety) + Turborepo (caching, pipelining)
## Consequences
- Benefits: Type safety across API boundary, strong consistency
- Risks: TypeScript compile overhead, Postgres ops required
- Mitigation: Invest in tooling, runbook docs
## Alternatives Considered
- MySQL: Weaker consistency historically
- MongoDB: Horizontal scaling easier but eventual consistency
# Monorepo (Turborepo)
.
├── apps/
│ ├── web/ (Next.js)
│ ├── api/ (Node.js/FastAPI)
│ └── worker/ (background jobs)
├── packages/
│ ├── shared/ (domain types, utilities)
│ ├── ui/ (reusable components)
│ └── database/ (schema, migrations)
├── turbo.json
└── pnpm-workspace.yaml
# Single service
src/
├── api/ (routes, handlers)
├── services/ (business logic, no I/O)
├── db/ (queries, migrations)
├── workers/ (async jobs)
└── utils/ (pure utilities)
tests/
├── unit/
├── integration/
└── e2e/
docs/
└── adr/ (ADR-001.md, ADR-002.md, ...)
/E2E\ 10% — Full user flow, real browser (Playwright)
/------\
/Integr \ 20% — Real DB + API (TestClient, testcontainers)
/----------\
/ Unit \ 70% — Pure logic, mocked I/O (pytest, Vitest)
/--------------\
test_<what>_<condition>_<expected_outcome>
# Good:
def test_process_payment_with_expired_card_returns_402(): ...
def test_create_user_duplicate_email_raises_conflict(): ...
# Bad:
def test_payment(): ...
def test_user_2(): ...
Business logic: 90%
API handlers: 80%
UI components: 60%
DB queries: 100% (integration tests)
Infrastructure: 80%
# .github/workflows/deploy.yml
name: Deploy
on:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- run: npm ci
- run: npm run test:ci
- run: npm run lint
deploy:
needs: test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm run build
- name: Blue-green deploy
run: |
NEW_ID=$(npm run deploy:new-version)
npm run smoke-test -- $NEW_ID
npm run cutover -- $NEW_ID
MAJOR.MINOR.PATCH
Breaking features Fixes
Process:
1. git tag v1.2.3
2. generate changelog: git log v1.2.2..v1.2.3 --oneline
3. write release notes (include migration guide for MAJOR)
4. deploy staging → verify → deploy production
5. monitor error rate for 30 min
6. automated rollback if error rate > 2%
Logs (what happened):
ERROR: Payment failed for order #123: Stripe timeout
Context: user_id=456, amount=$99.99, retry_count=2
Metrics (how much / how often):
payment_duration_ms{quantile="0.95"} 450
payment_failures_total{reason="stripe_timeout"} 15
Traces (why slow):
Request → ValidateOrder(5ms) → ChargeCard(450ms) → UpdateInventory(20ms)
Slow span: ChargeCard (network + retries)
Alert thresholds:
error_rate > 1%: page on-call
p99_latency > 2s: investigate
failed_deploy: rollback automatically
When inheriting or auditing an existing project:
STRUCTURE
□ Clear folder organization (src/, tests/, docs/, config/)
□ Entry points documented
□ Appropriate .gitignore (no secrets, no build artifacts)
CONTENT QUALITY
□ README with setup + usage
□ CONTRIBUTING.md exists
□ LICENSE file present
□ ADRs in docs/adr/ or equivalent
□ No dead code / unused imports
DEPENDENCY HEALTH
□ Lock file committed (package-lock.json, uv.lock, go.sum)
□ npm audit / pip-audit / trivy clean
□ No major version outdated without reason
AI-READINESS
□ Architecture document (ARCHITECTURE.md or ADRs)
□ Key flows documented (auth, payment, data ingestion)
□ API contracts (OpenAPI or GraphQL schema)
□ Error patterns documented