@plinng/ai-code-assistant-tools 1.0.0

package/README.md

@@ -0,0 +1,100 @@
+# @plinng/ai-code-assistant-tools
+
+Versioned, modular AI coding standards for the Plinng platform. Provides
+behavioral and architectural rules for Claude Code and Cursor that encode
+what linters and formatters cannot: architectural intent, error philosophy,
+and design discipline.
+
+---
+
+## What this is
+
+These are **not** linter rules. ESLint, Prettier, Ruff, and Biome handle
+formatting and style deterministically at zero LLM token cost. These rules
+encode the decisions that static analysis has no reach into:
+
+- Which layer is responsible for what
+- When and how to handle errors
+- Which design patterns to prefer and why.
+- SOLID principles and how to apply them in this codebase.
+
+---
+
+## Rules included
+
+| Rule file | Tool | Activated when | Enforces |
+|---|---|---|---|
+| `CLAUDE.md` / `universal.mdc` | Both | Always | How to work, commits, task runner, error + architecture summary |
+| `error-handling.md/mdc` | Both | `**/*.ts`, `**/*.py` | No silent catches; structured boundary logging; propagation discipline |
+| `architecture.md/mdc` | Both | `**/handlers/**`, `**/resolvers/**`, `**/routes/**`, `**/app/**` | Layer ordering; no DB client in handlers; factory injection |
+| `solid-principles.md/mdc` | Both | `**/*.ts`, `**/*.tsx` | SRP, OCP, LSP, ISP, DIP; don't refactor violations unless asked |
+| `clean-architecture.md/mdc` | Both | `**/*.ts`, `**/*.py` | Four-layer model; domain types from repositories; coupling detector |
+| `design-patterns.md/mdc` | Both | Always (Claude) / Agent Requested (Cursor) | Propose pattern + rationale before implementing |
+
+---
+
+## Install
+
+### Interactive CLI
+
+```bash
+npx @plinng/ai-code-assistant-tools
+```
+
+The installer will ask which AI assistant you use (Claude Code / Cursor / Both)
+and, for Cursor, whether to install at project scope or user scope. Existing
+files are backed up automatically as `<file>.backup-<timestamp>`
+
+### Manual install — Claude Code
+
+```bash
+cp claude-code/CLAUDE.md ~/.claude/CLAUDE.md
+cp claude-code/rules/*.md ~/.claude/rules/
+```
+
+### Manual install — Cursor (project scope)
+
+```bash
+cp -r cursor/rules/ .cursor/rules/
+```
+
+---
+
+## Cursor scope note
+
+**Project scope** (`.cursor/rules/`) is the reliably enforced path for teams.
+Rules installed there are version-controlled and apply to every developer who
+opens the project in Cursor.
+
+**User scope** (`~/.cursor/rules/`) is a filesystem convention. Cursor reads
+user rules from its Settings UI (plain text), not from a filesystem path
+directly. To apply user rules from this install, paste the content of each
+`.mdc` file into `Cursor Settings → General → Rules for AI`, or use Cursor
+Team Rules (requires Cursor Team/Enterprise plan) for enforced team standards.
+
+---
+
+## Updating
+
+Re-run the installer to get the latest rules. Existing files will be backed up
+before overwriting:
+
+```bash
+npx @plinng/ai-code-assistant-tools
+```
+
+---
+
+## Contributing
+
+Before adding or modifying a rule, verify it meets this checklist:
+
+1. **Cannot be enforced by a linter** — if ESLint/Ruff can catch it, it belongs in tool config, not here
+2. **Imperative with motivation** — "Use X because Y", not "Consider using X"
+3. **Both `.md` and `.mdc` updated** — keep Claude Code and Cursor rule content in sync
+4. **Line count passes** — run `moon run ai-code-assistant-tools:lint-rules`
+5. **PR to platform team** — rules affect all engineers; review is required
+
+```bash
+moon run ai-code-assistant-tools:lint-rules
+```

package/claude-code/CLAUDE.md

