fix lint

Author: mdjastrzebski

.claude/skills/code-review/SKILL.md

@@ -23,6 +23,7 @@ Transform code reviews from gatekeeping to knowledge sharing through constructiv
 ### 1. The Review Mindset
 
 **Goals of Code Review:**
+
 - Catch bugs and edge cases
 - Ensure code maintainability
 - Share knowledge across team
@@ -31,6 +32,7 @@ Transform code reviews from gatekeeping to knowledge sharing through constructiv
 - Build team culture
 
 **Not the Goals:**
+
 - Show off knowledge
 - Nitpick formatting (use linters)
 - Block progress unnecessarily
@@ -39,6 +41,7 @@ Transform code reviews from gatekeeping to knowledge sharing through constructiv
 ### 2. Effective Feedback
 
 **Good Feedback is:**
+
 - Specific and actionable
 - Educational, not judgmental
 - Focused on the code, not the person
@@ -48,20 +51,21 @@ Transform code reviews from gatekeeping to knowledge sharing through constructiv
 ```markdown
 ❌ Bad: "This is wrong."
 ✅ Good: "This could cause a race condition when multiple users
-         access simultaneously. Consider using a mutex here."
+access simultaneously. Consider using a mutex here."
 
 ❌ Bad: "Why didn't you use X pattern?"
 ✅ Good: "Have you considered the Repository pattern? It would
-         make this easier to test. Here's an example: [link]"
+make this easier to test. Here's an example: [link]"
 
 ❌ Bad: "Rename this variable."
 ✅ Good: "[nit] Consider `userCount` instead of `uc` for
-         clarity. Not blocking if you prefer to keep it."
+clarity. Not blocking if you prefer to keep it."
 ```
 
 ### 3. Review Scope
 
 **What to Review:**
+
 - Logic correctness and edge cases
 - Security vulnerabilities
 - Performance implications
@@ -72,6 +76,7 @@ Transform code reviews from gatekeeping to knowledge sharing through constructiv
 - Architectural fit
 
 **What Not to Review Manually:**
+
 - Code formatting (use Prettier, Black, etc.)
 - Import organization
 - Linting violations
@@ -159,20 +164,23 @@ For each file:
 
 ```markdown
 ## Security Checklist
+
 - [ ] User input validated and sanitized
 - [ ] SQL queries use parameterization
 - [ ] Authentication/authorization checked
 - [ ] Secrets not hardcoded
 - [ ] Error messages don't leak info
 
 ## Performance Checklist
+
 - [ ] No N+1 queries
 - [ ] Database queries indexed
 - [ ] Large lists paginated
 - [ ] Expensive operations cached
 - [ ] No blocking I/O in hot paths
 
 ## Testing Checklist
+
 - [ ] Happy path tested
 - [ ] Edge cases covered
 - [ ] Error cases tested
@@ -193,28 +201,28 @@ Instead of stating problems, ask questions to encourage thinking:
 
 ❌ "This is inefficient."
 ✅ "I see this loops through all users. Have we considered
-    the performance impact with 100k users?"
+the performance impact with 100k users?"
 ```
 
 ### Technique 3: Suggest, Don't Command
 
-```markdown
+````markdown
 ## Use Collaborative Language
 
 ❌ "You must change this to use async/await"
 ✅ "Suggestion: async/await might make this more readable:
-    ```typescript
+`typescript
     async function fetchUser(id: string) {
         const user = await db.query('SELECT * FROM users WHERE id = ?', id);
         return user;
     }
-    ```
-    What do you think?"
+    `
+What do you think?"
 
 ❌ "Extract this into a function"
 ✅ "This logic appears in 3 places. Would it make sense to
-    extract it into a shared utility function?"
-```
+extract it into a shared utility function?"
+````
 
 ### Technique 4: Differentiate Severity
 
@@ -230,7 +238,7 @@ Use labels to indicate priority:
 
 Example:
 "🔴 [blocking] This SQL query is vulnerable to injection.
- Please use parameterized queries."
+Please use parameterized queries."
 
 "🟢 [nit] Consider renaming `data` to `userData` for clarity."
 
