---
name: using-itsolpowers
description: "ITSOL router: planning, tech context, agent-browser dogfood, TDD, review, UI/UX, security."
---

# Using Itsolpowers

Use this skill as the router for ITSOL engineering work. The goal is to load the smallest useful set of skills, not every checklist.

## Routing Rule

Before refining requirements, implementing, debugging, reviewing, planning, or handing off an ITSOL task:

1. If the user asks to create, initialize, inspect, or update `.itsol.md`, load `itsol-repo-memory` first. If root `.itsol.md` exists, load `itsol-repo-memory` and apply repo or monorepo project policy before choosing testing, verification, implementation, review, or deployment strategy.
2. Load `itsol-workflow-mode` and resolve the workflow state before applying functional, bugfix, planning, implementation, or delegation gates. Honor an explicit user selection subject to platform authority and matched `.itsol.md` restrictions; otherwise use an allowed repository default or `governed`. Do not infer delegation from `continue`, `do it`, silence, or an unqualified `accept everything`.
3. At the start of every relevant task, report the selected `workflow_mode`, `mode_source`, and `decision_authority` concisely. Record and preserve all seven `itsol-workflow-mode` fields through task context, compaction, plans when present, handoffs, and every subagent task packet: `workflow_mode`, `mode_source`, `decision_authority`, `scope`, `artifact_state`, `execution_mode`, and `protected_constraints`.
4. Load `itsol-execution-policy` after workflow mode. Resolve the separate preset, policy sources, model/reasoning intent and control, distinct-agent/parallel/review ceilings, observable `done_when`, ranked `stop_after`, and escalation behavior. Default to `standard`; do not invent a numeric total-agent ceiling without explicit user or repository authority. Never use `maxTurns` or treat an agent stopping as task completion.
   Choose inline work for trivial tasks, sequential dependencies, overlapping file or semantic-contract ownership, and unsupported delegation controls. Use subagents only for independent work or required independent review that fits every ceiling.
