Add cover letters & improve writing guidelines
- Add Webflow Staff Software Engineer, Applied AI cover letter - Add Coinbase AI Growth Lead (Staff Software Engineer) cover letter - Add Virta Health Senior Site Reliability Engineer cover letter - Update CLAUDE.md: NEVER use em-dashes, prefer two sentences - Update CLAUDE.md: strengthen date checking requirements - Add senior.software.engineer resume softlink to Makefile - Remove em-dash from Virta cover letter closing 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
parent
01535b292d
commit
50cb9e7f36
4 changed files with 98 additions and 11 deletions
56
CLAUDE.md
56
CLAUDE.md
|
|
@ -1,5 +1,35 @@
|
|||
# Claude Memory and Instructions
|
||||
|
||||
## CRITICAL: ALWAYS CHECK FOR CLAUDE.MD FILES
|
||||
|
||||
**BEFORE working on ANY repository, ALWAYS check for CLAUDE.md files in this order:**
|
||||
|
||||
### Priority 1: Cross-Repository CLAUDE.md (Global)
|
||||
1. **Check for global CLAUDE.md**: Look for `/home/fox/CLAUDE.md` or `~/CLAUDE.md`
|
||||
2. **Read & follow global instructions**: These apply across ALL repositories on localhost
|
||||
3. **Global instructions are baseline**: These set the foundation for all work
|
||||
|
||||
### Priority 2: Repository-Specific CLAUDE.md (Local)
|
||||
1. **Check for repo CLAUDE.md**: Use `Read` to check if `./CLAUDE.md` exists in the repository root
|
||||
2. **Read & follow repo instructions**: If found, read the entire CLAUDE.md file & follow all instructions
|
||||
3. **Repo-specific overrides global**: Repository-specific CLAUDE.md instructions override or extend global guidelines
|
||||
4. **Check README too**: Also read README, README.md, or README.rst to understand the project
|
||||
|
||||
**Priority hierarchy:**
|
||||
- Repository-specific CLAUDE.md (highest priority)
|
||||
- Cross-repository CLAUDE.md (medium priority)
|
||||
- This file's instructions (baseline for this specific repo)
|
||||
|
||||
**Examples of what to look for:**
|
||||
- Build & test procedures
|
||||
- Commit message formats
|
||||
- Code style preferences
|
||||
- Special workflows or requirements
|
||||
- Project-specific constraints
|
||||
- Cross-repo conventions & standards
|
||||
|
||||
---
|
||||
|
||||
Read README.rst to understand the build system.
|
||||
|
||||
you are acting on behalf of russell ballestrini. don't fuck up.
|
||||
|
|
@ -90,17 +120,21 @@ Git operations can be destructive to uncommitted work. Always preserve user's wo
|
|||
- Example: "disrupt wheels & foster open collaboration" not "disrupt wheels and foster open collaboration"
|
||||
- This creates a more casual, punchy writing style that matches the brand voice
|
||||
|
||||
**Grammar: Don't overuse em-dashes (—) in place of commas**
|
||||
- Em-dashes are useful for emphasis or parenthetical thoughts, but overuse makes writing choppy
|
||||
- If a sentence has multiple "—" breaks, consider using commas or splitting into separate sentences
|
||||
- Example of overuse: "The opportunity to work—learning from experienced operators while contributing—combines technical challenge"
|
||||
- Better: "The opportunity to work with experienced operators while contributing combines technical challenge"
|
||||
- Use em-dashes sparingly for maximum impact
|
||||
**Grammar: NEVER use em-dashes (—)**
|
||||
- Do not use em-dashes in any writing (posts, cover letters, documentation)
|
||||
- Instead of em-dashes, prefer splitting into two separate sentences
|
||||
- Alternative: use commas or periods for sentence breaks
|
||||
- Example to avoid: "The opportunity to work—learning from experienced operators while contributing—combines technical challenge"
|
||||
- Correct approach: "The opportunity to work with experienced operators while contributing combines technical challenge." Or split into two sentences: "The opportunity to work combines technical challenge. Learning from experienced operators while contributing enhances the experience."
|
||||
- This creates clearer, more direct writing
|
||||
|
||||
## DATE HANDLING FOR NEW CONTENT
|
||||
|
||||
**ALWAYS check the current date before creating new posts or cover letters**
|
||||
- Check the <env> section for "Today's date" at the start of the conversation
|
||||
- The date may change during long conversations - use the actual current date
|
||||
- File names should match the date metadata (e.g., `2025-11-04-post-name.txt` with `:date: 2025-11-04`)
|
||||
- When creating new content, use the correct current date in both the filename and metadata
|
||||
**CRITICAL: ALWAYS check the current date BEFORE creating ANY new documents**
|
||||
- **MANDATORY**: Check the <env> section for "Today's date" at the start of EVERY conversation
|
||||
- **BEFORE creating**: Posts, cover letters, blog entries, or any dated content, verify the current date
|
||||
- The date may change during long conversations - ALWAYS use the actual current date from <env>
|
||||
- File names MUST match the date metadata (e.g., `2025-11-04-post-name.txt` with `:date: 2025-11-04`)
|
||||
- When creating new content, use the correct current date in BOTH the filename AND metadata
|
||||
- **NEVER assume** the date - always check <env> first
|
||||
- **NEVER use** old dates from previous examples or files
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue