agentleFS
4gray4gray/iptvnator/.agents/skills/iptvnator-nx-architecture/SKILL.md

iptvnator-nx-architecture

Skill7.6k starsChanged 6 days agoMITView on GitHub

Use when deciding where IPTVnator code belongs, creating or moving Nx projects, changing scoped aliases or tags, editing lint targets, or validating module boundaries.

  • Installs packages

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Every project keeps one scope:*, domain:*, and type:* tag.

    line 44
  2. Very specific:

    Use aliases from tsconfig.base.json and public src/index.ts barrels.

    line 61

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

IPTVnator Nx Architecture

Discover Before Deciding

In a fresh worktree, install first:

pnpm install --frozen-lockfile
pnpm nx show projects
pnpm nx show project <name>
pnpm nx show projects --withTarget test
pnpm nx show projects --withTarget e2e

Discovery is authoritative. The current app groups are web, electron-backend, web-backend, remote-control-web, website, web-e2e, electron-backend-e2e, stalker-mock-server, and xtream-mock-server. Current tool projects are eslint-tools, packaging, release-tools, and repository-skills.

Place Code by Ownership

  • apps/: runtime, development, E2E, and mock-server applications.
  • tools/: repository automation; tag its projects scope:tools.
  • libs/: domain libraries.
  • type:feature: route and screen orchestration.
  • type:ui: reusable visual components.
  • type:data-access: injectable state, API, persistence, or orchestration.
  • type:util: the destination for new pure helpers and contracts only.

Provider-neutral collection services that coordinate persistence belong in libs/portal/shared/data-access; pure collection helpers belong in libs/portal/shared/util; reusable views belong in libs/portal/shared/ui. Existing injectable/stateful services under a util path are legacy debt, not placement precedent.

Preserve Boundaries

Every project keeps one scope:*, domain:*, and type:* tag. Enforced type directions are:

SourceAllowed dependencies
app, E2E, dev-appfeature, UI, data-access, util
websiteUI, util
featurefeature, UI, data-access, util
UIUI, data-access, util
data-accessdata-access, util
utilutil

Domain constraints are additive. Never weaken either constraint to solve a placement problem. Preserve the documented workspace-shell-util path/tag exception: its injectable services require type:data-access so app routes can eagerly import them without loading the lazy shell feature.

Use aliases from tsconfig.base.json and public src/index.ts barrels. Do not add legacy bare aliases or deep imports. For a buildable library that has a local package.json, its package name must match its scoped alias.

Validate the Change

Production TypeScript targets under 300 lines; 400 is the hard limit. Tests are limited to 1200. The legacy baseline may only shrink. See tools/eslint/max-lines-config.mjs and regenerate after a split with tools/eslint/generate-max-lines-baseline.mjs; never add a new baseline entry.

Quote recursive globs in command-based lint targets, for example eslint "apps/<project>/**/*.ts", then compare coverage with find apps/<project> -name '*.ts' | wc -l.

Discover targets, then run affected lint/test/build targets and the closest available E2E target; do not invent targets. Canonical guidance: docs/architecture/nx-workspace-boundaries.md.

Download now (ZIP)

Trending

More talk lately.about the whole repository

Dec 2025: 1 mentionJan 2026: 1 mentionFeb 2026: 0 mentionsMar 2026: 1 mentionApr 2026: 0 mentionsMay 2026: 0 mentionsJun 2026: 3 mentionsJul 2026: 0 mentionsAug 2026: 1 mentionSep 2026: 2 mentionsOct 2026: 3 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the 4gray/iptvnator repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about 4gray/iptvnator

The biggest 5 of 25 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 25

Talked about on GitHub, Bluesky and Stack Overflow (25 times).

On GitHub · 19

14 more on GitHub

On Bluesky · 5

On Stack Overflow · 1

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.