@jaypie/mcp 0.1.0 → 0.1.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jaypie/mcp",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Jaypie MCP server",
   "license": "MIT",
   "author": "Finlayson Studio",
@@ -17,7 +17,8 @@
     "jaypie-mcp": "dist/index.js"
   },
   "files": [
-    "dist"
+    "dist",
+    "prompts"
   ],
   "scripts": {
     "build": "rollup --config",
@@ -36,5 +37,5 @@
   "publishConfig": {
     "access": "public"
   },
-  "gitHead": "f9017346106103230809370764572ac5e65eae09"
+  "gitHead": "3551541ce381627a92bea7f8baece6965d822f37"
 }

package/prompts/Branch_Management.md

@@ -0,0 +1,34 @@
+---
+description: Process for creating, merging branches (always read)
+---
+
+# Branch Management
+
+## Naming Conventions
+
+Name branches after the ticket or use a generic naming scheme.
+
+### Ticket Naming
+
+If the issue is from a ticketing system such as GitHub, Jira, or Linear, use `feat/{{ ticket }}`.
+Jira and Linear usually include a keyword like `DEV-12`.
+For GitHub tickets use `GITHUB-#`.
+
+### Generic Naming
+
+Check the first eight characters of the latest commit hash with `git -C workspace rev-parse --short=8 HEAD`
+Create a new branch prefixed with `feat/`.
+Make the branch name a concise two- or three-word summary of the ticket.
+Lead with the most important word.
+Use dashes, for example `feat/readme-update-abcd5678`.
+
+## Development
+
+Refer to [Development_Process.md](./Development_Process.md) for details on process, scripts, and tests expected in the development step.
+
+## Completion
+
+Push the completed branch.
+Start a new pull request.
+Describe the changes and any failing validation steps.
+Mark it closing the issue.

package/prompts/Development_Process.md

@@ -0,0 +1,67 @@
+---
+description: Development workflow, required reading for coding tasks (always read)
+---
+
+# Development Process
+
+## Baseline Conditions
+
+Check package.json scripts for build, format, lint, test, and typecheck commands.
+Build, lint, test, and typecheck the repository before continuing.
+Note but do not attempt to fix errors and warnings.
+
+## Development
+
+Start a subagent for actual feature implementation.
+Include any build, lint, test, and type warnings to disregard.
+Have the subagent write a test to validate work whenever possible.
+Have the subagent run tests but not worry about lint and types.
+Commit the changes when complete.
+Follow conventional commits.
+
+## Validation
+
+Use a subagent for each step, if applicable.
+Skip any step that does not have a corresponding npm script.
+If the npm script produces no errors or warnings, 
+Include any build, lint, test, and type warnings to disregard.
+Skip any step that cannot be passed.
+Commit after each step to ensure changes can be discarded.
+
+### Scrub
+
+Follow prompts/Jaypie_Scrub.md.
+If provided, allow repo instructions to override Jaypie scrub.
+Scrub can prevent errors in further steps, especially testing.
+
+### Test
+
+Test the repository.
+Have a subagent correct any new errors in the test
+Be clear whether the error is in the test or in the implementation.
+If the failure is an unchanged test, likely the new implementation is to blame.
+If the new implementation intentionally changed code covered by the test triggering the failure, the test may be incorrect.
+Commit the changes when complete.
+
+### Type Check
+
+Run `npm run typecheck`.
+Have a subagent correct any new type errors.
+Commit the changes when complete.
+
+### Format and lint
+
+Run the format, when available, or lint commands.
+Check status to see if format updated any files.
+Call a subagent for any remaining lint errors introduced by this branch.
+Commit the changes when complete.
+
+### Build
+
+Run `npm run build`.
+Have a subagent correct any new build errors.
+Commit the changes when complete.
+
+## Documentation
+
+Have a subagent update README.md, if any already-documented features were changed or new features introduced.

package/prompts/Jaypie_Agent_Rules.md

