docs: fix textlint violations in documentation

.github/PULL_REQUEST_TEMPLATE.md

@@ -4,7 +4,7 @@
 
 ## Type of Change
 
-- [ ] Bug fix (non-breaking change fixing an issue)
+- [ ] Bugfix (non-breaking change fixing an issue)
 - [ ] Security fix (non-breaking change addressing a security issue)
 - [ ] Documentation (changes to documentation only)
 - [ ] Refactoring (non-breaking change improving code structure)
@@ -27,7 +27,7 @@
   - Key names are treated as opaque strings
   - No structural inference (`[]`, `.`, brackets, paths, etc.)
 - [ ] **No silent behavior**
-  - No merging, overwriting, auto-fixing, or implicit resolution
+  - No merging, overwriting, autofixing, or implicit resolution
   - All boundary violations are reported explicitly
 - [ ] **Boundary respected**
   - No validation, coercion, schema, framework conventions, or business logic

CHANGELOG.md

@@ -5,4 +5,4 @@ This project uses GitHub Releases as the single source of truth for all changes.
 For the full and authoritative change history, including breaking changes and migration notes,  
 please see: <https://github.com/roottool/safe-formdata/releases>
 
-No additional change log is maintained in this file.
+No additional changelog is maintained in this file.

README.md

@@ -38,7 +38,7 @@ It enforces strict rules on keys and forbids structural inference by design.
 ## Overview
 
 FormData is untyped and unstructured by nature.
-Many parsers attempt to infer structure or semantics from key naming conventions.
+Parsers often attempt to infer structure or semantics from key naming conventions.
 
 safe-formdata intentionally does not.
 
@@ -85,7 +85,7 @@ Security decisions and issue triage are based on the definitions in SECURITY.md.
 
 ## Design decisions (Why not?)
 
-safe-formdata intentionally omits several common features.
+safe-formdata intentionally omits the following common features.
 
 ### Why no structural inference?
 
@@ -197,7 +197,7 @@ if (result.data !== null) {
 }
 ```
 
-**Key points**
+### Key points
 
 - All values are `string | File` - no automatic type conversion
 - Use `data !== null` to check for success and narrow the type

SECURITY.md

@@ -25,7 +25,7 @@ Users must upgrade to the latest version to receive security patches.
 
 ## Public vs Private Reporting
 
-safe-formdata distinguishes clearly between **private vulnerability disclosure**
+safe-formdata distinguishes between **private vulnerability disclosure**
 and **public security discussion**.
 
 ### Private (Security Advisory)

docs/PUBLISHING.md

@@ -33,15 +33,15 @@ This runs the following steps.
 
 1. **Prepare Release PR**: Bump version → Create release branch → Open PR for review
 2. **Review & Merge**: Maintainer reviews and merges release PR to main
-3. **Publish**: Manual trigger of publish workflow → All checks run → NPM publish
+3. **Publish**: Manual trigger of publish workflow → All checks run → npm publish
 
 The publish workflow is defined in `.github/workflows/publish.yml` and runs the following steps:
 
 1. Setup environment (Bun + dependencies)
 2. **Validate and build package** (`bun run prepare:publish`)
-3. Setup Node.js for NPM
-4. Publish to NPM with provenance
-5. Create and push git tag
+3. Setup Node.js for npm
+4. Publish to npm with provenance
+5. Create and push Git tag
 6. Create GitHub Release (draft)
 
 ---

skills/boundary-validator/examples/bad-code.md

@@ -160,7 +160,7 @@ function parse(formData: FormData): any {
 // Violates: No silent behavior
 ```
 
-### ❌ Object.assign / Spread Operator
+### ❌ Object.assign / spread syntax
 
 ```typescript
 // ❌ WRONG: Using Object.assign (merges)
@@ -488,7 +488,7 @@ export type ParseResult =
 
 ---
 
-## Testing Anti-Patterns
+## Testing antipatterns
 
 ### ❌ Not Testing Forbidden Keys
 

skills/boundary-validator/references/api-contract.md

@@ -241,7 +241,7 @@ For complete versioning policy, see README.md Versioning section.
 
 ### Key Points
 
-- **Patch versions** (0.1.x): Bug fixes, no API changes
+- **Patch versions** (0.1.x): bugfixes, no API changes
 - **Minor versions** (0.x.0): Non-breaking additions (with caution in 0.x)
 - **Major versions** (1.0.0+): Breaking changes allowed
 
@@ -259,7 +259,7 @@ The following changes are **breaking** and require a major version bump:
 
 The following changes are **non-breaking** and allowed in minor/patch versions:
 
-- Bug fixes in parsing logic
+- Bugfixes in parsing logic
 - Performance improvements
 - Internal refactoring
 - Documentation improvements

skills/boundary-validator/references/validation-patterns.md

@@ -8,7 +8,7 @@ Use these patterns when reviewing code changes to safe-formdata.
 
 ## Detection Strategy
 
-When reviewing code, search for these anti-patterns.
+When reviewing code, search for these antipatterns.
 
 1. **Keyword search**: Look for suspicious method calls and operators
 2. **Control flow analysis**: Examine conditional logic related to keys
@@ -18,7 +18,7 @@ When reviewing code, search for these anti-patterns.
 
 ## Rule 1: Keys are Opaque Strings
 
-### Anti-Patterns to Detect
+### Antipatterns to Detect
 
 #### Pattern: Bracket Notation Parsing
 
@@ -82,7 +82,7 @@ if (key === "exact_key_name") {
 
 ## Rule 2: No Silent Behavior
 
-### Anti-Patterns to Detect
+### Antipatterns to Detect
 
 #### Pattern: Merge/Overwrite
 
@@ -151,7 +151,7 @@ for (const [key, value] of formData.entries()) {
 
 ## Rule 3: No Inference, No Convenience
 
-### Anti-Patterns to Detect
+### Antipatterns to Detect
 
 #### Pattern: Structural Inference
 
@@ -248,7 +248,7 @@ export function parse(formData: FormData): ParseResult {
 
 ## Rule 4: Explicit Issue Reporting
 
-### Anti-Patterns to Detect
+### Antipatterns to Detect
 
 #### Pattern: Throwing Exceptions
 
@@ -321,7 +321,7 @@ return { data, issues: [] };
 
 ## Security-Specific Patterns
 
-### Anti-Patterns to Detect
+### Antipatterns to Detect
 
 #### Pattern: Unsafe Object Creation
 
@@ -376,7 +376,7 @@ for (const [key, value] of formData.entries()) {
 
 ## API Contract Patterns
 
-### Anti-Patterns to Detect
+### Antipatterns to Detect
 
 #### Pattern: Function Overloads