vigiles 3.0.0 → 4.0.1

package/skills/enforce-rules-format/SKILL.md

@@ -1,71 +0,0 @@
----
-name: enforce-rules-format
-description: Validate that all rules have proper enforcement classification (enforce/check/guidance)
-disable-model-invocation: true
----
-
-Validate that every rule in the project's instruction files has a proper enforcement classification, and fix any that are missing.
-
-## Instructions
-
-### Step 1: Detect Format
-
-Check which format the project uses:
-
-**v2 (spec-based):** Look for `CLAUDE.md.spec.ts` or any `*.spec.ts` files. If found, this is a v2 project — rules must use `enforce()`, `check()`, or `guidance()`.
-
-**v1 (hand-written):** Look for `CLAUDE.md`, `AGENTS.md`, `.cursorrules`. If found without a spec file, this is a v1 project — rules need `**Enforced by:**` or `**Guidance only**` annotations.
-
-### Step 2: Validate
-
-**For v2 specs:**
-
-The TypeScript type system already prevents unannotated rules — you can't create a rule without calling `enforce()`, `check()`, or `guidance()`. So focus on:
-
-1. Do `enforce()` rules reference real linter rules? Run `npx vigiles compile` to check.
-2. Are there guidance rules that COULD be `enforce()`? Check linter configs for matching rules.
-3. Are there `check()` assertions that could be delegated to a linter? Suggest `enforce()` instead.
-
-```bash
-npx vigiles compile
-npx vigiles discover
-```
-
-**For v1 hand-written files:**
-
-Scan for `###` headings. Each must have one of:
-
-- `**Enforced by:** \`linter/rule-name\``
-- `**Guidance only** — reason`
-- `<!-- vigiles-disable -->`
-
-Report missing annotations with a summary table.
-
-### Step 3: Fix Issues
-
-For each issue found:
-
-1. Check the project's linter configuration for matching rules
-2. Suggest `enforce("linter/rule")` (v2) or `**Enforced by:** \`linter/rule\`` (v1)
-3. If no linter rule exists, suggest `guidance()` (v2) or `**Guidance only**` (v1)
-4. **Ask the user** before making changes
-
-### Step 4: Suggest Migration
-
-If the project uses v1 format, suggest migrating to v2 specs for type safety:
-
-> Your rules could benefit from type-safe specs. Run the `migrate-to-spec` skill to convert your CLAUDE.md to a typed .spec.ts file.
-
-### Step 5: Verify
-
-Run the appropriate command:
-
-```bash
-# v2
-npx vigiles compile && npx vigiles check
-
-# validate
-npx vigiles check
-```
-
-Report the validation result.

package/skills/generate-logo/SKILL.md

@@ -1,103 +0,0 @@
----
-name: generate-logo
-description: Generate or iterate on the vigiles logo using ImageRouter API
----
-
-# Generate Logo
-
-Generate logo variations for vigiles using the ImageRouter API (imagerouter.io).
-
-## Setup
-
-Get an API key from https://imagerouter.io/api-keys. Pass it as an argument or set `IMAGEROUTER_API_KEY` env var. Do NOT commit the key.
-
-## API
-
-```
-Endpoint: https://api.imagerouter.io/v1/openai/images/generations
-Auth: Bearer token in Authorization header
-Method: POST, Content-Type: application/json
-```
-
-### Request body
-
-```json
-{
-  "prompt": "...",
-  "model": "google/nano-banana-2",
-  "quality": "high",
-  "size": "1024x1024",
-  "response_format": "url",
-  "output_format": "png"
-}
-```
-
-### Available models (image generation)
-
-List models: `GET https://api.imagerouter.io/v1/models`
-
-Known good models:
-
-- `google/nano-banana-2` — best quality, $0.07/image
-- `google/nano-banana-2:free` — free tier
-- `openai/gpt-image-1` — OpenAI's image model
-- `black-forest-labs/FLUX-1.1-pro` — FLUX pro
-
-### Response
-
-```json
-{
-  "created": 1775430873,
-  "data": [{ "url": "https://storage.imagerouter.io/..." }],
-  "cost": 0.069,
-  "latency": 27627
-}
-```
-
-Download the image from the URL in `data[0].url`.
-
-## Current logo
-
-The current logo (`logo.png`) is v6: overlapping translucent flame petals on dark background, amber-orange palette. Generated with `google/nano-banana-2`.
-
-### Prompt that produced it
-
-```
-A premium, refined logo icon for a developer tool called vigiles that compiles
-typed TypeScript specs to AI instruction files. Inspired by OpenAI geometric aesthetic and Apple
-minimalism. A single abstract geometric shape: an upward-pointing flame composed
-of 3 overlapping translucent rounded shapes, creating depth through overlap —
-similar to how the OpenAI logo uses overlapping curves. Warm amber to deep orange
-color palette. Black background. No text. No letters. Pure abstract mark. Clean
-enough to be an app icon. Luxurious, premium, modern tech company feel.
-```
-
-## Design principles
-
-- **Flame/torch motif** — vigiles were Rome's night watchmen who carried torches
-- **Amber/orange palette** — matches GitHub Action branding color
-- **No text in the icon** — must work at 16px favicon size
-- **Dark background variant** for README, light/transparent variant for npm
-
-## Example curl
-
-```bash
-curl 'https://api.imagerouter.io/v1/openai/images/generations' \
-  -H "Authorization: Bearer $IMAGEROUTER_API_KEY" \
-  -H 'Content-Type: application/json' \
-  -d '{
-    "prompt": "YOUR PROMPT HERE",
-    "model": "google/nano-banana-2",
-    "quality": "high",
-    "size": "1024x1024",
-    "response_format": "url",
-    "output_format": "png"
-  }'
-```
-
-## Workflow
-
-1. Generate variations with different prompts
-2. Save as `logo-v*.png` (gitignored)
-3. Pick the best, copy to `logo.png`
-4. Commit `logo.png` only

