Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →ledgerhq/ddd-structure-flow
Place and organize Ledger Wallet code in the DDD monorepo.
Passed 20 of 22 test cases with the skill, and 9 of 22 without it.
and 18 more in the full report
11 fixed9 passed either way2 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are creating a package containing shared ESLint and TypeScript linting configurations used only during build and dev testing across the monorepo. Where should this package be located, what should its npm package name be, and how should other packages consume it in package.json?
| Checked | Without skill | With skill |
|---|---|---|
| Places development tooling inside the support directory. | Missed | Passed |
| Names the support package using the @support/ prefix. | Missed | Passed |
| Requires consuming support packages via devDependencies in package.json. | Passed | Passed |
The instructions your model reads when the skill loads.
Use the lowest layer that can own the concern without depending on a higher layer.
Read the canonical architecture guide and the package creation checklist before creating a package.
Upstream source: Structure & Flow
| Concern | Location | Owns | Does not own |
|---|---|---|---|
| Platform entry point | apps/<app> | Screens, global routing, store composition, analytics, observability, app glue | Reusable feature internals |
| User-visible capability | features/flow/<feature> | Business-aware UI, user journeys, local state, flow routing | App-specific screen composition |
| Capability shared across flows | features/platform/<feature> | Hooks, selectors, NFR rules, React glue, and components shared by several flows or use cases | Single-flow internals and fully generic components |
| Business object | domain/entity/<entity> | Runtime schema, inferred type, defaults, mocks, selectors, slice | Network calls and feature state |
| Network/data access | domain/api/<name> | API contracts, calls, transformations, RTK Query, thunks | UI and app composition |
| Business-agnostic primitive or component | shared/<name> | Generic schemas, utilities, Redux primitives, and components without domain or feature knowledge | Domain or app knowledge |
| Development-only tooling | support/<name> | Shared test, TypeScript, lint, and format configuration | Runtime code |
Use these distinctions:
features/flow package; do not promote it to an entity.features/flow when it belongs to one flow or use case.features/platform when several flows or use cases need it, especially when it connects them to the domain.shared or the existing design-system package..web and .native variants beside each other inside the owning feature.Every unit is a private package with package.json, src/, explicit exports, and no cross-package relative imports.
features/flow/<feature>/src/
├── components/ # shared by several steps
├── hooks/
├── router/ # flow-local routing only
├── state/ # feature-scoped state
├── steps/<StepName>/
test cases passed, vs 9 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.