@@ -0,0 +1,28 @@
+# Plinng Platform — AI Coding Standards
+
+## How to work
+- Only make changes directly requested. A bug fix does not need surrounding code cleaned up.
+- Do not design for hypothetical future requirements. Three similar lines beat a premature abstraction.
+- Never push to the remote repository without an explicit human request.
+- Use Conventional Commits: `feat:`, `fix:`, `chore:`, `refactor:`, `docs:`, `test:`.
+- Run `moon run <project>:build` and verify no type errors before committing.
+- Do not add docstrings, comments, or type annotations to code you did not change.
+
+## Error handling
+- Never hide exceptions with fallback returns (`catch (e) { return null }`).
+- At system boundaries (HTTP handlers, queue consumers, cron jobs): log structured metadata `{ operation, identifiers, err }` then re-throw.
+- Inside service and domain layers: let errors propagate — do not catch and re-wrap without adding value.
+- Never add try/catch inside a repository or service unless translating a third-party error into a domain error.
+
+## Architecture
+- Handler → Service → Repository → Data source. Never skip layers.
+- Never import a database client (Prisma, Mongoose, pg) in a resolver, handler, or route file.
+- Use the repository pattern: data access belongs in `*Repository` or `*Store` modules only.
+- Inject dependencies via factory function arguments (`createHandler({ userRepo, logger })`), not global imports.
+- Handlers are stateless coordinators — no business logic, no data transformation beyond shaping the HTTP response
+
+## This monorepo
+- Task runner: Moon (`moon run <project>:<task>`).
+- Python services use `uv` for dependency management.
+- Stack-specific rules load automatically from `~/.claude/rules/` when matching file paths are open.
+- Never modify `moon.yml` task definitions without discussing with the platform team first.

package/claude-code/rules/architecture.md

@@ -0,0 +1,60 @@
+---
+paths: "**/resolvers/**,**/handlers/**,**/routes/**,**/app/**"
+---
+
+# Architecture — handlers, resolvers, and routes
+
+The dependency flow is strictly one direction:
+Handler/Resolver → Service → Repository → Data source
+
+Never skip or invert layers.
+
+## Handlers are stateless coordinators
+
+A handler's only responsibilities are:
+1. Parse and validate the incoming request
+2. Call the appropriate service method
+3. Shape the service result into an HTTP response
+
+Handlers must not contain business logic, domain rules, or data transformation
+beyond mapping service output to response shape.
+
+## Never access data sources from handlers or resolvers
+
+Never import Prisma, Mongoose, pg, a Redis client, or any external service SDK
+directly into a handler, resolver, or route file.
+
+```typescript
+// Violation — do not do this
+import { prisma } from '../db/client';
+
+export async function getOrderHandler(req: Request, res: Response) {
+  const order = await prisma.order.findUnique({ where: { id: req.params.id } });
+  res.json(order);
+}
+
+// Correct — delegate to service, which delegates to repository
+export function createOrderHandler({ orderService }: { orderService: OrderService }) {
+  return async (req: Request, res: Response) => {
+    const order = await orderService.getOrder(req.params.id);
+    res.json(order);
+  };
+}
+```
+
+## Inject dependencies via factory functions
+
+Use the `create*` factory pattern to inject services and repositories. Do not
+rely on module-level singletons or global imports for mutable dependencies.
+
+```typescript
+// Factory injection pattern
+export function createUserHandler({ userService, logger }: UserHandlerDeps) {
+  return {
+    getUser: async (req: Request, res: Response) => { ... },
+    createUser: async (req: Request, res: Response) => { ... },
+  };
+}
+```
+
+This makes handlers testable without module mocking.

package/claude-code/rules/branch-naming.md

@@ -0,0 +1,45 @@
+---
+description: Branch naming standard for git branch creation and rename in production-line-microservice
+alwaysApply: true
+---
+
+# Branch Naming
+
+## Format
+
+```
+<prefix>/<short-description>
+```
+
+Use **kebab-case**, all **lowercase**, and aim for **3-6 words** in the description.
+
+## Valid Prefixes
+
+| Prefix | Purpose | Example |
+|---|---|---|
+| `feat/` | New feature or capability | `feat/upsell-task-cleanup` |
+| `fix/` | Bug fix | `fix/duplicate-task-assignment` |
+| `refactor/` | Code restructuring (no behavior change) | `refactor/di-container-cleanup` |
+| `docs/` | Documentation only | `docs/update-readme-setup` |
+
+## Rules
+
+- **Always use `feat/`** - not `feature/` (historical branches may use `feature/` but new ones must not).
+- Keep descriptions concise but descriptive enough to identify the work.
+- Avoid generic names like `feat/update` or `fix/bug`.
+
+## Quick Validation
+
+- Prefix is one of: `feat/`, `fix/`, `refactor/`, `docs/`
+- Description is lowercase kebab-case
+- Description has 3-6 meaningful words
+- No `feature/` prefix in new branches
+
+## Examples
+
+```
+feat/webhook-retry-logic
+fix/task-repository-query-race
+refactor/use-case-error-handling
+docs/api-versioning-guide
+```

