2-Way binding between code and user stories- Magic by Vibe coding CLIs
How our team Improved Flutter Project Productivity & Management with Two-Way Bound User Stories and CLI Automation
While building trackMyPetition™, an AI-powered petition tracking platform, our team explored a better way to handle the often-fragmented workflow between product management and development.
Instead of separating specs, code, and tests across tools and teams, we adopted a two-way binding pattern—where structured user stories live in the codebase, are version-controlled, and drive everything from UI to logic and automated test coverage.
The Pattern: User Stories as the Source of Truth
Each feature—be it passkey login, views—is defined via modular, structured user story files in a dedicated userstories/ directory. These stories aren't static documentation—they’re actively wired to code.
Whenever a user story is updated:
This ensures that implementation, testing, and documentation remain in lockstep, making the codebase self-describing and auditable.
Two-Way Binding in Action
Using a CLI-first workflow (with Vibe Coding CLI and Makefile-driven tooling):
It’s a workflow where product design and engineering speak the same language—through the repo.
Recommended by LinkedIn
Why This Worked
Tooling That Helped
Final Thoughts
This approach not only helped us build trackMyPetition™ faster and cleaner—it’s also a highly adaptable pattern for any small or scaling team using Flutter or any modern framework.
Whether you're building a startup MVP or maintaining a complex product, this user story–bound architecture enables continuous alignment between design, code, and QA—without relying on bulky external tools.
If you're curious to implement something similar in your project, happy to share more.
#CLAUDE.md
# trackMyPetition™
trackMyPetition™ is AI-powered USCIS petition tracking software by TMP Labs LLC.
## Logo
assets/trackMyPetition.svg
## Application Structure
The application structure is defined through detailed user stories organized in the following directories:
- **Landing Page**: See [userstories/landingPage/](userstories/landingPage/)
- [Product Features Display](userstories/landingPage/productFeaturesDisplay.md)
- [Passkey Authentication Access](userstories/landingPage/passkeyAuthenticationAccess.md)
- [Footer Information](userstories/landingPage/footerInformation.md)
## Technical Requirements
### Platform
- **Flutter Application**
- **Mobile Interface**: Limited to landing page, login
- **Tablet/Desktop**: Full petition creation and editing capabilities
### Development Standards
- **Comments**: Always place comments to the right of code (not above)
- **Theme**: Use colors from logo
- **Flutter widgets**- Create reusable widget at every opportunity
- **Common Components**: Use standardized reusable components across the application:
- `FeatureCard`: For displaying features with icon, title, and description (responsive design)
- Components should be defined in `widgets/` directory with camelCase naming
- All reusable components must support responsive design patterns
- **Naming Convention**: Use camelCase for variables, functions, and file names
- **Build System**: Create Makefile for common development commands
- **Configuration settings**- All configuration settings would be defined through environment variables. If environment variables are not defined, they would read from .env
- **Test cases** - Automatically create and update test cases for all user stories
- **User Story Implementation** - When user stories in userstories/ directory are updated, automatically update the corresponding code implementation to match the new requirements. This includes:
- Updating screen layouts and UI components
- Modifying navigation flows and routing
- Adjusting business logic and data models
- Ensuring responsive design requirements are met
- Maintaining consistency between user stories and implementation
- **Implementation Notes Tracking** - Automatically maintain implementation notes in user story files when code is updated:
- Add "## Implementation Notes" section to each user story file
- Record all code changes with timestamps and file paths
- Include brief description of what was implemented/changed
- Track component relationships and dependencies
- Document responsive design implementations
- Note any deviations from original user story requirements
- Format: `- **[YYYY-MM-DD]** Updated `path/to/file.dart`: Brief description of change`
- Keep implementation history for audit trail and maintenance
- Link code changes back to specific acceptance criteria when applicable
## Authentication
- **Petitioner Login**: Auth0 passkey implementation
- **Attorney Login**: Auth0 passkey implementation
#Flutter #DeveloperProductivity #DevTools #VibeCLI #CLIDrivenDevelopment #ProjectManagement #trackMyPetition #SoftwareEngineering #UserStories #Fullstack #MakefileMagic #TwoWayBinding
This is insightful Amit