feat: add 7 bundled starter skills and expand test suite to 92 tests

skills/coding/code_review_checklist/SKILL.md

@@ -0,0 +1,40 @@
+# Code Review Checklist
+
+## When to use this skill
+Conduct a structured, thorough review of a pull request that catches real bugs,
+security issues, and scope creep — without nitpicking style that tooling should enforce.
+
+## Approach
+1. Read the PR description first to understand the intent before reading a single line of code
+2. Check **correctness**: does the code actually do what the description claims?
+3. Check **security**: injection vectors, hardcoded secrets, unvalidated external input
+4. Check **error handling**: are failure paths explicit, recoverable, and logged?
+5. Check **test coverage**: do new tests exercise the new code paths?
+6. Check **readability**: are names self-documenting? Is complexity justified by the problem?
+7. Check **scope**: is anything included that is outside the stated goal of the PR?
+8. Leave comments that are actionable and specific — cite line numbers, propose alternatives
+
+## Tools used
+- **git diff**: review the exact changeset, not the full file
+- **static analysis / linter**: run before reviewing to filter out mechanical issues
+- **test runner**: verify the test suite passes locally on the branch
+
+## Known constraints
+- Mark comments as **Blocking** or **Suggestion** — never leave ambiguity about what must change
+- Approve only when all blocking issues are resolved
+- Do not request changes that belong in a separate PR
+
+## Known failure modes
+- Spending 80% of review time on style issues a formatter should catch
+- Approving without reading the tests — most bugs hide in untested paths
+- Conflating "I would have done it differently" with "this is wrong"
+- Blocking PRs on out-of-scope issues instead of opening a follow-up ticket
+
+## Examples
+### Good comment
+> **Blocking** — `user_id` comes from the query string but is interpolated directly
+> into the SQL string at line 42. Use a parameterised query instead:
+> `cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))`
+
+### Bad comment
+> "This could probably be written more cleanly."

skills/coding/code_review_checklist/metadata.json

@@ -0,0 +1,46 @@
+{
+  "id": "d4e5f6a7-b8c9-0123-def0-345678901234",
+  "version": 1,
+  "type": "skill",
+  "domains": {
+    "coding": 0.92,
+    "ops": 0.3
+  },
+  "task_type": "code_review_checklist",
+  "content": {
+    "steps": [
+      "Read the PR description to understand intent before reading code",
+      "Check correctness: does the code do what the description claims?",
+      "Check for security issues: injection, hardcoded secrets, unvalidated input",
+      "Check error handling: are failure paths explicit and recoverable?",
+      "Check test coverage: are new code paths exercised by new tests?",
+      "Check readability: are names self-documenting? Is complexity justified?",
+      "Check for unnecessary scope creep beyond the stated goal",
+      "Leave actionable, specific comments — never vague praise or criticism"
+    ],
+    "tools_used": ["git diff", "static analysis", "linter"],
+    "constraints": [
+      "distinguish blocking issues from suggestions",
+      "approve only when blocking issues are resolved",
+      "do not request changes that are out of scope for the PR"
+    ],
+    "failure_modes": [
+      "nitpicking style over catching logic bugs",
+      "approving without reading tests",
+      "conflating personal preference with correctness",
+      "blocking on formatting issues that a linter should enforce"
+    ]
+  },
+  "outcome_quality": 4.1,
+  "confidence": 0.85,
+  "reuse_count": 0,
+  "success_rate": null,
+  "scope": "team",
+  "status": "active",
+  "created_at": "2026-05-25T10:00:00Z",
+  "expires_at": "2026-11-25T10:00:00Z",
+  "last_reinforced": null,
+  "transfer_domains": [],
+  "transfer_confidence": null,
+  "evolution_gen": 0
+}

skills/coding/refactor_for_readability/SKILL.md

