Brian Danos

AI / UI / Product Development

[Brian Danos @brian_danos]

# Coding Workflow

This is the standard workflow for developing features. Follow these steps in order. Do not skip steps.

## 0. Confirm access

Before doing anything else, confirm you have access to all the repos, env vars, services, and credentials this feature touches. If anything is missing, stop and tell me now. Do not start work and discover blockers halfway through.

## 1. Clarify requirements

Tell me who the users are, what specific problem this solves, and what the smallest version looks like that actually solves it. Call out every ambiguity you would otherwise have to guess on. Push back on anything that smells like scope creep. We ship focused solutions, not feature-rich ones.

## 2. Load context

Re-read the feature description, then read CLAUDE.md and our design, coding standards, and security docs. Surface any remaining implementation questions (approach, edge cases, how this fits existing patterns) before you plan.

## 3. Write a TDD plan and get approval

Step one of the plan must be writing failing tests that capture the acceptance criteria. Then implementation, then verification. Keep it tight. Walk me through it and wait for my approval before touching code.

## 4. Open a new PR

Create a branch and open a draft PR with a clear title and description that links the feature. All work happens on this branch.

## 5. Write tests first and confirm they fail

Run them and verify they fail for the right reason (assertion failures, not import errors or typos). Show me the failures before moving on.

## 6. Implement against the plan

Follow our coding standards, security checklist, and design system. Reference CLAUDE.md whenever you're unsure. Do not introduce new dependencies, patterns, or abstractions without flagging them first.

## 7. Run the tests until green

If anything fails, debug and iterate. Do not move on with red tests, and do not disable, skip, or weaken tests to force them green.

## 8. Run the full test suite

Run every test in the project, not just the new ones, and confirm nothing else broke. If you broke something elsewhere, fix it before moving on.

## 9. Manually verify in a browser

Open the app, exercise the happy path plus obvious edge cases (empty states, invalid input, permissions). Note exactly what you verified.

## 10. Do not stop between steps

Work straight through this checklist. The only valid reasons to pause are:

1. A genuine ambiguity in requirements
2. A test failure you cannot diagnose
3. Missing access or credentials

Otherwise keep going.

## 11. Hand off for review

Summarize what you built, what you tested, what's still untested, and anything I should manually verify. Give me the PR link.

## 12. Merge and ship after I confirm

[Brian Danos @brian_danos]

Stop prompting Claude Code step by step. Write your workflow once, commit it as CODING-WORKFLOW.md and let Claude follow it every session. Mine: clarify → TDD plan → draft PR → failing tests → implement → green → full suite → browser check → hand off.

Copy prompt below 👇

[Brian Danos @brian_danos]

Skeptical CTO Code Review

Act as a skeptical, experienced CTO conducting an honest technical audit of my project. Surface real risks, not aesthetic preferences or "I would have built it differently" noise. Help me separate legitimate concerns from stylistic disagreements.

Focus on security vulnerabilities (auth, data exposure, injection, PII), data integrity (schema, referential integrity, race conditions), scaling risks (patterns that break under load, N+1 queries, missing indexes), maintainability (coupling, hidden complexity, fragile patterns), and missing fundamentals (logging, monitoring, backups, audit trails, rate limiting). Filter out framework preferences, premature abstractions, pattern purity arguments disconnected from user impact, and recommendations to support every hypothetical future configuration. My philosophy prioritizes user experience and shipping over ultra-flexible architecture, so if a finding amounts to "you should support every possible scenario," push back on yourself before including it.

Start with a plan: what you'll review, in what order, and what you need from me to do it well. Then for each finding, give me the issue in plain language, a severity rating (Critical/High/Medium/Low), the concrete production failure mode, whether it's evidence-based or opinion, a minimum viable fix (not a rewrite), and rough effort. Rank findings by risk-adjusted priority, and explicitly flag any concerns from my advisor that you think are not actually problems and why. Be direct, don't soften critical issues, and say "no issue found" when something is fine. Distinguish "this will definitely cause problems" from "this could theoretically cause problems." One concrete failure mode beats ten abstract principles. If you don't have enough information, ask before assessing.

[Brian Danos @brian_danos]

I'm not a dev, but I'm shipping a SaaS app. An advisor told me my code was "built poorly" but couldn't give me real examples.

So I built a Claude Code prompt that acts as a skeptical CTO and tells me what's actually broken vs what's just taste.

Copy full prompt below 👇

[Brian Danos @brian_danos]

@everestchris6 POOL

[Brian Danos @brian_danos]

@everestchris6 Roof

[Brian Danos @brian_danos]

@recap_david Renovate

[Brian Danos @brian_danos]

@levie @DavidSacks The real problem is that we historically hired developers for meticulousness, technical depth, and attention to detail, while AI has changed the role to emphasize creativity, judgment, and taste. These strengths do not usually coexist.

[Brian Danos @brian_danos]

@PCreighton1 @Google Yes

[Brian Danos @brian_danos]

@everestchris6 Open claw

[Brian Danos @brian_danos]

@basit_designs Killer design!

[Brian Danos @brian_danos]

@guidorosso @rive_app @HelloJcToon @jeffamcavoy Beautiful interaction!

[Brian Danos @brian_danos]

Get the code here:
https://t.co/WlXXzFVamQ

[Brian Danos @brian_danos]

Steal It!

https://t.co/umoMHfVuQ9

[Brian Danos @brian_danos]

@PrajwalTomar_ Plan

[Ryo Lu @ryolu_]

on future of AI interfaces:

future interfaces flow like water — meeting people how they actually think, not how we assume they should

some of us think in bullet points, some in conversations, others need to see everything mapped out visually. the magic happens when the interface adapts to match your specific cognitive style instead of forcing everyone through the same chat box

imagine AI that knows you process complex info better as a timeline, or that you prefer quick back-and-forth over long explanations. it shifts between chat, canvas, tables, whatever actually works for how you think, but acting on the same ground truth

we're moving from “here's one single-purposefully built interface, deal with it” to interfaces that genuinely fit how minds and teams operate. not just understanding what you want, but how you want to receive and work with it

the breakthrough isn't more features — it's interfaces that feel invisible because they match your natural thought patterns perfectly — the ideal form of “it just works.” it grows from something simple and universal, into forms that capture the beautiful complexities of individual minds

rigid UIs assume everyone thinks the same way. adaptive interfaces recognize that great tools should bend to the user, not the other way around

[Brian Danos @brian_danos]

@PrajwalTomar_ Cursor

[Brian Danos @brian_danos]

AI is making software creation so easy that we’re about to see an explosion of super-niche, single-purpose apps. Disposable, one-use UIs to solve specific problems.

[Brian Danos @brian_danos]

@PrajwalTomar_ I start with o3 for requirements. Then used Claude Code and Opus 4 in Cursor, with Supabase for database and automation.

Opus 4 is a big step up. It breaks down complex tasks into to-do lists, which makes it much easier for me to understand what’s actually being developed.

[Brian Danos @brian_danos]

Claude Code + Opus 4 + Cursor + Supabase + Vercel =

MAGIC!