@dtt_siye/atool 1.1.0

package/skills/smart-dispatch/implementer-prompt.md

@@ -0,0 +1,146 @@
+# Implementer Agent Prompt Template (Smart-Dispatch)
+
+Use this template when dispatching implementer agents in smart-dispatch mode.
+
+**Key differences from subagent-driven-development:**
+- Agents do NOT commit (controller handles all git operations)
+- Agents do NOT install dependencies (sequential only)
+- Agents have strict file scope constraints
+- Agents report status for the controller to coordinate
+
+---
+
+## Template
+
+```
+Agent tool (general-purpose):
+  description: "Implement Task {N}: {task name}"
+  run_in_background: true
+  prompt: |
+    You are implementing Task {N}: {task name}
+
+    ## Task Description
+
+    {FULL TEXT of task from plan — paste it here, do NOT make agent read file}
+
+    ## Context
+
+    {Where this fits in the project: which chunk, what prior tasks built,
+     what this task depends on, architectural context}
+
+    ## Scope Limitations (CRITICAL)
+
+    You MUST strictly follow these scope constraints:
+
+    **ALLOWED:**
+    - Create these files: {list Create: files from task}
+    - Modify these files: {list Modify: files from task}
+
+    **FORBIDDEN:**
+    - git commit, git push, git add (controller handles ALL git operations)
+    - npm install, yarn add, pnpm add (dependency installation is sequential)
+    - cargo build, cargo add, pip install, go mod tidy (same reason)
+    - Modify ANY file NOT listed above
+    - Create ANY file NOT listed above
+
+    If you discover you need to modify or create a file outside this scope,
+    **STOP and return BLOCKED status** with details about what you need.
+
+    ## Before You Begin
+
+    If you have questions about:
+    - The requirements or acceptance criteria
+    - The approach or implementation strategy
+    - Dependencies or assumptions
+    - Anything unclear in the task description
+
+    **Ask them now.** Raise any concerns before starting work.
+
+    ## Your Job
+
+    Once you're clear on requirements:
+    1. Implement exactly what the task specifies
+    2. Write tests (if task specifies)
+    3. Verify implementation works
+    4. DO NOT commit (controller will handle this)
+    5. Self-review (see below)
+    6. Report back
+
+    Work from: {project directory}
+
+    **While you work:** If you encounter something unexpected or unclear, **ask questions**.
+    It is always OK to pause and clarify. Don't guess or make assumptions.
+
+    ## Code Organization
+
+    - Follow the file structure defined in the plan
+    - Each file should have one clear responsibility
+    - If a file you're creating grows beyond the plan's intent, stop and report
+      it as DONE_WITH_CONCERNS — don't split files on your own
+    - In existing codebases, follow established patterns
+    - Improve code you're touching the way a good developer would, but don't
+      restructure things outside your task scope
+
+    ## When You're in Over Your Head
+
+    **STOP and escalate when:**
+    - The task requires architectural decisions with multiple valid approaches
+    - You need to understand code beyond what was provided
+    - You feel uncertain about whether your approach is correct
+    - You've been reading files trying to understand without progress
+
+    **How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT.
+    Describe specifically what you're stuck on, what you've tried, and what
+    kind of help you need.
+
+    ## Before Reporting Back: Self-Review
+
+    Review your work:
+
+    **Completeness:**
+    - Did I implement everything in the spec?
+    - Did I miss any requirements or edge cases?
+
+    **Quality:**
+    - Are names clear and accurate?
+    - Is the code clean and maintainable?
+
+    **Discipline:**
+    - Did I avoid overbuilding (YAGNI)?
+    - Did I only build what was requested?
+    - Did I stay within my scope constraints?
+
+    If you find issues during self-review, fix them now.
+
+    ## Report Format
+
+    When done, report with this exact format:
+
+    **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
+    **Implemented:** {what you built}
+    **Files changed:** {list of files with brief description of changes}
+    **Tests:** {what you tested and results}
+    **Self-review:** {findings, if any}
+    **Concerns:** {if DONE_WITH_CONCERNS, explain the concerns}
+
+    Use DONE_WITH_CONCERNS if you completed the work but have doubts.
+    Use BLOCKED if you cannot complete the task.
+    Use NEEDS_CONTEXT if you need information that wasn't provided.
+    Never silently produce work you're unsure about.
+```
+
+## Usage Notes
+
+**Model selection:**
+- Simple tasks (1-2 files, clear spec): use `haiku` or `sonnet` model
+- Integration tasks (multi-file, pattern matching): use `sonnet`
+- Complex tasks (architecture decisions, nuanced logic): use `opus`
+
+**Re-dispatch:**
+- If agent returns NEEDS_CONTEXT → provide the context, re-dispatch with same template
+- If agent returns BLOCKED → escalate to user, do NOT re-dispatch automatically
+- If review fails → re-dispatch fix agent with additional context about what failed
+
+**Timeout:**
+- Default: allow up to 10 minutes per task
+- If agent appears stuck → check output, treat as BLOCKED if no progress