@@ -0,0 +1,54 @@
+# Refactor for Readability
+
+## When to use this skill
+Improve the clarity of existing code without changing its behaviour — targeting
+naming, function length, nesting depth, or mixed abstraction levels.
+
+## Approach
+1. Confirm full test coverage **before touching any code** — refactoring without tests is rewriting
+2. Identify the primary readability problem: naming, length, nesting, or abstraction mismatch
+3. Rename variables and functions to reflect their purpose, not their type or shape
+4. Extract long functions at natural seams — each function should do one thing at one level
+5. Flatten deep nesting with early returns and guard clauses
+6. Remove dead code: commented-out blocks, unused imports, unreachable branches
+7. Run all tests after **each atomic change** to catch accidental behaviour drift
+8. If a bug is found during refactoring, stop — open a separate fix PR first
+
+## Tools used
+- **pytest**: run after every atomic change
+- **rope**: safe automated rename and extract-function refactoring
+- **ast**: inspect the parse tree for structural issues before editing
+
+## Known constraints
+- Zero behaviour change — this is the hard rule
+- Commit each atomic step separately so `git bisect` can isolate regressions
+- Never mix refactoring and feature changes in the same PR
+
+## Known failure modes
+- Breaking behaviour while renaming because tests weren't run in between
+- Over-abstracting simple, linear code into layers of indirection
+- Renaming to shorter identifiers that lose domain meaning (`process` instead of `validate_invoice_totals`)
+- Bundling unrelated cleanup into one massive commit that is impossible to review
+
+## Examples
+### Good output pattern
+**Before:**
+```python
+def f(d):
+    if d is not None:
+        if d.get('type') == 'invoice':
+            if d.get('total') > 0:
+                return True
+    return False
+```
+**After:**
+```python
+def is_valid_invoice(document: dict) -> bool:
+    if document is None:
+        return False
+    return document.get("type") == "invoice" and document.get("total", 0) > 0
+```
+
+### Bad output pattern
+Renaming `process_data()` to `p()` to save keystrokes, or extracting a two-line
+function into a class with three layers of inheritance.

skills/coding/refactor_for_readability/metadata.json

@@ -0,0 +1,46 @@
+{
+  "id": "e5f6a7b8-c9d0-1234-ef01-456789012345",
+  "version": 1,
+  "type": "skill",
+  "domains": {
+    "coding": 0.9,
+    "ops": 0.15
+  },
+  "task_type": "refactor_for_readability",
+  "content": {
+    "steps": [
+      "Ensure full test coverage before touching any code",
+      "Identify the primary readability issue: naming, length, nesting, or mixed abstraction levels",
+      "Rename variables and functions to reflect their purpose, not their type",
+      "Extract long functions at natural seams — each function should do one thing",
+      "Flatten deep nesting with early returns or guard clauses",
+      "Remove dead code, commented-out blocks, and unused imports",
+      "Run all tests after each atomic change to catch accidental behaviour change",
+      "Do not change behaviour — open a separate PR if a bug is found"
+    ],
+    "tools_used": ["pytest", "rope", "ast"],
+    "constraints": [
+      "no behaviour change — refactor only",
+      "commit at each atomic step for easy bisect",
+      "do not mix refactor and feature in one PR"
+    ],
+    "failure_modes": [
+      "breaking behaviour while renaming — always run tests in between",
+      "over-abstracting simple code into frameworks",
+      "renaming to shorter names that lose meaning",
+      "mixing unrelated cleanup into one large commit"
+    ]
+  },
+  "outcome_quality": 4.0,
+  "confidence": 0.83,
+  "reuse_count": 0,
+  "success_rate": null,
+  "scope": "team",
+  "status": "active",
+  "created_at": "2026-05-25T10:00:00Z",
+  "expires_at": "2026-11-25T10:00:00Z",
+  "last_reinforced": null,
+  "transfer_domains": [],
+  "transfer_confidence": null,
+  "evolution_gen": 0
+}

skills/coding/write_unit_test/SKILL.md