package/claude-code/rules/clean-architecture.md

@@ -0,0 +1,57 @@
+---
+paths: "**/*.ts,**/*.py"
+---
+
+# Clean architecture — layering rules
+
+The codebase follows a four-layer architecture. Dependencies point inward only.
+
+```
+Handler / Controller  (outermost — HTTP, queues, cron)
+        ↓
+    Service           (business rules, orchestration)
+        ↓
+  Repository          (data access abstraction)
+        ↓
+  Data source         (Prisma, Mongoose, pg, Redis, external APIs)
+```
+
+## Layer responsibilities
+
+**Handler**: HTTP parsing, auth context extraction, input validation, response
+shaping. No business logic. Delegates immediately to a service.
+
+**Service**: Business rules, domain validation, orchestration across multiple
+repositories. Receives and returns domain types — never raw DB documents.
+
+**Repository**: Encapsulates all queries for a single aggregate. Returns typed
+domain objects. Handles DB-specific errors and translates them to domain errors.
+
+**Data source**: The actual client (Prisma, Mongoose). Only imported inside
+repository files.
+
+## Coupling violation detector
+
+If a single file imports from both an HTTP framework (`express`, `fastapi`,
+`hono`) and a database client (`prisma`, `mongoose`, `pg`, `motor`), it is a
+coupling violation. Split it along layer boundaries.
+
+```typescript
+// Violation — handler importing DB client directly
+import { Request, Response } from 'express'; // HTTP layer
+import { prisma } from '../db/client';        // Data layer — not allowed here
+```
+
+## Services receive domain types, not raw DB documents
+
+Repositories must map database results to domain types before returning them.
+Services must never access raw Prisma/Mongoose document fields (`_id`,
+`__v`, `createdAt` in raw object form) — only typed domain properties.
+
+```typescript
+// Repository — maps raw result to domain type
+async findById(id: string): Promise<User> {
+  const doc = await prisma.user.findUniqueOrThrow({ where: { id } });
+  return { id: doc.id, email: doc.email, name: doc.name }; // domain type
+}
+```

package/claude-code/rules/design-patterns.md

@@ -0,0 +1,42 @@
+# Design patterns
+
+Before implementing a non-trivial solution, propose the applicable design
+pattern with a one-sentence rationale explaining why it fits. State the
+pattern name explicitly. Do not propose patterns for simple, single-purpose
+functions — only for solutions involving multiple collaborators, varying
+behavior, or extension points.
+
+## Patterns to consider and when
+
+**Repository** — When multiple parts of the codebase need to query the same
+data source. Centralizes query logic and allows the data source to be swapped.
+
+**Factory** — When object creation involves conditional logic, multiple
+dependencies, or configuration. Use `createX({ dep1, dep2 })` functions
+instead of constructor-heavy classes.
+
+**Strategy** — When a behavior varies based on context (e.g., different
+payment processors, notification channels, export formats). Pass the strategy
+as a dependency rather than branching with `if/switch`.
+
+**Observer / Event emitter** — When an action in one part of the system
+should trigger reactions in decoupled parts. Prefer domain events over direct
+coupling between services.
+
+**Decorator** — When adding cross-cutting concerns (logging, caching, retry,
+auth) to an existing interface without modifying the underlying implementation.
+
+## Format for pattern proposals
+
+Before writing implementation code, state:
+
+```
+Pattern: Repository
+Why: Order data is accessed from three services; centralizing queries
+     prevents duplication and lets us swap the ORM in tests.
+```
+
+Then proceed with implementation only after the pattern is clear.
+
+Do not propose patterns speculatively — only when there is a concrete,
+present need in the current task.

package/claude-code/rules/error-handling.md

