ci: run editorconfig-checker

.github/workflows/checks.yml

@@ -10,8 +10,10 @@ jobs:
     steps:
       - name: Checkout the repository
         uses: actions/checkout@v7
-      - name: Check editorconfig
+      - name: Install editorconfig-checker
         uses: editorconfig-checker/action-editorconfig-checker@main
+      - name: Check editorconfig
+        run: editorconfig-checker
   package-json:
     runs-on: ubuntu-latest
     name: package.json

skills/codex/SKILL.md

@@ -132,16 +132,16 @@ Codex is powered by OpenAI models with their own knowledge cutoffs and limitatio
 
 When Codex is wrong:
 
-1. State your disagreement clearly to the user.
-2. Provide evidence: your own knowledge, web search, docs.
-3. Optionally resume the Codex session to discuss the disagreement. Be transparent about the sender: disclose your own actual model name, so Codex knows the follow-up comes from the AI agent coordinating the session rather than from the human user:
+1.  State your disagreement clearly to the user.
+2.  Provide evidence: your own knowledge, web search, docs.
+3.  Optionally resume the Codex session to discuss the disagreement. Be transparent about the sender: disclose your own actual model name, so Codex knows the follow-up comes from the AI agent coordinating the session rather than from the human user:
 
-   ```bash
-   echo "Follow-up from <your own model name>, the AI agent coordinating this session. I disagree with [X] because [evidence]. What's your take on this?" | codex exec --skip-git-repo-check resume --last 2>/dev/null
-   ```
+    ```bash
+    echo "Follow-up from <your own model name>, the AI agent coordinating this session. I disagree with [X] because [evidence]. What's your take on this?" | codex exec --skip-git-repo-check resume --last 2>/dev/null
+    ```
 
-4. Frame disagreements as discussions, not corrections — either AI could be wrong.
-5. Let the user decide how to proceed if there's genuine ambiguity.
+4.  Frame disagreements as discussions, not corrections — either AI could be wrong.
+5.  Let the user decide how to proceed if there's genuine ambiguity.
 
 ## Error Handling
 

skills/project/SKILL.md

@@ -32,15 +32,15 @@ Generate a project base from reference repositories: pick the closest references
 
 ## Process
 
-1. **Clarify the project profile if the user hasn't specified it.** You need four answers before generating:
-   - language: TypeScript or JavaScript;
-   - runtime: Node.js, frontend (browser), or both;
-   - structure: single package or pnpm monorepo;
-   - kind: published library or GitHub action (affects publishing/release setup).
-2. **Pick 1–2 references** from the table below that best match the profile.
-3. **Fetch the actual files** from the reference repos (e.g. `https://raw.githubusercontent.com/<org>/<repo>/HEAD/<path>`, or `gh api`) and use them as the source. References evolve; the fetched file wins over anything written in this skill.
-4. **Adapt** the copied files: project/package names, org and repo URLs, description, author, commitlint scopes, Node.js/pnpm versions (keep workflows in sync with `.tool-versions`). Drop files irrelevant to the profile (e.g. `pnpm-workspace.yaml` for a single package, `.size-limit.json` when bundle size doesn't matter).
-5. **Finish up:** `pnpm install`, `pnpm updateGitHooks`, then verify `pnpm test` passes.
+1.  **Clarify the project profile if the user hasn't specified it.** You need four answers before generating:
+    - language: TypeScript or JavaScript;
+    - runtime: Node.js, frontend (browser), or both;
+    - structure: single package or pnpm monorepo;
+    - kind: published library or GitHub action (affects publishing/release setup).
+2.  **Pick 1–2 references** from the table below that best match the profile.
+3.  **Fetch the actual files** from the reference repos (e.g. `https://raw.githubusercontent.com/<org>/<repo>/HEAD/<path>`, or `gh api`) and use them as the source. References evolve; the fetched file wins over anything written in this skill.
+4.  **Adapt** the copied files: project/package names, org and repo URLs, description, author, commitlint scopes, Node.js/pnpm versions (keep workflows in sync with `.tool-versions`). Drop files irrelevant to the profile (e.g. `pnpm-workspace.yaml` for a single package, `.size-limit.json` when bundle size doesn't matter).
+5.  **Finish up:** `pnpm install`, `pnpm updateGitHooks`, then verify `pnpm test` passes.
 
 ## References
 
@@ -96,16 +96,16 @@ All Node.js jobs: `pnpm/action-setup` → `actions/setup-node` with `cache: 'pnp
 Files to look for in references and generate, grouped by concern:
 
 ```
-Toolchain:   .tool-versions  .editorconfig  .gitignore
-Packages:    package.json  pnpm-workspace.yaml  packages/*/package.json
-TypeScript:  tsconfig.json  tsconfig.build.json  env.d.ts
-Lint:        oxlint.config.*  .npmpackagejsonlintrc.json
-Commits:     .commitlintrc.*  .czrc  .simple-git-hooks.json  .nano-staged.json
-Build/test:  vite.config.*  .size-limit.json
-Release:     .clean-publish  .simple-release.*
-GitHub:      .github/workflows/{checks,tests,commit,release}.yml  .github/renovate.json
-             .github/ISSUE_TEMPLATE/{config,bug-report,feature-request,question}.yml  .github/FUNDING.yml
-Docs:        README.md (badges: npm, node, dependencies, build)  LICENSE (MIT)
+Toolchain:    .tool-versions  .editorconfig  .gitignore
+Packages:     package.json  pnpm-workspace.yaml  packages/*/package.json
+TypeScript:   tsconfig.json  tsconfig.build.json  env.d.ts
+Lint:         oxlint.config.*  .npmpackagejsonlintrc.json
+Commits:      .commitlintrc.*  .czrc  .simple-git-hooks.json  .nano-staged.json
+Build/test:   vite.config.*  .size-limit.json
+Release:      .clean-publish  .simple-release.*
+GitHub:       .github/workflows/{checks,tests,commit,release}.yml  .github/renovate.json
+              .github/ISSUE_TEMPLATE/{config,bug-report,feature-request,question}.yml  .github/FUNDING.yml
+Docs:         README.md (badges: npm, node, dependencies, build)  LICENSE (MIT)
 ```
 
 `CHANGELOG.md` is generated by simple-release — don't create it by hand.