← all publishers

code-sherpas

@code-sherpas source repo

Report this profile Claim this profile

• 45 skills
• 0 followers
• 4 hours ago last updated

1. ▌
   Find Docs · code-sherpas

   Retrieves authoritative, up-to-date technical documentation, API references, configuration details, and code examples for any developer technology. Use this skill whenever answering technical questions or writing code that interacts with external technologies. This includes libraries, frameworks, programming languages, SDKs, APIs, CLI tools, cloud services, infrastructure tools, and developer platforms. Common scenarios: - looking up API endpoints, classes, functions, or method parameters - checking configuration options or CLI commands - answering "how do I" technical questions - generating code that uses a specific library or service - debugging issues related to frameworks, SDKs, or APIs - retrieving setup instructions, examples, or migration guides - verifying version-specific behavior or breaking changes Prefer this skill whenever documentation accuracy matters or when model knowledge may be outdated.
   0
   installs
2. ▌
   Update Token · code-sherpas

   Use when a maintainer wants to modify or add an existing token in pharos-tokens. Walks through editing the DTCG source, rebuilding, validating WCAG for colors, choosing the right version bump, and documenting the impact on consumers.
   0
   installs
3. ▌
   Review Tokens Pr · code-sherpas

   Use when reviewing a pharos-tokens PR. Exhaustive checklist covering DTCG format, WCAG contrast, canonical naming, valid references, and the presence of a changeset.
   0
   installs
4. ▌
   Add Token Category · code-sherpas

   Use when a genuinely new token category is needed (e.g. animation timeline tokens, border-width tokens, an opacity scale) that does not fit the existing color/spacing/typography/radius/shadow files.
   0
   installs
5. ▌
   Atomic Design · code-sherpas bundle

   Create or update web UI components with a strict reuse-first workflow. Use when building, refactoring, restyling, or extending frontend or template components while minimizing raw DOM or HTML by reusing or generalizing existing components first.
   0
   installs
6. ▌
   Domain Entity · code-sherpas

   Identify, interpret, review, or write domain entities in code. Use when an agent needs to decide whether a domain entity is defined by a stable identity that persists over time, or when it must implement, preserve, or refactor entity lifecycle, invariants, and behavior around domain data. When writing or changing a domain entity, use a class or the closest class-like construct the project stack supports. Do not model domain entities as plain type aliases or interfaces paired with standalone functions.
   0
   installs
7. ▌
   Business Logic · code-sherpas

   Identify, interpret, review, or write business logic in code. Use when an agent needs to decide whether code expresses business rules, business algorithms, or business workflows, or when it must implement, preserve, or refactor code that creates, stores, or transforms data according to real business policies.
   0
   installs
8. ▌
   Domain Service · code-sherpas

   Identify and encapsulate domain logic that does not belong to any single aggregate into domain services. Use when an agent needs to create, modify, review, or interpret business logic that involves multiple aggregates and does not have a natural owner. A domain service contains pure domain logic — it receives and returns domain types, has no infrastructure dependencies, and does not access repositories, transactions, or external systems. The business-logic entry point orchestrates the domain service by loading the necessary aggregates and passing them in.
   0
   installs
9. ▌
   Integration Logic · code-sherpas

   Identify, interpret, review, or write integration logic in code. Use when an agent needs to decide whether code exists so two independent applications can communicate, or when it must implement, preserve, or refactor protocol handling, message exchange, contract mapping, or communication workflows between separate running systems.
   0
   installs
10. ▌
    Aggregate Boundaries · code-sherpas

    Determine and enforce aggregate boundaries when domain entities relate to other domain entities. Use when an agent needs to create, modify, review, or interpret a domain entity that references another domain entity. The agent must determine whether the related entities belong to the same aggregate or to different aggregates, apply the correct reference style — direct reference within the same aggregate, identity reference across aggregates — and document the boundary decision in the project's agent instructions file so future tasks reuse the same decision without asking again.
    0
    installs
11. ▌
    Prefer Named Functions · code-sherpas

    Prefer named functions over anonymous functions across any technology stack. Use when an agent needs to define, refactor, or review functions, methods, callbacks, handlers, lambdas, arrow functions, or function expressions. Choose a named function unless the language, framework, idiomatic style, or local readability genuinely favors an anonymous form.
    0
    installs
