@dsalazardev/ai-hub-cli 0.0.0-stage → 0.2.0

package/skills/shared/analyze/SKILL.md

@@ -0,0 +1,123 @@
+---
+name: analyze
+description: "Use when constitution, spec, plan and tasks all exist and you want them cross-read against each other before any code is written — the ai-hub Spec-Kit pre-implementation gate. Reports coverage gaps, contradictions, duplication, ambiguity and scope drift; edits nothing. NOT the task breakdown (that is `tasks`), NOT the coding (that is `implement`), NOT the post-code test gate (that is `verify`), NOT resolving ambiguity (that is `clarify`)."
+tags: [sdd, analyze, consistency]
+recommends: [implement]
+profiles: [core, full]
+origin: ai-hub
+---
+
+# Analyze — the pre-implementation consistency gate
+
+You have a **constitution**, a **spec**, a **plan** and a **task list**. Four artifacts written at four different moments, by a mind that drifted a little each time. `analyze` reads all four *against each other* and surfaces where they disagree. It is the cheapest place in the whole chain to catch a problem — a contradiction found here costs a sentence; the same contradiction found mid-implement costs a rewrite.
+
+Sixth phase of the ai-hub Spec-Kit chain (`constitution → specify → clarify → plan → tasks → analyze → implement`); the method itself lives in `../sdd/SKILL.md`. It is a **gate, not a worker**: it produces a report and stops. The user reads the findings and decides what to fix, and which phase to send each fix back to.
+
+**Report only. Resolve nothing.** Never edit the constitution, spec, plan or tasks; never open a code file to "just fix it"; never silently reconcile a contradiction by picking a side. This one is absolute because a gate that quietly fixes things stops being a gate: the user never learns the spec was wrong, the plan built on the old assumption stays stale, and the "consistency check" has manufactured a new inconsistency. Name the conflict, show both sides with locations, propose where it should be resolved, hand the decision back.
+
+**Model tier: `heavy`** (adversarial cross-reading). Resolve and apply it per `../sdd/references/model-routing.md`; routing is off unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`.
+
+**Register.** Read `technical_level` in `02-DOCS/wiki/harness/user-profile.md` before reporting; with no profile, use analogies and say the harness has not set the register yet. The register changes how the report reads, never what gets checked; the six analyses always run in full.
+
+The report is the same for every reader: a finding table (severity, the two artifacts, the conflict in one line), a one-line *why it matters* per CRITICAL/HIGH finding, and per finding the recommended resolution phase and the trade-off of leaving it. For a `non-technical` reader, explain the consequence at implement time with an everyday analogy so they can choose.
+
+## Inputs — locate the four artifacts
+
+Read all four before analyzing. The ai-hub Spec-Kit artifacts live under `02-DOCS/wiki/sdd/`, indexed from `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer to it):
+
+| Artifact | Canonical location | Role in the check |
+| --- | --- | --- |
+| Constitution | `02-DOCS/wiki/sdd/constitution.md` | The non-negotiables. Everything below must obey it. |
+| Spec | `02-DOCS/wiki/sdd/specs/<slug>.md` | WHAT & WHY. The source of truth for requirements. |
+| Plan | `02-DOCS/wiki/sdd/plans/<slug>.md` | HOW. Must cover every spec requirement, add nothing the spec didn't ask for. |
+| Tasks | task list inside the plan artifact | The ordered, verifiable steps. Must implement the plan, no more. |
+
+If any artifact is missing, **stop and say so** — analyze cannot gate what isn't there. Name the missing one and the phase that produces it. If a `<slug>` is ambiguous (several specs), ask which feature is being gated; do not analyze all of them blindly.
+
+## The six analyses
+
+Run every one. Each compares a specific pair (or the whole set against the constitution) and emits findings.
+
+1. **Constitution compliance** — does any spec requirement, plan decision or task violate a non-negotiable (stack canon, quality bar, convention)? A constitution breach is the highest-severity finding there is; the constitution wins by definition.
+2. **Requirement coverage (spec → plan → tasks)** — map every spec requirement forward. Each must trace to at least one plan section and at least one task. A requirement with no task is a **gap** (it will silently not ship). Build the coverage map below.
+3. **Scope drift (tasks/plan → spec)** — map backward. Any plan section or task that satisfies *no* spec requirement is **drift** — work the spec never asked for. Flag it; the fix is either cut the work or amend the spec, and that is the user's call.
+4. **Contradiction** — direct disagreements between two artifacts: the spec says Postgres, the plan says SQLite; the spec says "no auth in v1", a task adds login. Quote both sides.
+5. **Duplication** — the same requirement stated twice in conflicting words, or two tasks doing the same job. Duplication is where contradictions breed later.
+6. **Ambiguity / underspecification** — requirements or tasks too vague to implement or to verify ("handle errors gracefully", "make it fast" with no number, a task with no done-check). These do not block by themselves but feed back to `clarify` (spec) or `tasks` (missing done-check).
+   - **Carrier completeness (isolated-implementer check).** Because `implement`/`parallel` dispatch tasks to **context-isolated** `developer` subagents that see only their own task, also confirm the plan carries a **§0 Global Constraints** block (verbatim project-wide values) and that every task whose correctness depends on a contract it doesn't own has an **Interfaces** block (`Consumes`/`Produces`, exact signatures). A constraint or neighbor-signature that lives only in prose is invisible to the blind worker — flag a missing carrier as `AMBIGUOUS` (it will surface as drift or breakage at implement time). See `../plan/references/plan-template.md` §0 and `../tasks/SKILL.md` (Per-task Interfaces).
+
+### Requirement coverage map (build this every run)
+
+A copy-able table that makes gaps and drift visible at a glance:
+
+```text
+REQ-ID | Spec requirement (short)        | Plan section | Task(s) | Status
+------ | ------------------------------- | ------------ | ------- | ----------
+R1     | Email/password sign-up          | §3 Auth      | T2,T3   | covered
+R2     | Rate-limit login (5/min/IP)     | §3 Auth      | —       | GAP
+R3     | —                               | §5 Webhooks  | T9      | DRIFT
+R4     | "Fast" search                   | §4 Search    | T6      | AMBIGUOUS (no metric)
+```
+
+- `GAP` — spec requirement with no task → it won't be built.
+- `DRIFT` — plan/task with no spec requirement → unrequested scope.
+- `AMBIGUOUS` — covered but not specific enough to verify later.
+- `covered` — traces cleanly spec → plan → task.
+
+## Severity scale
+
+Rank every finding so the user triages fast:
+
+- **CRITICAL** — constitution violation, or a contradiction that makes the artifacts un-implementable as written. Must resolve before `implement`.
+- **HIGH** — a coverage GAP on a core requirement, or scope DRIFT that adds real cost. Resolve before implement.
+- **MEDIUM** — duplication, or AMBIGUOUS items with no number/done-check. Resolve or consciously accept.
+- **LOW** — wording mismatches, cosmetic inconsistencies. Note and move on.
+
+## Output — the report (and where it goes)
+
+Produce a single consistency report:
+
+1. **Verdict line** — `GATE: PASS` (zero CRITICAL/HIGH) or `GATE: BLOCKED` (one or more CRITICAL/HIGH), with the counts.
+2. **Coverage map** — the table above.
+3. **Findings table** — `# | Severity | Type | Artifact A (loc) | Artifact B (loc) | Conflict | Resolve in (phase)`.
+4. **Recommended routing** — group fixes by the phase that owns them (`clarify` for spec ambiguity, `plan` for missing architecture, `tasks` for a missing done-check, `constitution` if a principle itself is wrong). If findings pour in across all six checks, the artifacts diverged badly — recommend re-running `clarify`/`plan` before a line-by-line analyze is even useful.
+
+Write the report to `02-DOCS/wiki/sdd/analysis/<slug>.md` (create the dir if absent) and index it in `02-DOCS/wiki/index.md` under the `sdd/` topic, so the next phase and the harness can find it. It is an OKF v0.1 wiki article: open it with YAML frontmatter carrying a non-empty `type:` (use `type: analysis`), a `timestamp` in ISO 8601, and standard markdown links — never wikilinks. The report is the artifact analyze owns — it is the *only* thing analyze writes. Per-run point-in-time; overwrite on re-run, the wiki keeps history.
+
+Render it in the orient voice, in the user's register. Do not log a decision to `decisions.md` — analyze decides nothing; the phase that resolves the finding logs its own decision.
+
+## Anti-patterns
+
+| Anti-pattern | Why it breaks the gate / do instead |
+| --- | --- |
+| Fixing a "trivial" contradiction in the spec yourself | Then you are `clarify`/`plan`/`tasks`, not `analyze`. Report it; the user resolves. |
+| Starting to code because nothing CRITICAL turned up | Analyze never transitions to code. Hand the verdict to `implement`; that phase starts the work. |
+| Waving through plan work the spec never asked for because it's obviously a good idea | That is DRIFT. Flag it. Good ideas still need the spec amended (user's call), or they are silent scope creep. |
+| Siding with the plan when it contradicts the constitution | The constitution wins by definition — flag CRITICAL. If the principle itself is wrong, that is a `constitution` change the user makes, not a quiet override here. |
+| Guessing what a vague requirement meant | Guessing defeats the gate. Mark AMBIGUOUS and route to `clarify`; do not encode your guess. |
+
+## Result envelope
+
+End with the parseable block every SDD phase shares, so the dispatcher can chain without
+interpreting prose (contract: `../sdd/SKILL.md`):
+
+```json result-envelope
+{
+  "status": "complete|blocked|failed",
+  "executive_summary": "Cross-read of spec/plan/tasks against the constitution; findings ranked.",
+  "artifact": "02-DOCS/wiki/sdd/analysis/<slug>.md",
+  "next_recommended": "implement",
+  "risk": "low|medium|high",
+  "skill_resolution": {
+    "used": ["analyze"],
+    "missing": [],
+    "fallback": [],
+    "compact_rules": ["Read adversarially across artifacts, not inside one.", "A finding without a location is an opinion."]
+  },
+  "evidence": ["report path exists", "blockers listed with artifact + location", "constitution conflicts named"]
+}
+```
+
+## Next in the chain
+
+On `GATE: PASS` (or once the user consciously accepts the remaining MEDIUM/LOW findings), proceed to **`implement`** — execute the tasks with TDD discipline, delegating concrete test tooling to the relevant stack skill (`fastapi`, `nextjs`, `go`, `flutter`, `postgresdb`). On `GATE: BLOCKED`, route each CRITICAL/HIGH finding to its owning phase (`clarify`, `plan`, `tasks`, or `constitution`), let the user resolve, then re-run `analyze`. The gate only opens once.

