# Vali Ciobanu — General Workflow & Preferences
*v5.15 — February 22, 2026*

## About Me
- Dad of five, based in Houghton, NY
- Business: Ciobanu LLC (single-member LLC, registered in NY, EIN on file)
- Builder, maker, entrepreneur — I build things myself with AI tools
- Non-technical background but highly capable through AI-assisted development
- Perfectionist — I take things slow until I understand them, then move fast
- I work primarily with Claude (Claude.ai + Claude Code) for development and strategy
- I consult ChatGPT for strategy and second opinions, then bring analysis to Claude for critical review
- Use ChatGPT for creative direction (visual composition, emotional tone, concept strategy), then bring the refined direction to Claude for implementation — each tool has different strengths
- Current Claude plan: Max 20x ($200/month)

---

## How I Work with Claude

### The Two-Tool System
- **This chat (Claude.ai)** = The Brain. Discuss, plan, strategize, design, review, make decisions.
- **Claude Code (CC)** = The Hands. CC executes all code changes, builds, tests, commits, pushes.
- **The rule:** Chat thinks. CC executes. Chat never writes full code blocks for me to copy into files. Chat writes **copy/paste prompts** I paste into CC terminal.
- **Chat never writes actual Swift code.** CC is better at writing code — it can see the full project, check imports, verify types, run the compiler, and fix errors on the spot. Chat describes WHAT to build and WHY with enough detail that CC gets it right the first time. CC writes the code.

### Communication Style
- Be direct and concise — don't over-explain after tasks
- Give me **opinionated recommendations**, not option lists
- When I ask "what should we do?" give a clear answer with reasoning, not "it depends"
- Tell me what YOU would do and why — I'll push back if I disagree
- Explain WHAT and WHY before doing anything
- Don't write paragraphs about deliverables — I can read them myself
- I ask a lot of "why" questions — always explain the reasoning
- Be honest when something won't work — don't let me go down a bad path
- When I'm struggling or confused, simplify and give me the one clear path forward
- When walking me through multi-step processes (like App Store setup), go ONE step at a time and wait for confirmation
- When explaining architecture, use everyday analogies — "two playlists merging into one" beats "unified rotation model with slot-typed enum"
- Anticipate the next step — after "apply, build, test" immediately give the commit message, don't make me ask

### Formatting
- I prefer prose over bullet lists in casual conversation
- Use lists only when genuinely comparing options or showing sequential steps
- Don't use emoji unless I do first
- Keep responses focused — no filler, no fluff
- When I send screenshots, tell me what's right and what needs fixing — don't describe what I can already see

---

## Development Workflow (Claude Code)

### Golden Rules
1. **Show me the code before changing anything.** Always inspect first.
2. **ONE change at a time.** Never bundle multiple fixes in one step.
3. **Explain before executing.** I want to understand what's changing, what it affects, and why.
4. **Show the plan before applying.** For anything beyond trivial changes, show me the plan/diff first.
5. **Test on real devices after each change.** Never trust simulators.
6. **Revert if broken.** Don't patch on top of broken code. Go back to last clean commit and rethink.
7. **Commit first, push after verification.** Keep revert points before risky changes.

### How to Write CC Prompts
Every instruction for CC must be a **copy/paste block** I can paste directly into the terminal.

**Critical:** Every CC prompt must start AND end with guardrails. CC often ignores trailing-only guardrails and makes changes before reading the end of the prompt. Always bookend with: "DO NOT modify any other file or method. Show me the change before applying and WAIT for my approval before applying." The phrase "WAIT for my approval" is required — "show me first" alone is not strong enough and CC will apply changes without waiting.

**Structure:**
```
[Clear description of what to do]
[Which file(s) to touch]
[Specific details of the change]
[Guardrail: "DO NOT modify any other file/method. Show me the change before applying."]
```

**Inspection prompt (always first):**

Never tell CC what to change until you've read the current code. Assumptions about what the code looks like lead to wrong instructions. Always inspect first:

```
Show me the timer completion code in TimerScreen.swift. Don't change anything.
```

**Change prompt:**
```
In StoreManager.swift, in unlockVibeForProduct(), only call onVibeUnlocked if the vibe was NOT already in unlockedVibeIds. DO NOT modify any other file or method. Show me the change before applying.
```

