Consolidated commit message to v22 signals
This commit is contained in:
@@ -0,0 +1,31 @@
|
||||
{
|
||||
"mcpServers": {
|
||||
"postgres-db": {
|
||||
"command": "npx",
|
||||
"args": [
|
||||
"-y",
|
||||
"@modelcontextprotocol/server-postgres",
|
||||
"${POSTGRES_URL}"
|
||||
],
|
||||
"env": {
|
||||
"POSTGRES_URL": "${env:SQLALCHEMY_DATABASE_URI}"
|
||||
}
|
||||
},
|
||||
"filesystem": {
|
||||
"command": "npx",
|
||||
"args": [
|
||||
"-y",
|
||||
"@modelcontextprotocol/server-filesystem",
|
||||
"."
|
||||
]
|
||||
},
|
||||
"angular-cli": {
|
||||
"command": "npx",
|
||||
"args": [
|
||||
"-y",
|
||||
"@angular/cli",
|
||||
"mcp"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,30 @@
|
||||
# Project Architecture & Guidelines
|
||||
|
||||
## Monorepo Layout
|
||||
- **Backend**: `./brewman` (Python, managed via `uv`)
|
||||
- **Frontend**: `./overlord` (Angular, managed via `npm`/`ng`)
|
||||
- **Environment**: Root `.env` file containing shared/database variables.
|
||||
|
||||
---
|
||||
|
||||
## Execution Rules & Commands
|
||||
|
||||
### Backend (`/brewman`)
|
||||
- **Working Directory**: Always execute backend commands within `./brewman` OR pass `--directory brewman` to `uv`.
|
||||
- **Package & Script Management**:
|
||||
- Use `uv` exclusively. Never run bare `pip` or global `python`.
|
||||
- Run scripts/tests: `uv run python <script>` or `uv run pytest` from inside `./brewman`.
|
||||
- Manage dependencies: `uv add <package>` or `uv remove <package>`.
|
||||
- **Environment**: The root `.env` file (`../.env` relative to `brewman`) contains the database connection string and secret keys.
|
||||
|
||||
### Frontend (`/overlord`)
|
||||
- **Working Directory**: Always execute frontend commands within `./overlord`.
|
||||
- **Commands**:
|
||||
- Run dev server: `npm start` or `ng serve`
|
||||
- Code generation: `ng g c components/<name>` (prefer standalone components)
|
||||
- Testing: `ng test --watch=false`
|
||||
- Build: `ng build`
|
||||
|
||||
### Database (PostgreSQL)
|
||||
- Database settings are defined in the root `.env`.
|
||||
- Inspect schema, run migrations, or check types strictly via database tools or `uv run` scripts inside `./brewman`.
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
trigger: glob
|
||||
globs: ./bookie/**/**
|
||||
---
|
||||
|
||||
# Persona
|
||||
|
||||
You are a dedicated Angular developer who thrives on leveraging the absolute latest features of the framework to build cutting-edge applications. You are currently immersed in Angular v20+, passionately adopting signals for reactive state management, embracing standalone components for streamlined architecture, and utilizing the new control flow for more intuitive template logic. Performance is paramount to you, who constantly seeks to optimize change detection and improve user experience through these modern Angular paradigms. When prompted, assume You are familiar with all the newest APIs and best practices, valuing clean, efficient, and maintainable code.
|
||||
|
||||
## Examples
|
||||
|
||||
These are modern examples of how to write an Angular 20 component with signals
|
||||
|
||||
```ts
|
||||
import { ChangeDetectionStrategy, Component, signal } from '@angular/core';
|
||||
|
||||
|
||||
@Component({
|
||||
selector: '{{tag-name}}-root',
|
||||
templateUrl: '{{tag-name}}.html',
|
||||
})
|
||||
export class {{ClassName}} {
|
||||
protected readonly isServerRunning = signal(true);
|
||||
toggleServerStatus() {
|
||||
this.isServerRunning.update(isServerRunning => !isServerRunning);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```css
|
||||
.container {
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
height: 100vh;
|
||||
|
||||
button {
|
||||
margin-top: 10px;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```html
|
||||
<section class="container">
|
||||
@if (isServerRunning()) {
|
||||
<span>Yes, the server is running</span>
|
||||
} @else {
|
||||
<span>No, the server is not running</span>
|
||||
}
|
||||
<button (click)="toggleServerStatus()">Toggle Server Status</button>
|
||||
</section>
|
||||
```
|
||||
|
||||
When you update a component, be sure to put the logic in the ts file, the styles in the css file and the html template in the html file.
|
||||
|
||||
## Resources
|
||||
|
||||
Here are the some links to the essentials for building Angular applications. Use these to get an understanding of how some of the core functionality works
|
||||
https://angular.dev/essentials/components
|
||||
https://angular.dev/essentials/signals
|
||||
https://angular.dev/essentials/templates
|
||||
https://angular.dev/essentials/dependency-injection
|
||||
|
||||
## Best practices & Style guide
|
||||
|
||||
Here are the best practices and the style guide information.
|
||||
|
||||
### Coding Style guide
|
||||
|
||||
Here is a link to the most recent Angular style guide https://angular.dev/style-guide
|
||||
|
||||
### TypeScript Best Practices
|
||||
|
||||
- Use strict type checking
|
||||
- Prefer type inference when the type is obvious
|
||||
- Avoid the `any` type; use `unknown` when type is uncertain
|
||||
|
||||
### Angular Best Practices
|
||||
|
||||
- Always use standalone components over `NgModules`
|
||||
- Do NOT set `standalone: true` inside the `@Component`, `@Directive` and `@Pipe` decorators
|
||||
- Use signals for state management
|
||||
- Implement lazy loading for feature routes
|
||||
- Use `NgOptimizedImage` for all static images.
|
||||
- Do NOT use the `@HostBinding` and `@HostListener` decorators. Put host bindings inside the `host` object of the `@Component` or `@Directive` decorator instead
|
||||
|
||||
### Components
|
||||
|
||||
- Keep components small and focused on a single responsibility
|
||||
- Use `input()` signal instead of decorators, learn more here https://angular.dev/guide/components/inputs
|
||||
- Use `output()` function instead of decorators, learn more here https://angular.dev/guide/components/outputs
|
||||
- Use `computed()` for derived state learn more about signals here https://angular.dev/guide/signals.
|
||||
- Prefer inline templates for small components
|
||||
- Prefer Reactive forms instead of Template-driven ones
|
||||
- Do NOT use `ngClass`, use `class` bindings instead, for context: https://angular.dev/guide/templates/binding#css-class-and-style-property-bindings
|
||||
- Do NOT use `ngStyle`, use `style` bindings instead, for context: https://angular.dev/guide/templates/binding#css-class-and-style-property-bindings
|
||||
|
||||
### State Management
|
||||
|
||||
- Use signals for local component state
|
||||
- Use `computed()` for derived state
|
||||
- Keep state transformations pure and predictable
|
||||
- Do NOT use `mutate` on signals, use `update` or `set` instead
|
||||
|
||||
### Templates
|
||||
|
||||
- Keep templates simple and avoid complex logic
|
||||
- Use native control flow (`@if`, `@for`, `@switch`) instead of `*ngIf`, `*ngFor`, `*ngSwitch`
|
||||
- Use the async pipe to handle observables
|
||||
- Use built in pipes and import pipes when being used in a template, learn more https://angular.dev/guide/templates/pipes#
|
||||
|
||||
### Services
|
||||
|
||||
- Design services around a single responsibility
|
||||
- Use the `providedIn: 'root'` option for singleton services
|
||||
- Use the `inject()` function instead of constructor injection
|
||||
@@ -0,0 +1,17 @@
|
||||
---
|
||||
name: angular-signals
|
||||
description: Writes modern Angular code using Standalone Components and Signals. Use whenever generating frontend UI or state logic.
|
||||
---
|
||||
# Modern Angular Standards
|
||||
|
||||
## Architecture
|
||||
- NEVER generate or use `NgModule`.
|
||||
- ALL components, directives, and pipes must be `standalone: true`.
|
||||
|
||||
## State Management (Signals)
|
||||
- Prefer Angular Signals (`signal()`, `computed()`, `effect()`) for synchronous, local component state instead of `BehaviorSubject`.
|
||||
- Use the new Signal-based inputs and outputs: `input()` and `output()` instead of `@Input()` and `@Output()`.
|
||||
- Use standard RxJS strictly for asynchronous streams (e.g., HTTP requests, router events).
|
||||
|
||||
## Control Flow
|
||||
- Use the new built-in control flow (`@if`, `@for`, `@switch`) instead of structural directives (`*ngIf`, `*ngFor`).
|
||||
@@ -0,0 +1,16 @@
|
||||
---
|
||||
name: fastapi-pydantic-v2
|
||||
description: Writes modern FastAPI endpoints using Pydantic v2 syntax and Annotated dependencies. Use whenever generating or refactoring API routes.
|
||||
---
|
||||
# FastAPI & Pydantic v2 Standards
|
||||
|
||||
## Pydantic v2 Rules
|
||||
- NEVER use `.dict()` or `.json()`. ALWAYS use `.model_dump()` and `.model_dump_json()`.
|
||||
- NEVER use `@validator` or `@root_validator`. ALWAYS use `@field_validator` and `@model_validator(mode="before|after")`.
|
||||
- NEVER use `schema_extra`. Use `json_schema_extra` inside the `model_config` dict.
|
||||
- Use `pydantic_settings.BaseSettings` for all environment variable configurations.
|
||||
|
||||
## FastAPI Rules
|
||||
- ALWAYS use `typing.Annotated` for dependency injection (e.g., `db: Annotated[AsyncSession, Depends(get_db)]`).
|
||||
- Do not use `def` for endpoints that perform I/O; always use `async def`.
|
||||
- Raise `fastapi.HTTPException` for expected client errors instead of returning standard dictionaries.
|
||||
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"kind": "tool-skill",
|
||||
"version": "0.0.19"
|
||||
}
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: library-skills
|
||||
description: Use Library Skills to discover, install, refresh, repair, check, and manage agent skills from installed packages.
|
||||
---
|
||||
|
||||
# Library Skills
|
||||
|
||||
Use this skill when a project might benefit from agent skills bundled by its installed packages, or when existing Library Skills-managed symlinks are stale, broken, orphaned, or need to be checked.
|
||||
|
||||
Run commands from the project root.
|
||||
|
||||
Agents bundle their own skills by including an `.agents/skills` directory. More details in [Library Skills](https://library-skills.io).
|
||||
|
||||
## First-Time Setup
|
||||
|
||||
- Make sure project dependencies are installed first, for example with `uv sync` for Python projects or `npm install` / `bun install` for Node.js projects.
|
||||
- Run `uvx library-skills` or `npx library-skills` to discover skills bundled by the installed packages and install selected skills interactively.
|
||||
- Use `uvx library-skills --all` or `npx library-skills --all` only when all newly discovered skills should be installed without selecting individual skills.
|
||||
- Use `uvx library-skills --tool-skill` or `npx library-skills --tool-skill` to copy this Library Skills tool skill into the project so future agents know how to discover, install, update, repair, and check skills.
|
||||
|
||||
## Commands
|
||||
|
||||
- Run `uvx library-skills` or `npx library-skills` to discover package-provided skills, install selected new skills, and reconcile existing managed symlinks.
|
||||
- Run `uvx library-skills list` or `npx library-skills list` to inspect discovered and installed skills.
|
||||
- Run `uvx library-skills list --json` or `npx library-skills list --json` for machine-readable installed status.
|
||||
- Run `uvx library-skills scan --json` or `npx library-skills scan --json` for discovery-only automation.
|
||||
- Run `uvx library-skills --check` or `npx library-skills --check` to validate managed skill symlink state without changing files.
|
||||
- Run `uvx library-skills --yes` or `npx library-skills --yes` to repair stale managed symlinks and remove orphaned managed symlinks non-interactively.
|
||||
- Add `--claude` when `.claude/skills` should also be managed.
|
||||
- Add `--skill NAME` to install a specific discovered skill by name.
|
||||
|
||||
## Safety
|
||||
|
||||
- Prefer rerunning `library-skills` over editing managed symlinks manually.
|
||||
- If installed skill symlinks are broken, dependencies may not be installed yet. Try the project's normal install command first, such as `uv sync`, `npm install`, or `bun install`, then rerun `library-skills`.
|
||||
- Do not delete or overwrite hand-authored skill directories.
|
||||
- Library Skills only removes managed symlinks. It should not remove copied or hand-authored skill directories.
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
name: sqlalchemy-async
|
||||
description: Writes SQLAlchemy 2.0 async database queries using Psycopg3. Use whenever interacting with the PostgreSQL database.
|
||||
---
|
||||
# SQLAlchemy 2.0 Async Standards
|
||||
|
||||
## Model Definitions
|
||||
- ALWAYS use SQLAlchemy 2.0 Declarative Base with `Mapped` and `mapped_column`.
|
||||
- Example: `id: Mapped[int] = mapped_column(primary_key=True)`
|
||||
- NEVER use the old `Column(Integer, primary_key=True)` syntax.
|
||||
|
||||
## Querying
|
||||
- NEVER use `session.query()`. This is legacy 1.x syntax.
|
||||
- ALWAYS use `sqlalchemy.select()` combined with `await session.execute(stmt)`.
|
||||
- Extract results using `.scalars().all()` or `.scalar_one_or_none()`.
|
||||
|
||||
## Session Management
|
||||
- Use `sqlalchemy.ext.asyncio.AsyncSession`.
|
||||
- Ensure all database I/O is awaited.
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
name: strict-mypy
|
||||
description: Enforces strict MyPy type checking conventions matching the project's pyproject.toml configuration. Use whenever writing or modifying Python code.
|
||||
---
|
||||
# Strict MyPy Typing Standards
|
||||
|
||||
This project uses a highly strict MyPy configuration (`strict = true`). When writing or refactoring Python code, you MUST adhere to the following rules to ensure the code passes type checking:
|
||||
|
||||
## 1. Absolute Signature Completeness
|
||||
- EVERY function and method must have fully typed arguments and a return type (`disallow_untyped_defs`, `disallow_incomplete_defs`).
|
||||
- ALWAYS specify `-> None` for functions and methods that do not return a value.
|
||||
- NEVER leave type hints partially defined (e.g., typing only some arguments).
|
||||
- Decorators must be completely type-hinted using `typing.Callable` or `typing.ParamSpec` (`disallow_untyped_decorators`).
|
||||
|
||||
## 2. No Implicit Optionals
|
||||
- `arg: str = None` is strictly forbidden.
|
||||
- You MUST explicitly union with None: `arg: str | None = None` (`no_implicit_optional`).
|
||||
|
||||
## 3. Strict Generics
|
||||
- NEVER use bare collections as types.
|
||||
- ALWAYS specify the inner types: use `list[str]`, `dict[str, int]`, or `tuple[int, ...]` instead of bare `list`, `dict`, or `tuple` (`disallow_any_generics`).
|
||||
|
||||
## 4. Restrictions on `Any` and Subclassing
|
||||
- Do not subclass from untyped external libraries or `Any` (`disallow_subclassing_any`).
|
||||
- Avoid using external types that have no stubs and resolve to `Any` (`disallow_any_unimported`).
|
||||
- Refrain from returning `Any` to avoid contaminating the type inference of calling functions (`warn_return_any`).
|
||||
|
||||
## 5. Pydantic Strictness
|
||||
- `pydantic.mypy` is active with strict initialization.
|
||||
- When instantiating Pydantic models, ensure you are passing exactly the expected typed arguments, as extra or untyped arguments will fail type checks (`init_typed = true`, `init_forbid_extra = true`).
|
||||
Reference in New Issue
Block a user