package/skills/smart-dispatch/reviewer-prompt.md

@@ -0,0 +1,199 @@
+# Reviewer Agent Prompt Template (Smart-Dispatch)
+
+Use this template when dispatching reviewer agents in smart-dispatch mode.
+
+Two review stages: **Spec Compliance** (stage 1) and **Code Quality** (stage 2).
+Stage 2 only runs after Stage 1 passes.
+
+---
+
+## Stage 1: Spec Compliance Review
+
+```
+Agent tool (general-purpose):
+  description: "Spec review Task {N}: {task name}"
+  prompt: |
+    You are reviewing whether an implementation matches its specification.
+
+    ## What Was Requested
+
+    {FULL TEXT of task requirements from the plan}
+
+    ## What Implementer Claims They Built
+
+    {From implementer's report — paste the full report}
+
+    ## CRITICAL: Do Not Trust the Report
+
+    The implementer's report may be incomplete, inaccurate, or optimistic.
+    You MUST verify everything independently by reading the actual code.
+
+    **DO NOT:**
+    - Take their word for what they implemented
+    - Trust their claims about completeness
+    - Accept their interpretation of requirements
+
+    **DO:**
+    - Read the actual code they wrote
+    - Compare actual implementation to requirements line by line
+    - Check for missing pieces they claimed to implement
+    - Look for extra features they didn't mention
+
+    ## Scope Check
+
+    The implementer was restricted to these files:
+    - Create: {file list}
+    - Modify: {file list}
+
+    Verify:
+    - Did they ONLY create/modify the listed files?
+    - Did they touch any files outside scope?
+    - If yes → this is a CRITICAL issue
+
+    ## Your Job
+
+    Read the implementation code and verify:
+
+    **Missing requirements:**
+    - Did they implement everything requested?
+    - Are there requirements they skipped or missed?
+    - Did they claim something works but didn't implement it?
+
+    **Extra/unneeded work:**
+    - Did they build things not requested?
+    - Did they over-engineer or add unnecessary features?
+    - Did they add "nice to haves" not in spec?
+
+    **Misunderstandings:**
+    - Did they interpret requirements differently than intended?
+    - Did they solve the wrong problem?
+
+    ## Report Format
+
+    Report with this exact format:
+
+    **Verdict:** PASS | FAIL
+    **Scope Compliance:** PASS | VIOLATION — {details}
+
+    If PASS:
+      Brief summary confirming spec compliance.
+
+    If FAIL:
+      List each issue:
+      - [MISSING] {what was not implemented} ({file}:{line})
+      - [EXTRA] {what was built but not requested} ({file}:{line})
+      - [WRONG] {what was misunderstood} ({file}:{line})
+```
+
+---
+
+## Stage 2: Code Quality Review
+
+**Only dispatch after Stage 1 passes.**
+
+```
+Agent tool (general-purpose):
+  description: "Quality review Task {N}: {task name}"
+  prompt: |
+    You are reviewing code quality for an implementation.
+
+    ## Implementation Details
+
+    Task: {task name}
+    Files changed:
+    {list of changed files with brief descriptions from implementer report}
+
+    ## Your Job
+
+    Review the actual code for quality concerns:
+
+    **Dead code:**
+    - Unused imports?
+    - Unreachable code?
+    - Commented-out code that should be removed?
+
+    **Duplication:**
+    - Copy-pasted code that should be extracted?
+    - Similar patterns that could be abstracted?
+
+    **Complexity:**
+    - Functions > 40 lines?
+    - Cyclomatic complexity > 10?
+    - Deep nesting (> 3 levels)?
+
+    **Error handling:**
+    - Unhandled errors?
+    - Empty catch blocks?
+    - Unsafe patterns (unwrap without check, null without guard)?
+
+    **Security:**
+    - Hardcoded credentials or secrets?
+    - SQL injection, XSS, or other OWASP issues?
+    - Unvalidated user input?
+
+    **Conventions:**
+    - Follows project's established patterns?
+    - Naming conventions consistent?
+    - File organization clean?
+
+    ## Severity Levels
+
+    - **Critical:** Must fix before commit (security, data loss, crash risk)
+    - **Important:** Should fix (dead code, duplication, poor error handling)
+    - **Minor:** Nice to have (naming, formatting, minor style issues)
+
+    ## Report Format
+
+    **Verdict:** PASS | FAIL
+    **Issues found:** {count}
+
+    If PASS:
+      Brief summary of strengths.
+
+    If FAIL:
+      List each issue:
+      - [Critical] {description} ({file}:{line})
+      - [Important] {description} ({file}:{line})
+      - [Minor] {description} ({file}:{line})
+
+      Suggest fixes for Critical and Important issues.
+```
+
+---
+
+## Usage Notes
+
+**Review scheduling:**
+- Reviews run SEQUENTIALLY per task (not parallelized)
+- Stage 2 only after Stage 1 passes
+- If Stage 1 fails → re-dispatch implementer fix agent, then re-run Stage 1
+- If Stage 2 fails → re-dispatch implementer fix agent, then re-run Stage 2
+- Max 2 retries per review stage
+
+**Fix agent re-dispatch:**
+When a review fails, re-dispatch the implementer with additional context:
+
+```
+Agent tool (general-purpose):
+  description: "Fix Task {N}: {issue description}"
+  run_in_background: {same as original dispatch}
+  prompt: |
+    You are fixing issues found during review of Task {N}.
+
+    ## Original Task
+    {task description}
+
+    ## Review Findings
+    {reviewer's report with specific issues}
+
+    ## Your Job
+    Fix ONLY the issues identified in the review. Do not change anything else.
+    Follow the same scope constraints as the original task.
+
+    ## Report Format
+    Same as original: Status, Files changed, What was fixed.
+```
+
+**Model for reviewers:**
+- Use `sonnet` for reviews (good balance of speed and thoroughness)
+- Use `opus` for complex architectural reviews