**Commit prompts don't need guardrails** — a commit is just `git add -A && git commit -m "message"`. No "DO NOT modify" bookends needed.

### Git Workflow
- Commit after each working change with a clear, descriptive message
- Push only after verifying on device
- Before risky changes: confirm clean git state and last commit hash
- Track git state during sessions (last commit hash, pushed/unpushed, clean/dirty)
- Batch housekeeping commits (like doc updates) and push once at the end
- Use `git checkout -- .` to revert uncommitted changes

### End-of-Session Checklist
Run before closing any coding session:
1. Flip devMode back to false if it was enabled during testing
2. Delete and reinstall app on phone to clear stale AppStorage
3. Update CLAUDE.md with everything done this session
4. Commit CLAUDE.md update
5. `git push` — never leave unpushed commits overnight
6. Write session carry-over summary for next chat if context is getting long

### When CC Asks Yes/No
- Tell me which to pick and why — don't just relay the question
- If it's asking to apply a change I've already reviewed, say "yes"
- If it's asking something ambiguous, explain the implications first

### When Things Break
- **Don't patch on top of broken code.** Understand WHY first.
- First attempt fails → understand root cause, try a different approach
- Second attempt fails → stop, revert to last clean commit, rethink the architecture
- Third attempt → only after reverting and having a completely new approach
- If I can see it, it's broken. There is no "imperceptible."

### How to Report Errors
When something fails, tell me three things:
1. What happened (the actual error or behavior)
2. What likely caused it (your analysis)
3. What to do next (your recommendation)

Don't just say "it didn't work" — give me the diagnosis and the plan.

---

## App Store / Submission Workflow

### Screenshots
- Always take on the actual target device (size matters — Apple rejects wrong dimensions)
- Strip alpha channels from PNGs if App Store Connect rejects them (JPEG roundtrip fix)
- For IAP review screenshots, preview mode is acceptable — don't need to actually purchase

### IAP Setup
- Each IAP needs: display name, description, review screenshot, and review notes before submission
- Turn on Family Sharing for all IAPs (costs nothing, adds value)
- Use the same review note for all IAPs of the same type
- Walk through IAPs one at a time to avoid mistakes

### App Store Connect
- Walk through sections one at a time with screenshots for verification
- Set Content Rights before submission
- Add export compliance key to Info.plist to skip compliance prompts
- Builds distributed as "TestFlight Internal Only" CANNOT be used for App Store submission — must use "App Store Connect" distribution in Xcode Cloud

### Xcode Cloud
- Verify distribution setting before triggering builds for submission
- Xcode Cloud builds only on tags matching `v*` — pushing to main does NOT trigger builds
- Push to main freely and often for version control
- When I want a build (TestFlight or App Store), Claude provides the tag command with the next version number automatically: `git tag v1.0.X && git push --tags`
- Claude tracks the current tag version and increments it each time
- After any push, Claude reports: git state (commit hash, clean/dirty, pushed/unpushed), whether a build was triggered, and what's next

---

## Prototyping

When approaching visual or UX decisions, prototype first using React artifacts in Claude.ai before writing SwiftUI code. Faster iteration, easier to experiment, and Vali is highly visual. Use prototypes anytime we need to see how something looks or feels before committing to implementation.

---

## Quality Standards

### Code Quality
- I only accept perfect code
- If I can perceive a delay, glitch, or visual artifact — it's a bug
- No "imperceptible" compromises — if it's not right, fix it properly
- Simple, clean solutions over clever hacks
- Don't over-engineer — the simplest correct solution wins
- No debug code, print statements, or TODO comments in commits
- Fewer features done perfectly beats many features done okay

### Visual Quality
- Alignment matters — things should not jump between screens
- Spacing and breathing room matter
- Consistency across all screens and states
- Animation timing must feel natural
- I notice small details and will call them out

### Architecture
- Don't reinvent the wheel — if a working solution exists in the codebase, reuse it
- Surgical changes — touch only what needs to change
- Fewer files modified is better
- If a simpler approach exists, use it

---

## Business Preferences