package/skills/shared/analyze/evals/README.md

@@ -0,0 +1,72 @@
+# Eval harness — `analyze` skill
+
+`analyze` is the ai-hub Spec-Kit **pre-implementation consistency gate**. These evals
+check two things: that the skill **triggers** on the right prompts (a
+cross-check of the planning artifacts before coding) and stays quiet on
+near-misses (anything that resolves, builds, runs, or debugs code), and that it
+**measurably changes the answer** — reporting and routing instead of editing
+artifacts or jumping into code. Cases live in `cases.yaml`. There is no shell
+runner: triggering and report quality are judgment calls graded by an agent
+harness plus a human spot-check.
+
+## What's in `cases.yaml`
+
+- `should_trigger` — prompts that MUST load `analyze` (several avoid the word
+  "analyze" to test intent, not keyword).
+- `should_not_trigger` — near-misses routed to the correct existing sibling via
+  `route_to` (debugging, verification via a stack skill, plan authoring, code
+  review, harness bootstrap, db perf).
+- `capability` — a full BLOCKED-gate scenario with a `must_include` rubric to
+  grade with vs without the skill.
+
+## Triggering eval
+
+Goal: the gate fires when the four artifacts exist and a cross-check is wanted,
+and never on a near-miss.
+
+1. Configure an agent with the **full catalog of skill descriptions** available
+   for routing (analyze + harness, init, the stack skills fastapi/nextjs/go/
+   flutter/postgresdb, secure-coding, deployment, design, marketing,
+   presentations, course-storytelling, building-agents) so routing competes
+   realistically. When the other ai-hub Spec-Kit phase skills (clarify, plan, tasks,
+   implement, verify, review, debug) are added to the repo, include them too —
+   they are the closest competitors and the sharpest test of the boundary.
+2. For each `should_trigger` prompt: feed it cold, record whether `analyze` is
+   the skill the agent loads. Run **3-5 trials** per prompt (fresh context).
+3. For each `should_not_trigger` prompt: confirm `analyze` does NOT load and the
+   chosen skill matches `route_to`. Same 3-5 trials.
+4. Score: `triggered_correctly / total_trials` across both lists.
+
+**Pass bar: >= 90% trigger accuracy** over all prompts and trials, with **zero
+systematic false-positives** on the debugging and verification near-misses
+(those are the known traps — "is it ready to ship / why is it failing" is a
+post-implementation or runtime concern, not a pre-implementation artifact gate).
+
+## Capability eval
+
+Goal: prove the skill changes the answer, not just the routing.
+
+1. For the `capability` scenario, run it **twice**:
+   - **WITHOUT** the skill (base agent, no `analyze` loaded).
+   - **WITH** the `analyze` skill loaded.
+2. Grade each output against the `must_include` checklist — one point per item
+   covered. A human or grading agent marks each item present / absent.
+3. Compute coverage = `items_covered / total_items` for each run.
+
+**Pass bar: WITH the skill covers >= 80% of `must_include`; WITHOUT clearly
+lower** (target a >= 30-point gap). The discriminating behaviors are the
+report-only discipline (no artifact edits, no code), running all six analyses,
+the constitution-violation + GAP double-flag on the missing rate limit, the
+DRIFT call on the Redis cache, the coverage map, the verdict line, and the
+hand-off to the next phase.
+
+## Notes on honesty
+
+- Trials are stochastic; report the raw fraction, not a rounded "pass".
+- The highest-signal capability check is **restraint**: a correct answer reports
+  and routes, it does not "helpfully" rewrite the spec or start coding. Treat a
+  confident answer that edits an artifact or begins implementation as a
+  **capability failure** even if its analysis is otherwise sharp — that behavior
+  defeats the gate.
+- Re-run after any edit to `SKILL.md`. Wording changes shift both triggering and
+  rubric coverage, and the report-only boundary is easy to soften by accident.