package/skills/software-architecture/SKILL.md

@@ -0,0 +1,278 @@
+---
+name: software-architecture
+description: Use when designing, reviewing, or scaffolding system architecture — covers architecture style selection, high-concurrency/HA design, DDD, clean architecture, microservice boundaries, and deployment strategy.
+version: 1.0.0
+category: architecture
+---
+
+# Software Architecture Design Skill
+
+Use this skill when asked to design, evolve, review, or scaffold backend/system architecture — especially for Java-based platforms, distributed systems, microservices, high-concurrency services, or cloud-native deployments.
+
+## When to Trigger
+
+- Design system or technical architecture
+- Choose between monolith, distributed, SOA, microservice, serverless
+- Split modules, services, domains, or repositories
+- Design for high concurrency / high availability / scalability
+- Define service boundaries, gateway, cache, MQ, registry, config center, observability
+- Review whether an architecture is over-designed or under-designed
+- Propose deployment topology, CI/CD flow, container or Kubernetes deployment
+- Produce ADRs, architecture notes, HLD/LLD, or implementation plans
+
+Do not trigger for isolated code formatting or minor bug fixes unless they affect architecture or non-functional requirements.
+
+---
+
+## Core Philosophy
+
+Three principles drive every architecture decision:
+
+1. **Architecture serves business technical problems, not technology fashion.** It exists to solve high concurrency, high availability, performance, scalability, security, and evolution — not to showcase frameworks.
+
+2. **The soul of architecture is the technical solution, not the middleware list.** "Using Redis / MQ / Kubernetes" is not architecture. Components are useful only when they serve a coherent solution.
+
+3. **Architecture must evolve.** Avoid "ultimate architecture" one-shot design. Design for the current business stage; iterate as scale, complexity, and traffic change.
+
+Prefer: **suitable over trendy**, **simple over grand but fragile**, **evolvable over one-step finality**.
+
+---
+
+## Non-Negotiable Principles
+
+1. **Suitability first** — choose what the team can realistically build, operate, and debug.
+2. **Simplicity first** — if a simpler design meets current requirements, prefer it.
+3. **Evolution first** — the first architecture should leave room for extraction, scaling, and refactoring later.
+4. **Problem-first reasoning** — always describe: business context → constraints → technical risks → candidate solution → trade-offs → chosen architecture → evolution path.
+5. **Clear boundaries** — every service/module/repo/DB boundary must correspond to a real business capability, not arbitrary technical slicing.
+6. **Operational reality** — architecture is incomplete without deployment, observability, rollback, security, and change management.
+
+---
+
+## Architecture Decision Workflow
+
+### Step 1: Frame the Problem
+State: business goal, users/traffic/environments, latency/availability/scalability/security expectations, team capability, delivery timeline, major constraints (existing stack, compliance, integration dependencies).
+
+### Step 2: Identify the Dominant Technical Problem
+Classify the main driver: high concurrency / high availability / performance bottleneck / delivery speed / integration complexity / data consistency / cost or ops burden.
+
+### Step 3: Choose the Minimum Viable Architecture Style
+
+Use this progression — explain why simpler options are not enough before recommending a more complex one:
+
+| Style | Choose when |
+|-------|------------|
+| **Monolith** | Small scope, small team, fast delivery, domain still changing |
+| **Distributed modular** | Modules need independent scaling/deployment, multiple channels sharing backend |
+| **SOA** | Enterprise-level shared service layer, heterogeneous protocols already in use |
+| **Microservices** | Clear business capability splits, teams own services independently, full ops/tooling ready |
+| **Serverless** | Event-driven, bursty traffic, minimal infra management desired |
+
+### Step 4: Define Architecture Building Blocks
+Define only what is necessary: client/frontend, gateway/access layer, application/service layer, domain/business layer, persistence/data layer, cache, MQ, config center, service registry, auth/identity, observability, deployment/CI-CD, rollback/resilience.
+
+### Step 5: Map NFRs to Concrete Design
+| NFR | Concrete mechanisms |
+|-----|-------------------|
+| High concurrency | Statelessness, horizontal scaling, cache, queue, async, read-write split |
+| High availability | Degrade, rate limit, rollback, gray release, redundancy |
+| Performance | Static resources, request merge, caching, async IO |
+| Maintainability | Clear service boundaries, API contracts, documentation, automated tests |
+| Security | Authn/authz, validation, audit, masking, secure defaults |
+
+### Step 6: Produce Deliverables
+Architecture summary, component view, deployment view, service decomposition, data flow, interface contract outline, risk list with mitigations, phased evolution roadmap, implementation checklist.
+
+---
+
+## Architecture Style Rules
+
+### Monolith
+- Keep clear layered/module boundaries inside — do not let it become "big ball of mud"
+- Isolate domain modules even within one repo
+- Prepare extraction seams around high-change or high-load modules
+- **Do not recommend microservices if the only reason is "future scalability" without present evidence**
+
+### Distributed Modular System
+- Define interface boundaries early
+- Keep shared business logic in versioned service layers or libraries
+- Make remote communication explicit and observable
+
+### Microservices
+Choose only when **all** are mostly true: clean business capability splits, teams own services independently, full tooling ready (CI/CD, tracing, monitoring, config, registry, gateway).
+
+Rules:
+- Each service = one clear business capability
+- Services must be independently deployable
+- Do not share databases across services unless transitional and justified
+- Document consistency strategy when data spans services
+- Ensure automated contract and integration testing
+
+**Warning signs:** too-tiny services without strong boundaries, no tracing/gateway/config center/rollback plan, distributed transactions added casually, services split by technical layer instead of business capability.
+
+### Serverless
+- Address function granularity — too fine creates orchestration overhead
+- Handle observability and integration testing explicitly
+
+---
+
+## Clean Architecture & DDD Principles
+
+- Follow **Domain-Driven Design** and ubiquitous language
+- Separate domain entities from infrastructure concerns
+- Keep business logic independent of frameworks
+- Define use cases clearly and keep them isolated
+- Use **domain-specific names**: `OrderCalculator`, `UserAuthenticator` — avoid generic names like `utils`, `helpers`, `common`, `shared`
+- Separate concerns: no business logic in UI components, no DB queries in controllers
+
+---
+
+## High-Concurrency Design
+
+When concurrency is a key requirement, apply these levers in order:
+
+1. **Statelessness** — prefer stateless services; use token-based context; avoid sticky sessions
+2. **Splitting** — by business domain, read/write characteristics, or function/sub-capability
+3. **Service governance** — discovery, routing, timeout, retry, rate limiting, fallback
+4. **Caching by layer** — client cache → CDN/edge → gateway/access → application → data layer. Define cacheable objects, TTL, invalidation strategy; call out consistency risks
+5. **Message queue and async** — use MQ only for: decoupling, async non-blocking work, traffic buffering/peak shaving, eventual consistency. Define retry/dead-letter/compensation
+6. **Reduce request count** — staticization, request merge/aggregation, rate limiting, load shaping
+7. **Speed up the path** — parallelize independent steps, async notifications, read replicas, delayed writes for non-real-time ops
+8. **Resource scaling** — horizontal scaling preferred; vertical scaling acceptable as fastest short-term fix
+
+---
+
+## High-Availability Design
+
+### Degradation
+- Centralized degrade switches
+- Fallback to local cache / stale data / read-only mode where acceptable
+- Front-loaded degrade at gateway or Nginx
+- Business-priority downgrade: keep core flow, defer/disable non-core features
+
+### Rate Limiting and Protection
+- Controls for malicious traffic, abnormal IPs, gateway-level throttling
+
+### Rollback
+Every architecture proposal must include: rollback path, stable previous version reference, gray release strategy if relevant.
+
+### Monitoring and Alerts
+At minimum: metrics, logs, traces, alert thresholds, **business error monitoring** (not just system error monitoring).
+
+---
+
+## Business Design Rules
+
+Always consider for order, payment, submission, workflow, approval, job triggering, messaging, and callback scenarios:
+
+- **Duplicate-prevention design**
+- **Idempotency** — explicit design for any operation that may be retried
+- **State machines** — for workflows with distinct states and transitions
+- **Operation feedback** in admin/backoffice systems
+- **Approval flow** for high-risk or business-controlled changes
+- **Backup / recovery** thinking
+
+---
+
+## Cloud-Native Platform Baseline
+
+Only include components the scenario justifies — do not recommend the full stack for a small internal system:
+
+WAF / CDN / ingress / LB → API gateway → service registry/discovery → config center → auth / OAuth2 → service-to-service client or RPC → cache layer → relational DB (with replicas/shards if needed) → MQ → object storage → search engine (if needed) → metrics + tracing + logs → alerting → container registry → CI/CD → Kubernetes or equivalent.
+
+---
+
+## Output Format
+
+### A. Architecture Summary
+- Business context and dominant technical drivers
+- Recommended architecture style
+- Why this complexity level is right for now
+
+### B. Component Design
+Key components and their responsibilities.
+
+### C. Data and Interaction Design
+Sync vs async boundaries, API boundaries, data ownership, consistency approach, cache strategy.
+
+### D. Deployment and Operations
+Environment layout, scaling model, CI/CD, observability, rollback.
+
+### E. Risk and Trade-offs
+What this architecture solves and what complexity it introduces.
+
+### F. Evolution Roadmap
+Phased stages — e.g., Phase 1: modular monolith → Phase 2: extract hot/high-change services → Phase 3: platform governance and observability hardening.
+
+---
+
+## Integration with Tech-Stack Skills
+
+This skill orchestrates architecture; stack-specific skills govern implementation detail.
+
+| Concern | Skill |
+|---------|-------|
+| Module/service boundaries | **This skill** |
+| Controller/service/dao code style, logging, naming | **java-conventions** |
+| React/Vue/JS/CSS project structure and implementation | **web-conventions** |
+| Go project structure, error handling, concurrency patterns | **go-conventions** |
+| Python project structure, typing, async patterns | **python-conventions** |
+| Rust project structure, ownership, error handling | **rust-conventions** |
+| Swift/iOS project structure, SwiftUI patterns | **swift-conventions** |
+| Flutter/Dart project structure, widget patterns | **flutter-conventions** |
+| React Native project structure, navigation patterns | **react-native-conventions** |
+| Android/Kotlin project structure, Jetpack patterns | **android-conventions** |
+| HarmonyOS/ArkTS project structure, ArkUI patterns | **harmony-conventions** |
+| Dockerfile, Terraform, CI/CD pipeline patterns | **devops-conventions** |
+
+## Integration with Workflow Skills
+
+| Workflow | When to Use | How |
+|----------|-------------|-----|
+| **project-analyze** | Analyzing an existing project's architecture | Run `/project-analyze` (v5.0 五维分析框架) first to generate knowledge graph and module inventory, then use that data to inform architecture review |
+| **code-review** | Architecture compliance validation | code-review Dimension 5 validates architecture compliance; for major violations, follow up with this skill for deeper review |
+| **doc-standards-enforcer** | Producing architecture documentation (ADRs, HLD/LLD) | After producing architecture deliverables, validate documentation format with `doc-standards-enforcer` |
+| **doc-coauthoring** | Co-authoring technical specs or design documents | Use `doc-coauthoring` workflow for collaborative document creation; this skill provides technical content accuracy |
+| **project-query** | 需要查询架构分析详细数据（层违反、耦合度等） | 建议运行 |
+
+### Architecture Review Workflow
+
+For existing projects requiring architecture assessment:
+
+1. Run `/project-analyze` (v5.0 五维分析框架) to generate knowledge graph
+2. Review the generated architecture diagrams and module dependency graph
+3. Use this skill's Review Checklist against the analysis results
+4. Produce ADR or architecture improvement plan
+5. Validate output with `doc-standards-enforcer`
+
+---
+
+## Guardrails
+
+Do **not**:
+- Recommend microservices by default
+- Add Redis, MQ, ES, Kubernetes, or gateway without tying them to a requirement
+- Create service splits that mirror technical layers instead of business capabilities
+- Ignore rollback, observability, or release strategy
+- Propose strong consistency across distributed services without calling out complexity and cost
+- Treat architecture diagrams as sufficient without delivery and ops explanation
+- Overfit for hypothetical future scale while hurting current delivery
+
+---
+
+## Review Checklist
+
+**Problem-fit:** Business problem clearly stated? Main technical driver identified? Design solves real problem rather than showcases technology?
+
+**Simplicity:** Is there a simpler design that would work now? Unnecessary distributed complexity avoided?
+
+**Boundaries:** Service/module boundaries aligned to business capability? Data ownership clear? Sync and async boundaries clear?
+
+**NFR mapping:** Each key NFR mapped to concrete architecture measures? Concurrency, availability, security, and performance handled explicitly?
+
+**Operability:** Monitoring, logs, traces, alerts, and rollback covered? Deployment topology described?
+
+**Safety and correctness:** Duplicate prevention and idempotency addressed? Rate limits, degradation, and fallback paths defined? Consistency trade-offs explained?
+
+**Evolution:** Design supports incremental evolution? Phased roadmap instead of "final architecture" thinking?