12. ▌
    Built In Temporal Types · code-sherpas

    Require built-in or standard-library temporal types for dates, times, datetimes, and related values. Use when an agent needs to create, modify, review, or interpret temporal fields, parameters, return types, persistence mappings, serializers, parsers, or API contracts. When timezone semantics matter, use a representation that preserves a geographic timezone such as an IANA zone ID and not merely a fixed UTC offset.
    0
    installs
13. ▌
    Domain Entity Discovery · code-sherpas

    Identify which domain entities are needed to represent a business domain before implementing them. Use when an agent receives a task that requires modeling a new domain area or extending an existing one — such as implementing a new feature, module, or end-to-end flow — and the domain entities involved are not yet defined in the codebase. The agent must extract domain concepts from the requirements, propose a set of domain entities with their relationships, validate the proposal with the human, and document the agreed model before proceeding to implementation.
    0
    installs
14. ▌
    Domain Entity Typed Ids · code-sherpas

    Determine how to type domain entity identifiers based on the project's type system. Use when an agent needs to create, modify, review, or interpret the type of a domain entity's identifier. In languages with a nominal type system, use typed IDs — a distinct type per domain entity that wraps the underlying identifier type. In languages with a structural type system, use typed IDs only if the language offers a low-friction mechanism to make them nominally distinct. Otherwise, use the underlying identifier type directly.
    0
    installs
15. ▌
    Functional UI Prototype · code-sherpas

    Build functional UI/UX prototypes that run entirely in the browser. Use when creating, extending, or refactoring a prototype that must look and behave like a complete feature without touching backend code. All data persistence is simulated through localStorage with realistic latency so the prototype can be used under the same conditions as a full implementation. Backend modification is strictly prohibited.
    0
    installs
16. ▌
    Neverthrow Return Types · code-sherpas

    Require `neverthrow`-based return types in TypeScript and JavaScript code whenever the surrounding technology allows it. Use when creating, refactoring, reviewing, or extending standalone functions, exported module functions, class methods, object methods, service methods, repository methods, and similar APIs that should expose explicit success and failure result types in their signatures. Prefer `Result<T, E>` for synchronous code and `ResultAsync<T, E>` for asynchronous code. Only skip a `neverthrow` return type when a framework, library, runtime interface, or externally imposed contract is incompatible and requires a different return shape.
    0
    installs
17. ▌
    Domain Entity Uuidv4 Ids · code-sherpas

    Require UUIDv4 identifiers for domain entities. Use when an agent needs to create, modify, review, or interpret domain entity ID fields, ID types, constructors, persistence mappings, serialization, or API contracts tied to domain entity identity. Prefer the programming language's built-in UUID type when it exists. If the language has no built-in UUID type, use `string` while preserving explicit UUIDv4 generation and validation semantics.
    0
    installs
18. ▌
    Utc Zoned Temporal Types · code-sherpas

    Require UTC for timezone-aware built-in or standard-library temporal types. Use when an agent needs to create, modify, review, or interpret temporal fields, parameters, return types, persistence mappings, serializers, parsers, or API contracts that can carry timezone information. When the stack supports timezone-aware temporal types, prefer those built-in types and use the UTC timezone.
    0
    installs
19. ▌
    Immutable Domain Entities · code-sherpas

    Require the immutable design pattern for domain entities. Use when an agent needs to create, modify, review, or interpret domain entities and should preserve identity while expressing state changes through new immutable instances. Domain entities must be modeled as immutable classes, not as plain type aliases or interfaces paired with standalone functions.
    0
    installs
20. ▌
    Neverthrow Wrap Exceptions · code-sherpas

    Capture exceptions and promise failures with `neverthrow` instead of hand-written `try/catch` in TypeScript and JavaScript code. Use when wrapping synchronous functions that may throw, promise-returning functions that may throw before returning, existing `PromiseLike` values that may reject, or third-party APIs such as parsers, database clients, HTTP clients, file-system helpers, serializers, and SDK calls. Prefer `Result.fromThrowable` for synchronous throwers, `ResultAsync.fromThrowable` for promise-returning functions that may throw or reject, and `ResultAsync.fromPromise` when you already have a `PromiseLike` value in hand. Only keep `try/catch` when the language construct, cleanup requirement, or framework boundary truly requires it.
    0
    installs
