npm install -g --ignore-scripts @earendil-works/pi-coding-agent

http://localhost:1234/v1

{
  "providers": {
    "lmstudio": {
      "baseUrl": "http://localhost:1234/v1",
      "api": "openai-completions",
      "apiKey": "lm-studio",
      "compat": {
        "supportsDeveloperRole": false,
        "supportsReasoningEffort": false
      },
      "models": [
        { "id": "qwen2.5-coder-14b-instruct" }
      ]
    }
  }
}

pi --list-models | grep lmstudio

pi --model lmstudio/qwen2.5-coder-14b-instruct

mkdir -p ~/.pi/agent/skills/{code-review,coding,angular-21,mail-agent}

---
name: code-review
description: Review code changes for correctness, security, performance and maintainability. Use when asked to review a PR, a diff, a commit, or a specific file.
---

# Code Review

## Workflow
1. Run `git diff` (or read the changed files) to see exactly what changed.
2. Read enough surrounding code to understand the context.
3. Check the items below, in order.
4. Report findings grouped by severity.

## Checklist
- **Correctness** — edge cases, off-by-one, null/undefined, error handling, async/await, races.
- **Security** — injection, secrets, unsafe input, path traversal, broken authz.
- **Performance** — unnecessary work in loops, N+1 queries, memory leaks, blocking calls.
- **Maintainability** — naming, duplication, function size, dead code, missing types.
- **Tests** — are the key paths covered? did the change break existing behavior?

## Output format
- **Summary** — one or two sentences.
- **Blocking** — must fix before merge.
- **Non-blocking** — nice to have.
- **Suggested diff** — concrete fix, never just a description.

Be specific: reference file, line, and why it matters. Do not nitpick style unless it affects readability.

---
name: coding
description: General coding assistant workflow. Use when writing, refactoring, explaining, or fixing code in any language.
---

# Coding

## Principles
- Read existing code before changing it; match its conventions.
- Prefer small, pure functions with clear names.
- Handle errors explicitly; never swallow exceptions silently.
- Add types (or docstrings) on public interfaces.
- Keep changes minimal and focused; do not refactor unrelated code.

## Workflow
1. Restate the task and confirm the acceptance criteria.
2. Explore the relevant files (`read`, `grep`, `find`).
3. Propose the plan, then implement with `edit`/`write`.
4. Run the project's checks (tests, linter, build) before declaring done.
5. Summarize what changed and any manual verification steps.

## When unsure
- Ask a clarifying question instead of guessing.
- Prefer the simplest solution that satisfies the requirements.
- If the project has an `AGENTS.md`, follow it strictly.

---
name: angular-21
description: Angular 21+ conventions and patterns. Use when working on Angular components, services, templates, signals, dependency injection, or routing.
---

# Angular 21+

## Standalone & DI
- Components are standalone by default; do not create NgModules for new code.
- Use `inject()` instead of constructor injection.
- Prefer `provide*` functions in `app.config.ts` (e.g. `provideHttpClient`, `provideRouter`).

## Signals (preferred over RxJS for state)
- Use `signal`, `computed`, and `effect` for local state.
- Use `input()`, `output()`, `model()` for component APIs instead of `@Input`/`@Output`.
- Keep the app zoneless: avoid mutating state outside signals.
- Interop only when needed: `toSignal` / `toObservable`.

## Templates
- Use the new control flow: `@if`, `@for` (with `track`), `@switch`.
- Use `@defer` to lazy-load heavy parts of a template.
- Prefer `let` bindings and signal reads over method calls in templates.

## RxJS & HTTP
- Use the new signals-based `httpResource` for declarative HTTP when available.
- Keep `AsyncPipe` usage where observables remain; prefer signals for new code.

## Style
- Use `OnPush`/zoneless change detection; avoid `ChangeDetectorRef` hacks.
- Strong typing: no `any`, prefer `interface` and generics.
- Small, focused components; move logic to services or stores.
- Follow the Angular Style Guide naming (`*.component.ts`, `*.service.ts`).

---
name: mail-agent
description: Draft, reply to and polish emails. Use when asked to write, answer, or improve an email or message.
---

# Mail Agent

## Workflow
1. Ask for recipient, context and goal if not provided.
2. Draft the email following the structure below.
3. Keep it short: one topic, one clear call to action.

## Structure
- **Subject** — specific and honest (4–8 words).
- **Greeting** — match the relationship (formal/informal).
- **Body** — context in 1–2 sentences, then the request/answer.
- **Call to action** — what you need and by when.
- **Signature** — name, role, and optional contact.

## Tone rules
- Professional, warm, no jargon.
- Never passive-aggressive; reframe complaints as requests.
- For replies: quote only the relevant part, answer point by point.

## Safety
- Draft text only by default; do not send email automatically.
- If a send script exists (`./scripts/send.sh`), run it only after the user explicitly confirms the final draft.

## Example

Subject: Follow-up on the Angular migration review

Hi Marco,

just following up on the migration review we discussed on Monday. Could you have a look at the open PR by Thursday so we can unblock the release?

Thanks,
[Your name]

/skill:code-review
/skill:angular-21

Review the last commit for security issues.

Add a standalone component with signals that fetches a list of users with httpResource.

Draft a polite follow-up email to the team about the delayed release.