Apply the oss-init conventions and fix stale site links

.claude-plugin/marketplace.json

@@ -11,7 +11,7 @@
       "source": "./plugins/probitas",
       "description": "Probitas scenario testing framework integration",
       "category": "testing",
-      "homepage": "https://probitas-test.github.io/documents/"
+      "homepage": "https://probitas-test.github.io/"
     }
   ]
 }

.claude/commands/doc/update.md

@@ -8,18 +8,17 @@ description: Sync plugin content with latest Probitas documentation
 
    Use WebFetch to get the latest docs:
 
-   - https://probitas-test.github.io/documents/llms.txt
-   - https://probitas-test.github.io/documents/docs/scenario/index.md
-   - https://probitas-test.github.io/documents/docs/client/index.md
-   - https://probitas-test.github.io/documents/docs/expect/index.md
-   - https://probitas-test.github.io/documents/docs/configuration/index.md
+   - https://probitas-test.github.io/llms.txt
+   - https://probitas-test.github.io/docs/scenario/index.md
+   - https://probitas-test.github.io/docs/client/index.md
+   - https://probitas-test.github.io/docs/expect/index.md
+   - https://probitas-test.github.io/docs/configuration/index.md
 
 2. **Review and update plugin files**
 
    Compare fetched docs with current plugin content:
 
-   - `plugins/probitas/rules/*.md` - Conventions and guidelines
-   - `plugins/probitas/skills/probitas/SKILL.md` - Patterns and quick reference
+   - `plugins/probitas/skills/*/SKILL.md` - Patterns and quick reference
    - `plugins/probitas/commands/*.md` - Slash command definitions
    - `plugins/probitas/agents/*.md` - Agent definitions
 

.claude/rules/adr.md

@@ -0,0 +1,19 @@
+---
+paths: "docs/adr/**"
+---
+
+# Writing an ADR
+
+Before writing, fixing or reviewing a record in `docs/adr/`, read
+`docs/adr/README.md` and follow "How to write one" step by step. It is the
+whole rule; this file only makes sure it is read at the moment of writing.
+
+The three steps people skip:
+
+- Write the title first, as one sentence. It is the decision; everything else
+  restates it or follows from it.
+- Ask of every line: would changing this take a new record that supersedes
+  this one? If an ordinary change would do, the line is specification — leave
+  it out.
+- When fixing a record, rewrite it from the title. Do not edit the previous
+  draft.

.claude/rules/formatting.md

@@ -4,9 +4,10 @@ paths: "**/*.md, **/*.json"
 
 # Formatting Rules
 
-After modifying `*.md` or `*.json` files, run `deno fmt` to ensure consistent
-formatting.
+After modifying `*.md` or `*.json` files, run `just fmt` (which runs
+`deno fmt`) to ensure consistent formatting. `just ci` fails on unformatted
+files.
 
 ```bash
-deno fmt
+just fmt
 ```

.claude/rules/probitas-research.md

@@ -20,7 +20,7 @@ Check `plugins/probitas/` for existing documentation:
 
 If plugin resources don't cover the question:
 
-- **LLM Sitemap**: https://probitas-test.github.io/documents/llms.txt
+- **LLM Sitemap**: https://probitas-test.github.io/llms.txt
   - Comprehensive documentation optimized for AI consumption
   - Use WebFetch to retrieve specific sections
 

.claude/rules/spec.md

@@ -0,0 +1,21 @@
+---
+paths: "docs/spec/**"
+---
+
+# Writing a spec
+
+Before writing, fixing or reviewing a file in `docs/spec/`, read
+`docs/spec/README.md` and follow "How to write one". It is the whole rule;
+this file only makes sure it is read at the moment of writing.
+
+The checks people skip:
+
+- Ask of every line: can a test pin this down? Then it belongs in a test.
+  Would a user call a change to it a change in behaviour? If not, it is not
+  spec.
+- Numbered steps, mapping tables, other programs' file locations, exact
+  strings and ordering rules are candidates to take out — unless they
+  describe a format this project defines for others to write.
+- A review fix that does not change what a user sees does not touch the spec.
+- Do not copy the level of detail of neighbouring specs; they may be too
+  detailed themselves.

.envrc.sample

@@ -1 +1,2 @@
+# Copy to .envrc and run `direnv allow` to enter the Nix dev shell automatically.
 use flake

.gitattributes

@@ -0,0 +1,3 @@
+# Check text out with LF on every OS, so a Windows checkout builds and tests
+# the same bytes as the others.
+* text=auto eol=lf

.github/workflows/check.yml

@@ -6,16 +6,37 @@ on:
   pull_request:
     branches: [main]
 
+# A pull request only needs its latest commit checked. A run on main waits
+# for the one before it instead of cancelling it, so each one finishes and
+# saves the caches that pull requests start from.
+concurrency:
+  group: check-${{ github.ref }}
+  cancel-in-progress: ${{ github.event_name == 'pull_request' }}
+
+permissions:
+  contents: read
+
 jobs:
-  fmt:
-    name: Format
+  ci:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
-
-      - uses: denoland/setup-deno@v2
+      - uses: actions/checkout@v7
         with:
-          deno-version: v2.x
-
-      - name: Check formatting
-        run: deno fmt --check
+          persist-credentials: false
+      - uses: cachix/install-nix-action@v31
+        with:
+          extra_nix_config: |
+            experimental-features = nix-command flakes
+      # The store the development shell comes from. Only an exact match is
+      # restored, and only main saves, so pull requests cannot evict the
+      # caches each other start from.
+      - uses: nix-community/cache-nix-action@v7
+        with:
+          primary-key: nix-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('flake.nix', 'flake.lock') }}
+          save: ${{ github.ref == 'refs/heads/main' }}
+      # Load the development shell (flake.nix) into the job.
+      - uses: nicknovitski/nix-develop@v1
+      # The same gate as local development (justfile).
+      - run: just ci
+        env:
+          CI: "1"