21. ▌
    Repository No Business Logic · code-sherpas

    Require that repositories contain no business logic. Use when an agent needs to create, modify, review, or interpret a repository implementation. A repository is a persistence gateway — it stores and retrieves domain entities exactly as requested. It must not validate business rules, enforce invariants, make domain decisions, transform domain state, filter results based on business criteria, or perform any operation that belongs to the domain layer. All business logic belongs in domain entities, domain services, or business-logic entry points.
    0
    installs
22. ▌
    Iso8601 Millisecond Precision · code-sherpas

    Require ISO 8601 textual representations for temporal values. Use when an agent needs to format, serialize, parse, document, review, or define textual date, time, datetime, or timestamp representations in APIs, events, persistence, logs, configuration, or other string-based boundaries. When the textual representation includes a time component, require millisecond precision.
    0
    installs
23. ▌
    Diagnose And Fix Tracked Errors · code-sherpas

    Diagnose a bug surfaced by an error-tracking or observability tool — or a supplied stack trace or log — reach its root cause with evidence, and apply or propose the fix at the design-correct location, which is often not where the error manifests. Use when an agent must triage a tracked error event, reproduce the reported failure deterministically, isolate the origin through falsifiable hypotheses, decide which layer owns the violated invariant or rule, and fix plus regression-test at that layer before closing the loop in the tracking tool. The agent must defer to the project's observability tooling, agent instructions, and design conventions rather than assume any specific tool, error model, or architecture.
    0
    installs
24. ▌
    Domain Entity Reference Direction · code-sherpas

    Determine whether a domain entity should hold a reference to another domain entity and in which direction. Use when an agent needs to create, modify, review, or interpret a domain entity that relates to another domain entity. A domain entity should only hold a reference to another entity if it needs that reference to enforce its own invariants or execute its own domain behavior. References that exist only to support read queries belong in the repository, not in the entity.
    0
    installs
25. ▌
    Write Persistence Representations · code-sherpas

    Create or update persistence-layer data representations in any stack, including ORM entities, schema definitions, table mappings, document models, collection definitions, and similar database-facing code. Use when agents needs to add or change persisted fields, identifiers, relationships, indexes, timestamps, auditing fields, or storage mappings in frameworks, libraries, or ORMs such as Prisma, TypeORM, Sequelize, Drizzle, Mongoose, Hibernate/JPA, Doctrine, Ecto, Active Record, or equivalent persistence technologies.
    0
    installs
26. ▌
    Domain Entity Reference Optionality · code-sherpas

    Determine whether a reference from one domain entity to another should be required or optional. Use when an agent needs to create, modify, review, or interpret a domain entity that holds a reference to another domain entity and must decide if that reference can be absent. A reference is required when the entity cannot exist in a valid domain state without it. A reference is optional when the entity can exist in a valid domain state without it. This rule applies only to single-value references — collection references are never nullable because an empty collection represents the absence of related entities.
    0
    installs
27. ▌
    Business Logic Entry Point Vocabulary · code-sherpas

    Map common industry names to the concept of business-logic entry point. Use when an agent encounters or the user mentions terms such as use case, application service, service layer, command handler, query handler, interactor, or similar names that refer to entry points to business logic. Recognize these terms as synonyms for business-logic entry point and apply all business-logic entry-point skills accordingly.
    0
    installs
28. ▌
    Business Logic Entry Point Colocate Types · code-sherpas

    Require project-declared parameter types and return types of a business-logic entry point to be declared in the same file as the entry point itself, when the project stack allows it. Use when an agent needs to create, modify, review, or organize type definitions for command types, query types, success types, error types, or other project-declared types used in the signature of a business-logic entry point. Do not place these types in separate files, shared type modules, or barrel exports.
    0
    installs
29. ▌
    Business Logic Entry Point One Per Module · code-sherpas

    Require each business-logic entry point to live in its own separate module. Use when an agent needs to create, modify, review, or organize business-logic entry points such as command handlers, query handlers, use cases, or application services. Do not group multiple entry points in a single class, object, or file based on the domain entity they operate on. Each entry point must be either a top-level function in its own module, or a class or object with exactly one public function in its own module.
    0
    installs
