메뉴
Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use once, at the start of a new Hedgehog project, before hedgehog-bootstrap's add-on steps, to land the golden-core workspace (Nx, packages/config, packages/db, apps/api, apps/web, and every enforcement file) and verify it's green. Runs as the first move of the `bootstrap` agent, which `planner` invokes automatically after Confirm & Lock. No per-project decisions, no add-on awareness.
Use once, at the start of a new Hedgehog project, to land the core workspace and scaffold whichever add-ons (Auth, Queue, Mobile) planning intake turned on (TODO.md's Add-ons block). Runs when the `bootstrap` agent runs, which `planner` invokes automatically after Confirm & Lock. Scoped to project scaffolding; per-module work runs through the `hedgehog-loop` skill, one step at a time.
Use for every unit of work once a Hedgehog project is bootstrapped — building one Order step (schema, contract, repository, service, controller, hook, screen), gating it, committing it, and checking it off TODO.md. Triggers on "next step", "build this module", "what's next", or the start of any work session on a bootstrapped project. Also covers the Correction Protocol for fixing a wrong upstream step.
Link workspace packages in the Hedgehog pnpm monorepo. USE WHEN: (1) you just created or generated new packages and need to wire up their dependencies, (2) code imports from a sibling package and needs it added as a dependency, (3) you get resolution errors for workspace packages (@org/*) like "cannot find module", "failed to resolve import", "TS2307", or "cannot resolve". DO NOT patch around with tsconfig paths or manual package.json edits - use pnpm's workspace commands to fix actual linking.
Generate code using nx generators. INVOKE IMMEDIATELY when user mentions scaffolding, setup, structure, creating apps/libs, or setting up project structure. Trigger words - scaffold, setup, create a new app, create a new lib, project structure, generate, add a new project. ALWAYS use this BEFORE calling nx_docs or exploring - this skill handles discovery internally.
Explore and understand Nx workspaces. USE WHEN answering questions about the workspace, projects, or tasks. ALSO USE WHEN an nx command fails or you need to check available targets/configuration before running a task. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What depends on library Y?', 'What targets can I run?', 'Cannot find configuration for task', 'debug nx task failure'.
| name | nx-run-tasks |
| description | Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace. |
Run tasks with Nx via pnpm nx (Hedgehog workspaces are pnpm-only).
For more details on any command, run it with --help (e.g. pnpm nx run-many --help, pnpm nx affected --help).
You can check those via pnpm nx show project <projectname> --json, for example pnpm nx show project myapp --json. It contains a targets section which has information about targets that can be run. You can also just look at the package.json scripts or project.json targets, but you might miss out on inferred tasks by Nx plugins.
pnpm nx run <project>:<task>
where project is the project name defined in package.json or project.json (if present).
pnpm nx run-many -t build test lint typecheck
You can pass a -p flag to filter to specific projects, otherwise it runs on all projects. You can also use --exclude to exclude projects, and --parallel to control the number of parallel processes (default is 3).
Examples:
pnpm nx run-many -t test -p proj1 proj2 — test specific projectspnpm nx run-many -t test --projects=*-app --exclude=excluded-app — test projects matching a patternpnpm nx run-many -t test --projects=tag:api-* — test projects by tagUse pnpm nx affected to only run tasks on projects that have been changed and projects that depend on changed projects. This is especially useful in CI and for large workspaces.
pnpm nx affected -t build test lint
By default it compares against the base branch. You can customize this:
pnpm nx affected -t test --base=main --head=HEAD — compare against a specific base and headpnpm nx affected -t test --files=libs/mylib/src/index.ts — specify changed files directlyThese flags work with run, run-many, and affected:
--skipNxCache — rerun tasks even when results are cached--verbose — print additional information such as stack traces--nxBail — stop execution after the first failed task--configuration=<name> — use a specific configuration (e.g. production)