package/skills/pr-to-lint-rule/SKILL.md

@@ -1,97 +0,0 @@
----
-name: pr-to-lint-rule
-description: Convert a recurring PR review comment into an automated lint rule with tests and spec entry
-disable-model-invocation: true
-argument-hint: <description of recurring PR feedback>
----
-
-Convert a recurring PR review comment into an automated lint rule.
-
-## Arguments
-
-$ARGUMENTS — A natural language description of the pattern to enforce. Examples:
-
-- "we keep telling people not to import directly from antd, use our design system barrel file instead"
-- "people forget to use our custom logger instead of console.log"
-- "don't use unwrap() in production code, use expect() or proper error handling"
-- "API route handlers must use the withAuth wrapper"
-
-## Instructions
-
-You are generating an automated lint rule from a recurring code review pattern. Follow these steps:
-
-### Step 1: Detect the Project Language and Toolchain
-
-Look at the repository to determine:
-
-- **Primary language** (JS/TS, Python, Rust, Go, Ruby, etc.)
-- **Linter in use** (ESLint, Ruff, Clippy, golangci-lint, RuboCop, etc.)
-- **Testing framework** (Vitest, Jest, pytest, cargo test, etc.)
-- **Existing custom rules** (to match conventions)
-
-**If the language or linter cannot be confidently detected** (e.g. polyglot repo, no linter config, or multiple candidates), **ask the user** which language and linter to target before generating anything.
-
-### Step 2: Generate the Lint Rule
-
-Based on the detected (or user-specified) language, generate the appropriate rule type:
-
-**Read the linter-specific reference doc before generating.** Each doc covers existing plugins to check first, rule/lint anatomy, AST patterns, auto-fix safety, testing, and edge cases.
-
-| Language              | Linter    | Reference doc                 |
-| --------------------- | --------- | ----------------------------- |
-| JavaScript/TypeScript | ESLint    | `../linter-docs/eslint.md`    |
-| Python                | Ruff      | `../linter-docs/ruff.md`      |
-| Python                | Pylint    | `../linter-docs/pylint.md`    |
-| Ruby                  | RuboCop   | `../linter-docs/rubocop.md`   |
-| Rust                  | Clippy    | `../linter-docs/clippy.md`    |
-| CSS                   | Stylelint | `../linter-docs/stylelint.md` |
-
-For all linters, follow this order:
-
-1. **Check existing plugins/rules first** — see the plugin table in the linter doc
-2. **Try built-in config options** — most linters have `no-restricted-*` or equivalent rules that handle one-off patterns without custom code
-3. **Only write a custom rule** when you need AST analysis, auto-fix, or configurable options beyond what exists
-
-If a custom rule is needed, the reference doc provides: rule anatomy, AST node cheat sheet, auto-fix/suggest patterns, testing examples, and registration instructions.
-
-#### For Go (go/analysis)
-
-No linter doc yet. Generate an analyzer using `golang.org/x/tools/go/analysis` with `analysistest` tests.
-
-#### For other languages
-
-Generate the most idiomatic linting approach with test cases and integration instructions.
-
-### Step 3: Add to Instruction File
-
-**If the project uses v2 specs** (has `CLAUDE.md.spec.ts`):
-
-Add an `enforce()` rule to the spec file:
-
-```typescript
-"<rule-id>": enforce("<linter>/<rule-name>", "<why>"),
-```
-
-Then run `npx vigiles compile` to regenerate CLAUDE.md.
-
-**If the project uses v1** (hand-written CLAUDE.md):
-
-Append an annotation block:
-
-```markdown
-### <Rule title — imperative, concise>
-
-**Enforced by:** `<linter>/<rule-name>`
-**Why:** <One sentence explaining the architectural reason>
-```
-
-### Step 4: Present the Output
-
-Show the user:
-
-1. All generated files with full contents
-2. Step-by-step integration instructions
-3. The spec rule or CLAUDE.md block to add
-4. How to verify it works (run the linter, expect it to catch a violation)
-
-Ask the user if they want you to write the files and update the spec/CLAUDE.md.