30. ▌
    Business Logic Ensure Authorized Requester · code-sherpas

    Enforce an authorization business constraint at business-logic entry points using an `ensure requester is authorized` formalism translated into the syntax and conventions of the project language. Use when an agent needs to create, modify, review, or interpret authorization or permission checks at business-logic entry points. The constraint must be a module-private function in the same module as the entry point. It must verify that the authenticated requester is allowed to execute that entry point's action before any business operation runs. On success it returns a unit-equivalent value. On failure it returns an error when the requester is not authorized.
    0
    installs
31. ▌
    Business Logic Ensure Business Constraints · code-sherpas

    Formalize business constraints at business-logic points using an `ensure ...` style translated into the syntax and conventions of the project language. Use when an agent needs to create, modify, review, or interpret business-rule precondition checks such as eligibility checks, availability checks, permission checks, or invariant-preserving entry checks. These constraints must return only a unit-equivalent success value such as `void`, `unit`, `undefined`, or `None`, or an error when the condition is not satisfied.
    0
    installs
32. ▌
    Business Logic Entry Point Use Repositories · code-sherpas

    Require business-logic entry points to access domain-entity persistence exclusively through repositories. Use when an agent needs to create, modify, review, or interpret business-logic entry points that create, read, or modify domain entities. Entry points must not call the project's ORM, database library, framework persistence API, or any other persistence technology directly. All persistence operations on domain entities must go through a repository.
    0
    installs
33. ▌
    Business Logic Entry Point Execution Context · code-sherpas

    Require every business-logic entry point to wrap its body with `runWithinContext`, which provides an execution context implicitly accessible from any point in the execution chain. In Node.js projects use AsyncLocalStorage. Use when an agent needs to create, modify, review, or interpret business-logic entry points. The execution context stores cross-cutting data such as the requester identity, the database transaction, or other request-scoped information so that inner functions can access it without receiving it as an explicit parameter. `runWithinContext` only sets up the context — it reuses an existing context or creates a new one. It does not open database transactions; that is a separate concern handled by the transaction skill. The entry point does not build or pass the context object. Infrastructure callers must not be aware of the execution context.
    0
    installs
34. ▌
    Business Logic Ensure Authenticated Requester · code-sherpas

    Enforce an authentication business constraint at business-logic entry points using an `ensure requester is authenticated` formalism translated into the syntax and conventions of the project language. Use when an agent needs to create, modify, review, or interpret authentication checks at business-logic entry points. The constraint must verify that the request triggering the execution comes from an authenticated requester before any business logic runs. On success it must return the requester id to facilitate downstream business logic. On failure it must return an error when the requester is not authenticated.
    0
    installs
35. ▌
    Business Logic Entry Point Database Transaction · code-sherpas

    Require every business-logic entry point to wrap its entire flow in a database transaction using a dedicated `runWithinTransaction` function that receives the callback with the logic to execute and the isolation level. The function uses the project's library, framework, or ORM, when the underlying persistence technology supports transactions. Use when an agent needs to create, modify, review, or interpret business-logic entry points that interact with a database. The transaction must encompass the full entry-point flow, including business constraints, business operations, and persistence, so that the entire flow succeeds or fails atomically.
    0
    installs
36. ▌
    Business Logic Entry Point Repository Interface · code-sherpas

    Require business-logic entry points to depend on a repository interface rather than a concrete repository implementation. Use when an agent needs to create, modify, review, or interpret how a business-logic entry point references a repository. When the project's programming language supports interfaces, protocols, traits, or abstract types, the entry point must depend on the repository abstraction, not on the concrete implementation. When the language does not support such constructs, this skill does not apply.
    0
    installs
37. ▌
    Business Logic Entry Point Primitive Input Types · code-sherpas

    Require business-logic entry point input parameters to use only primitive or basic types. Use when an agent needs to create, modify, review, or interpret the command or query types accepted by business-logic entry points. Input fields must be strings, numbers, or booleans. Do not use domain-entity types, domain aggregate types, branded or opaque primitive types, enums, temporal types, or other complex domain objects as input fields.
    0
    installs