@@ -0,0 +1,51 @@
+# Write Unit Test
+
+## When to use this skill
+Write focused, deterministic unit tests for a function or method that verify
+behaviour — not implementation — and will catch real regressions.
+
+## Approach
+1. Identify the function's contract: inputs, outputs, and observable side effects
+2. List cases: happy path, boundary values, invalid inputs, known failure modes
+3. Write one test per behaviour with a name that reads as a sentence:
+   `test_<function>_<condition>_<expected_result>`
+4. Assert only on outputs and observable side effects — never on internal state
+5. Mock only at external boundaries (I/O, network, clock); never mock the unit itself
+6. Run the test to confirm it **fails** before the implementation is correct, then passes after
+
+## Tools used
+- **pytest**: test runner and assertion library
+- **unittest.mock**: patching external dependencies at the boundary
+- **hypothesis**: property-based testing for boundary and fuzz cases
+
+## Known constraints
+- One assertion focus per test — split multi-concern tests
+- Tests must be fully independent: no shared mutable state, no ordering assumptions
+- Tests must be deterministic: freeze time, seed random, mock network
+
+## Known failure modes
+- Testing implementation details (private methods, internal state) — breaks on refactor
+- Over-mocking causes tests that always pass but never catch real bugs
+- Shared mutable fixtures causing order-dependent test failures
+- Asserting on log output or print statements instead of return values
+
+## Examples
+### Good output pattern
+```python
+def test_parse_date_iso_format_returns_date_object():
+    result = parse_date("2026-01-15")
+    assert result == date(2026, 1, 15)
+
+def test_parse_date_invalid_string_raises_value_error():
+    with pytest.raises(ValueError, match="Invalid date"):
+        parse_date("not-a-date")
+```
+
+### Bad output pattern
+```python
+def test_parse_date():
+    # Tests three different things, unclear what fails
+    assert parse_date("2026-01-15") == date(2026, 1, 15)
+    assert parse_date("") is None
+    assert parse_date("bad") is None
+```

skills/coding/write_unit_test/metadata.json

@@ -0,0 +1,46 @@
+{
+  "id": "c3d4e5f6-a7b8-9012-cdef-234567890123",
+  "version": 1,
+  "type": "skill",
+  "domains": {
+    "coding": 0.95,
+    "testing": 0.9
+  },
+  "task_type": "write_unit_test",
+  "content": {
+    "steps": [
+      "Identify the function's contract: inputs, outputs, and side effects",
+      "List the happy path, edge cases, and known failure modes",
+      "Write one test per behaviour — not one test per function",
+      "Use descriptive test names that read as sentences: test_<function>_<condition>_<expected>",
+      "Assert on outputs and observable side effects only — not internal state",
+      "Mock only external dependencies (I/O, network, time); never mock the unit under test",
+      "Run the test in isolation to confirm it fails before the fix and passes after"
+    ],
+    "tools_used": ["pytest", "unittest.mock", "hypothesis"],
+    "constraints": [
+      "one assertion focus per test",
+      "no test-to-test dependencies",
+      "tests must be deterministic",
+      "mock at the boundary, not inside the unit"
+    ],
+    "failure_modes": [
+      "testing implementation details instead of behaviour",
+      "over-mocking causing tests that never catch real bugs",
+      "shared mutable state between tests causing order-dependent failures",
+      "asserting on log output instead of return values or side effects"
+    ]
+  },
+  "outcome_quality": 4.3,
+  "confidence": 0.88,
+  "reuse_count": 0,
+  "success_rate": null,
+  "scope": "team",
+  "status": "active",
+  "created_at": "2026-05-25T10:00:00Z",
+  "expires_at": "2026-11-25T10:00:00Z",
+  "last_reinforced": null,
+  "transfer_domains": [],
+  "transfer_confidence": null,
+  "evolution_gen": 0
+}

skills/general/api_integration_debugging/SKILL.md

