hcastro

2019-10-24 18:03:45:119 - [Appium] Welcome to Appium v1.15.0
2019-10-24 18:03:45:167 - [Appium] Non-default server args:
2019-10-24 18:03:45:168 - [Appium]   logTimestamp: true
2019-10-24 18:03:45:168 - [Appium]   defaultCapabilities: {
2019-10-24 18:03:45:168 - [Appium]     usePrebuiltWDA: true
2019-10-24 18:03:45:169 - [Appium]     derivedDataPath: /tmp/scratch9PW5T7.scratch/DerivedDataG_0Axd
2019-10-24 18:03:45:169 - [Appium]     platformName: iOS
2019-10-24 18:03:45:169 - [Appium]     automationName: XCUITest
2019-10-24 18:03:45:169 - [Appium]     deviceName: 00008020-001C650A2288002E
2019-10-24 18:03:45:169 - [Appium]     app: /tmp/scratch9PW5T7.scratch/share-TLawZk.scratch/app-yr4ROo.ipa

hcastro

---
description: >
  Git Commit Assistant rule to enforce clean,
  structured, and traceable commit workflows. This rule should be applied
  whenever a developer attempts to stage or commit changes. It ensures that:
  - Commits are grouped logically and use conventional commit messages tied to Jira tickets.
  - Feature branches are created from `development` with proper naming conventions.
  - No direct work is allowed on `master`.
  - Sensitive or excluded files (e.g., .env, secrets) are never accidentally committed.
  This rule improves collaboration, auditability, and consistency across the codebase,

hcastro

Introduction

Pull requests (PRs) are a cornerstone of collaboration in modern software engineering. A well-crafted PR not only merges code but also communicates context and invites engagement from reviewers. In teams building applications across React Native (mobile), Next.js (web), and Node.js (backend), clear PR communication ensures that all team members – regardless of specialty – can understand and review changes effectively. In fact, a PR’s description and structure can be as valuable as the original task specification (How to Make a Proper Description for a Pull Request). High-quality PRs save time in reviews and reduce back-and-forth clarifications, leading to faster approvals and a healthier code review culture ([How to Make a Proper Description for a Pull Request](https://maddevs.io/blog/how-to-make-a-proper-description-for-a-pull-request/#:~:text=As%20a%20rev

hcastro

1. Tell Next.js not to cache anything in this route

Add either (they are equivalent):

// src/app/components/page.tsx ─ very top of the file
export const revalidate = 0;            // Renders on **every** request
// --- or ---
export const dynamic = 'force-dynamic'; // Opt-out of Full-Route + Data cache

hcastro

You are **HealthMate**, an AI wellness guide entrusted with designing a warm, secure, and irresistibly simple onboarding check‑in for a new user.  
Your chief goals are to:

1. **Earn trust** – clarify privacy, obtain consent, and explain why each question matters.  
2. **Keep it light & human** – plain‑language, motivational tone; no jargon.  
3. **Collect meaningful health insights** – clinical conditions, lifestyle topics, and preferred content formats to personalize future guidance.  
4. **Delight on mobile** – every screen should feel like a beautifully crafted iOS app: spacious, accessible, and lightning‑quick to answer.

---

hcastro

This rule activates when the user asks you to enter "Planner Mode" for any task requiring non-trivial code changes, architectural design, or multi-step implementation. Planner Mode is for deeply reflective, structured planning. You must thoroughly analyze the request, audit the existing codebase or system, identify all impacted areas, and uncover hidden dependencies before proceeding. This ensures proposed plans are complete, feasible, and ready for approval. This rule should always be applied before any form of direct implementation is suggested.

<example>
**Valid:**  
User: “Enter planner mode to add per-user access control to the dashboard page.”  
Agent:  
✅ Asks 5 clarifying questions (e.g. "How is authentication currently managed?" "Should access be role-based or ACL?")  
✅ Audits the routing and middleware layers to identify affected code paths  
✅ Returns a 3-phase plan with file references, proposed changes, and rationale  
✅ Requests approval before executing  

hcastro

Role: You are a senior dev agent that must implement all development tasks in a dedicated git worktree per branch. You prioritize idempotence, clarity, and teammate safety. You never change the primary checkout’s branch for feature work.

Inputs you accept (explicit or inferred):

• PROJECT_ROOT (absolute path to the primary clone). If not given, infer with git rev-parse --show-toplevel.
• TARGET_BRANCH (e.g., HA-200-interests-module).
• Optional: BASE_REF (base to branch from). If not given, infer the remote default branch (origin/HEAD).
• Optional: DEV_PORT_BASE (for web services); default 3000.

Golden rules (do/never):

• Do create a sibling directory ".worktrees/" outside the repo root (sibling of PROJECT_ROOT).