@@ -0,0 +1,61 @@
+---
+paths: "**/*.ts,**/*.py"
+---
+
+# Error handling
+
+Never catch an error and return null, undefined, or a default value. Silent
+catches hide bugs and make debugging impossible. Always let the error surface.
+
+```typescript
+// Anti-pattern — never do this
+async function getUser(id: string) {
+  try {
+    return await userRepo.findById(id);
+  } catch (e) {
+    return null; // caller can't distinguish "not found" from "DB exploded"
+  }
+}
+
+// Correct — propagate at domain layer
+async function getUser(id: string) {
+  return await userRepo.findById(id); // let errors propagate
+}
+```
+
+At system boundaries (HTTP handlers, queue consumers, cron jobs), catch errors
+once, log structured metadata, then re-throw or respond with an error status:
+
+```typescript
+// HTTP handler boundary
+async function handleGetUser(req: Request, res: Response) {
+  try {
+    const user = await userService.getUser(req.params.id);
+    res.json(user);
+  } catch (err) {
+    logger.error({ operation: 'getUser', userId: req.params.id, err });
+    res.status(500).json({ error: 'Internal server error' });
+  }
+}
+```
+
+Python equivalent — boundary catch with structured log, then re-raise or
+return an error response:
+
+```python
+# FastAPI route boundary
+@router.get("/users/{user_id}")
+async def get_user(user_id: str, service: UserService = Depends(get_user_service)):
+    try:
+        return await service.get_user(user_id)
+    except Exception as err:
+        logger.error({"operation": "get_user", "user_id": user_id, "error": str(err)})
+        raise HTTPException(status_code=500, detail="Internal server error")
+```
+
+Do not add try/catch inside services or repositories unless you are
+translating a third-party library error into a typed domain error. In that
+case, wrap once at the outermost repository method and throw a domain error.
+
+Only add error handling at system boundaries — one catch per entry point, not
+one catch per function call.

package/claude-code/rules/solid-principles.md

@@ -0,0 +1,44 @@
+---
+paths: "**/*.ts,**/*.tsx"
+---
+
+# SOLID principles
+
+## Single Responsibility Principle
+A module has one reason to change. A class or function that handles HTTP
+parsing, business logic, AND database access has three reasons to change —
+split it. If you cannot describe a module's purpose without "and", it violates SRP.
+
+## Open/Closed Principle
+Extend behavior via composition, not by modifying existing code. Add new
+capabilities by creating new modules or passing new dependencies — do not
+reach into existing implementations and add branches. Prefer strategy objects
+and dependency injection over `if (featureFlag)` conditions in core logic.
+
+## Liskov Substitution Principle
+Subtypes must honor the behavioral contract of the type they extend. If a
+function accepts a `Repository` interface, every concrete implementation must
+satisfy the same pre/postconditions. Never throw additional errors, accept
+fewer inputs, or return narrower output types than the interface declares.
+
+## Interface Segregation Principle
+Define narrow, role-specific interfaces. A `UserRepository` interface should
+not include email-sending methods. Callers should depend only on the interface
+members they actually use — split large interfaces by caller role.
+
+## Dependency Inversion Principle
+High-level modules (services, domain logic) must depend on abstractions
+(interfaces, type aliases), not on concrete implementations (Prisma client,
+specific HTTP framework). Pass concrete implementations via factory function
+arguments or constructor injection so they can be swapped in tests.
+
+## Legacy code and SOLID violations
+If you encounter existing code that violates SOLID principles, do NOT refactor
+it unless explicitly asked to do so. Add a comment noting the violation and
+continue with the requested change:
+
+```typescript
+// TODO: SRP violation — this handler also contains business logic; refactor when scope permits
+```
+
+Unsolicited refactoring introduces risk and scope creep.

package/cursor/rules/architecture.mdc

@@ -0,0 +1,48 @@
+---
+globs: "**/resolvers/**,**/handlers/**,**/routes/**,**/app/**"
+alwaysApply: false
+---
+
+# Architecture — handlers, resolvers, and routes
+
+The dependency flow is strictly one direction:
+Handler/Resolver → Service → Repository → Data source
+
+Never skip or invert layers.
+
+## Handlers are stateless coordinators
+
+A handler's only responsibilities:
+1. Parse and validate the incoming request
+2. Call the appropriate service method
+3. Shape the service result into an HTTP response
+
+No business logic, domain rules, or data transformation beyond response shaping.
+
+## Never access data sources from handlers or resolvers
+
+Never import Prisma, Mongoose, pg, Redis, or any external service SDK directly
+into a handler, resolver, or route file.
+
+```typescript
+// Violation — do not do this
+import { prisma } from '../db/client';
+export async function getOrderHandler(req, res) {
+  const order = await prisma.order.findUnique({ where: { id: req.params.id } });
+  res.json(order);
+}
+
+// Correct — factory injection, delegate to service
+export function createOrderHandler({ orderService }: { orderService: OrderService }) {
+  return async (req: Request, res: Response) => {
+    const order = await orderService.getOrder(req.params.id);
+    res.json(order);
+  };
+}
+```
+
+## Inject dependencies via factory functions
+
+Use the `create*` factory pattern. Do not rely on module-level singletons or
+global imports for mutable dependencies. This makes handlers testable without
+module mocking.

