mirror of
https://github.com/pbakaus/impeccable.git
synced 2026-09-12 14:16:28 +03:00
- Bump skills plugin version 2.1.1 -> 3.0.0 (plugin.json, marketplace.json, harness SKILL.md files). CLI and Chrome extension unchanged. - Remove prefixed universal zip bundle and all related code: factory.js prefix/outputSuffix options, zip.js variant pass, utils.js prefixSkillReferences, the "universal-prefixed" entry in download-providers.js, and the matching test suite in utils.test.js. - Redesign Get Started step 1 "Install the skill and CLI": two terminal rows (npx skills + npm i -g impeccable) with paired notes, drop the Recommended badge. - Collapse "Other install methods" back into a <details> element so the primary install path is the first thing users see. - Simplify step 3 to "Add the Chrome extension": remove the CLI tool block (now in step 1), use standard .btn .btn-primary for the CTA so it matches other primary buttons (square corners, accent slide-up hover), and lay out the preview screenshot next to the button instead of stacked so the screenshot no longer dominates vertical space. - CLAUDE.md: rewrite with v3.0 architecture, the "no em dash also means no --" rule, the harness-dirs-are-tracked gotcha, the named-export test-spy warning, and the evals inline-skill.ts sync note. - AGENTS.md, DEVELOP.md: drop prefixed variant references. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
33 lines
2.6 KiB
Markdown
33 lines
2.6 KiB
Markdown
# Repository Guidelines
|
||
|
||
## Project Structure & Module Organization
|
||
|
||
`source/` is the source of truth. Author skills in `source/skills/impeccable/` and keep provider output in `dist/` generated, not hand-edited. Build logic lives in `scripts/`, with provider configs in `scripts/lib/transformers/`. Runtime detection code ships from `src/`. The website lives in `public/`, local API/dev serving lives in `server/`, and regression coverage lives in `tests/` with fixtures under `tests/fixtures/`.
|
||
|
||
## Build, Test, and Development Commands
|
||
|
||
- `bun run dev` - start the local Bun server.
|
||
- `bun run build` - regenerate `dist/`, derived site assets, and validation output.
|
||
- `bun run rebuild` - clean and rebuild everything from scratch.
|
||
- `bun test tests/build.test.js` - run a focused Bun test.
|
||
- `bun run test` - run the full Bun + Node test suite.
|
||
- `bun run build:browser` / `bun run build:extension` - rebuild browser-specific bundles.
|
||
|
||
Run `bun run build` after changing anything in `source/`, transformer code, or user-facing counts.
|
||
|
||
## Coding Style & Naming Conventions
|
||
|
||
Use ESM, semicolons, and the existing two-space indentation style in JS, HTML, and CSS. Prefer small, single-purpose modules over large abstractions. Keep filenames descriptive and lowercase with hyphens where needed; skill entrypoints stay as `SKILL.md`, helper scripts use `.js` or `.mjs`. In source frontmatter, use clear kebab-case names and concise descriptions. There is no dedicated formatter or linter configured here, so match surrounding code closely.
|
||
|
||
## Testing Guidelines
|
||
|
||
Tests use Bun’s test runner plus Node’s built-in `--test`. Name tests `*.test.js` or `*.test.mjs` and place new fixtures near the behavior they cover, usually under `tests/fixtures/`. Prefer targeted test runs while iterating, then finish with `bun run test`. If you change generated outputs or provider transforms, verify both source parsing and at least one affected provider path in `dist/`.
|
||
|
||
## Commit & Pull Request Guidelines
|
||
|
||
Recent history favors short, imperative subjects such as `Fix: ...`, `Add ...`, `Improve ...`, or `Bump ...`. Keep commits focused and explain the user-facing impact when it is not obvious. PRs should summarize what changed, list validation performed, and call out regenerated artifacts like `dist/` or `build/`. Include screenshots for visible `public/` changes and mention affected providers when transform behavior changes.
|
||
|
||
## Contributor Notes
|
||
|
||
Do not edit generated provider files directly unless you are intentionally patching generated output as part of a build-system change. Prefer fixing the root source in `source/`, `scripts/`, or `src/`, then regenerate artifacts.
|