package/skills/shared/analyze/evals/cases.yaml

@@ -0,0 +1,74 @@
+skill: analyze
+
+# Prompts that MUST load the `analyze` skill. `analyze` is the ai-hub Spec-Kit
+# pre-implementation GATE: it cross-reads constitution vs spec vs plan vs tasks
+# and REPORTS gaps, contradictions, duplication, ambiguity and scope drift. It
+# never edits the artifacts and never writes code — the user resolves each
+# finding. Several prompts deliberately avoid the word "analyze" to test that
+# the intent (a consistency cross-check before coding) is what triggers.
+should_trigger:
+  - prompt: "The spec, plan and task list are all written — before I start coding, can you check they actually agree with each other?"
+    why: "Cross-reading spec/plan/tasks for agreement right before implementation is the exact job of the pre-implementation gate."
+
+  - prompt: "Did we miss any requirement? I want to know which spec requirements have no task behind them."
+    why: "Requirement coverage (spec -> plan -> tasks) and surfacing GAPs is analysis #2; the user is asking for the coverage map without naming the skill."
+
+  - prompt: "The plan mentions a Redis cache and a webhook handler that I don't remember being in the spec — is that scope creep?"
+    why: "Plan/task work that satisfies no spec requirement is DRIFT — analysis #3; this is the backward-mapping check phrased as 'scope creep'."
+
+  - prompt: "Run the consistency gate over the SDD artifacts for the checkout feature."
+    why: "Explicit request for the consistency gate across the SDD artifacts; the core trigger for this phase."
+
+  - prompt: "Our constitution says Postgres only, but I think the plan picked a different database somewhere — can you cross-check before we build?"
+    why: "Constitution compliance (analysis #1) plus contradiction detection between constitution and plan, explicitly before building."
+
+  - prompt: "Sanity-check the spec against the plan and tasks for me — I don't want to find contradictions halfway through implementing."
+    why: "Pre-implementation contradiction detection across the artifacts is the gate's purpose; 'halfway through implementing' is the cost analyze exists to avoid."
+
+  - prompt: "Before implement, is everything aligned? Give me a coverage map of requirements to tasks."
+    why: "Asking for alignment plus a requirement-to-task coverage map immediately before the implement phase is precisely the analyze hand-off."
+
+# NEAR-MISS prompts that must NOT load `analyze`. Each routes to the genuinely
+# correct sibling that exists in this repo. The recurring trap: anything that
+# RESOLVES, BUILDS, or RUNS rather than reports, and anything that inspects code
+# rather than the SDD planning artifacts.
+should_not_trigger:
+  - prompt: "The login test is failing with a 500 and I can't tell why — help me find the root cause."
+    route_to: "secure-coding"
+    why: "A failing test / runtime fault is root-cause debugging on code, not a planning-artifact cross-check; analyze never opens source files. (Routes to the nearest existing repo skill for the auth fault.)"
+
+  - prompt: "Run the lint, type-check and test suite and tell me if the FastAPI service is ready to ship."
+    route_to: "fastapi"
+    why: "Running lint/types/tests on built code is the post-implementation verification gate via the stack skill — analyze is pre-implementation and runs nothing."
+
+  - prompt: "Write the technical implementation plan for the payments feature from this spec."
+    route_to: "fastapi"
+    why: "Authoring the plan/architecture is plan-phase work delegated to the stack skill; analyze checks an existing plan, it does not write one."
+
+  - prompt: "Review this pull request diff for correctness bugs and cleanups."
+    route_to: "secure-coding"
+    why: "Adversarial review of a code diff is code review, not a constitution/spec/plan/tasks consistency report on planning artifacts."
+
+  - prompt: "Audit my workspace and set up docs/tools and docs/ with a Knowledge map."
+    route_to: "harness"
+    why: "Bootstrapping the workspace control plane is the harness's job; analyze only reads the SDD artifacts the harness's docs/ layer happens to store."
+
+  - prompt: "Profile why the Postgres query in the dashboard is slow and propose an index."
+    route_to: "postgresdb"
+    why: "Query performance and indexing is database engineering on real code/SQL, not a pre-implementation artifact cross-check."
+
+# Concrete tasks the skill should guide, with a rubric to grade WITH vs WITHOUT
+# the skill loaded. A correct skill-guided answer reports and routes; an
+# ungrounded answer typically starts editing artifacts or jumps to coding.
+capability:
+  - scenario: "I have constitution.md, a spec, a plan and a task list under .specify/ for a 'team invites' feature. The constitution says 'Postgres only, every endpoint rate-limited'. The spec requires email invites with a 5/min rate limit and invite expiry after 7 days. The plan adds a Redis-backed cache nobody asked for and is silent on rate limiting. The tasks cover sending invites and expiry but have no task for rate limiting and no done-check on the expiry task. Run the gate."
+    must_include:
+      - "Reports only and resolves nothing: explicitly does NOT edit the spec/plan/tasks and writes no code; hands each finding back to the user to resolve."
+      - "Reads the register from AGENTS.md and writes the report in that register (or notes no profile and uses analogies), with every finding in one line."
+      - "Runs all six analyses (constitution compliance, coverage, scope drift, contradiction, duplication, ambiguity), not just coverage."
+      - "Flags the missing rate-limit task as a coverage GAP and as a CONSTITUTION violation (constitution requires every endpoint rate-limited) — marks it CRITICAL/HIGH and routes it to the tasks/plan phase."
+      - "Flags the Redis cache as scope DRIFT (no spec requirement behind it) and notes the resolution is the user's call: cut it or amend the spec."
+      - "Flags the expiry task's missing done-check as AMBIGUOUS and routes it to the tasks phase; flags any vague requirement to clarify."
+      - "Builds a requirement-coverage map (REQ -> plan section -> task -> status) marking covered / GAP / DRIFT / AMBIGUOUS."
+      - "Emits a verdict line (GATE: BLOCKED here, with CRITICAL/HIGH counts) and writes the report to specs/<slug>/analysis.md indexed in the Knowledge map."
+      - "Ends by pointing to the next phase: route the blocking findings back to their owning phases, resolve, re-run analyze; only on PASS proceed to implement."