38. ▌
    Business Logic Entry Point Repository Operations · code-sherpas

    Require repository interfaces to expose a standard set of operations with specific signatures, naming conventions, and a strict error model. Use when an agent needs to create, modify, review, or interpret repository interfaces used by business-logic entry points. Repositories must offer findBy<Field> (single-row, returns an absence-permitting type), findManyBy<Field> (multi-row, collection), search (dynamic filters, pagination, sorting), countBy<Field> (numeric aggregation, AND/OR), existsBy<Field> / existManyBy<Field> (booleans derived from countBy<Field>), create, update, and deleteById. Errors describe only infrastructure concerns; any domain-level outcome (not found, empty, zero, false) is a valid return value.
    0
    installs
39. ▌
    Business Logic Entry Point Cqs Handler Signatures · code-sherpas

    Enforce a signature pattern for business-logic entry points when Command-Query Separation is being followed. Use when an agent needs to create, modify, review, or interpret command handlers or query handlers at business-logic entry points. Name handlers with an infinitive plus a command-handler or query-handler suffix adapted to the language style, accept exactly one parameter named `command` or `query`, always wrap input values in a dedicated `...Command` or `...Query` type, return the project's empty equivalent for successful non-create command handlers, return a `...CommandHandlerSuccess` type for successful create command handlers, and return a `...QueryHandlerSuccess` type for successful query handlers.
    0
    installs
40. ▌
    Business Logic Typical Domain Entity Entry Points · code-sherpas

    Promote a standard set of business-logic entry points around a domain-entity type when an agent must decide which entry points to implement. Use when designing, creating, modifying, reviewing, or completing business-logic entry points for a specific domain entity. Prefer basic entity entry points such as create, update, find by id, search, and delete by id; use explicit mark-as entry points for finite-state changes such as enum or boolean status transitions; use explicit assign or add entry points for one-to-many or many-to-many associations between domain entities; and use explicit check-whether-can-be entry points when the business operation needs a boolean answer about whether an action is currently allowed.
    0
    installs
41. ▌
    Business Logic Entry Point Repository Domain Types · code-sherpas

    Require that the types exchanged between business-logic entry points and repositories are domain-entity types and domain value types. Use when an agent needs to create, modify, review, or interpret repository interfaces or their usage from business-logic entry points. Repository method signatures must not expose persistence-technology types such as ORM entities, database records, row objects, document models, or any type generated by or dependent on the concrete persistence technology.
    0
    installs
42. ▌
    Business Logic Entry Point Command Query Separation · code-sherpas

    Enforce Command-Query Separation specifically at business-logic entry points. Use when an agent needs to create, modify, review, or interpret public functions, methods, handlers, use cases, application services, facades, or similar entry points that trigger business logic. Classify each entry point as either a command that changes state or a query that returns data, never both. The only allowed data return from a command is the ID or IDs of domain entities created by a create operation.
    0
    installs
43. ▌
    Business Logic Entry Point Prefer Top Level Functions · code-sherpas

    Prefer top-level functions over classes or objects for implementing business-logic entry points when the project stack allows it without introducing friction. Use when an agent needs to decide the code shape for a business-logic entry point such as a command handler, query handler, use case, or application service. Choose a top-level function unless the language, framework, or project conventions make classes or objects the natural, frictionless choice.
    0
    installs
44. ▌
    Business Logic Entry Point Domain Entity Payload Types · code-sherpas

    Require business-logic entry points to use domain-entity types directly in returned payloads whenever they return domain-entity data. Use when an agent needs to create, modify, review, or interpret the success payload of business-logic entry points, including query handlers and any other business-layer API that returns domain-entity data. Do not map domain entities into separate payload types, DTOs, view models, or similar transport shapes at the business-logic entry point when the payload is supposed to contain domain-entity data.
    0
    installs
45. ▌
    Business Logic Entry Point Transaction Isolation Levels · code-sherpas

    Set transaction isolation levels for business-logic entry points when Command-Query Separation and database transactions are both in use and the underlying persistence technology supports configurable isolation levels. Use when an agent needs to create, modify, review, or interpret the isolation level of a database transaction at a business-logic entry point that follows CQS. Query handlers must use the least blocking isolation level available in the project's database. Command handlers must use REPEATABLE READ isolation level.
    0
    installs