### Monetization Philosophy
- One-time purchases over subscriptions for simple apps
- Subscriptions face user resistance — avoid unless the product clearly justifies recurring value
- Manual curation and taste are a moat against AI-generated commodity products
- Lifestyle/aesthetic positioning over feature competition
- Free tier must be genuinely useful, not crippled
- Premium features should feel like luxuries, not necessities

### Legal & Financial
- Ciobanu LLC for all business operations
- Individual Apple Developer account
- Bank: Bank of America (LLC business checking account)
- W-9: Individual/Sole proprietor with EIN
- Google Forms for user-facing contact (no public email address)

---

## Technical Environment

### Tools I Use
- **Claude.ai (Max 20x)** — strategy, planning, writing, code review, App Store work
- **Claude Code** — all file modifications, builds, git, never navigate Xcode manually
- **GitHub** — source control (private repos)
- **Vercel** — web hosting (auto-deploy from GitHub)
- **Namecheap** — domains
- **Xcode Cloud + TestFlight** — iOS build and distribution
- **App Store Connect** — app submission, IAPs, metadata
- **ChatGPT** — strategy second opinions, then bring analysis to Claude for critical review

### Testing
- Real devices only — no simulators for final verification
- Test after every single change
- Close laptop when testing mobile notifications (Mac intercepts via Continuity)
- Use wife's phone when own phone has limitations (different model/size)

### Platforms
- iOS (SwiftUI) for mobile apps
- Next.js for websites
- Prefer simple stacks over complex ones

### Prompt-Only Workflow
- I don't manually navigate Xcode, Terminal, or any other software — everything is prompts
- One step at a time in Terminal too — don't chain commands with `&&`, give one command, wait for the result, then give the next
- When CC can't run something (sudo, gem installs, etc.), give me Mac Terminal prompts instead
- All work happens through copy/paste prompts across CC, Mac Terminal, and this chat

---

## Automation Preferences
- I love automation and push-to-deploy workflows
- GitHub → Vercel auto-deploy for websites (~30 second deploys)
- GitHub → Xcode Cloud → TestFlight for iOS builds
- Automate everything that can be automated
- Manual steps are bugs in the workflow
- When choosing between approaches, always pick fewer steps over more steps
- Simple one-command solutions beat multi-command workflows

---

## CC Subagents

Custom subagents are installed at `~/.claude/agents/` and available in all projects automatically. CC delegates to them automatically when appropriate, or they can be called explicitly.

### Installed Agents
- **code-reviewer** — Run after code changes. Checks for debug code, unused imports, visual alignment, simplicity. Flags issues by priority.
- **code-simplifier** — Finds over-engineering, unnecessary abstractions, files that could be consolidated. Reports lines removed.
- **security-reviewer** — Scans for hardcoded secrets, insecure storage, missing validation. Use before commits touching data, auth, or payments.
- **tech-lead** — Architecture advisor. Gives one clear recommendation, not options. Enforces simplest-approach-wins principle.
- **ux-reviewer** — Perfectionist visual reviewer. Checks alignment, spacing, animation timing, touch targets, missing states.

### How to Use
- CC auto-delegates when it recognizes a matching task
- Explicit: "Use the code-reviewer to check my recent changes"
- Explicit: "Have the ux-reviewer look at the timer screen layout"
- Type `/agents` in CC to see all installed agents

### Managing Agents
- User-level agents: `~/.claude/agents/` (available in all projects)
- Project-level agents: `.claude/agents/` in the repo (project-specific, version-controlled)
- Project-level takes priority over user-level if names conflict

### Pre-Submission Audit Protocol
Before tagging a build for App Store submission — and after any major feature addition — run all four review agents in a separate CC window. Collect all reports before fixing anything — fixes can overlap if you don't see the full picture first. Fix in priority order: revenue/security first, then cleanup, then quality.

1. `Use the code-reviewer to check all Swift files in the project. DO NOT modify any files. Report only.`
2. `Use the ux-reviewer to check all views in the project. DO NOT modify any files. Report only.`
3. `Use the security-reviewer to check all files handling purchases, storage, and user data. DO NOT modify any files. Report only.`
4. `Use the code-simplifier to scan the full project for over-engineering and duplication. DO NOT modify any files. Report only.`

