# Getting Started with Kiro as a Developer Kiro is an agentic AI IDE and CLI that helps you go from prototype to production with **spec‑driven development**—turning natural‑language prompts into structured requirements, architecture, and executable tasks that generate code, tests, and docs aligned with your intent. ## First thing to do: add Agent Steering & Skills In each Kiro workspace, you can define **Agent Steering & Skills** so that your agents behave the way you expect and follow your team’s engineering practices. 1. In your Kiro workspace, click the **Agent Steering & Skills** icon in the main navigation. ![Agent Steering & Skills icon](/images/kiro-agent-steering-icon.png) 2. Click **Add steering & skills**. 3. Create a new steering document for your workspace and paste in the content below (or an adapted version of it). Here’s the steering document I use for **Lifeway frontend development**, focused on React Native, TypeScript, Expo, and TV/mobile best practices: ````markdown --- inclusion: always name: lifeway-frontend-development description: Comprehensive guide for Lifeway's React Native development with TypeScript, Expo, and mobile/TV UI best practices. Includes testing strategies, state management patterns, and production-proven practices from mobile and TV codebases. fileMatchPattern: ["**/*.ts", "**/*.tsx"] --- # Code Style and Structure ## General Principles - Write concise, technical TypeScript code with accurate examples - Use functional and declarative programming patterns; avoid classes - Prefer iteration and modularization over code duplication - Use descriptive variable names with auxiliary verbs (e.g., isLoading, hasError) - Structure files: exported component, subcomponents, helpers, static content, types ## Naming Conventions - Use snakeCases for directories (e.g., `components/formElements`) - Favor named exports for components - Use PascalCase for component names - Use camelCase for functions and variables ## TypeScript Usage - Use TypeScript for all code; prefer types over interfaces - Avoid enums; use maps or const objects instead - Use functional components with TypeScript types - Use strict mode in TypeScript for better type safety - Prefer const assertions and `as const` for literal types to improve type inference - Use discriminated unions for handling different states and variants in components - Avoid using `any` type; use `unknown` and proper type guards when type is unclear - Leverage React Native's built-in types (e.g., ViewStyle, TextStyle, ImageStyle) for styling props ```typescript // Good - discriminated union type LoadingState = { status: "loading" } type SuccessState = { status: "success"; data: Data } type ErrorState = { status: "error"; error: Error } type State = LoadingState | SuccessState | ErrorState // Good - const assertion const COLORS = { primary: "#007AFF", secondary: "#5856D6" } as const // Avoid - enum enum Colors { Primary = "#007AFF", Secondary = "#5856D6" } ``` ## Syntax and Formatting - Use the "function" keyword for pure functions - Avoid unnecessary curly braces in conditionals; use concise syntax for simple statements - Use declarative JSX - Use Biome for mobile/TV apps, Prettier for other packages - Format on save and before commits --- # Testing Practices ## Testing Framework Configuration ### Mobile & TV Apps (Jest) - Use Jest with `jest-expo` preset for React Native testing - Configuration: `.jest/spec/config.ts` - Test files: `**/__tests__/**/*.spec.{ts,tsx}` or `**/*.spec.{ts,tsx}` - Run tests: `yarn test` (from frontend/ directory) - Watch mode: `yarn test:watch` ### Shared Packages (Vitest) - Use Vitest for `@lifeway/react-native-shared` and other shared packages - Faster execution and better ESM support - Configuration in `vitest.config.ts` ## Test Structure & Organization ### File Organization ``` feature/ ├── components/ │ ├── MyComponent.tsx │ └── __tests__/ │ └── MyComponent.spec.tsx ├── state/ │ ├── myState.ts │ └── __tests__/ │ └── myState.spec.ts └── utils/ ├── myUtil.ts └── __tests__/ └── myUtil.spec.ts ``` ### Test Naming Conventions - Use `describe()` blocks to group related tests - Use `it()` or `test()` for individual test cases - Use descriptive names that explain the behavior being tested - Follow pattern: "when [condition], should [expected behavior]" ```typescript describe("MyComponent", () => { describe("when user is authenticated", () => { it("should display user profile", () => { // test implementation }) }) describe("when user is not authenticated", () => { it("should redirect to login", () => { // test implementation }) }) }) ``` ## Testing Utilities ### Test Renderer Pattern Use the `testRenderer` helper for consistent test setup with all required providers: ```typescript import { testRenderer } from "@/src/test/testRenderer" const renderPage = testRenderer() it("should render correctly", () => { const { getByText } = renderPage() expect(getByText("Hello")).toBeTruthy() }) ``` The `testRenderer` automatically wraps components with: - `SafeAreaProvider` - `UserPreferenceContextProvider` - `ThemeContextProvider` - `AlertProvider` - `CustomApolloClientProvider` (with mock support) - `DeviceProvider` - `Subscribe` (for RxJS state) - Other global providers ### GraphQL Mocking Override GraphQL responses in tests: ```typescript import type { MockedResponse } from "@apollo/client/testing" const mockResponse: MockedResponse[] = [ { request: { query: GET_STUDY_BY_ID, variables: { id: "test-id" } }, result: { data: { studyByID: { id: "test-id", title: "Test Study" } } } } ] const { getByText } = testRenderer()(mockResponse) ``` ## Component Testing ### React Testing Library - Use `@testing-library/react-native` for component testing - Query by accessibility properties (role, label) over test IDs when possible - Use `waitFor` for async operations - Use `fireEvent` for user interactions ```typescript import { fireEvent, waitFor } from "@testing-library/react-native" it("should handle button press", async () => { const onPress = jest.fn() const { getByRole } = testRenderer(

← AllPosts tagged #software-development2 posts

Latest

Getting Started with Kiro as a Developer

The Pragmatic Programmer: Summary and Key Insights