5. Identify the task type: initiative delivery, repo memory/init, intake, Codex agent setup/diagnostics, current technology research, requirements review, feature implementation, bug debugging, technical planning, code review, self-review, QA handoff, agent-browser dogfood/browser QA, security review, infrastructure work, database work, ML/AI work, UI/UX work, frontend work, or backend work. If the user supplies a broad business document describing a whole module, application, migration, or multi-phase capability, load `itsol-initiative-delivery`; analyze and trace the complete scope instead of selecting one implementation slice.
6. Load one process skill first, usually `itsol-initiative-delivery`, `itsol-task-intake`, `itsol-repo-memory`, `itsol-current-tech-context`, `application-technology-migration`, `itsol-functional-planning`, `itsol-subagent-workflow`, `itsol-requirements-review`, `itsol-feature-implementation`, `itsol-bug-debugging`, `itsol-tdd-workflow`, `itsol-technical-planning`, `itsol-code-review-workflow`, `itsol-self-review`, or `itsol-qa-handoff`.
7. Load focused domain skills only for touched areas. Prefer `security-authz-tenant-review` over a broad security sweep when the change is only authorization.
8. Read the selected skill's guide index before making claims based on ITSOL standards. Within each selected skill, follow its [references/guide.md](references/guide.md) link; if it is a routing index, load only the sector files relevant to the task.
9. If several skills apply, use the most risk-shaping skill first: repo policy, security, data integrity, deployment safety, then implementation style.
10. Load `itsol-current-tech-context` whenever planning, reviewing, implementing, upgrading, or starting work depends on frameworks, SDKs, runtimes, libraries, package managers, generated clients, external APIs, Rust editions, .NET SDKs, Node/Bun/npm packages, database drivers, or infrastructure tooling.
11. For existing repos, use `itsol-current-tech-context` to inspect local version pins first and verify current official documentation for those versions. For new projects, use it to select latest stable versions unless the user explicitly pins otherwise.
12. For machine learning, AI engineering, model quality, datasets, evals, training, LLM/RAG, model serving, MLOps, drift, retraining, model cards, or ML review work, route through the smallest `ml-*` skill: `ml-ai-project-planning`, `ml-data-evaluation`, `ml-training-experiments`, `ml-llm-rag-engineering`, or `ml-serving-mlops-review`. If the primary touched surface is Rust/Rig/Candle/provider/runtime code, prefer existing `rust-ml-llm-*` skills first and add generic `ml-*` only for cross-cutting project, data, evaluation, serving, or review concerns.
13. For rewrite, technology migration, modernization, strangler, branch-by-abstraction, parallel run, data cutover, compatibility contract, or legacy decommissioning work, load `application-technology-migration` before normal feature or bug workflows.
14. For UI/UX tasks, new views, visible frontend flows, design-system changes, responsive behavior, accessibility, frontend tests, or UI review, load `ui-ux-workflow` plus the smallest focused UI skills for the touched surface. For React 19 or Next.js work, also load the smallest relevant `react-nextjs-*` skill: implementation/review/debugging, App Router/rendering, API/cache/forms, or quality/security. For TanStack Query v5 in React/Next.js, prefer the focused `tanstack-query-react-nextjs-*` skill for implementation, review, or debugging. For Expo / React Native mobile apps, route Expo SDK, React Native, Expo Router, development builds, CNG/prebuild, app config, permissions, storage/offline, native modules, EAS Build, EAS Update/OTA, store release, and mobile debugging/review through the focused `expo-*` skills. For Electron desktop apps, route desktop shell, main/preload/renderer, IPC, BrowserWindow, auto-update, packaging, code signing, and desktop security work through the focused `electron-*` skills. For Tauri desktop apps, route Rust/frontend boundaries, commands, invoke/events, capabilities, permissions, WebView platform behavior, sidecars, updater, bundling, signing, and release work through the focused `tauri-*` skills.
15. For agent-browser, local browser dogfood, pre-QA frontend validation, browser-based reproduction, console/network/HAR/trace evidence, Web Vitals checks, or production-safe browser smoke tests, route through the smallest `agent-browser-*` skill. Explicit agent-browser work must not be handled only by generic `ui-frontend-testing-qa` or `itsol-qa-handoff`. For command-sensitive browser automation, check `agent-browser --version` and `agent-browser --help`; if the installed CLI supports versioned local guidance such as `agent-browser skills get core` or `agent-browser skills get dogfood`, load it so commands match the installed CLI version.
16. For functional tasks, feature work, endpoints, UI flows, integrations, or behavior changes, load `itsol-functional-planning` and `itsol-requirements-review`, then apply their prerequisites according to `itsol-workflow-mode`.
17. In `governed`, use `decision_authority: user` and `execution_mode: pending` until the user chooses inline or subagents; vague or underspecified functional requests run the full Discovery Gate before a Business Plan; the Technical Decision Gate requires the user's choice; plans use `artifact_state: draft` until the user sees and explicitly approves the specific artifact, then become `Approved` with `artifact_state: approved`.
18. In `autonomous-planned`, use `decision_authority: delegated` and `execution_mode: auto` until the agent chooses inline or subagents from task shape; create and review the normal Business, Technical, or Technical Fix Plans with `artifact_state: draft`, resolve material findings, choose the documented recommendation, then set `artifact_state: ready-for-execution`, mark plans `Ready for execution`, and continue without approval pauses. Never call this explicit user approval.
19. In `direct`, use `decision_authority: delegated` within the requested scope, `artifact_state: not-required`, and `execution_mode: auto` until the agent chooses inline or subagents from task shape; omit persistent Business, Technical, and Technical Fix Plans, their plan reviews, Decision Gates, plan paths, approval gates, and execution-mode approval while retaining scoped evidence, TDD or replacement verification, focused reviews, and final self-review.
20. In autonomous modes, ask one targeted question only when equally plausible choices materially change behavior, permissions, data handling, rollout, or architecture. Do not let internet research silently settle such ambiguity; use it to support a safe recommendation or frame the blocker.
21. For bugs, regressions, failing tests, production symptoms, or broken behavior, load `itsol-bug-debugging`; evidence remains required in every mode, while Fix Decision Gate and Technical Fix Plan behavior follow `itsol-workflow-mode` (`governed`, `autonomous-planned`, or `direct`).
22. For feature work, bugfixes, behavior changes, refactors, UI changes, or migration slices, load `itsol-tdd-workflow` before writing production code. If `.itsol.md` marks the touched project as `limited` or `not-supported`, do not scaffold a new test framework just to satisfy TDD; record the TDD exception and run required replacement verification.
23. If execution uses subagents, load `itsol-subagent-workflow` before starting implementation and include the complete seven-field `itsol-workflow-mode` state in every task packet. A subagent with missing, inconsistent, or restriction-conflicting state must return `blocked`.
24. For every code review, build a coverage map of relevant review areas. If the PR is large, multi-surface, security/data/infra sensitive, migration-related, generated-contract related, documentation-version-sensitive, frontend/UI-heavy, browser-testing-heavy, ML/AI-related, or hard to review in one context, route review through focused subagents before producing the verdict.
25. If the work has independent surfaces, consider subagents for planning, read-only investigation, review, or implementation. Start implementation subagents only when `itsol-workflow-mode` authorization is valid: approved artifacts and user-selected execution in `governed`, reviewed `Ready for execution` artifacts in `autonomous-planned`, or `artifact_state: not-required` with agent-selected execution in `direct`.
26. Apply explicit mode changes only to remaining work, retain existing artifacts, and follow `itsol-workflow-mode` transition rules. Keep workflow autonomy separate from authority for destructive data operations, unrequested production publication/deployment, secrets outside scope, external communications or purchases, and security weakening.
27. For Codex custom-agent installation, updates, removal, model/reasoning presets, `~/.codex/agents`, `.codex/agents`, or `[agents]` limits, use `itsol-codex-setup` in the main agent. For read-only diagnosis use `itsol-codex-doctor`. Never delegate configuration writes and never probe model entitlement with a paid task.