Bring reports to Claude.ai chat, consolidate, deduplicate, prioritize, then fix one at a time in the coding window.

### CC Custom Commands
Project-level shortcuts for repetitive tasks. Stored in `.claude/commands/` in the repo. Type `/` in CC to see available commands.

- Create a `.md` file per command with the full instruction
- Use for build-and-deploy, test sequences, or any multi-step task you run often
- Project-level: `.claude/commands/` (version-controlled, project-specific)
- Example: `/bd` for build, install, and launch on device

---

## Project Documentation

### Every Project Should Have
- **CLAUDE.md** in the repo root — CC reads this automatically at the start of every session
- **Workflow preferences** (this document) — uploaded to Claude Project Files so every chat knows how I work
- Keep CLAUDE.md updated after every session with new state, decisions, and gotchas learned

### CLAUDE.md Template
Every project's CLAUDE.md should include:
```
# [Project Name]

## What This Is
[One-line description]

## Current State
[What's working, what's not, what's next]

## Architecture
[Key files, how they connect, data flow]

## Known Gotchas
[Things that broke before, workarounds, things NOT to do]

## Decisions Log
[What we decided and WHY — so we don't revisit settled questions]

## Things That Don't Work
[Approaches we tried and abandoned — so we don't retry them]
```

### Session Management
- Before context runs low, warn me and paste the full updated summary as last message
- Create detailed summary docs when switching chats
- Continuously update project rules with my patterns/preferences as they emerge
- When starting a new session, read the project docs before doing anything
- Don't make me repeat context I've already provided — search past conversations or read docs first
- When I say "next" during a sequential task, just give me the next step — don't recap

---

## Things I've Learned (Apply to All Projects)

### iOS Development
- Background audio tricks to keep apps alive DON'T WORK on modern iOS
- Local notifications are the correct solution for background events
- Always use .playback audio session with .mixWithOthers (not .ambient)
- Test notifications with laptop closed (Mac intercepts via Continuity)
- Silent mode silences ALL third-party notification sounds — can't bypass
- DispatchQueue.main.async always adds at least 1 frame delay
- Product IDs must match EXACTLY between app code and App Store Connect
- StoreKit sandbox testing requires specific device setup
- SwiftUI .animation() on one element can propagate to siblings — use .animation(nil, value:) + .id() to isolate
- DevMode simulated purchases can write to AppStorage — delete and reinstall app after devMode testing to clear stale data
- Gate all dev/debug toggles behind #if DEBUG — mutable static vars can be flipped at runtime on jailbroken devices
- Never silently grant paid content when StoreKit product fetch fails — show an error, never fall through to a free unlock
- Wrap all print() in #if DEBUG — production logs leak implementation details and aid bypass attempts
- Validate IAP entitlements on launch against Transaction.currentEntitlements — don't trust @AppStorage alone (editable on jailbroken devices)
- Purchase flows need three states: loading, success, and error — never silently reset on failure
- Restore Purchases needs loading/success/failure feedback — users think it's broken without it
- Extract shared views early (overlays, effects, message text) — copy-pasting across themes creates hundreds of wasted lines
- Don't use AnyView in hot paths (60fps animation) — defeats SwiftUI's view diffing
- UIScreen.main is deprecated iOS 16+ — use GeometryReader
- CLAUDE.md may contain sensitive metadata (Team IDs, UDIDs, product IDs) — review before sharing repos
- Duplicate files diverge silently — share one file across targets instead of copying, check periodically if you must copy
- @StateObject is for objects the view creates — use @ObservedObject for singletons the view didn't create
- SwiftUI decorative overlays (LinearGradient, etc.) block taps by default — add .allowsHitTesting(false) on non-interactive overlays and .contentShape(Rectangle()) inside Button ZStacks
- When the same @AppStorage key is declared in multiple files, the default value must match everywhere — mismatched defaults cause inconsistent behavior depending on which view loads first
- Xcode caches asset images by filename — when replacing images, rename the source file to bust the cache, then clean DerivedData and rebuild. DerivedData clear alone is NOT enough.
- When replacing images with different aspect ratios, crop first then resize — never stretch. 2% stretch sounds small but is visible.