.gitignore

@@ -1,2 +1,6 @@
 .DS_Store
 .coverage
+/.envrc
+.direnv/
+result
+/.claude/worktrees/

AGENTS.md

@@ -0,0 +1,74 @@
+# probitas-test Claude Plugins
+
+Official Claude Code plugin marketplace for
+[Probitas](https://probitas-test.github.io/) ecosystem.
+
+There is no build step: the plugins are Markdown and JSON.
+
+## How it is built
+
+- **Each layer holds one thing.** Put a fact in the one layer that owns it,
+  and nowhere else.
+
+  | Layer          | Holds                                                |
+  | -------------- | ---------------------------------------------------- |
+  | `docs/adr/`    | one decision and why it was made                     |
+  | `docs/spec/`   | the behaviour users and other components can rely on |
+  | Plugin content | the skills, commands and agents the plugins ship     |
+  | Commits        | why a change was made                                |
+
+  Before writing, fixing or reviewing a record, read `docs/adr/README.md`;
+  before writing, fixing or reviewing a spec, read `docs/spec/README.md`.
+  Follow their writing order.
+- **Dependencies are current.** Before adding or bumping one, look up its
+  latest release in the registry. Do not copy a version from memory or from
+  another repository.
+
+When editing anything under `plugins/`, follow
+[`.claude/rules/plugin-maintenance.md`](.claude/rules/plugin-maintenance.md).
+For questions about Probitas itself, follow
+[`.claude/rules/probitas-research.md`](.claude/rules/probitas-research.md).
+
+## Quality gate
+
+Run `just ci` before reporting a change as done. CI runs the same recipe. It
+checks the formatting of Markdown, JSON and Nix files and that every plugin
+manifest parses; `just fmt` fixes the formatting.
+
+## Layout
+
+| Path                              | What lives there                                                          |
+| --------------------------------- | ------------------------------------------------------------------------- |
+| `.claude-plugin/marketplace.json` | the marketplace definition                                                |
+| `plugins/probitas/`               | the Probitas plugin: `.claude-plugin/`, `skills/`, `commands/`, `agents/` |
+| `docs/`                           | ADRs and specs                                                            |
+| `.claude/`                        | this repository's own rules and commands                                  |
+| `.github/`                        | CI                                                                        |
+
+## Documentation source
+
+Plugin content is based on the Probitas documentation:
+
+- Site: https://probitas-test.github.io/
+- LLM sitemap: https://probitas-test.github.io/llms.txt
+
+Use `/doc:update` to sync the plugin content with the latest documentation.
+
+## Language
+
+- README, docs and commit messages: English
+- Plugin content and code comments: English
+
+## Commits
+
+[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), as
+described in [`.gitmessage`](.gitmessage) (install it with
+`git config commit.template .gitmessage`):
+
+```
+<type>[optional scope]: <description>
+```
+
+- Types: `feat`, `fix`, `deps`, `refactor`, `test`, `docs`, `style`, `chore`.
+- Scopes name the area touched, such as `probitas` (the plugin) or
+  `marketplace`.

docs/adr/README.md

@@ -0,0 +1,80 @@
+# Architecture Decision Records
+
+The significant decisions behind claude-plugins, one decision per file.
+
+## Conventions
+
+- Files are named `YYYYMMDD-<slug>.md` after the day the decision was made, so
+  listing the directory in name order lists the decisions in time order. Numbers
+  and an index are avoided because parallel changes would collide on them.
+- The slug is the title in kebab case, so a file name and its title always lead
+  to each other.
+- Each record has a status and the sections Context, Decision, Alternatives
+  considered and Consequences.
+- An accepted record is not rewritten. When the decision changes, a new record
+  supersedes it, and both say so in their status.
+- Records refer to each other by file name. A record does not link to the
+  specification, which keeps changing; the decision is complete within the
+  record.
+
+## What belongs in a record
+
+A record holds one decision, not everything decided while doing the work.
+
+For every line, ask: **if this changed, would it take a new record that
+supersedes this one?**
+
+- Yes — it is part of the decision. Keep it.
+- No, an ordinary change to the code or the specification would do — it is
+  specification or implementation. Leave it out.
+
+Formats, file locations, encodings, UI details and the order of steps almost
+always answer no.
+
+## How to write one
+
+Write in this order, and do not judge details line by line along the way:
+
+1. **Title** — the decision as one sentence. This sentence is the decision.
+2. **Decision** — restate the title, with only what the replacement test above
+   keeps.
+3. **Alternatives considered** — only options that would have replaced the
+   title's decision, each with why it was not taken.
+4. **Consequences** — only what follows directly from the decision.
+5. **Context** — only what a reader needs to see why the title was the answer.
+
+When a record under review needs fixing, rewrite it from the title without
+looking at the previous draft. Editing the draft keeps the details the new
+decision no longer needs.
+
+Before committing, apply the replacement test to every line once more.
+
+## Example
+
+This is the size to aim for.
+
+```markdown
+# Keep the user's words in a dictionary of their own
+
+Status: Accepted
+
+## Context
+
+Words the user registers were appended to the bundled dictionary. Every update
+replaces the bundled dictionary, so the user's words were lost.
+
+## Decision
+
+The user's words live in a separate dictionary that updates never touch.
+
+## Alternatives considered
+
+- Merge the user's words back into the bundled dictionary after each update.
+  A failed merge still loses them, and the two sources become impossible to
+  tell apart.
+
+## Consequences
+
+- Updates can replace the bundled dictionary wholesale.
+- Lookups consult two dictionaries.
+```