## Subagent Routing

In Claude Code, this plugin provides scoped subagents for engineering-domain and workflow skills, for example `itsolpowers:dotnet-web-api-review` or `itsolpowers:security-api-input-review`. Main-agent-only operational skills such as `itsol-codex-setup` and `itsol-codex-doctor` intentionally have no delegated agent. Prefer the matching plugin subagent when delegating work for a selected skill, because the subagent preloads that skill and carries the same ITSOL workflow constraints in an isolated context.

In Codex, do not treat ITSOL skill names as `agent_type` values. Codex subagent roles are platform roles such as `default`, `explorer`, or `worker`. When forking conversation context, do not also set an explicit `agent_type`; spawn the subagent with forked context and provide the ITSOL skill name in the task instructions or structured skill item. If a Codex role such as `explorer` or `worker` is required, do not use forked context; pass only the minimal task context manually.

Use subagents when the task can be split into independent workstreams, such as UI/API/database/infra changes, multi-area code review, several debugging hypotheses, security plus implementation review, or incident evidence gathering.

When subagent-driven execution is selected, treat `itsol-subagent-workflow` as the canonical contract for the task graph, task packet, statuses, write scope, stop conditions, response contract, review loop, and final validation. Router guidance may reinforce that contract but must not redefine a parallel version of it.

Only the main agent orchestrates subagents. A delegated subagent must not spawn another subagent, invoke external agent CLIs such as `codex exec` or `claude`, or try to perform second-level delegation. If the delegated work is still too broad, it must return the recommended split to the main agent.

For code review, subagents are mandatory for large or multi-area PRs. Assign separate review subagents by pragmatic risk area, such as security, infrastructure, frontend, backend, database, generated clients/API contracts, migration/rewrite, QA/release, performance, or test strategy. Inline-only review is acceptable only for tiny single-surface diffs, and the reviewer must state why subagents were unnecessary.

For planning or review that depends on current framework, SDK, runtime, package, or API behavior, delegate a current-tech pass to `itsolpowers:itsol-current-tech-context` when possible. Feed its version findings into the Technical Plan or final review verdict.

For frontend UI/UX work, delegate focused review passes by area when useful: `ui-design-system`, `ui-component-architecture`, `ui-view-states-forms`, `ui-responsive-media`, `ui-tailwind-tokens`, `ui-accessibility-motion`, `ui-performance-stability`, `ui-frontend-testing-qa`, and `ui-code-review`. For React 19/Next.js PRs, use `react-nextjs-review` as the framework-level reviewer and split large PRs further through `react-nextjs-app-router-rendering`, `react-nextjs-api-cache-forms`, `react-nextjs-quality-security`, `tanstack-query-react-nextjs-review`, security, UI, generated-client, or testing subagents based on the diff. For ML/AI PRs, split large or risky reviews through `ml-data-evaluation`, `ml-training-experiments`, `ml-llm-rag-engineering`, `ml-serving-mlops-review`, security/privacy, infrastructure/serving, current-tech, QA/release, and `rust-ml-llm-review` when Rust/Rig/Candle code is primary. For Expo / React Native PRs, split large or security/release-sensitive reviews through `expo-react-native-review`, `expo-security-permissions`, `expo-eas-release-ota`, UI/frontend, generated-client/API, TanStack Query, security, dependency/current-tech, and testing subagents based on changed surfaces. For Electron PRs, split large or security-sensitive reviews through `electron-desktop-review`, `electron-security-hardening`, `electron-release-distribution`, UI/frontend, security, infrastructure, and testing subagents based on changed surfaces. For Tauri PRs, split large or security-sensitive reviews through `tauri-desktop-review`, `tauri-security-capabilities`, `tauri-release-distribution`, Rust, UI/frontend, security, infrastructure, and testing subagents based on changed surfaces.

For browser dogfood, pre-QA validation, or browser-based bug reproduction, split large sessions through `agent-browser-dogfood-workflow`, `agent-browser-interaction-debugging`, `agent-browser-diagnostics-evidence`, `agent-browser-qa-reporting`, and `agent-browser-security-production-safety` based on risk. Add UI, framework, security, data, or infra subagents only when the browser evidence points at those surfaces.

