|
| 1 | +--- |
| 2 | +name: Feature Development |
| 3 | +description: Strict guidelines and workflow for developing new features, ensuring quality, proper branching, UI/UX standards, and comprehensive testing in Upnext. |
| 4 | +--- |
| 5 | + |
| 6 | +# Feature Development Skill |
| 7 | + |
| 8 | +This skill outlines the strict workflow and quality standards that must be followed when developing new features in the Upnext project. |
| 9 | + |
| 10 | +## 🌿 1. Branching Strategy |
| 11 | +- **Always work on a fresh branch** created off the latest `main` branch. |
| 12 | +- **Naming convention**: Use `feature/<feature-name>` for new features (e.g., `feature/episode-details`). |
| 13 | +- Ensure you have the latest code before branching off to avoid conflicts. |
| 14 | + |
| 15 | +## 🎨 2. UI/UX & Design Standards |
| 16 | +- **Refer to the [Frontend Design Skill](../frontend_design/SKILL.md)** for UI/UX best practices. |
| 17 | +- Ensure all screens follow the established design flow and architecture. |
| 18 | +- Use the existing design system tokens, Material 3 components, and adaptive layouts. |
| 19 | +- Do not take shortcuts with UI implementation; visual excellence and smooth user experience are critical. |
| 20 | + |
| 21 | +## 🏗️ 3. Code Architecture & Quality |
| 22 | +- Maintain a **high-quality approach** to feature development. |
| 23 | +- Adhere to the established app architecture (Clean Architecture, MVVM, Unidirectional Data Flow). |
| 24 | +- Avoid hacks, technical debt, or shortcuts. Code must be production-ready and scalable. |
| 25 | +- Ensure proper separation of concerns (UI, Domain, Data layers). |
| 26 | + |
| 27 | +## 🧪 4. Testing & Regressions |
| 28 | +- **No regressions**: Ensure that new changes do not break existing Unit or Instrumented tests. |
| 29 | +- **High Test Coverage**: Add comprehensive tests for all new code. |
| 30 | + - Write Unit Tests (JUnit, Mockito, Turbine) for ViewModels, Repositories, and Domain logic. |
| 31 | + - Write/Update Instrumented Tests for UI components and Navigation flows where applicable. |
| 32 | +- Refer to the **[Android Testing Skill](../android_testing/SKILL.md)** for testing best practices. |
| 33 | + |
| 34 | +## 🔍 5. Code Analysis & Formatting |
| 35 | +- **Linting & Detekt**: You must run code analysis tools before finalizing the feature. |
| 36 | + - Run `./gradlew :app:ktlintFormat` to format styling. |
| 37 | + - Run `./gradlew :app:detekt` to ensure no static analysis rules are broken. |
| 38 | +- **Build Verification**: Run `./gradlew :app:assembleDebug` and `./gradlew :app:testDebugUnitTest` to ensure the project compiles and tests pass successfully locally. |
| 39 | +- Fix any formatting, linting, or analysis errors immediately. |
| 40 | + |
| 41 | +## 🚀 6. Commit & Push Protocol |
| 42 | +- **Only commit and push once all the above steps are completed and verified locally.** |
| 43 | +- Commit messages should be clear, descriptive, and follow conventional commit formats. |
| 44 | +- **CI Safety**: Ensure that your local verifications are thorough so that Continuous Integration (CI) is NOT the place where bugs, broken tests, or Detekt violations are discovered. All code must be validated locally before the push. |
0 commit comments