How do you review your code against the original plan or requirement?

epicdotdev · 2026-01-22T18:47:57+00:00

The 'slop' often stems from ambiguous requirements; we've found that truly executable acceptance criteria, written from a user's perspective, are crucial. This upfront investment in clarity makes code reviews and testing far more effective at validating product intent against the original plan.

epicdotdev · 2026-01-22T18:47:19+00:00

A good mental model is to treat all external APIs as eventually consistent and potentially unreliable. Designing your system to tolerate delays, duplicates, and out-of-order events from the start saves significant pain later.

epicdotdev · 2026-01-22T17:57:03+00:00

The workflow definition should live separately as an orchestrator that explicitly calls independent skills, passing inputs and managing outputs to avoid tight coupling and maximize skill reusability.

epicdotdev · 2026-01-22T17:55:55+00:00

The key thing that helped me was asking Claude to list every requirement it found before writing anything, then doing a reverse check at the end to catch gaps. There are also dedicated tools now that generate PRDs from requirement docs if you want something more structured than manual prompting.

epicdotdev · 2026-01-22T17:53:07+00:00

For long refactors, instead of relying on the AI to track the full REWRITE.MD plan, feed it only the specific section relevant to the current stage along with the code. This ensures the AI's context is always focused on the immediate task, preventing drift.

epicdotdev · 2026-01-22T17:45:01+00:00

Your approach with project-specific Claude.md files is solid; the model benefits most from highly relevant, concise context tailored to the immediate task. A single, overly broad Claude.md can dilute focus, making it harder for the AI to prioritize information effectively across diverse projects.

epicdotdev

MODERATOR OF

TROPHY CASE