@@ -0,0 +1,110 @@
+---
+trigger: always_on
+description: Baseline rules in Jaypie repositories. Required reading.
+---
+
+# Jaypie's Agent Rules
+
+This repository uses Jaypie, an opinionated event-driven fullstack library.
+
+## Errors
+
+Jaypie providers errors that will be handled properly when thrown (e.g., presenting the correct status code).
+
+`import { BadGatewayError, BadRequestError, ConfigurationError, ForbiddenError, GatewayTimeoutError, GoneError, IllogicalError, InternalError, MethodNotAllowedError, NotFoundError, NotImplementedError, RejectedError, TeapotError, UnauthorizedError, UnavailableError, UnhandledError, UnreachableCodeError } from "jaypie";`
+
+ConfigurationError is a special InternalError 500 that is also thrown when types are incorrect.
+
+Though supported, rely on default error messages when throwing.
+Custom error messages should be logged not thrown
+
+<Bad>
+throw new NotFoundError("Item not found");
+</Bad>
+<Good>
+log.error("Item not found");
+throw new NotFoundError();
+</Good>
+
+Error messages may be returned to the user especially in express.
+
+## Logging
+
+`import { log } from "jaypie";`
+`log` has methods `trace`, `debug`, `info`, `warn`, `error`, `fatal`, and `var`.
+Only `trace` and `var` should be used in "happy paths".
+`debug` should be used when execution deviates from the happy path.
+`info` should rarely be used.
+`var` expects a _single_ key-value pair like `log.var({ key: "value" });`.
+Do _not_ pass multiple keys to `var`.
+
+## Testing
+
+`@jaypie/testkit` is a testing library used with vitest providing custom matchers and mocks for the main Jaypie library.
+Always use the testkit to mock Jaypie.
+Always create a manual mock for a models package.
+Always mock network calls and external commands.
+Jaypie relies heavily on mocking to confirm expected behavior and prevent behavior drift.
+
+See [Jaypie_Mocks_and_Testkit.md](./Jaypie_Mocks_and_Testkit.md) for more context.
+
+### Configuration
+
+Mocks and matchers are usually configured at the subpackage-level in `testSetup.js` (legacy path) or `vitest.setup.[js|ts]` (modern path).
+The subpackage `[vite|vitest].config[js|ts]` will reference the setup file.
+All jaypie functions are mocked with `vi.mock("jaypie", async () => vi.importActual("@jaypie/testkit/mock"));`
+
+vitest.setup.ts
+```typescript
+import { matchers as jaypieMatchers } from "@jaypie/testkit";
+import * as extendedMatchers from "jest-extended";
+import { expect , vi} from "vitest";
+
+expect.extend(extendedMatchers);
+expect.extend(jaypieMatchers);
+
+vi.mock("jaypie", async () => vi.importActual("@jaypie/testkit/mock"));
+```
+
+### Errors
+
+Use matchers to test errors.
+`expect(fn).toThrowBadGatewayError();`
+`await expect(async() => fn()).toThrowBadGatewayError();`
+Do not use `.rejects`
+
+### Matchers
+
+toBeCalledAboveTrace, toBeCalledWithInitialParams, toBeClass, toBeJaypieError, toMatchBase64, toMatchJwt, toMatchMongoId, toMatchSchema, toMatchSignedCookie, toMatchUuid4, toMatchUuid5, toMatchUuid, toThrowBadGatewayError, toThrowBadRequestError, toThrowConfigurationError, toThrowForbiddenError, toThrowGatewayTimeoutError, toThrowInternalError, toThrowJaypieError, toThrowNotFoundError, toThrowUnauthorizedError, toThrowUnavailableError,
+
+### Order of Tests
+
+Tests are named `./__tests__/<subject>.spec.<js|ts>`.
+Each file should have one top-level `describe` block.
+Organize tests in one of seven second-level describe block sections in this order:
+
+1. Base Cases - it is the type we expect ("It is a Function"). For functions, the simplest possible call works and returns not undefined ("It Works"). For objects, the expected shape.
+2. Error Conditions - any error handling the code performs
+3. Security - any security checks the code performs
+4. Observability - any logging the code performs
+5. Happy Paths - The most common use case
+6. Features - Features in addition to the happy path
+7. Specific Scenarios - Special cases
+Omit describe blocks for sections that are not applicable or empty.
+Whenever possible, especially when refactoring, write the test first so the user can confirm the expected behavior passes/fails.
+
+### Test Coverage
+
+Aim for complete coverage of all happy paths, features, and error conditions.
+Whenever possible, confirm mocked functions are called.
+Confirm calls to log above debug in Observability. Do not confirm calls to debug, var, or trace.
+
+## Linting
+
+Use double quotes, trailing commas, and semicolons.
+Do not delete `// eslint-disable-next-line no-shadow` comments; add when shadowing variables, especially `error` in catch blocks.
+
+### Beyond Lint
+
+Whenever a hard-coded value like `site: "datadoghq.com"` is used, define a constant at the top of the file, `const DATADOG_SITE = "datadoghq.com"`, and reference that throughout.
+Alphabetize as much as possible.