package/cursor/rules/clean-architecture.mdc

@@ -0,0 +1,49 @@
+---
+globs: "**/*.ts,**/*.py"
+alwaysApply: false
+---
+
+# Clean architecture — layering rules
+
+Four layers, dependencies point inward only:
+
+```
+Handler / Controller  (HTTP, queues, cron)
+        ↓
+    Service           (business rules, orchestration)
+        ↓
+  Repository          (data access abstraction)
+        ↓
+  Data source         (Prisma, Mongoose, pg, Redis, external APIs)
+```
+
+## Layer responsibilities
+
+**Handler**: HTTP parsing, auth extraction, input validation, response shaping.
+No business logic. Delegates to a service immediately.
+
+**Service**: Business rules, domain validation, orchestration across repositories.
+Receives and returns domain types — never raw DB documents.
+
+**Repository**: Encapsulates all queries for one aggregate. Returns typed domain
+objects. Translates DB errors to domain errors.
+
+**Data source**: The actual client. Only imported inside repository files.
+
+## Coupling violation detector
+
+If a file imports from both an HTTP framework (`express`, `fastapi`, `hono`)
+and a database client (`prisma`, `mongoose`, `pg`, `motor`), it is a coupling
+violation. Split it along layer boundaries.
+
+## Services receive domain types, not raw DB documents
+
+Repositories must map database results to domain types before returning them.
+
+```typescript
+// Repository — maps to domain type
+async findById(id: string): Promise<User> {
+  const doc = await prisma.user.findUniqueOrThrow({ where: { id } });
+  return { id: doc.id, email: doc.email, name: doc.name };
+}
+```

package/cursor/rules/design-patterns.mdc

@@ -0,0 +1,43 @@
+---
+description: "Design patterns — propose applicable patterns before implementing complex solutions involving multiple collaborators, varying behavior, or extension points"
+alwaysApply: false
+---
+
+# Design patterns
+
+Before implementing a non-trivial solution, propose the applicable design
+pattern with a one-sentence rationale explaining why it fits. State the
+pattern name explicitly. Do not propose patterns for simple, single-purpose
+functions.
+
+## Patterns to consider and when
+
+**Repository** — Multiple parts of the codebase query the same data source.
+Centralizes query logic and allows the data source to be swapped.
+
+**Factory** — Object creation involves conditional logic, multiple dependencies,
+or configuration. Use `createX({ dep1, dep2 })` functions.
+
+**Strategy** — Behavior varies based on context (payment processors, notification
+channels, export formats). Pass the strategy as a dependency.
+
+**Observer / Event emitter** — An action should trigger reactions in decoupled
+parts. Prefer domain events over direct coupling between services.
+
+**Decorator** — Adding cross-cutting concerns (logging, caching, retry, auth)
+to an existing interface without modifying the underlying implementation.
+
+## Format for pattern proposals
+
+Before writing implementation code, state:
+
+```
+Pattern: Repository
+Why: Order data is accessed from three services; centralizing queries
+     prevents duplication and lets us swap the ORM in tests.
+```
+
+Then proceed with implementation only after the pattern is clear.
+
+Do not propose patterns speculatively — only when there is a concrete,
+present need in the current task.

package/cursor/rules/error-handling.mdc

