

Also from Kynth Studios


Also from Kynth Studios


Also from Kynth Studios
1# Project Structure23This section provides an overview of the folder structure used in this project, designed to be modular, scalable, and easy to maintain.45We follow a feature-based and App Router-oriented architecture using Next.js 15. Each directory serves a clear purpose: separating concerns like UI, business logic, API routes, static content, and reusable types.67## features/89This directory organizes the app into logical features such as todo, sign, top, and admin. Each feature has subfolders for UI components, templates, and logic (e.g., hooks, contexts, DnD logic). This makes each feature self-contained and easy to scale.1011## tests/1213This directory contains a comprehensive testing environment using Vitest and modern testing frameworks. The test suite achieves 100% pass rate with high code coverage and follows feature-based organization that mirrors the main application structure. It includes unit tests with MSW (Mock Service Worker) for API mocking, integration tests using Docker and Firebase Emulator environment, and end-to-end tests with Playwright for complete user workflow validation.1415## app/1617This is where the actual routing and rendering logic resides, structured by Next.js App Router conventions. Grouped routes like (auth) or (admin) allow cleaner separation between different parts of the application without polluting the URL.1819## api/2021All server functions (APIs) live here, further divided into general, admin, and auth routes. This separation ensures better access control and clearer codebase navigation.2223## types/, data/, public/2425These directories store cross-cutting concerns such as reusable types, static data (e.g., form definitions or validation rules), and assets like images or CSS. They help in maintaining clarity across the project by centralizing shared resources.2627## todoApp-submodule/2829The todoApp-submodule is a support module designed to centralize mock API management and documentation, improving development efficiency and team collaboration. It is primarily composed of the following two directories:3031### mocks/3233This directory centralizes mock API definitions using MSW (Mock Service Worker). It includes environment-specific setup files like browser.ts and server.ts, mock data such as todos.ts and user.ts, and API handlers like auth.ts and lists.ts. This structure enables frontend development to proceed independently, even when the backend is not yet implemented.3435### docs/3637This directory organizes the project's specifications and technical documents in a structured manner. Documentation is categorized by API, mock, and feature scope, including files such as MOCK.md and api/auth.md. Closely integrated with todoApp-submodule, it serves as a centralized knowledge base that supports design consistency and effective team communication.3839```40todoApp-next/41├── app/ # App Router-based route definitions for Next.js42│ ├── (admin)/ # Grouped routes related to admin43│ │ └── admin/ # Admin page44│ │ └── page.tsx45│ ├── (auth)/ # Grouped routes related to authentication46│ │ ├── _signIn/ # Logic for signing in47│ │ │ └── signIn.ts48│ │ ├── _signOut/ # Logic for signing out49│ │ │ └── signOut.ts50│ │ ├── _signUp/ # Logic for signing up51│ │ │ └── signUp.ts52│ │ ├── account/ # Account-related pages53│ │ │ └── error/ # Account error page54│ │ │ └── page.tsx55│ │ ├── signin/ # Sign-in page56│ │ │ └── page.tsx57│ │ └── signup/ # Sign-up page58│ │ └── page.tsx59│ ├── (dashboards)/ # Grouped routes for dashboards60│ │ ├── loading.tsx # Loading screen for dashboard61│ │ └── todo/ # Task management page62│ │ └── page.tsx63│ ├── api/ # API routes64│ │ ├── (admin)/ # Admin API65│ │ │ └── users/ # Admin user API66│ │ │ ├── [userId]/ # API for specific user67│ │ │ │ ├── lists/ # List management API for a user68│ │ │ │ │ └── route.ts69│ │ │ │ └── todos/ # Todo management API for a user70│ │ │ │ └── route.ts71│ │ │ └── route.ts72│ │ ├── (general)/ # General user API73│ │ │ ├── dashboards/ # Content information API74│ │ │ │ └── route.ts75│ │ │ ├── lists/ # List management API76│ │ │ │ └── route.ts77│ │ │ ├── todos/ # Todo management API78│ │ │ │ └── route.ts79│ │ │ └── user/ # User info API80│ │ │ └── route.ts81│ │ ├── auth/ # Authentication-related APIs82│ │ │ ├── [...nextauth]/ # NextAuth.js API handler83│ │ │ ├── refresh/ # Token refresh API84│ │ │ │ └── route.ts85│ │ │ └── server-login/ # Server-side login API86│ │ │ └── route.ts87│ ├── libs/ # Shared libraries88│ ├── providers/ # React providers89│ │ ├── MSWProvider.tsx # Mock Service Worker provider90│ │ └── SessionProvider.tsx # Session management provider91│ ├── static/ # Static CSS files92│ │ ├── input.css93│ │ └── output.css94│ └── utils/ # Utility functions95├── features/ # Feature-specific components and logic96│ ├── admin/ # Admin-related features97│ │ ├── components/ # Admin UI components98│ │ └── templates/ # Admin UI templates99│ ├── libs/ # Shared libraries100│ ├── shared/ # Shared features across the app101│ │ ├── components/ # Common UI components102│ │ │ └── elements/ # Generic UI elements103│ │ └── templates/ # Shared templates104│ ├── sign/ # Sign-in/Sign-up features105│ │ ├── components/ # Auth-related UI components106│ │ │ └── elements/ # Auth-specific UI elements107│ │ └── templates/ # Auth templates108│ ├── todo/ # Todo feature109│ │ ├── components/ # UI components for todos110│ │ │ └── elements/ # UI elements for todos111│ │ ├── contexts/ # Context for todo state112│ │ ├── dnd/ # Drag-and-drop logic113│ │ ├── hooks/ # Custom hooks for todo114│ │ └── templates/ # Todo page templates115│ ├── top/ # Top page feature116│ │ ├── components/ # Top page UI components117│ │ └── templates/ # Top page templates118│ └── utils/ # Shared utilities across features119├── data/ # Static data and link definitions120│ ├── form.ts # Form definitions121│ ├── validatedData.ts # Validated data122│ └── links/ # External link definitions123├── public/ # Static assets such as images124├── scripts/ # Project utility scripts125│ ├── init-firebase-data.ts # Firebase Emulator data initialization (tsx execution)126│ ├── cleanup-db.ts # Test database cleanup127│ └── helpers/ # Helper functions for scripts128│ └── testDbDataFetcher.ts # Test data fetching utilities129├── tests/ # Comprehensive testing suite130│ ├── setup.ts # Global unit test environment setup131│ ├── setup-integration.ts # Integration test environment setup132│ ├── test-utils.tsx # Custom render functions and test utilities133│ ├── features/ # Feature-based test structure134│ │ ├── utils/ # Utility function tests (4 files)135│ │ ├── shared/ # Shared component tests136│ │ │ └── components/ # Navigation and common component tests137│ │ ├── todo/ # Todo feature comprehensive testing138│ │ │ ├── api.integration.test.ts # Todo API integration tests139│ │ │ ├── contexts/ # TodoContext tests140│ │ │ ├── components/ # Todo component tests (13 files)141│ │ │ │ ├── elements/ # UI element tests (Status, TodoList, Add, Modal, Error)142│ │ │ │ ├── PushContainer/ # Container component tests143│ │ │ │ └── MainContainer/ # Main container tests144│ │ │ ├── hooks/ # Todo custom hooks tests (4 files)145│ │ │ └── templates/ # TodoWrapper template tests146│ │ └── libs/ # Common library tests147│ ├── e2e/ # End-to-end testing with Playwright148│ │ ├── global-setup.ts # E2E test global setup149│ │ ├── global-teardown.ts # E2E test global cleanup150│ │ └── todo-flow.spec.ts # Comprehensive todo workflow E2E tests151│ └── fixtures/ # Test fixtures for Firebase Emulator152│ ├── auth_export/ # Authentication data export153│ └── firestore_export/ # Firestore data export154├── todoApp-submodule/155│ ├── mocks/ # Form definitions156│ │ ├── browser.ts # MSW browser configuration157│ │ ├── server.ts # MSW Node.js configuration158│ │ ├── initMocks.ts # Mock initialization159│ │ ├── data/ # Mock data definitions160│ │ │ ├── index.ts # Data exports161│ │ │ ├── lists.ts # List mock data162│ │ │ ├── todos.ts # Todo mock data163│ │ │ └── user.ts # User mock data164│ │ └── handlers/ # API handler definitions165│ │ ├── index.ts # Handler exports166│ │ ├── auth.ts # Authentication API handlers167│ │ ├── dashboard.ts # Dashboard API handlers168│ │ ├── lists.ts # List API handlers169│ │ └── todos.ts # Todo API handlers170│ └── docs/ # It contains project-wide documentation such as API specifications, feature overviews, and mock API details.171│172└── types/ # TypeScript type definitions173 ├── common.ts # Common types174 ├── components.ts # Component-related types175 ├── lists.ts # List-related types176 ├── next-auth.d.ts # Types for NextAuth.js177 ├── todos.ts # Todo-related types178 ├── auth/ # Auth-specific types179 ├── form/ # Form-specific types180 └── markdown/ # Markdown-related types181```182
One repository carrying more than one format is the comparison this product exists for: does anyone actually write different content in each file, or is one a copy of the other?
| Repository | Format | Stack | Covers | Score | Changed |
|---|---|---|---|---|---|
| sakatai11/todoApp-next.clinerules/introduction.md · 0 | Cline rules | no sections | 16/100 | 13 days ago | |
| sakatai11/todoApp-next.claude/CLAUDE.md · 0 | CLAUDE.md | buildtestlint-formattesting-strategy+1 | 82/100 | 13 days ago | |
| sakatai11/todoApp-next.clinerules/best-practices.md · 0 | Cline rules | style | 8/100 | 13 days ago | |
| sakatai11/todoApp-next.clinerules/coding-guidelines.md · 0 | Cline rules | test | 29/100 | 13 days ago | |
| sakatai11/todoApp-next.clinerules/development-guidelines.md · 0 | Cline rules | testlint-formattesting-strategysecurity+3 | 59/100 | 13 days ago | |
| sakatai11/todoApp-next.clinerules/security-guidelines.md · 0 | Cline rules | security | 4/100 | 13 days ago | |
| sakatai11/todoApp-next.clinerules/tech-stack.md · 0 | Cline rules | testlint-formattesting-strategy | 33/100 | 13 days ago | |
| sakatai11/todoApp-nextAGENTS.md · 0 | AGENTS.md | buildtestlint-formattesting-strategy+1 | 82/100 | 13 days ago |
Same format, overlapping stack, ranked by quality.
| Repository | Format | Stack | Covers | Score | Changed |
|---|---|---|---|---|---|
| bashdeban/fastmind.clinerules/.project-consistency-keeper2.md · 5 | Cline rules | setupbuildtestlint-format+11 | 100/100 | 14 days ago | |
| JCodesMore/ai-website-cloner-template.clinerules · 32k | Cline rules | buildlint-formatstylearch+3 | 97/100 | 7 days ago | |
| BryaanF/LiantPortfolio.clinerules/project-guidelines.md · 0 | Cline rules | buildstylearchgit+2 | 96/100 | 14 days ago | |
| u9401066/zotero-keepervscode-extension/resources/repo-assets/pubmed-search-mcp/.clinerules/50-pubmed-project.md · 6 | Cline rules | testlint-formatstylearch+1 | 94/100 | 14 days ago | |
| u9401066/zotero-keeper.clinerules/50-pubmed-project.md · 6 | Cline rules | testlint-formatstylearch+1 | 94/100 | 14 days ago | |
| VaillerTeeter/HoshimiNest.clinerules/project-identity.md · 1 | Cline rules | setuparchtypesdo-not | 93/100 | 12 days ago | |
| blendsdk/codeops-mcp.clinerules/project.md · 0 | Cline rules | buildteststylearch+7 | 91/100 | 14 days ago | |
| tsongglod123/excel-formula-visualizer.clinerules/development.md · 0 | Cline rules | setupbuildtestarch+2 | 86/100 | today |
A badge carrying the measured quality of the strongest agent config file in this repository, out of 100. It reads from this index every time somebody loads your page, so it changes when the measurement changes and there is nothing to keep up to date. Free, no account, and the value is not something you or we can set by hand.
[](https://rulestack.kynth.studio/configs/sakatai11-todoapp-next-clinerules-project-structure)Would rather not hotlink us? Every badge is also served in shields.io’s endpoint schema, so shields renders the image and your readers never talk to our domain:
Published by Toolproof, the masthead over this index and eight others. The method behind the number is at toolproof.kynth.studio/methodology, and the whole thing is readable as JSON with no key at /api.