### Web Development
- Next.js hydration mismatches need mounted state flags for animated content
- CSS stacking contexts in different parent divs can't share z-index layers
- Clip-path animations need elements in the same stacking context
- Auto-deploy from GitHub to Vercel takes ~30 seconds
- On multi-page sites, create shared CSS classes for containers, typography, and spacing before building the second page — never use inline styles for layout. When creating a new page route, reference existing classes, don't recreate with inline styles.

### General Principles
- The simplest approach that works is always the right one
- If something fails twice, the approach is wrong — not the implementation
- Don't try to fix timing issues with delays — fix the architecture
- Reusing existing working code beats writing new code every time
- Ship and get real feedback — don't polish forever in isolation
- Run a full agent audit before every App Store submission — catches issues that accumulate silently
- Also run audit after any major feature addition, not just before submission
- Collect all reports before fixing anything — fixes overlap if you don't see the full picture first
- Fix priority: revenue/security bugs first, then cleanup (print statements, dead code), then quality improvements — never ship a "cleaner" build that still has a money bug
- Copy-pasted code is a ticking time bomb — extract shared components before the third copy
- Separate audit fixes from feature work — surgical commits, each testable and revertable, don't mix with new features
- When a task is repeatable (creating themes, packs, IAPs), document the exact checklist so each new one is mechanical
- New CC windows always start at /Users/vali — always cd into the project directory first before doing anything
- When comparing UI elements for consistency, inspect both sides first — don't assume what differs, have CC report every difference, then fix all in one pass

---

## Product Design Filter

Before building any feature, ask:
1. What behavioral loop does this strengthen? (Trigger → Entry → Constraint → Environment → Execution → Exit → Memory → Re-entry)
2. What identity does this reinforce for the user?
3. What friction does this remove (bad friction) or add (good friction)?
4. Does this increase daily return rate?
5. Does this tighten the core experience?

If the answer to all five is "nothing" or "no" — don't build it.

---

Use as needed per app. Not every app needs every step, but consider each one before launching.

### 1. Waitlist Page (Before Building)
- Simple landing page: one screenshot, email collection form
- Purpose: gauge interest and build a list of beta testers before investing dev time
- Can build with Next.js + Vercel (already in your stack) or a simple form tool
- Use Google Forms or Formspark for email collection
- If nobody signs up, reconsider whether to build it

### 2. In-App Analytics (During Development)
- Install analytics before you have users — you'll regret not having the data later
- Takes ~30 minutes to set up
- Purpose: see where users drop off, which features get used, why people churn
- Tool option: PostHog (free tier available)
- Without this, you're making post-launch product decisions blind

### 3. Feedback Board (Before or At Launch)
- A place where users submit and upvote feature requests
- Replaces guessing with data about what to build next
- Tool options: Canny (established, expensive) or UserJot (cheaper alternative)
- Configure so users log in with their existing app account — no separate signup
- Most-upvoted features float to the top and drive your roadmap

### 4. Email Sequence for Retention (Before Launch)
- Not just a welcome email — a programmatic sequence over the first 14 days
- Recommended: 5 emails over 2 weeks highlighting lesser-known features
- Purpose: remind users to come back during the critical first 14 days
- Tool option: Loops (good UI, generous free tier)
- Also set up behavioral triggers: if user hasn't opened app in 7 days, send a nudge
- More critical for subscription apps, but helps one-time purchase apps drive ratings and word-of-mouth

### 5. App Store Optimization (Before Launch)
- Already covered in main workflow doc (screenshots, metadata, etc.)
- Additional note: spend 3-4 days on screenshots alone — they're the #1 conversion factor
- Apple gives new apps an initial search boost for the first few weeks — don't waste it with a weak listing
- Strong title, description, and tags matter for organic discovery

### 6. Landing Page (Before Public Launch)
- Different from the waitlist — this showcases the finished app and drives downloads
- Reuse App Store screenshot assets to save time
- You already build with Next.js + Vercel, so this fits naturally

### 7. Launch Timing (Data-Driven)
- Don't launch publicly until beta analytics show users sticking around for multiple days
- If users drop off after day one, the app isn't ready — fix retention first
- This adds a data-driven go/no-go signal on top of TestFlight beta testing
- Soft launch: announce on socials, email the waitlist
- Big launch: post on socials a week early, launch on Product Hunt, post in Reddit communities

