component-review.rules

Component Review Rules

Add new rules to this list in the same format. Keep each rule focused and testable. Categories define ordering and scope.

Product functionality

Focus on externally visible behavior in the UI, not internal function details.

Registration

The component is registered in the application. For core compoents: with registry.RegisterComponent For integrations: listed in the integration's Components() or Triggers() output.

Naming

• For core components: uses the same name as the registration name
• For integration components: name should follow the format <integration>.<name>, e.g. github.getIssue vs github.GetIssue
• A component name should always use camel-case, and should never contain spaces, or underscore
• If the component is a trigger, it should start with on
• Trigger names should use the resource names that they reference, not actions, unless the trigger itself is about an specific action. For example, github.onIssueComment instead of github.onIssueCommented

Label

• The component label shown in the UI is non-empty and human-readable
• Uses Title Case
• No raw slug casing

Description

The component description shown in the UI is non-empty, user-facing. Short, clear and concise.

Documentation

• The component documentation shown in the UI is non-empty.
• It is valid markdown
• If it uses titles, the biggest level should be ##

Icon

• The component icon shown in the UI is non-empty and maps to a valid UI icon
• Either Lucide Icon slug
• Or an existing custom asset

Color

The component color shown in the UI is non-empty and consistent with existing component color usage.

Example output

• The example output shown in the UI embeds an example
• JSON file (e.g., example_output.json).
• Example JSON files are valid and match the emitted payload structure.

Configuration fields

• Every configuration field shown in the UI has a: Name, Label, Type, and Description
• Required fields are marked Required: true.
• Required fields should always be placed before optional fields
• When possible, configuration never asks users to enter IDs that aren't easily available to them (e.g., requiring a Discord channel ID).
• When users can choose from existing resources (e.g., a GitHub repository), always use FieldTypeIntegrationResource. Example: instead of having a channelId field of type FieldTypeString, use a FieldTypeIntegrationResource configuration field.
• For trigger filters and component configuration that use equality, non-equality, or regex matching, prefer configuration.FieldTypeAnyPredicateList and match values via configuration.MatchesAnyPredicate. Avoid ad-hoc wildcard or comma parsing unless any-predicate-list cannot express the requirement. If configuration.FieldTypeAnyPredicateList cannot meet your requirements, look for ways to extend it before developing a specific implementation.
• if filters are part of the trigger, we should always have a default filter for the most common use case. That makes it easier for the user to configure it, and we don't produce unnecessary events to the system. For example, the default github.onPush refs filter is for commits on the main branch.