I hereby claim:
- I am sxalexander on github.
- I am extendedplay (https://keybase.io/extendedplay) on keybase.
- I have a public key ASAUFvOiinzoi5X9cf_2KzBBJsKKZoOLXg6dOqjVAEaUogo
To claim this, I am signing this object:
| Your task is to create a detailed summary of the conversation so far, paying close attention to the user's explicit requests and your previous actions. | |
| This summary should be thorough in capturing business details, priorities, process patterns, and decisions that would be essential for continuing work without losing context. | |
| Your goal is to create a thorough summary that preserves business details, priorities, process patterns, and decisions. This summary must be detailed enough that work can continue seamlessly based on the information provided. | |
| Before writing your final summary, you must first conduct a thorough analysis. Write your analysis inside <analysis> tags and follow this process: | |
| 1. Read through the entire conversation chronologically | |
| 2. For each message and section, identify: | |
| - The user's explicit requests and stated intents |
| --- | |
| description: How to use Cursor rules effectively - READ THIS FIRST for any project work | |
| globs: | |
| alwaysApply: true | |
| --- | |
| # Understanding Rules | |
| Rules are your project-specific knowledge base. They guide your decision-making with context that doesn't exist in code alone. **ALWAYS CHECK FOR RELEVANT RULES** when making decisions. |
| Your task is to create a detailed summary of the conversation so far, paying close attention to the user's explicit requests and your previous actions. | |
| This summary should be thorough in capturing technical details, code patterns, and architectural decisions that would be essential for continuing development work without losing context. | |
| Before providing your final summary, wrap your analysis in <analysis> tags to organize your thoughts and ensure you've covered all necessary points. In your analysis process: | |
| 1. Chronologically analyze each message and section of the conversation. For each section thoroughly identify: | |
| - The user's explicit requests and intents | |
| - Your approach to addressing the user's requests | |
| - Key decisions, technical concepts and code patterns | |
| - Specific details like file names, full code snippets, function signatures, file edits, etc |
I hereby claim:
To claim this, I am signing this object:
| <?php | |
| /***** | |
| * WordPress Bootstrap Example | |
| *****/ | |
| // prevent remote execution | |
| if ($_SERVER['SERVER_ADDR'] != $_SERVER['REMOTE_ADDR']) exit(); | |
| /** Load WordPress Bootstrap, relative to the script directory */ | |
| require_once( dirname( __FILE__ ) . '/../wp-load.php' ); |
| #! /bin/sh | |
| # DESCRIPTION Setup wildcard domains using dnsmasq so *.doc is automatically sent to a running boot2docker vm | |
| # MAINTAINER [email protected] | |
| # See: | |
| # https://echo.co/blog/never-touch-your-local-etchosts-file-os-x-again | |
| # https://gist.github.com/r10r/5108046 | |
| # http://passingcuriosity.com/2013/dnsmasq-dev-osx/ | |
| # check for homebrew | |
| if ! command -v brew >/dev/null; then |
| # Compiled source # | |
| ################### | |
| *.com | |
| *.class | |
| *.dll | |
| *.exe | |
| *.o | |
| *.so | |
| # Packages # |
| #!/bin/sh | |
| # Shell script to install your public key on a remote machine | |
| # Takes the remote machine name as an argument. | |
| # Obviously, the remote machine must accept password authentication, | |
| # or one of the other keys in your ssh-agent, for this to work. | |
| ID_FILE="${HOME}/.ssh/id_rsa.pub" | |
| if [ "-i" = "$1" ]; then |
| [color] | |
| diff = auto | |
| status = auto | |
| branch = auto | |
| interactive = auto | |
| ui = true | |
| pager = true | |
| [color "branch"] | |
| current = yellow reverse |