@@ -0,0 +1,45 @@
+---
+globs: "**/*.ts,**/*.py"
+alwaysApply: false
+---
+
+# Error handling
+
+Never catch an error and return null, undefined, or a default value. Silent
+catches hide bugs and make debugging impossible. Always let the error surface.
+
+```typescript
+// Anti-pattern — never do this
+async function getUser(id: string) {
+  try {
+    return await userRepo.findById(id);
+  } catch (e) {
+    return null; // caller can't distinguish "not found" from "DB exploded"
+  }
+}
+
+// Correct — propagate at domain layer
+async function getUser(id: string) {
+  return await userRepo.findById(id);
+}
+```
+
+At system boundaries (HTTP handlers, queue consumers, cron jobs), catch once,
+log structured metadata `{ operation, identifiers, err }`, then re-throw or
+respond with an error status.
+
+Python boundary example:
+
+```python
+@router.get("/users/{user_id}")
+async def get_user(user_id: str, service: UserService = Depends(get_user_service)):
+    try:
+        return await service.get_user(user_id)
+    except Exception as err:
+        logger.error({"operation": "get_user", "user_id": user_id, "error": str(err)})
+        raise HTTPException(status_code=500, detail="Internal server error")
+```
+
+Only add error handling at system boundaries — one catch per entry point, not
+one catch per function call. Do not add try/catch inside services or
+repositories unless translating a third-party error into a domain error.

package/cursor/rules/solid-principles.mdc

@@ -0,0 +1,40 @@
+---
+globs: "**/*.ts,**/*.tsx"
+alwaysApply: false
+---
+
+# SOLID principles
+
+## Single Responsibility Principle
+A module has one reason to change. If you cannot describe a module's purpose
+without "and", it violates SRP. Split handler, business logic, and data access
+into separate layers.
+
+## Open/Closed Principle
+Extend behavior via composition, not by modifying existing code. Add new
+capabilities with new modules or dependencies — do not add branches to core
+logic. Prefer strategy objects and dependency injection over feature flags
+inside implementations.
+
+## Liskov Substitution Principle
+Subtypes must honor the behavioral contract of the type they extend. Every
+concrete implementation of a `Repository` interface must satisfy the same
+pre/postconditions. Never throw additional errors or return narrower types
+than the interface declares.
+
+## Interface Segregation Principle
+Define narrow, role-specific interfaces. Callers should depend only on the
+interface members they actually use. Split large interfaces by caller role.
+
+## Dependency Inversion Principle
+High-level modules depend on abstractions (interfaces, type aliases), not on
+concrete implementations. Pass concrete implementations via factory function
+arguments so they can be swapped in tests.
+
+## Legacy code and SOLID violations
+If you encounter existing code that violates SOLID, do NOT refactor it unless
+explicitly asked. Add a comment noting the violation and continue:
+
+```typescript
+// TODO: SRP violation — handler contains business logic; refactor when scope permits
+```

package/cursor/rules/universal.mdc

@@ -0,0 +1,28 @@
+---
+alwaysApply: true
+---
+
+# Plinng Platform — Universal Rules
+
+## How to work
+- Only make changes directly requested. A bug fix does not need surrounding code cleaned up.
+- Do not design for hypothetical future requirements. Three similar lines beat a premature abstraction.
+- Never push to the remote repository without an explicit human request.
+- Use Conventional Commits: `feat:`, `fix:`, `chore:`, `refactor:`, `docs:`, `test:`.
+- Run `moon run <project>:build` and verify no type errors before committing.
+- Do not add docstrings, comments, or type annotations to code you did not change.
+
+## Task runner
+- This monorepo uses Moon as the task runner: `moon run <project>:<task>`.
+- Python services use `uv` for dependency management.
+- Never modify `moon.yml` task definitions without discussing with the platform team first.
+
+## Error handling summary
+- Never hide exceptions with fallback returns (`catch (e) { return null }`).
+- At system boundaries: log `{ operation, identifiers, err }` then re-throw.
+- Inside service and domain layers: let errors propagate.
+
+## Architecture summary
+- Handler → Service → Repository → Data source. Never skip layers.
+- Never import a database client in a handler, resolver, or route file.
+- Use factory function injection: `createHandler({ userRepo, logger })`.

package/package.json

@@ -0,0 +1,27 @@
+{
+  "name": "@plinng/ai-code-assistant-tools",
+  "version": "1.0.0",
+  "description": "CLI installer for Plinng platform AI coding standards",
+  "bin": {
+    "ai-code-assistant-tools": "./bin/install.js"
+  },
+  "scripts": {
+    "build": "tsc -p tsconfig.json && node scripts/add-shebang.js",
+    "release": "npm run build && npm publish"
+  },
+  "files": [
+    "bin/",
+    "claude-code/",
+    "cursor/"
+  ],
+  "engines": {
+    "node": ">=20"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "devDependencies": {
+    "@types/node": "^20.0.0",
+    "typescript": "^5.7.0"
+  }
+}