@@ -389,24 +397,28 @@ test('displays incremented count when clicked', () => {
 ## Security Review Checklist
 
 ### Authentication & Authorization
+
 - [ ] Is authentication required where needed?
 - [ ] Are authorization checks before every action?
 - [ ] Is JWT validation proper (signature, expiry)?
 - [ ] Are API keys/secrets properly secured?
 
 ### Input Validation
+
 - [ ] All user inputs validated?
 - [ ] File uploads restricted (size, type)?
 - [ ] SQL queries parameterized?
 - [ ] XSS protection (escape output)?
 
 ### Data Protection
+
 - [ ] Passwords hashed (bcrypt/argon2)?
 - [ ] Sensitive data encrypted at rest?
 - [ ] HTTPS enforced for sensitive data?
 - [ ] PII handled according to regulations?
 
 ### Common Vulnerabilities
+
 - [ ] No eval() or similar dynamic execution?
 - [ ] No hardcoded secrets?
 - [ ] CSRF protection for state-changing operations?
@@ -444,14 +456,14 @@ When author disagrees with your feedback:
 
 1. **Seek to Understand**
    "Help me understand your approach. What led you to
-    choose this pattern?"
+   choose this pattern?"
 
 2. **Acknowledge Valid Points**
    "That's a good point about X. I hadn't considered that."
 
 3. **Provide Data**
    "I'm concerned about performance. Can we add a benchmark
-    to validate the approach?"
+   to validate the approach?"
 
 4. **Escalate if Needed**
    "Let's get [architect/senior dev] to weigh in on this."
@@ -488,25 +500,31 @@ When author disagrees with your feedback:
 
 ```markdown
 ## Summary
+
 [Brief overview of what was reviewed]
 
 ## Strengths
+
 - [What was done well]
 - [Good patterns or approaches]
 
 ## Required Changes
+
 🔴 [Blocking issue 1]
 🔴 [Blocking issue 2]
 
 ## Suggestions
+
 💡 [Improvement 1]
 💡 [Improvement 2]
 
 ## Questions
+
 ❓ [Clarification needed on X]
 ❓ [Alternative approach consideration]
 
 ## Verdict
+
 ✅ Approve after addressing required changes
 ```
 
@@ -517,4 +535,4 @@ When author disagrees with your feedback:
 - **references/security-review-guide.md**: Security-focused review checklist
 - **assets/pr-review-template.md**: Standard review comment template
 - **assets/review-checklist.md**: Quick reference checklist
-- **scripts/pr-analyzer.py**: Analyze PR complexity and suggest reviewers
+- **scripts/pr-analyzer.py**: Analyze PR complexity and suggest reviewers

.claude/skills/doc-coauthoring/SKILL.md

@@ -10,6 +10,7 @@ This skill provides a structured workflow for guiding users through collaborativ
 ## When to Offer This Workflow
 
 **Trigger conditions:**
+
 - User mentions writing documentation: "write a doc", "draft a proposal", "create a spec", "write up"
 - User mentions specific doc types: "PRD", "design doc", "decision doc", "RFC"
 - User seems to be starting a substantial writing task
@@ -42,18 +43,21 @@ Start by asking the user for meta-context about the document:
 Inform them they can answer in shorthand or dump information however works best for them.
 
 **If user provides a template or mentions a doc type:**
+
 - Ask if they have a template document to share
 - If they provide a link to a shared document, use the appropriate integration to fetch it
 - If they provide a file, read it
 
 **If user mentions editing an existing shared document:**
+
 - Use the appropriate integration to read the current state
 - Check for images without alt-text
 - If images exist without alt-text, explain that when others use Claude to understand the doc, Claude won't be able to see them. Ask if they want alt-text generated. If so, request they paste each image into chat for descriptive alt-text generation.
 
 ### Info Dumping
 
 Once initial questions are answered, encourage the user to dump all the context they have. Request information such as:
+
 - Background on the project/problem
 - Related team discussions or shared documents
 - Why alternative solutions aren't being used
@@ -63,6 +67,7 @@ Once initial questions are answered, encourage the user to dump all the context
 - Stakeholder concerns
 
 Advise them not to worry about organizing it - just get it all out. Offer multiple ways to provide context:
+
 - Info dump stream-of-consciousness
 - Point to team channels or threads to read
 - Link to shared documents
@@ -107,6 +112,7 @@ If user wants to add more, let them. When ready, proceed to Stage 2.
 
 **Instructions to user:**
 Explain that the document will be built section by section. For each section:
+
 1. Clarifying questions will be asked about what to include
 2. 5-20 options will be brainstormed
 3. User will indicate what to keep/remove/combine
@@ -162,6 +168,7 @@ Inform them they can answer in shorthand or just indicate what's important to co
 ### Step 2: Brainstorming
 
 For the [SECTION NAME] section, brainstorm [5-20] things that might be included, depending on the section's complexity. Look for:
+
 - Context shared that might have been forgotten
 - Angles or considerations not yet mentioned
 
@@ -172,6 +179,7 @@ Generate 5-20 numbered options based on section complexity. At the end, offer to
 Ask which points should be kept, removed, or combined. Request brief justifications to help learn priorities for the next sections.
 
 Provide examples:
+
 - "Keep 1,4,7,9"
 - "Remove 3 (duplicates 1)"
 - "Remove 6 (audience already knows this)"
@@ -205,6 +213,7 @@ Provide a note: Instead of editing the doc directly, ask them to indicate what t
 ### Step 6: Iterative Refinement
 
 As user provides feedback:
+
 - Use `str_replace` to make edits (never reprint the whole doc)
 - **If using artifacts:** Provide link to artifact after each edit
 - **If using files:** Just confirm edits are complete
@@ -223,6 +232,7 @@ When section is done, confirm [SECTION NAME] is complete. Ask if ready to move t
 ### Near Completion
 
 As approaching completion (80%+ of sections done), announce intention to re-read the entire document and check for:
+
 - Flow and consistency across sections
 - Redundancy or contradictions
 - Anything that feels like "slop" or generic filler
@@ -300,11 +310,13 @@ Generate 5-10 questions that readers would realistically ask.
 ### Step 2: Setup Testing
 
 Provide testing instructions:
+
 1. Open a fresh Claude conversation: https://claude.ai
 2. Paste or share the document content (if using a shared doc platform with connectors enabled, provide the link)
 3. Ask Reader Claude the generated questions
 
 For each question, instruct Reader Claude to provide:
+
 - The answer
 - Whether anything was ambiguous or unclear
 - What knowledge/context the doc assumes is already known
@@ -314,6 +326,7 @@ Check if Reader Claude gives correct answers or misinterprets anything.
 ### Step 3: Additional Checks
 
 Also ask Reader Claude:
+
 - "What in this doc might be ambiguous or unclear to readers?"
 - "What knowledge or context does this doc assume readers already have?"
 - "Are there any internal contradictions or inconsistencies?"
@@ -343,33 +356,39 @@ Ask if they want one more review, or if the work is done.
 
 **If user wants final review, provide it. Otherwise:**
 Announce document completion. Provide a few final tips:
+
 - Consider linking this conversation in an appendix so readers can see how the doc was developed
 - Use appendices to provide depth without bloating the main doc
 - Update the doc as feedback is received from real readers
 
 ## Tips for Effective Guidance
 
 **Tone:**
+
 - Be direct and procedural
 - Explain rationale briefly when it affects user behavior
 - Don't try to "sell" the approach - just execute it
 
 **Handling Deviations:**
+
 - If user wants to skip a stage: Ask if they want to skip this and write freeform
 - If user seems frustrated: Acknowledge this is taking longer than expected. Suggest ways to move faster
 - Always give user agency to adjust the process
 
 **Context Management:**
+
 - Throughout, if context is missing on something mentioned, proactively ask
 - Don't let gaps accumulate - address them as they come up
 
 **Artifact Management:**
+
 - Use `create_file` for drafting full sections
 - Use `str_replace` for all edits
 - Provide artifact link after every change
 - Never use artifacts for brainstorming lists - that's just conversation
 
 **Quality over Speed:**
+
 - Don't rush through stages
 - Each iteration should make meaningful improvements
 - The goal is a document that actually works for readers

AGENTS.md

@@ -63,15 +63,17 @@ The project uses `yarn` for dependency management and script execution.
 When users ask you to perform tasks, check if any of the available skills below can help complete the task more effectively. Skills provide specialized capabilities and domain knowledge.
 
 How to use skills:
+
 - Invoke: Bash("openskills read <skill-name>")
 - The skill content will load with detailed instructions on how to complete the task
 - Base directory provided in output for resolving bundled resources (references/, scripts/, assets/)
 
 Usage notes:
+
 - Only use skills listed in <available_skills> below
 - Do not invoke a skill that is already loaded in your context
 - Each skill invocation is stateless
-</usage>
+  </usage>
 
 <available_skills>
 
@@ -88,6 +90,7 @@ Usage notes:
 </skill>
 
 </available_skills>
+
 <!-- SKILLS_TABLE_END -->
 
 </skills_system>

website/docs/14.x/cookbook/basics/custom-render.md

@@ -16,12 +16,12 @@ interface RenderWithProvidersProps {
 
 export async function renderWithProviders<T>(
   ui: React.ReactElement<T>,
-  options?: RenderWithProvidersProps,
+  options?: RenderWithProvidersProps
 ) {
   return await render(
     <UserProvider.Provider value={options?.user ?? null}>
       <ThemeProvider.Provider value={options?.theme ?? 'light'}>{ui}</ThemeProvider.Provider>
-    </UserProvider.Provider>,
+    </UserProvider.Provider>
   );
 }
 ```