@morsa/guidance-bank 0.2.0

package/dist/core/projects/createBankDeriveGuidance/stacks/angular.js

@@ -0,0 +1,252 @@
+export const ANGULAR_DERIVE_GUIDANCE = `## Angular Guidance
+
+Focus on Angular patterns: components, templates, routing, DI, RxJS/signals, forms, testing, and architecture boundaries.
+
+## Codebase Exploration Before Generating
+
+### Structure Discovery
+
+1. List root folders.
+2. Identify where Angular source code lives (for example: src/, apps/, libs/, projects/).
+3. Map feature/module hierarchy 2-3 levels deep.
+4. Record the exact folder names and paths you found.
+
+### Pattern Extraction (Read Real Files)
+
+For each category, read 2-3 representative files and extract reusable decisions:
+
+| Category | What to Find | What to Extract |
+|----------|--------------|-----------------|
+| Feature structure | Feature folders and boundaries | Placement rules for components/services/models/routes |
+| Components | Component model and container/presentational split | Selector naming, inputs/outputs, host bindings |
+| Templates | Control flow and binding patterns | @if/@for usage, track strategy, async pipe strategy, event handling |
+| Routing | Route configs and lazy loading | loadChildren/loadComponent conventions, guards/resolvers |
+| State layer | Signals/RxJS/store/effects | State ownership, side-effect boundaries, update patterns, interop boundaries |
+| Services/API | HttpClient and data services | DI conventions, mapping, error handling, retries |
+| Forms | Reactive forms and validators | Form initialization, validation style, submit flow |
+| Styling | SCSS/CSS organization | Token usage, naming convention, layout patterns |
+| Performance | Change detection and template costs | OnPush/default usage, template computation boundaries |
+| Testing | Spec structure and helpers | Test location, mocking style, critical test expectations |
+
+### Config and Tooling Analysis (Angular-Specific)
+
+Read these files if present:
+- package.json and lockfile
+- angular.json / workspace.json / project.json
+- eslint config and formatting config
+- src/main.ts, app config, bootstrap files
+- app.routes.ts and route setup files
+- nx.json / turbo.json (if monorepo)
+- workspace lint rules for boundaries (for example \`@nx/enforce-module-boundaries\`)
+- tailwind config (if present) and shared style token files
+
+### Version and Feature Gate (Angular)
+
+Before turning patterns into rules, verify what is actually used in this codebase:
+- Angular version from dependencies and workspace config.
+- Component style in real files: standalone, NgModule, or mixed.
+- State style in real files: signals, RxJS streams, store/effects, or mixed.
+- Use standalone APIs only when version and code evidence support them (Angular 14+ and real standalone usage).
+- Use template control flow (\`@if/@for/@switch\`) only when version and code evidence support it (Angular 17+ with real usage/migration evidence).
+- Use signals only when version and code evidence support them (Angular 16+ with real imports/usages like \`signal\`, \`computed\`, \`effect\`).
+- Use \`takeUntilDestroyed\` for subscription cleanup only when version and code evidence support it (Angular 16+ with \`DestroyRef\`/interop usage); otherwise keep the existing local cleanup pattern.
+- If a feature is not supported by version and code evidence, do not generate rules that require it.
+
+### Red Flag Detection (Angular-Specific)
+
+Search for recurring issues that should become explicit rules:
+- TODO/FIXME/HACK patterns
+- mixed state patterns without clear ownership
+- mixed usage of \`inject()\` and constructor DI without a clear project convention
+- business logic in templates instead of component/service layer
+- \`@for\` loops without stable tracking strategy when control flow syntax is used
+- ad-hoc dependency creation instead of DI
+- manual subscriptions without the project-approved cleanup strategy (\`takeUntilDestroyed\` when supported, otherwise local equivalent)
+- nested subscriptions instead of flattened stream composition (\`switchMap\`/\`concatMap\`/\`exhaustMap\` or local effect/store patterns)
+- duplicated state sources across signals and observables without explicit ownership boundaries
+- duplicated API mapping logic
+- direct HttpClient usage in templates/components when a service abstraction exists
+- browser-only APIs (\`window\`, \`document\`, \`localStorage\`) used without platform guards in SSR-capable projects
+- DOM side effects inside constructors instead of lifecycle/hooks with platform checks
+- large shared modules with unclear responsibility
+- cross-feature imports that violate established boundaries
+- hardcoded design values where project tokens/variables are the standard
+- expensive template-bound computations or repeated function calls in hot render paths
+- inconsistent API error contract across handlers/services/interceptors/UI layer
+- error handling and notification behavior duplicated across features
+- side effects in \`computed\`/\`effect\` without clear boundaries and intent
+
+### Analysis Checklist (Angular Project)
+
+Document these with file path evidence:
+
+- Architecture and boundary model.
+- Component and template model.
+- Routing and lazy-loading strategy.
+- State and async model (ownership, subscriptions, interop).
+- Service/API model and error-contract boundaries.
+- SSR/hydration and browser-only API handling strategy (if SSR-capable).
+- Change detection and template performance patterns.
+- Styling mode and design-token strategy.
+- Testing strategy and depth by module type.
+- Main recurring anti-patterns and where they appear.
+
+Before final output, gather concrete evidence for each applicable item.
+If evidence remains partial, continue conservatively and mark uncertainty with \`[VERIFY: ...]\` instead of blocking output.
+
+### Generation Locks (Prevent Architecture Drift)
+
+Apply these constraints when generating rules and skills:
+- Preserve detected architecture and import/workspace boundaries.
+- Preserve component/template interaction model (including stable loop tracking when \`@for\` is used).
+- Preserve state ownership and async boundaries (subscriptions, interop, side effects).
+- Preserve routing loading strategy.
+- Preserve SSR/browser safety boundaries in SSR-capable projects.
+- Preserve styling system and token conventions.
+- Avoid high-impact workflow changes unless strongly supported by project evidence.
+
+## Skill Candidates (Angular)
+
+Generate these skills with actual project paths and Angular-specific workflow steps:
+Generate only skills that have clear project evidence and practical value.
+For small/low-confidence projects, 2-4 core skills are usually enough.
+
+### adding-feature
+- Include actual feature folder structure used in this project.
+- Show how to add component/service/route wiring using existing local patterns.
+- Include integration with state layer and tests where applicable.
+
+### adding-service
+- Include service and API client structure used in this project.
+- Show DI pattern, request/response mapping, and error handling.
+- Include mocking/test strategy for service behavior.
+
+### code-review
+- Include Angular-specific review checklist based on project patterns.
+- Cover template complexity, state ownership, subscription safety, and route boundaries.
+
+### common-anti-patterns
+- Include recurring Angular anti-patterns from this project.
+- Pair each anti-pattern with preferred local alternative.
+
+### troubleshooting
+- Include common Angular build/runtime/test issues for this codebase.
+- Include where to inspect first when these issues happen.
+
+### [framework-specific]
+Generate 1-3 extra skills based on actual stack usage:
+- signals-patterns (if signals are primary)
+- rxjs-patterns (if RxJS orchestration is primary)
+- ngrx-patterns (if NgRx is present)
+- forms-patterns (if complex forms are central)
+- monorepo-workflows (if apps/libs pattern exists)
+
+### enrichment-tasks (optional)
+- Generate this only when the user explicitly asks for enrichment, or when analysis shows a clear gap in the existing rule/skill bank.
+
+## Rule Generation Requirements
+
+### What NOT to Include
+
+- Do not invent generic philosophy ("clean code", "think about user").
+- Do not duplicate what linters/formatters fully enforce.
+- Do not add rules without evidence from codebase patterns.
+- Do not repeat the same rule across multiple rule topics.
+- Do not propose Angular APIs that are incompatible with detected project version and architecture mode.
+- Do not force Angular workflow-changing migrations unless they are already reflected in project direction and evidence.
+
+### Rule Content Requirements
+
+Keep this section Angular-specific:
+- Capture decisions tied to Angular architecture, templates, routing, state, and DI boundaries.
+- Prefer Angular-native patterns and terminology over generic cross-stack wording.
+- Highlight recurring Angular anti-patterns and safer local alternatives.
+- Include interaction, lifecycle, subscription, and performance constraints only when supported by project evidence.
+- Keep rules compatible with current Angular workflow unless stronger project evidence justifies change.
+
+## Algorithm: Analysis -> Rules (Angular)
+
+Follow this systematic approach for Angular projects:
+
+**Structure -> Architecture Rules:**
+1. Identify repeated folder/module structures across features.
+2. Define placement rules for components, services, models, and routes.
+3. Document cross-feature boundaries and allowed dependencies.
+
+**Components/Templates -> UI Rules:**
+1. Scan representative component and template files.
+2. Extract repeated patterns for bindings, control flow, and composition.
+3. Convert repeated high-quality patterns into concise rules.
+
+**State/Async -> Data Flow Rules:**
+1. Identify how state is owned and updated (signals/RxJS/store).
+2. Identify where side effects live and how async errors are handled.
+3. Identify subscription orchestration and signals/observables interop boundaries.
+4. Generate rules that keep ownership, side effects, and interop boundaries explicit.
+
+**Configs -> Architectural Constraints:**
+1. Inspect Angular/workspace/eslint settings.
+2. Promote only meaningful architectural constraints (aliases, boundaries, layering).
+3. Avoid restating trivial formatter/linter-only behavior.
+
+**Performance -> Change Detection and Template Rules:**
+1. Identify dominant change detection strategy (OnPush/default) by module type.
+2. Detect repeated template performance issues (heavy bindings, repeated function calls, unstable loops).
+3. Generate concise rules that improve performance without forcing architectural rewrites.
+
+**Red Flags -> Safety Rules:**
+1. If the same anti-pattern appears repeatedly, define "Avoid X, do Y instead".
+2. Tie alternatives to existing utilities/patterns used in this codebase.
+
+**Tests -> Testing Rules:**
+1. Identify where tests live and which module types are covered.
+2. Extract common spec patterns, helper usage, and minimal expected coverage.
+3. Require tests for module types that are consistently tested in this project.
+
+## Recommended Rule Topics (Angular Project)
+
+Split by topic:
+Generate only topics that are supported by concrete project evidence.
+
+| Topic | Covers (Angular-Specific) |
+|------|----------------------------|
+| \`architecture\` | feature boundaries, module placement, dependency direction |
+| \`components\` | standalone patterns, selector/file naming, composition |
+| \`templates\` | binding rules, control flow style, template complexity limits |
+| \`routing\` | lazy loading, guards/resolvers, route organization |
+| \`state-management\` | signals/RxJS/store ownership and side-effect boundaries |
+| \`state-interop\` | signals/observables bridge boundaries and ownership consistency |
+| \`services-data\` | API services, mapping, interceptors, error handling |
+| \`performance\` | change detection usage, template performance boundaries |
+| \`forms\` | reactive forms architecture, validation and submit flow |
+| \`styling\` | SCSS/CSS structure, token usage, naming convention |
+| \`testing\` | spec placement, test helpers, minimum critical checks |
+| \`error-handling\` | error mapping, user messages, retry/logging boundaries |
+| \`ssr-browser-boundaries\` | browser-only API guards and platform-safe behavior in SSR-capable projects |
+| \`i18n\` | localization key usage and string handling (if applicable) |
+
+## Context-to-Rule/Skill Mapping (Angular)
+
+Use this mapping to decide what files to generate:
+Generate only skills that are supported by concrete project evidence.
+
+| Found in Angular Codebase | Generate Rule Topic | Generate Skill |
+|--------------------------|---------------------|----------------|
+| Standalone component pattern | \`components\`, \`templates\` | \`adding-feature\` |
+| NgModule-heavy feature setup | \`architecture\`, \`components\` | \`adding-feature\` |
+| Nx workspace with boundary rules | \`architecture\` | \`monorepo-workflows\` |
+| Signals-based state | \`state-management\` | \`signals-patterns\` |
+| RxJS stream orchestration | \`state-management\` | \`rxjs-patterns\` |
+| NgRx store/effects | \`state-management\` | \`ngrx-patterns\` |
+| Signals/RxJS interop boundaries | \`state-interop\`, \`state-management\` | \`code-review\` |
+| Structured API services | \`services-data\` | \`adding-service\` |
+| Complex reactive forms | \`forms\` | \`forms-patterns\` |
+| OnPush-dominant components | \`components\`, \`templates\` | \`code-review\` |
+| Repeated template performance issues | \`performance\`, \`templates\` | \`troubleshooting\` |
+| Tailwind utility-first styling | \`styling\` | \`code-review\` |
+| BEM-dominant styling conventions | \`styling\` | \`code-review\` |
+| Route guards/resolvers usage | \`routing\` | \`code-review\` |
+| SSR/browser platform guards | \`ssr-browser-boundaries\` | \`troubleshooting\` |
+| Repeated runtime/build issues | \`error-handling\` | \`troubleshooting\` |
+| Repeated unsafe patterns | \`error-handling\` | \`common-anti-patterns\` |
+`;