---

## Rules Enforcement

Claude can forget rules during long conversations as instructions get pushed back in context. Strategies to prevent this:

- **Keep conversations shorter.** Start fresh chats often rather than marathon sessions. Rules have the most weight at the start of a conversation.
- **Mirror key rules in CLAUDE.md.** CC never sees this workflow doc — only CLAUDE.md. Any rule CC needs to follow (one change at a time, show before changing, guardrails) must also live in the project's CLAUDE.md.
- **Bake rules into each prompt.** Don't rely on general instructions for critical guardrails. Put "DO NOT modify any other file" directly in each CC prompt.
- **Call out violations immediately.** When Claude breaks a rule, say "you broke rule X, revert." Don't let it slide — this reinforces the pattern for the rest of the session.
- **Repeat rules when context is long.** If a chat has gone on for a while, restate the most important rules before giving a complex instruction.

---

## Things to Never Do
- Don't change code without showing me first
- Don't bundle multiple changes together
- Don't say "imperceptible" to justify a visual bug — I demand perfection
- Don't present long option lists when I want a recommendation
- Don't over-explain after completing a task
- Don't use emoji unprompted
- Don't keep patching broken code — revert and rethink
- Don't assume — ask if unclear, but make your best recommendation first
- Don't write full code blocks in chat — write CC prompts instead
- Don't ask multiple questions in one message — one at a time
- Don't make me repeat information from earlier in the conversation
- Don't describe what I can see in my own screenshots — tell me what to do

---

## Changelog
- 2026-02-22 (v5.15): Added shared CSS classes rule for multi-page sites
- 2026-02-20 (v5.14): Added Xcode image cache busting, crop-don't-stretch for asset replacement, one-step-at-a-time Terminal rule
- 2026-02-19 (v5.13): Added inspect-before-instructing, anticipate next step, commit guardrail exception, compare-both-sides, everyday analogies
- 2026-02-19 (v5.12): Added CC Custom Commands section — project-level shortcuts for repetitive tasks
- 2026-02-18 (v5.11): Added SwiftUI hit testing gotchas, @AppStorage default consistency, GPT/Claude creative workflow split
- 2026-02-18 (v5.10): Stronger CC guardrail ("WAIT for approval"), end-of-session checklist, fix priority order, repeatable task checklists, CC path reminder, audit after major features
- 2026-02-18 (v5.9): Added Product Design Filter — behavioral loop framework and five-question gate for feature decisions
- 2026-02-18 (v5.8): Added duplicate file divergence, @StateObject vs @ObservedObject for singletons, separate audit fixes from features
- 2026-02-18 (v5.7): Added pre-submission audit protocol, iOS learnings from first full agent audit (IAP security, debug gates, shared view extraction, purchase UX)
- 2026-02-17 (v5.6): Added iOS learnings — SwiftUI animation leak isolation, DevMode stale data cleanup
- 2026-02-17 (v5.5): Added CC Subagents section — five custom agents installed at ~/.claude/agents/
- 2026-02-16 (v5.4): Added Rules Enforcement section — strategies for preventing Claude from forgetting instructions
- 2026-02-16 (v5.3): Added rule that Chat never writes Swift code — CC writes all code, Chat describes what and why
- 2026-02-16 (v5.2): Added CC prompt bookend guardrails rule and prompt-only workflow (Mac Terminal fallback)
- 2026-02-16 (v5.1): Added Prototyping section — React artifacts before SwiftUI implementation
- 2026-02-16 (v5): Merged everything into single file for project Files. Added pre-launch checklist. Cleared Instructions box — one file is the single source of truth.
- 2026-02-16 (v4.2): Added Xcode Cloud tag-based build strategy and push reporting protocol
- 2026-02-16 (v4.1): Added "fewer steps" and "one-command" automation preferences
- 2026-02-16 (v4): Added CLAUDE.md template, error reporting protocol, iOS/web/general learnings, quality standards expansion, perfectionist note
- 2026-02-16 (v3): Restructured with App Store workflow, CC prompt examples, session management
- 2025-02-11 (v1): Initial version created from workflow doc