package/skills/shared/angular/SKILL.md

@@ -0,0 +1,275 @@
+---
+name: angular
+description: "Use when building, refactoring, or debugging Angular (v20/21+): standalone components, signals, zoneless change detection, @if/@for/@defer control flow, inject() DI, resource()/httpResource(), RxJS interop, NgRx SignalStore, ng CLI. NOT React (that is react), NOT Next.js (that is nextjs), NOT a TypeScript language question (that is typescript)."
+tags: [angular, frontend, web, signals, typescript, spa]
+recommends: [typescript, testing-web, secure-coding]
+origin: ai-hub
+---
+
+# Angular — Standalone, Signals, Zoneless (Angular 20/21+)
+
+> Build Angular the way it ships in 2026: standalone components, signals as the reactivity model, zoneless change detection, built-in control flow, and `inject()` DI. Treat NgModules, `*ngFor`, and `@Input()` decorators as legacy you only touch to migrate.
+
+## Not this skill
+
+**AngularJS (1.x)** is out of scope entirely — this skill is Angular 2+ only and the APIs do not map.
+Route elsewhere for **React** → `../react/SKILL.md`; **Next.js App Router** → `../nextjs/SKILL.md`;
+**Vue/Nuxt, Svelte, SolidJS, Astro** → `../vue-nuxt/SKILL.md`, `../svelte/SKILL.md`,
+`../solid-js/SKILL.md`, `../astro/SKILL.md`; a **pure TypeScript language question** (generics,
+narrowing, tsconfig) with no Angular dimension → `../typescript/SKILL.md`; a **standalone NestJS
+API** → `../nestjs/SKILL.md`; a generic Node service → `../nodejs/SKILL.md`; **cross-framework
+Playwright e2e strategy** → `../testing-web/SKILL.md` / `../e2e-testing/SKILL.md`. Angular Universal
+SSR and Angular's own `ng test` (Vitest) setup stay here.
+
+## Decide first
+
+| Situation | Do this | Why |
+|-----------|---------|-----|
+| Greenfield app / new feature | Zoneless + signals + standalone by default. `ng new` (Angular 21) already excludes Zone.js. | The defaults shipped stable in v20-v21; fight them and you write more code that the framework now does for you. |
+| Brownfield NgModule + decorator app | Migrate incrementally with the schematics in `references/migration.md` (NgModule→standalone, control flow, decorator→signal inputs, Zone.js→zoneless, Karma→Vitest); do not rewrite. Keep Zone.js until you flip it on purpose. | A working app that uses `*ngIf` is not a bug. Churn introduces risk for no user value. |
+| "View not updating" complaint | Jump to the change-detection section: signal not read in template, `OnPush` without a signal, or stale Zone.js assumption. | Zoneless means a mutation that no signal observes will never repaint — the fix is structural, not a `detectChanges()` call. |
+
+## The modern baseline
+
+No NgModules. Bootstrap a standalone root component and configure providers in `app.config.ts`.
+
+```typescript
+// main.ts
+import { bootstrapApplication } from '@angular/platform-browser';
+import { App } from './app/app';
+import { appConfig } from './app/app.config';
+
+bootstrapApplication(App, appConfig);
+```
+
+```typescript
+// app/app.config.ts
+import { ApplicationConfig, provideZonelessChangeDetection } from '@angular/core';
+import { provideRouter } from '@angular/router';
+import { provideHttpClient, withFetch } from '@angular/common/http';
+import { routes } from './app.routes';
+
+export const appConfig: ApplicationConfig = {
+  providers: [
+    provideZonelessChangeDetection(), // no Zone.js; CD driven by signals + events
+    provideRouter(routes),
+    provideHttpClient(withFetch()),
+  ],
+};
+```
+
+- Rule: one `bootstrapApplication` call, providers in `app.config.ts`. Why: NgModule bootstrap (`platformBrowserDynamic().bootstrapModule(AppModule)`) is the legacy path — more files, slower to reason about.
+- Rule: components are `standalone` by default (the `standalone` flag is implied in v20+; do not write `standalone: true` in new code, and never write `standalone: false`). Why: standalone is the framework default now; the flag is noise.
+
+**Bad → Good**
+
+```typescript
+// Bad — NgModule wiring for a single component
+@NgModule({ declarations: [UserCard], imports: [CommonModule], exports: [UserCard] })
+export class UserCardModule {}
+
+// Good — standalone component imports only what it uses
+@Component({
+  selector: 'app-user-card',
+  imports: [DatePipe],
+  template: `<p>{{ joined() | date }}</p>`,
+})
+export class UserCard {
+  joined = input.required<Date>();
+}
+```
+
+## Signals as the reactivity model
+
+`signal()` holds state, `computed()` derives it, `effect()` runs side effects, `linkedSignal()` resets writable state when a source changes.
+
+```typescript
+import { signal, computed, effect, linkedSignal } from '@angular/core';
+
+const qty = signal(1);
+const price = signal(9.99);
+const total = computed(() => qty() * price());        // derived — recomputes lazily
+const draftQty = linkedSignal(() => qty());            // writable, resets when qty changes
+
+effect(() => console.log('total changed:', total())); // side effect ONLY (logging, DOM, sync)
+```
+
+- Rule: derive with `computed()`, never with `effect()`. Why: an `effect()` that writes a signal to "compute" a value creates a hidden dependency graph that loops or fires extra times — `computed()` is pull-based and memoized.
+- Rule: `effect()` is for side effects (logging, `localStorage`, imperative DOM, 3rd-party libs), not for keeping two signals in sync. Why: synced state belongs in `computed()` or `linkedSignal()`.
+
+Component I/O is signal-based: `input()`, `input.required()`, `output()`, `model()` for two-way.
+
+**Bad → Good**
+
+```typescript
+// Bad — decorator I/O, mutable, no type-safety on required
+@Input() userId!: string;
+@Output() saved = new EventEmitter<User>();
+
+// Good — signal inputs/outputs
+userId = input.required<string>();          // read as userId()
+saved = output<User>();                     // emit with saved.emit(user)
+name = model('');                           // two-way: [(name)]="..."
+```
+
+## Templates: built-in control flow
+
+Use `@if` / `@for` / `@switch` / `@defer`. The legacy `*ngIf` / `*ngFor` / `*ngSwitch` structural directives are deprecated.
+
+```html
+@if (user(); as u) {
+  <h1>{{ u.name }}</h1>
+} @else {
+  <app-spinner />
+}
+
+@for (item of items(); track item.id) {
+  <li>{{ item.label }}</li>
+} @empty {
+  <li>No items</li>
+}
+
+@defer (on viewport) {
+  <app-heavy-chart [data]="rows()" />
+} @placeholder {
+  <div class="skeleton"></div>
+}
+```
+
+- Rule: every `@for` **must** declare `track`. Why: it is required syntax (the template won't compile without it) and it controls DOM reuse — `track item.id` over `track $index` when items have stable identity, or the DOM thrashes on reorder.
+- Rule: reach for `@defer` to lazy-load heavy sub-trees and enable incremental hydration. Why: it ships less JS up front without manual `loadComponent` plumbing.
+
+**Bad → Good**
+
+```html
+<!-- Bad — legacy structural directive, no tracking -->
+<li *ngFor="let item of items">{{ item.label }}</li>
+
+<!-- Good — built-in control flow with track -->
+@for (item of items(); track item.id) { <li>{{ item.label }}</li> }
+```
+
+## Data fetching
+
+Default to signal-based resources; reach for `HttpClient` + RxJS only when you need streams, cancellation, or operator composition.
+
+```typescript
+import { httpResource } from '@angular/common/http';
+import { resource } from '@angular/core';
+
+// httpResource — declarative GET wired to HttpClient; reactive to its URL signal
+users = httpResource<User[]>(() => `/api/users?team=${this.team()}`);
+// template: @if (users.isLoading()) {…} @else { @for (u of users.value(); track u.id) {…} }
+// users.error()  -> error signal;  users.reload() -> refetch
+
+// resource — any async loader (not just HTTP)
+profile = resource({
+  params: () => ({ id: this.userId() }),
+  loader: ({ params }) => fetchProfile(params.id),
+});
+```
+
+- Rule: `httpResource()`/`resource()` give you `value()`, `isLoading()`, `error()`, `reload()` for free — prefer them over a manual `subscribe` that you have to clean up. Why: less boilerplate, no leak, refetches automatically when its source signals change.
+- Rule: when you genuinely need a stream (websocket, debounced search, retry/switchMap), keep `HttpClient` + RxJS and bridge to a signal with `toSignal()`. Why: signals are not streams; do not fake backpressure with effects. `references/signals-rxjs.md` has the signals-vs-RxJS decision matrix, `toSignal`/`toObservable` interop recipes, `effect` pitfalls (infinite loops, untracked reads), and `takeUntilDestroyed`.
+
+## DI & services
+
+```typescript
+@Injectable({ providedIn: 'root' })
+export class UserApi {
+  private http = inject(HttpClient);          // field initializer — no constructor needed
+  list = () => this.http.get<User[]>('/api/users');
+}
+```
+
+- Rule: inject with `inject()`, not constructor parameters. Why: `inject()` works in field initializers and composes into plain functions (guards, factories); constructor DI is the legacy ergonomic.
+- Rule: `providedIn: 'root'` for app-wide singletons. Why: tree-shakable — unused services drop from the bundle.
+- Rule: HTTP cross-cutting concerns are functional interceptors: `provideHttpClient(withInterceptors([authInterceptor]))`. Why: class interceptors with `HTTP_INTERCEPTORS` are the older multi-provider pattern.
+
+## Routing
+
+```typescript
+// app.routes.ts
+export const routes: Routes = [
+  { path: 'users', loadComponent: () => import('./users/users-list').then(m => m.UsersList) },
+  { path: 'users/:id', loadComponent: () => import('./users/user-detail').then(m => m.UserDetail),
+    canActivate: [authGuard] },
+];
+
+export const authGuard: CanActivateFn = () => inject(AuthService).isLoggedIn();
+```
+
+Enable route-bound signal inputs with `withComponentInputBinding()` in `provideRouter`, then read route params as signal inputs:
+
+```typescript
+provideRouter(routes, withComponentInputBinding());
+// in UserDetail: id = input.required<string>();  // bound from the :id segment
+```
+
+- Rule: lazy-load routes with `loadComponent` (or `loadChildren` with a routes array). Why: smaller initial bundle, no NgModule needed.
+- Rule: guards/resolvers are functions (`CanActivateFn`, `ResolveFn`) using `inject()`. Why: class-based guards are deprecated.
+
+## State
+
+- Local/feature state → a signal service (`@Injectable` holding `signal`/`computed`). Simple, no library.
+- App-wide state → **NgRx SignalStore** (`signalStore`, `withState`, `withComputed`, `withMethods`, `withProps`) — signals-native, pairs cleanly with `resource()`.
+
+```typescript
+export const CartStore = signalStore(
+  { providedIn: 'root' },
+  withState({ items: [] as Item[] }),
+  withComputed(({ items }) => ({ count: computed(() => items().length) })),
+  withMethods((store) => ({ add: (i: Item) => patchState(store, s => ({ items: [...s.items, i] })) })),
+);
+```
+
+- Note: **Signal Forms** is experimental (prototype since Angular 21.0.0-next.2). For production forms use reactive/typed forms (`FormGroup`/`FormControl` with typed values). Why: do not ship a prototype API to users.
+
+## CLI workflow
+
+```bash
+ng new my-app                  # Angular 21: zoneless + standalone + Vitest by default
+ng generate component user-card # standalone by default; no --standalone flag needed
+ng generate service user-api
+ng build                       # production build
+ng test                        # Vitest (default runner in v21; Karma is deprecated)
+ng update @angular/core @angular/cli  # version bumps + automated migrations
+```
+
+## Testing
+
+Use Vitest + `TestBed`. Provide zoneless CD in tests and set signal inputs via `componentRef`.
+
+```typescript
+import { TestBed } from '@angular/core/testing';
+import { provideZonelessChangeDetection } from '@angular/core';
+
+it('renders the user name', async () => {
+  TestBed.configureTestingModule({
+    providers: [provideZonelessChangeDetection()],
+  });
+  const fixture = TestBed.createComponent(UserCard);
+  fixture.componentRef.setInput('joined', new Date('2026-01-01'));
+  await fixture.whenStable();                       // not detectChanges() — let CD settle
+  expect(fixture.nativeElement.textContent).toContain('2026');
+});
+```
+
+- Rule: set signal inputs with `fixture.componentRef.setInput('name', value)`, never by poking the instance field. Why: `setInput` flows through the input pipeline and marks the view dirty.
+- Rule: prefer `await fixture.whenStable()` over manual `detectChanges()` loops under zoneless. Why: it waits for the scheduler to flush instead of forcing a single synchronous pass.
+
+## Anti-patterns
+
+| Bad | Why it's wrong | Good |
+|-----|----------------|------|
+| `@NgModule` in new code | Standalone is the default; modules add ceremony and slow analysis | Standalone component with an `imports: []` array |
+| `*ngIf` / `*ngFor` / `*ngSwitch` | Legacy structural directives; deprecated | `@if` / `@for (… ; track id)` / `@switch` |
+| `@Input()` / `@Output()` decorators | No required-input safety, not signal-reactive | `input()` / `input.required()` / `output()` / `model()` |
+| `effect(() => this.total.set(a()*b()))` | Effect-to-derive-state loops and double-fires | `total = computed(() => a()*b())` |
+| `@for` without `track` | Won't compile; if forced, DOM thrashes on reorder | `track item.id` (stable identity) |
+| `subscribe()` in a component with no teardown | Memory leak; runs after the view is destroyed | `toSignal()` or `takeUntilDestroyed()` |
+| `ChangeDetectorRef.detectChanges()` to "fix" a stale view | Masks the real cause under zoneless | Read the value through a signal so CD tracks it |
+| Nested `subscribe()` inside `subscribe()` | Callback pyramid, lost cancellation | `switchMap`/`concatMap`, one subscription |
+| Constructor DI only (`constructor(private x: X)`) | Legacy ergonomic; can't compose into functions | `private x = inject(X)` |
+
+`scripts/verify.sh` is a heuristic copy-banlist lint — it greps your Angular sources for the banned patterns above. It is a hint, not a compiler.

package/skills/shared/angular/evals/README.md

@@ -0,0 +1,3 @@
+# angular evals
+
+Trigger and capability checks for modern Angular work.

package/skills/shared/angular/evals/cases.yaml

@@ -0,0 +1,38 @@
+skill: angular
+
+should_trigger:
+  - prompt: "Migrate this Angular app from NgModules to standalone components."
+    why: "Standalone migration is central modern Angular work."
+  - prompt: "Why is my Angular view not updating in zoneless mode?"
+    why: "Zoneless change detection and signals are Angular-specific."
+  - prompt: "Replace *ngFor with @for and track expressions."
+    why: "Built-in control flow migration belongs to Angular."
+  - prompt: "Use input() signals instead of decorator @Input in this component."
+    why: "Signal inputs are Angular-specific."
+  - prompt: "Monta una app Angular con componente standalone y signals."
+    why: "Spanish Angular standalone/signals request triggers this skill."
+
+should_not_trigger:
+  - prompt: "Fix a React hook state bug."
+    route_to: "react"
+    why: "React hooks are not Angular."
+  - prompt: "Implement a Next.js server component."
+    route_to: "nextjs"
+    why: "Next.js App Router/React Server Components is a separate stack."
+  - prompt: "Explain TypeScript conditional types."
+    route_to: "typescript"
+    why: "Pure TypeScript without Angular belongs to TypeScript."
+  - prompt: "Build a NestJS backend module."
+    route_to: "nestjs"
+    why: "NestJS is backend DI; Angular is frontend framework."
+
+capability:
+  - scenario: "A brownfield Angular app uses NgModules, decorator inputs and Zone.js; the user wants a safe modern migration."
+    must_include:
+      - "Detects Angular version and brownfield vs greenfield before changing architecture."
+      - "Migrates incrementally to standalone components rather than rewriting everything."
+      - "Uses signals/input() and built-in @if/@for/@defer control flow where appropriate."
+      - "Explains zoneless change detection and avoids detectChanges() as a default patch."
+      - "Keeps providers in app.config.ts/provide* APIs for modern bootstrap."
+      - "Uses RxJS interop deliberately with toSignal/toObservable when needed."
+      - "Routes pure TypeScript or backend NestJS questions to those skills."