@@ -0,0 +1,41 @@
+# API Integration Debugging
+
+## When to use this skill
+Diagnose a broken or misbehaving integration with an external HTTP API — covering
+auth failures, request shape errors, network issues, and response parsing bugs.
+
+## Approach
+1. Capture the **raw** HTTP request and response: method, URL, headers, body, status code, latency
+2. Verify authentication: token present, not expired, has the required scope/permissions
+3. Compare the request shape against the API spec: method, path, content-type, required fields, encoding
+4. Reproduce the failure with a minimal `curl` or `httpx` call **outside the application** to isolate app vs. API
+5. Check for network-layer issues: DNS resolution, TLS certificate validity, proxy config, firewall rules
+6. Review rate limiting: check `Retry-After`, `X-RateLimit-*` headers; verify retry logic uses exponential backoff
+7. Validate response parsing: check whether the API changed its schema; compare against latest API changelog
+8. Add structured logging at the integration boundary for request ID, status, and latency
+
+## Tools used
+- **curl / httpx**: reproduce the request in isolation
+- **wireshark / mitmproxy**: inspect raw network traffic when headers alone are insufficient
+- **OpenAPI spec**: compare actual request against documented contract
+
+## Known constraints
+- Always reproduce outside the application before changing application code
+- Never log full authentication tokens — truncate to last 4 characters in logs
+- Check the API provider's status page and changelog before assuming a code bug
+
+## Known failure modes
+- Assuming auth is correct without verifying token scope — 403 ≠ 401
+- Ignoring `Retry-After` headers and hammering the API, triggering a cascade rate-limit ban
+- Not pinning API version, causing silent breaking changes on provider upgrade
+- Parsing errors caused by HTML error pages returned with status 200 OK
+
+## Examples
+### Good output pattern
+**Observation:** POST /v2/orders returns 422 Unprocessable Entity.  
+**Isolation:** curl reproduces it — app code not at fault.  
+**Root cause:** API now requires `currency` field (added in v2.3, released 2026-04-10).  
+**Fix:** Add `"currency": "USD"` to the request payload; pin to API version v2.3 in the client header.
+
+### Bad output pattern
+"The API is broken, let's add a retry loop until it works."

skills/general/api_integration_debugging/metadata.json

@@ -0,0 +1,46 @@
+{
+  "id": "b8c9d0e1-f2a3-4567-1234-789012345678",
+  "version": 1,
+  "type": "skill",
+  "domains": {
+    "coding": 0.8,
+    "ops": 0.75
+  },
+  "task_type": "api_integration_debugging",
+  "content": {
+    "steps": [
+      "Capture the raw HTTP request and response — headers, body, status code",
+      "Verify authentication: token present, not expired, correct scope",
+      "Check the request shape against the API spec: method, URL, content-type, required fields",
+      "Isolate the failure by reproducing with a minimal curl or httpx call outside the application",
+      "Check for network-layer issues: DNS, TLS cert, proxy, firewall",
+      "Review rate limiting and retry logic — check Retry-After headers",
+      "Validate response parsing — check for schema changes in the API response",
+      "Add structured logging for request/response at the integration boundary"
+    ],
+    "tools_used": ["curl", "httpx", "wireshark", "openapi spec"],
+    "constraints": [
+      "reproduce outside the app before blaming the app code",
+      "never log full auth tokens — truncate to last 4 chars",
+      "check API changelog before assuming a bug"
+    ],
+    "failure_modes": [
+      "assuming auth is correct without verifying the token scope",
+      "ignoring Retry-After headers causing cascade rate-limit failures",
+      "not pinning API version causing silent contract changes",
+      "parsing errors from HTML error pages returned as 200 OK"
+    ]
+  },
+  "outcome_quality": 4.1,
+  "confidence": 0.84,
+  "reuse_count": 0,
+  "success_rate": null,
+  "scope": "team",
+  "status": "active",
+  "created_at": "2026-05-25T10:00:00Z",
+  "expires_at": "2026-11-25T10:00:00Z",
+  "last_reinforced": null,
+  "transfer_domains": [],
+  "transfer_confidence": null,
+  "evolution_gen": 0
+}