القائمة
Skill for the tester agent. Choose the right type of tests — unit, integration, contract, e2e, static — based on risk, context, and ROI. Load BEFORE planning any test approach.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Skill for the orchestrator agent. Hierarchical journal system with time-based consolidation. Use at session startup to load context, after completing tasks to record results, and at consolidation intervals. Do NOT manage journals manually.
Generic hierarchical journal system for any agent's operational context with time-based consolidation. Use this skill whenever you need to read, write, or consolidate operational journals — including at session startup, after completing tasks, before ending a session, or when reviewing past work. This skill works for ANY agent type (persona, non-persona, implementer, tester, researcher, etc.). Do NOT attempt to manage journal context manually; always consult this skill for all journal operations.
Skill for the implementer agent. Language-agnostic code implementation workflow for features, bugs, refactors, and tests. Load before writing or modifying any code.
Skill for the orchestrator agent. Complete plan lifecycle management — track, verify, and report on plans from creation through completion. Use whenever creating plans, marking them done, checking active vs completed status, or verifying plan integrity. Do NOT manage plans manually; always use the scripts documented here.
Skill for the orchestrator agent. Decision rules for assigning tasks to the correct specialist agent type. Consult before every subagent dispatch. Load at startup.
Skill for the planner agent. Standard template for producing a final plan ready to hand off to a developer. Provides plan type templates, quality gates, and validation scripts. Do NOT hand off raw, unvalidated plans — always run plan-validate.sh first.
استنادا إلى تصنيف SOC المهني
| name | test-strategy-selection |
| description | Skill for the tester agent. Choose the right type of tests — unit, integration, contract, e2e, static — based on risk, context, and ROI. Load BEFORE planning any test approach. |
| Type | What It Tests | Speed | Confidence | Cost |
|---|---|---|---|---|
| Static analysis | Types, lint, dead code | ⚡ Instant | Low | $0 |
| Unit | Single function/class in isolation | ⚡ ms | Low–Medium | $ |
| Integration | Multiple components working together | 🐢 seconds | High | $$ |
| Contract | Service boundary compatibility | 🐢 seconds | Medium–High | $$ |
| End-to-end | Full user flow through the system | 🐌 minutes | Highest | $$$$ |
Write tests at the lowest level that gives you the confidence you need.
Is a unit test enough?
YES → Write unit test
NO → Is an integration test enough?
YES → Write integration test
NO → Write E2E test
Unnecessary elevation adds cost and fragility without adding confidence.
| Question | Test Type |
|---|---|
| "Does this function do what I expect?" | Unit |
| "Do these components work together?" | Integration |
| "Is my API contract still compatible?" | Contract |
| "Can a user actually do this thing?" | E2E |
| "Is my code well-typed and lint-free?" | Static |
| "Is this performance-sensitive path fast enough?" | Benchmark |
| "Is the migration reversible?" | Integration |
| Dimension | 1 (Low) | 2 (Medium) | 3 (High) | 4 (Critical) |
|---|---|---|---|---|
| Business Impact | Cosmetic, rarely used | Minor feature | Core feature, revenue-impacting | Safety-critical, financial, PII |
| Failure Probability | Stable, tested | Occasional changes | High churn, complex logic | New code, external deps, concurrency |
| Score | Testing Requirement |
|---|---|
| 1-4 | Minimal — smoke tests, unit only |
| 5-6 | Standard — unit + integration |
| 7-9 | Thorough — unit + integration + contract |
| 10-16 | Extensive — unit + integration + contract + E2E |
| Category | Budget | Examples |
|---|---|---|
| 🔴 Critical (10-16) | 40% | Payment, auth, data integrity |
| 🟠 High (7-9) | 30% | Search, user management |
| 🟡 Medium (5-6) | 20% | Profiles, notifications |
| 🟢 Low (1-4) | 10% | Admin panels, logging |
| Dimension | Unit | Integration | Contract | E2E |
|---|---|---|---|---|
| Execution speed | ⚡ ms | 🐢 seconds | 🐢 seconds | 🐌 minutes |
| Write cost | $ | $$ | $$ | $$$$ |
| Maintenance cost | $ | $$ | $ | $$$$ |
| Debugging signal | ✅ Precise | ✅ Good | ✅ Good | ❌ Noisy |
| Flakiness | 🟢 Very low | 🟢 Low | 🟢 Very low | 🔴 High |
| Shape | Ratio | Best For |
|---|---|---|
| Pyramid | 70% Unit / 20% Integration / 10% E2E | Monoliths, logic-heavy apps |
| Trophy | Static + Unit + fat Integration + thin E2E | Component-driven frontends |
| Honeycomb | Many Integration + Contract, few Unit + E2E | Microservices |
The shape debate is mostly semantic. What matters: tests are fast, reliable, and catch meaningful failures.
Greenfield: Start with pyramid (70/20/10). Invest in test infrastructure early — Testcontainers, CI pipeline, sharding.
Legacy (untested): Write a test before every bug fix; write a test before every refactor; start with integration tests — they give more value when boundaries are unclear.
Monolith: Classic pyramid. Resist the temptation to write E2E tests because they're "easy."
Microservices: Contract testing is the linchpin. Unit + Contract dominate; minimize E2E.
| Trigger | Tests to Run |
|---|---|
| Every commit (branch) | Lint, unit, type check |
| Pull request open/update | + Integration, impact-analyzed regression |
| Merge to main | + Contract, component tests |
| Deploy to staging | + E2E (critical paths) |
| Deploy to production | + Smoke tests |
Hard gates (pipeline fails): test failures, critical security vulns, build errors. Soft gates (warning only): coverage drops, medium-severity findings.
Use as signals, not goals:
| Code Type | Target | Test Level |
|---|---|---|
| Business logic | 90%+ branch | Unit |
| API handlers | 80%+ line | Unit + Integration |
| Utility/pure functions | 95%+ | Unit |
| Critical UI components | 60%+ | Integration |
Speed budgets: