← all publishers

parvez3019

@parvez3019 source repo

21 published skills

  1. Idempotency And Immutability · parvez3019 bundle
    Make operations safe to repeat and data safe to share. Covers designing idempotent commands, consumers and jobs, idempotency keys and deduplication stores, conditional updates and natural idempotency, exactly-once effect over at-least-once delivery, plus immutable value objects and events, defensive copying, safe publication across threads, append-only history versus in-place mutation, and where mutability is still the right answer. Use when writing an operation a client or broker may retry, a message handler, a scheduled job, a value type, or shared state, and when the user says 'idempotent', 'duplicate', 'retry safety', 'exactly once', 'immutable', 'defensive copy', or 'thread safe'. This skill governs repeatability and mutability — retry and breaker mechanics belong to resilience-patterns, the idempotency-key header contract to api-contracts.
    0 installs
  2. Data Access · parvez3019 bundle
    Write the persistence layer so it is correct under concurrency and fast under load. Covers repository implementations that return domain types, ORM discipline and the N+1 problem, explicit transaction boundaries and isolation levels, optimistic and pessimistic locking, connection pool sizing, keyset pagination, indexing and query plans, batching, caching with a defined invalidation story, and zero-downtime schema migrations. Use when writing a repository, a query, a migration, or a caching layer, when diagnosing a slow or deadlocking query, or when the user says 'repository', 'ORM', 'query', 'N+1', 'transaction', 'migration', 'index', 'connection pool', or 'lock'. This skill governs how data is stored and fetched — the shape of domain types belongs to domain-modelling, read models and consistency to cqrs-and-consistency.
    0 installs
  3. Design First · parvez3019 bundle
    Facilitate design before code through progressive disclosure: climb from context to components to interactions to contracts, asking questions and stopping for approval at each level instead of emitting a finished design. Covers the four-level ladder, depth calibration, approval gates, and how to record the result as a durable blueprint. Use before implementing a new service, endpoint, event, or integration, and when the user says 'design', 'blueprint', 'how should we build', 'spec this out', or 'think before coding'. This skill governs the facilitation process — the design content itself belongs to service-boundaries, api-contracts, domain-modelling, and resilience-patterns.
    0 installs
  4. API Contracts · parvez3019 bundle
    Design and evolve the contracts that cross a service boundary — synchronous APIs and published events — specification first. Covers resource and operation modelling, OpenAPI and AsyncAPI as source of truth, backward-compatible evolution and versioning, RFC 9457 problem details, idempotency keys, pagination and filtering, and event schema compatibility modes. Use when adding or changing an endpoint, message, or published event, when reviewing a schema, or when the user says 'API design', 'contract', 'OpenAPI', 'AsyncAPI', 'versioning', 'breaking change', 'REST', or 'event schema'. This skill governs what crosses a boundary — not where boundaries fall (see service-boundaries), not how contracts are verified (see contract-testing).
    0 installs
  5. API Protocols · parvez3019 bundle
    Choose the right protocol for an interface and use it the way it was designed to be used. Covers REST resource and cache semantics, GraphQL schema design with N+1 batching, depth and complexity limits and persisted queries, gRPC service and message design with streaming and deadlines, WebSockets and Server-Sent Events for push with reconnection, heartbeats and backpressure, and the selection criteria between them. Use when starting a new interface, adding a subscription or stream, exposing an internal service, or when the user says 'REST', 'GraphQL', 'gRPC', 'WebSocket', 'SSE', 'streaming', 'real time', or 'which protocol'. This skill governs protocol choice and protocol-specific craft — contract shape, versioning and error semantics belong to api-contracts.
    0 installs
  6. Stack Profile · parvez3019 bundle
    Record this project's technology choices once, so every other skill speaks the team's actual language instead of generic pattern names. Detects the language, framework, datastore, broker, test tooling, contract tooling, secret manager, and deployment platform from the repository, confirms the gaps by interview, and writes .msskills/stack.md plus a starter .msskills/config.yaml. Use on first setup in a repository, after adopting a new framework or broker, when guidance from other skills feels generic, or when the user says 'set up', 'stack profile', 'configure the skills', or 'onboard this repo'. Run this before the workflows — it is what turns 'add a circuit breaker' into the project's own library and idiom.
    0 installs
  7. Test Strategy · parvez3019 bundle
    Choose the right test level for each behaviour and write tests that fail only for real reasons. Covers the microservice test portfolio — unit, component (service in isolation with real infrastructure and stubbed collaborators), integration, and narrow end-to-end — plus what each level must not own, test doubles discipline, determinism and flakiness, arrange-act-assert structure, assertion quality, coverage versus value, mutation testing, and test data management. Use when writing or reviewing any test, deciding what level to test at, diagnosing a flaky or slow suite, or when the user says 'tests', 'unit test', 'component test', 'test pyramid', 'mocking', 'flaky', or 'coverage'. This skill governs test design inside a service — cross-service contract verification belongs to contract-testing.
    0 installs
  8. Design Service · parvez3019
    Run a design session before code exists, producing an approved blueprint the implementation workflow can build from. Climbs the four design levels — context, components, interactions, contracts — pausing for approval at each, and pulls in boundary, data, API, resilience, and security thinking at the level where each belongs. Use before building a new service, capability, endpoint, or integration, when a change needs agreement before code, or when the user says 'design this', 'blueprint', 'spec this out', 'how should we build', or 'plan the service'. Produces .msskills/designs/<feature>.md; implement-service refuses to start without it.
    0 installs
  9. Review Service · parvez3019
    Audit service code against every microservices principle and report severity-ranked findings, each anchored to a file, a line, and the rule it breaks. Covers scoping a review to a diff, branch, pull request or whole service, running the applicable principle checklists and anti-pattern scans, verifying each candidate finding against a concrete failure scenario, and separating genuine defects from deliberate trade-offs. Use before merging, when reviewing a pull request or a diff, when auditing an existing service, or when the user says 'review', 'code review', 'audit this', or 'is this ready to ship'. Reports findings and does not change code — to apply fixes, follow up with implement-service or refactor-safely.
    0 installs
  10. Secure Service · parvez3019 bundle
    Apply security controls at every trust boundary of a service. Covers the OWASP API Security Top 10 with object- and function-level authorisation first, service-to-service authentication with mTLS or signed tokens, input validation and injection prevention, secrets handling, output and error hygiene, PII classification and data protection, rate limiting of sensitive business flows, and supply-chain integrity through pinning, SBOMs and provenance. Use when writing or reviewing a handler, a client call, a query, an authorisation check, a dependency change, or anything touching credentials, tokens, or personal data; also when the user says 'security', 'auth', 'vulnerability', 'secrets', 'OWASP', or 'threat model'. This skill governs trust boundaries — not contract shape (see api-contracts), not failure behaviour (see resilience-patterns).
    0 installs
  11. Refactor Safely · parvez3019
    Change the structure of existing code without changing its behaviour, in verified steps small enough to abandon. Covers pinning current behaviour with characterisation tests before touching anything, sequencing small reversible transformations, keeping the build green throughout, separating refactoring from behaviour change, and extracting a service from a monolith by strangler fig. Use when improving structure, paying down design debt, preparing code for a feature, splitting a module or service, or when the user says 'refactor', 'clean this up', 'restructure', 'extract', 'strangle', or 'reduce coupling'. This workflow preserves behaviour — to add or change behaviour use implement-service, to audit without changing use review-service.
    0 installs
  12. Contract Testing · parvez3019 bundle
    Prove that a consumer and a provider still agree, without deploying them together. Covers the consumer-driven flow — consumer expectations, broker publication, provider verification, and a can-i-deploy gate in the pipeline — plus provider-driven and bi-directional variants, message and event contracts for Kafka or queues, contract versioning with branches and environments, pending contracts, and what a contract test must never assert. Use when adding or changing an integration between two services, when a consumer breaks after a provider release, when wiring deployment gates, or when the user says 'contract test', 'Pact', 'consumer-driven', 'can-i-deploy', or 'provider verification'. This skill governs cross-service agreement — contract design belongs to api-contracts, in-service test levels to test-strategy.
    0 installs
  13. Domain Modelling · parvez3019 bundle
    Design the classes that carry business meaning, using tactical domain-driven design. Covers entities versus value objects, aggregate boundaries justified by a named invariant, domain services, domain events, factories, the ubiquitous language, making illegal states unrepresentable, and keeping behaviour on the type that owns the rule rather than in a service. Use when creating or changing a domain class, choosing an aggregate boundary, deciding whether something is an entity or a value, naming a domain concept, or when the user says 'domain model', 'DDD', 'aggregate', 'entity', 'value object', 'domain class', or 'business rules'. This skill governs the shape of domain types — persistence craft belongs to data-access, read models and consistency to cqrs-and-consistency, service-level boundaries to service-boundaries.
    0 installs
  14. Implement Service · parvez3019
    Turn an approved design into working code and tests, built inside-out one layer at a time, with every principle's checklist run before anything is presented. Covers implementation ordering, per-component validation against architecture, data, resilience, security and configuration rules, writing tests alongside the code at the right level, and pacing the work so review happens while it is still cheap. Use after design-service has produced an approved blueprint, or when the user says 'implement', 'build it', 'code this up', or 'write the service'. This workflow writes code — for changing existing code safely see refactor-safely, for auditing it see review-service.
    0 installs
  15. Clean Architecture · parvez3019 bundle
    Place code in the right layer and keep dependencies pointing inward, inside a single service. Covers ports and adapters (hexagonal) layering, the dependency rule, SOLID applied at class and service level, anti-corruption layers, framework isolation, and choosing a design pattern only when a named force demands it. Use when writing or reviewing any implementation code, deciding where a class belongs, wiring a dependency, adding a framework annotation to domain code, or when the user says 'architecture', 'layering', 'SOLID', 'coupling', 'hexagonal', 'design pattern', or 'where should this go'. This skill governs structure inside one service — not where services divide (see service-boundaries), not aggregate rules (see domain-modelling), not adapter craft (see infrastructure-adapters).
    0 installs
  16. Service Boundaries · parvez3019 bundle
    Decide where a service ends and the next one begins, using domain-driven strategic design. Covers bounded contexts, context maps and integration patterns, ubiquitous language, autonomy and coupling tests, the modular-monolith-first bias, and extraction by strangler fig. Use when proposing a new service, splitting or merging existing ones, naming a module, deciding which service owns a piece of data, or when the user says 'should this be its own service', 'boundaries', 'decompose', 'bounded context', or 'microservice or monolith'. This skill governs where boundaries fall — not what crosses them (see api-contracts), not internal layering (see clean-architecture), not aggregate design (see domain-modelling).
    0 installs
  17. Resilience Patterns · parvez3019 bundle
    Make a service behave predictably when its dependencies are slow, failing, or duplicating work. Covers timeouts and deadline propagation, retry with exponential backoff, jitter and retry budgets, circuit breakers, bulkheads, rate limiting and load shedding, fallbacks and graceful degradation, idempotent consumers, the transactional outbox and inbox, saga compensation, and health probes. Use when writing or reviewing any call that leaves the process, when handling a message, or when the user says 'resilience', 'circuit breaker', 'retry', 'timeout', 'cascading failure', 'outbox', 'saga', or 'graceful degradation'. This skill governs runtime failure behaviour — not layering (see clean-architecture), not test design (see test-strategy).
    0 installs
  18. Cqrs And Consistency · parvez3019 bundle
    Decide how reads are served, how far they may lag behind writes, and who owns each piece of data. Covers the five levels of command-query separation and when each is earned, read models and projections with a stated staleness budget, rebuildability, event sourcing and its permanent costs, read-your-writes, and data ownership between services. Use when adding a read model or projection, choosing between one model and separate read and write paths, evaluating event sourcing, deciding whether a service may hold a copy of another's data, or when the user says 'CQRS', 'read model', 'projection', 'event sourcing', 'eventual consistency', or 'stale data'. This skill governs the read path and the consistency model — domain types belong to domain-modelling, query and transaction craft to data-access.
    0 installs
  19. Collaborative Judgment · parvez3019 bundle
    Surface genuine architectural trade-offs as structured options with consequences instead of silently picking one. Governs how every other skill in this library reports its Ambiguity Signals — synchronous vs asynchronous, strong vs eventual consistency, orchestration vs choreography, split vs keep together. Use when a decision has two defensible answers, when the user says 'what do you think', 'which approach', 'trade-offs', or 'options', or when another skill routes an ambiguity here. This skill governs how a decision is presented and recorded — not what the right answer is (that belongs to the domain skill that raised it).
    0 installs
  20. Config And Dependencies · parvez3019 bundle
    Keep a service's configuration and its dependency graph under control. Covers configuration as environment rather than code, separating config from secrets, fail-fast validation of typed config at startup, feature flags and blast radius, environment parity and drift, plus dependency selection, semantic versioning, lockfiles, transitive bloat, automated updates, and internal shared libraries. Use when adding or changing a setting, wiring an environment, introducing a feature flag, adding or upgrading a library, or when the user says 'config', 'environment variable', 'feature flag', 'dependency', 'upgrade', 'lockfile', or 'shared library'. This skill governs what varies per deployment and what the service is built from — secret storage rules belong to secure-service.
    0 installs
  21. Infrastructure Adapters · parvez3019 bundle
    Write the adapter layer that connects a service to everything outside it. Covers designing ports at the right granularity and owning them inward, wrapping third-party SDKs so their types never reach the domain, mapping and anti-corruption at the edge, where resilience and observability belong, adapters for HTTP clients, brokers, caches, blob storage and the clock, and how to test an adapter without testing the vendor. Use when writing or reviewing a client, a consumer, a publisher, a repository implementation, a mapper, or any wrapper around an external system, or when the user says 'adapter', 'port', 'client', 'SDK', 'wrapper', 'anti-corruption layer', or 'infrastructure'. This skill governs the outer layer's craft — the layering rules themselves belong to clean-architecture, persistence specifics to data-access.
    0 installs