Skip to content

Instantly share code, notes, and snippets.

@hcastro
hcastro / git-worktree.md
Created October 25, 2025 13:29
git worktree cursor command

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).
@hcastro
hcastro / gist:bd9e165ced5083bce62e1569d1181b25
Last active August 15, 2025 02:05
cursor planner mode
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
hcastro / gist:aacba5415735328689272eccb7349b92
Created July 21, 2025 16:58
Dynamic Onboarding Flow Generation Prompt
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
hcastro / nextjs-cache-invalidate.md
Created May 7, 2025 20:26
Cache Invalidation playbook (nextjs 15 / RSC)

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
hcastro / publishing-pull-requests.md
Created April 4, 2025 02:49
Best Practices for Publishing Pull Requests in Modern Software Teams

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
hcastro / git-commit-assistant.mdc
Created April 2, 2025 15:13
git commit assistant
---
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
hcastro / gist:0ec6d2f7c86466971efbaecacd049217
Created October 24, 2019 18:22
appium 1.15 unknown udid
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