package/dist/core/projects/createBankDeriveGuidance/stacks/ios.js

@@ -0,0 +1,254 @@
+export const IOS_DERIVE_GUIDANCE = `## iOS Guidance
+
+Focus on iOS/Swift patterns: SwiftUI, UIKit, architecture boundaries, state and async flow, navigation, services, testing, and UI boundaries.
+Treat SwiftUI, UIKit, TCA, MVVM, coordinators, and KMM as possible branches, not defaults. Promote only patterns that are supported by file-path evidence in this codebase.
+
+## Codebase Exploration Before Generating
+
+### Structure Discovery
+
+1. List contents of the root directory.
+2. Identify main source folders (for example: \`Sources/\`, \`Features/\`, \`App/\`, \`Modules/\`).
+3. Map the folder hierarchy 2-3 levels deep.
+4. Record the exact folder names and paths you found.
+
+### Pattern Extraction (Read Actual Files)
+
+For each category, read 2-3 representative Swift files and extract patterns:
+
+| Category | What to Find | What to Extract |
+|----------|--------------|-----------------|
+| Features/Screens | Feature folders (\`*View.swift\`, \`*ViewModel.swift\`, \`*Reducer.swift\`, \`*Coordinator.swift\`) | Screen/module structure and the actual local architecture pattern |
+| Services | Service files (\`*Service.swift\`, \`*Actor.swift\`) | Protocol abstraction, actor usage, async/await |
+| Views | SwiftUI views (\`*View.swift\`) | View composition, modifiers, environment usage |
+| Models/Entities | Entity files (\`*Entity.swift\`, \`*Model.swift\`) | Codable, Equatable, Identifiable conformances |
+| Tests | Test files (\`*Tests.swift\`) | XCTest structure, mocking, and any framework-specific helpers actually in use |
+| Navigation | Coordinator/Router files | NavigationStack, NavigationPath, coordinator, tab flow, or custom navigation ownership |
+| Dependencies | DI files (\`*Dependency.swift\`, \`*Client.swift\`, container or factory files) | TCA Dependencies, factories, constructor injection, or custom DI container |
+| Shared Modules | Shared components or modules folders | Reusable SwiftUI/UIKit components, styling tokens, app-wide primitives |
+| Platform Integration | App lifecycle, notifications, widgets, extensions, deep links | Runtime boundaries and platform-specific integration points |
+| KMM Integration | KMM wrapper files | ResultWrapper handling, entity mapping, only if present |
+
+### Config and Dependency Analysis (iOS-Specific)
+
+Read these iOS project files if they exist:
+- \`Package.swift\` (SPM dependencies and targets)
+- \`Podfile\` (CocoaPods dependencies)
+- \`*.xcodeproj\` / \`*.xcworkspace\` / \`project.pbxproj\`
+- \`Cartfile\` (Carthage, if used)
+- app entry point: \`@main App.swift\`, \`AppDelegate.swift\`, \`SceneDelegate.swift\`
+- architecture entry points only when present: \`AppReducer.swift\`, \`AppView.swift\`, root coordinator, root router
+- build configs: \`*.xcconfig\`, \`Info.plist\`, build phases
+- linter configs: \`.swiftlint.yml\`, \`.swiftformat\`
+- platform integration configs: widget/extension targets, deep-link registration, notification setup
+- KMM: \`shared/\` folder, \`KMMWrapper.swift\`, framework imports
+
+### Version and Feature Gate (iOS)
+
+Before turning patterns into rules, verify what is actually used in this codebase:
+- UI framework mode: SwiftUI, UIKit, or mixed.
+- Architecture style: TCA, MVVM, MVC, VIPER, Clean, coordinator-driven, lightweight screen logic, or mixed.
+- Async style: async/await, Combine, callbacks, or mixed.
+- Dependency pattern: TCA Dependencies, Resolver/Factory, constructor injection, manual injection, or mixed.
+- Navigation ownership: NavigationStack, coordinator/router, UIKit navigation controller, or mixed.
+- Platform surface: app-only, app + widgets/extensions, deep links, notifications, or mixed.
+- Do not force TCA, MVVM, coordinators, KMM, or any other architecture pattern unless project evidence supports them.
+- If the project is simple SwiftUI/UIKit without a heavyweight architecture, preserve that simplicity instead of inventing extra layers.
+
+### Red Flag Detection (Swift-Specific)
+
+Search for recurring iOS/Swift problems that should become explicit rules:
+- \`// TODO:\`, \`// FIXME:\`, \`// HACK:\` comments
+- \`// swiftlint:disable\` usage
+- \`@MainActor\` missing where needed, or overused
+- force unwraps \`!\` outside of tests or IBOutlets
+- \`print()\` statements in production code
+- hardcoded strings that should be localized
+- hardcoded colors/spacing where shared tokens/components exist
+- direct service instantiation instead of dependency injection
+- side effects in SwiftUI view body or reducer body
+- \`Task { }\` without proper cancellation handling
+- missing \`Equatable\`/\`Sendable\` conformances where needed
+- inconsistent async/await vs Combine usage
+- navigation logic leaking into unrelated view/service layers
+- UIKit/SwiftUI bridging patterns that are repeated but undocumented
+- extension/widget/deep-link boundaries handled inconsistently
+
+### Code Style Extraction (Swift)
+
+From representative Swift files, identify:
+- import order: \`Foundation\` -> \`SwiftUI/UIKit\` -> third-party -> local modules
+- access control patterns: \`private\`, \`internal\`, \`public\` usage
+- type naming: \`PascalCase\` for types, \`camelCase\` for properties/methods
+- file naming: \`FeatureNameView.swift\`, \`FeatureNameReducer.swift\`, \`FeatureNameViewModel.swift\`, etc.
+- extension organization: separate extensions for protocol conformances
+- MARK comments: \`// MARK: -\` usage for code organization
+- documentation: \`///\` doc comments on public APIs
+- property wrappers: \`@State\`, \`@Binding\`, \`@Environment\`, \`@Dependency\`, \`@Observable\` patterns
+- closure syntax: trailing closure conventions
+- guard vs if-let patterns
+
+### Analysis Checklist (iOS Project)
+
+Document these with file path evidence:
+
+- Architecture and feature module organization.
+- UI framework mode and screen composition patterns.
+- State management and async model.
+- Dependency injection and service/client pattern.
+- Navigation strategy and ownership.
+- Platform integration boundaries (widgets, extensions, notifications, deep links) if present.
+- Networking/persistence/KMM integration, if present.
+- Testing approach and helper usage.
+- Code style conventions that are not already enforced by formatters.
+- Main recurring anti-patterns and where they appear.
+
+Before final output, gather concrete evidence for each applicable item.
+If evidence remains partial, continue conservatively and mark uncertainty with \`[VERIFY: ...]\` instead of blocking output.
+
+### Generation Locks (Prevent Architecture Drift)
+
+Apply these constraints when generating rules and skills:
+- Preserve detected architecture (TCA/MVVM/coordinator/simple SwiftUI/UIKit/etc.) and do not migrate implicitly.
+- Preserve detected UI framework mode (SwiftUI/UIKit/mixed).
+- Preserve dependency injection and service ownership model.
+- Preserve navigation ownership model.
+- Preserve concurrency model unless strong project evidence suggests convergence.
+- Preserve the observed complexity level: if the project uses lightweight patterns, do not generate enterprise-style layers.
+- Preserve build/runtime and module-boundary assumptions.
+
+## Skill Candidates (iOS)
+
+Generate these skills with actual project paths and Swift-specific workflow steps:
+Generate only skills that have clear project evidence and practical value.
+For small/low-confidence projects, 2-4 core skills are usually enough.
+
+### adding-feature
+- Include actual feature folder structure used in this project.
+- Reference real View/ViewModel/Reducer/Coordinator files as templates based on the detected local architecture.
+- Show step-by-step for the detected architecture pattern only.
+- Include navigation and parent integration when relevant.
+
+### adding-service
+- Include actual service/client file paths and dependency registration style.
+- Show protocol definition, implementation, registration, and async/error handling.
+- Include mocking/test strategy for service behavior.
+
+### code-review
+- Include iOS/Swift-specific review checklist based on project patterns.
+- Cover architecture compliance, UI composition, async handling, dependency use, and testing.
+
+### common-anti-patterns
+- Include recurring Swift/iOS anti-patterns from this project.
+- Pair each anti-pattern with the preferred local alternative.
+
+### troubleshooting
+- Include common build/runtime/test issues for this codebase.
+- Include where to inspect first when these issues happen.
+
+### [framework-specific]
+Generate 1-3 additional skills based on actual stack usage:
+- tca-patterns (if TCA is primary)
+- mvvm-patterns (if MVVM or view-model-heavy flow is primary)
+- coordinator-patterns (if coordinator/router ownership is central)
+- kmm-integration (if shared/KMM is present)
+- adding-widget (if reusable widget/component system is central)
+- extension-workflows (if widgets/extensions/deep links are central)
+- [domain]-workflows (if a domain workflow is clearly repeated)
+
+### enrichment-tasks (optional)
+- Generate this only when the user explicitly asks for enrichment, or when analysis shows a clear gap in the existing rule/skill bank.
+
+## Rule Generation Requirements
+
+### What NOT to Include
+
+- Do not invent generic philosophy ("clean code", "think about user").
+- Do not duplicate what linters/formatters enforce.
+- Do not add rules without evidence from codebase patterns.
+- Do not repeat rules across multiple files.
+
+### Rule Content Requirements
+
+Keep this section iOS-specific:
+- Capture decisions tied to Swift architecture and app structure (TCA/MVVM, navigation, DI, async model).
+- Prefer Swift-native patterns and terminology over generic cross-stack wording.
+- Highlight iOS-specific risks and anti-patterns that recur in this codebase.
+- Match the actual architecture level of the project; do not upscale a lightweight codebase into a layered architecture just because the stack allows it.
+
+## Algorithm: Analysis -> Rules (iOS)
+
+Follow this systematic approach for iOS projects:
+
+**Structure -> Architecture Rules:**
+1. Detect patterns in feature folders and module layout.
+2. Generate placement rules for the artifacts that actually exist here: views, view models, reducers, coordinators, services, models, modules.
+3. Document module boundaries and what can import what.
+
+**Swift Files -> Code Style Rules:**
+1. For views, reducers/view models, and services, scan 2-3 representative files each.
+2. Identify import grouping, access control, MARK usage, and extension organization.
+3. Promote only repeated high-signal conventions.
+
+**Configs -> Architectural Rules:**
+1. Inspect Package.swift, Podfile, swiftlint, xcconfig, and project metadata.
+2. Create rules for module imports, dependency access, runtime boundaries, and platform integrations.
+3. Do not restate what SwiftLint/SwiftFormat already enforce.
+
+**Red Flags -> Safety Rules:**
+1. If the same Swift anti-pattern appears repeatedly, define "Avoid X, do Y instead".
+2. Reference the actual correct pattern from this repo.
+
+**Tests -> Testing Rules:**
+1. Identify test location pattern and XCTest/TestStore usage.
+2. Extract mocking and assertion conventions.
+3. Require tests only for module types that are consistently tested in this project.
+
+## Recommended Rule Topics (iOS Project)
+
+Split by topic:
+Generate only topics that are supported by concrete project evidence.
+
+| Topic | Covers (iOS-Specific) |
+|------|------------------------|
+| \`architecture\` | TCA/MVVM structure, layers, feature module organization |
+| \`code-style\` | Swift naming, imports, access control, MARK comments |
+| \`dependencies\` | DI pattern, service protocols, actors, dependency registration |
+| \`navigation\` | NavigationStack, Coordinator, or reducer-driven navigation |
+| \`swiftui-patterns\` | View composition, modifiers, environment, previews |
+| \`uikit-patterns\` | UIViewController patterns, lifecycle, layout (if UIKit) |
+| \`tca-patterns\` | Reducer structure, State/Action, effects, testing (if TCA) |
+| \`mvvm-patterns\` | ViewModel ownership, bindings, async flow (if MVVM) |
+| \`services\` | API clients, persistence, mapping, boundary normalization |
+| \`widget-system\` | Reusable UI components and styling tokens |
+| \`kmm-integration\` | Shared/KMM wrappers and entity bridging |
+| \`platform-integration\` | widgets, extensions, notifications, deep links, app lifecycle boundaries |
+| \`testing\` | XCTest patterns, TestStore, mocking, snapshots |
+| \`error-handling\` | Error types, logging, user-facing failures |
+| \`localization\` | String localization and formatting (if applicable) |
+
+## Context-to-Rule/Skill Mapping (iOS)
+
+Use this mapping to decide what files to generate:
+Generate only skills that are supported by concrete project evidence.
+
+| Found in iOS Codebase | Generate Rule Topic | Generate Skill |
+|----------------------|---------------------|----------------|
+| TCA architecture (\`@Reducer\`, \`Store\`) | \`architecture\`, \`tca-patterns\` | \`adding-feature\` |
+| MVVM architecture (\`ObservableObject\`, \`@Observable\`) | \`architecture\`, \`mvvm-patterns\` | \`adding-feature\`, \`mvvm-patterns\` |
+| Swift code conventions | \`code-style\` | \`code-review\` |
+| TCA Dependencies (\`@Dependency\`) | \`dependencies\` | \`adding-service\` |
+| Custom DI (Resolver, Factory) | \`dependencies\` | \`adding-service\` |
+| NavigationStack / Coordinator | \`navigation\` | - |
+| SwiftUI views | \`swiftui-patterns\` | - |
+| UIKit views | \`uikit-patterns\` | - |
+| API/Network layer | \`services\` | - |
+| Reusable UI components | \`widget-system\` | \`adding-widget\` |
+| KMM shared module | \`kmm-integration\` | \`kmm-integration\` |
+| Widgets/extensions/deep links | \`platform-integration\` | \`extension-workflows\` |
+| XCTest / TCA TestStore | \`testing\` | - |
+| Error types, logging | \`error-handling\` | - |
+| Localized strings | \`localization\` | - |
+| SwiftLint violations | - | \`common-anti-patterns\` |
+| Build/runtime issues | - | \`troubleshooting\` |
+`;