package/skills/swift-conventions/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: swift-conventions
+description: Swift/iOS development conventions and best practices
+version: 1.0.0
+---
+
+# Swift / iOS Conventions
+
+Use this skill when working on Swift/iOS applications.
+
+## When to Use
+- Detected iOS/Swift project (Package.swift, .xcodeproj, .xcworkspace)
+- User asks about iOS or Swift development best practices
+- Writing or reviewing Swift code
+
+## Related Skills
+- `android-conventions` — Android native development
+- `flutter-conventions` — Flutter/Dart cross-platform development
+
+## General Principles
+- Follow Apple Human Interface Guidelines
+- Responsive layouts that adapt to different screen sizes and orientations
+- Handle offline scenarios gracefully
+- Optimize for performance (list lazy loading, memory management)
+- Proper error handling and user feedback
+
+## Code Style
+- Follow Swift API Design Guidelines
+- Use SwiftUI for UI (modern projects)
+- Protocol-oriented programming
+- Value types over reference types when possible
+- `guard` for early returns
+- `final` classes by default, only remove when subclassing is needed
+
+## Architecture
+- MVVM with SwiftUI
+- The Composable Architecture (TCA) for complex state
+- Clean Architecture for large apps
+
+## SwiftUI Patterns
+- `@StateObject` for owned observable objects
+- `@ObservedObject` for observed objects from parent
+- `@EnvironmentObject` for shared state
+- `@AppStorage` for user preferences
+- `@Observable` macro (Observation framework) for modern projects
+
+## API Integration
+- Repository pattern for data access
+- Error handling with proper user feedback
+- Loading states and skeleton screens
+- `async/await` for network calls
+- Offline-first when applicable
+
+## Navigation
+- SwiftUI NavigationStack / NavigationSplitView
+- Type-safe routing with enums
+- Deep linking support
+- Sheet and fullScreenCover for modals
+
+## Testing
+- XCTest for unit and UI tests
+- Swift Testing framework (new)
+- Mock with protocols (no mocking frameworks needed)
+- Preview-based development
+- `@Test` macro for modern test syntax
+
+## Performance
+- Lazy loading for large lists
+- Image optimization and caching (Kingfisher/AsyncImage)
+- Instruments profiling
+- Reduce view body complexity
+- Use `@ViewBuilder` judiciously