Ground every plan and implementation in code that already exists. A plan that says "follows the same pattern as app/components/edit/DocumentEdit.svelte" beats one describing an abstraction in the abstract — the executor gets low cognitive load and a working reference. This is the method; the calling skill says what to build.
Steps
- Learn the layout that applies. App code is under
app/: .svelte screens/components/modals live in app/components/<feature>/ (feature dirs: camera, edit, list, ocr, pdf, pkpass, qrcode, security, settings, view, common, widgets); domain logic lives in service singletons under app/services/ (documents.ts, sync.ts, ocr.ts, security.ts, …); data models in app/models/; helpers in app/utils/, app/helpers/, app/transformers/; strings in app/i18n/; SCSS themes in app/themes/. Platform splits use .android.ts / .ios.ts.
- Find a similar existing implementation. Glob/Grep for a
.svelte component or a service that solves a comparable problem. Read 1-2 end-to-end so you can point at them by path.
- Identify reusable assets — existing components in
app/components/common/ and app/components/widgets/, svelte stores (app/utils/svelte/store.ts), service singletons, models, and utils/helpers. Reuse these by name rather than inventing new ones.
- Map the touch surface — every file, component, service, model, i18n key that needs to change. Trace data flow and callers (service singletons are shared, so a change ripples) so nothing is missed.
- Check third-party libraries — when a library is involved (
@nativescript-community/*, @akylas/*, svelte-native, sqlite/kiss-orm, …), use Context7 for version-matched docs before assuming an API.
Bias
Pick the simplest, cleanest solution: reuse existing patterns/components/hooks, fewest files touched, smallest new surface. If a clever approach and a boring approach reach the same outcome, choose the boring one.
1---2name: understand-project3description: Ground a feature or fix in existing code before planning or building — find a similar pattern, identify reusable assets, map the touch surface. Internal helper invoked by feat / fix (both modes) — not meant to be run on its own.4---56Ground every plan and implementation in code that already exists. A plan that says "follows the same pattern as `app/components/edit/DocumentEdit.svelte`" beats one describing an abstraction in the abstract — the executor gets low cognitive load and a working reference. This is the _method_; the calling skill says what to build.78## Steps9101. **Learn the layout that applies.** App code is under `app/`: `.svelte` screens/components/modals live in `app/components/<feature>/` (feature dirs: `camera`, `edit`, `list`, `ocr`, `pdf`, `pkpass`, `qrcode`, `security`, `settings`, `view`, `common`, `widgets`); domain logic lives in service singletons under `app/services/` (`documents.ts`, `sync.ts`, `ocr.ts`, `security.ts`, …); data models in `app/models/`; helpers in `app/utils/`, `app/helpers/`, `app/transformers/`; strings in `app/i18n/`; SCSS themes in `app/themes/`. Platform splits use `.android.ts` / `.ios.ts`.112. **Find a similar existing implementation.** Glob/Grep for a `.svelte` component or a service that solves a comparable problem. Read 1-2 end-to-end so you can point at them by path.123. **Identify reusable assets** — existing components in `app/components/common/` and `app/components/widgets/`, svelte stores (`app/utils/svelte/store.ts`), service singletons, models, and utils/helpers. Reuse these by name rather than inventing new ones.134. **Map the touch surface** — every file, component, service, model, i18n key that needs to change. Trace data flow and callers (service singletons are shared, so a change ripples) so nothing is missed.145. **Check third-party libraries** — when a library is involved (`@nativescript-community/*`, `@akylas/*`, svelte-native, sqlite/kiss-orm, …), use Context7 for version-matched docs before assuming an API.1516## Bias1718Pick the simplest, cleanest solution: reuse existing patterns/components/hooks, fewest files touched, smallest new surface. If a clever approach and a boring approach reach the same outcome, choose the boring one.
ossappscollective