For subagent-driven implementation, use `itsol-subagent-workflow`: split work into task slices, agree the concurrency limit, delegate implementation, run a separate review subagent after each implementation result, repeat fixes until review is clean, commit reviewed task slices with Angular commit convention when allowed, then validate the integrated result.

Assign each subagent through a task packet with a narrow goal, source of truth, read scope, write scope or `read-only`, forbidden scope, required skills, verification or replacement evidence, allowed statuses, and stop conditions. Keep the main agent responsible for the immediate blocker, cross-surface decisions, integrating results, avoiding conflicting edits, and final verification.

Validate every subagent response against its task packet and the canonical response contract before treating it as accepted. A `completed` result still needs evidence. A `partial`, `blocked`, or `failed` result needs explicit main-agent handling: record what is verified, what is unverified, any coverage gap, the next decision or revised split, and whether work must stop.

## Commit Convention

When creating commits for ITSOL work, use Angular commit convention. Keep commits focused and scoped to the completed slice:

- `feat(scope): add customer export filter`
- `fix(scope): handle missing tenant permission`
- `test(scope): cover stale query invalidation`
- `refactor(scope): isolate webhook validation`
- `docs(scope): update planning workflow`

Do not mix unrelated changes in one commit. If the worktree contains unrelated user changes, stage only the intended files or stop and ask before committing.

## Skill Families

- Core workflow: `itsol-initiative-delivery`, `itsol-task-intake`, `itsol-repo-memory`, `itsol-current-tech-context`, `application-technology-migration`, `itsol-functional-planning`, `itsol-subagent-workflow`, `itsol-requirements-review`, `itsol-feature-implementation`, `itsol-bug-debugging`, `itsol-tdd-workflow`, `itsol-technical-planning`, `itsol-code-review-workflow`, `itsol-self-review`, `itsol-qa-handoff`.
- Security: threat modeling, auth/session, authz/tenant, API/input, frontend/browser, files/integrations, secrets/config, supply chain, QA scenarios, vulnerability response.
- Infrastructure: deployment design, container build/runtime, Nomad, routing/proxy/TLS, edge protection, secrets/config, observability, backup/DR, capacity, incident debugging, production readiness.
- UI/UX frontend: `ui-ux-workflow`, `ui-design-system`, `ui-component-architecture`, `ui-view-states-forms`, `ui-responsive-media`, `ui-tailwind-tokens`, `ui-accessibility-motion`, `ui-performance-stability`, `ui-frontend-testing-qa`, `ui-code-review`.
- Agent-browser dogfood: `agent-browser-dogfood-workflow`, `agent-browser-interaction-debugging`, `agent-browser-diagnostics-evidence`, `agent-browser-qa-reporting`, `agent-browser-security-production-safety`.
- ML/AI engineering: `ml-ai-project-planning`, `ml-data-evaluation`, `ml-training-experiments`, `ml-llm-rag-engineering`, `ml-serving-mlops-review`; use `rust-ml-llm-*` first for Rust/Rig/Candle-specific code.
- Frontend, mobile, and desktop: `react-nextjs-*`, `tanstack-query-react-nextjs-*`, `svelte-*`, `tanstack-query-svelte-*`, `expo-*`, `electron-*`, `tauri-*`, `hey-api-openapi-*`.
- Backend and typed TypeScript: `dotnet-web-api-*`, `effect-typescript-*`.
- Rust: `rust-*`, plus `rust-ml-llm-*` for Rig, Candle, RAG, local inference, and LLM systems.
- Databases: `postgres-*`, `mongodb-*`, and `mssql-*` for schema/data modeling, .NET data access, review, and operations debugging.

## Output Standard

At every relevant task start, lead with the selected mode, source, and decision authority from `itsol-workflow-mode`, then preserve the complete seven-field state. For implementation work, also state the selected skills, matched `.itsol.md` policy when present, plan paths when the selected mode requires artifacts, execution mode, concrete risk areas, Current Tech Context when relevant, and RED/GREEN verification or a documented TDD exception with replacement verification. Report any separate protected-action authorization without treating it as a planning gate. For subagent-driven work, also report task statuses, reviewed slices, unresolved `partial`, `blocked`, or `failed` items, unverified items, coverage gaps, and final integration checks. For review work, lead with findings by severity and include repo policy plus version/documentation context for findings that depend on framework, SDK, runtime, package, or API behavior. For debugging, gather evidence, then report the mode-appropriate Technical Fix Plan state (`Draft`, `Approved`, `Ready for execution`, or `not-required`) before proposing or implementing fixes.

## Execution Policy

After resolving `itsol-workflow-mode`, load `itsol-execution-policy`, resolve the complete sibling execution state and observable `done_when`, and preserve both contracts through plans, task context, compaction, delegation, continuation, review, and handoff. Resource policy never changes workflow authority. Do not set `maxTurns`; do not accept agent termination or a `completed` label without validating evidence.