Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 12 additions & 2 deletions .github/chatmodes/analyze.chatmode.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,8 +3,18 @@
# SPDX-FileContributor: Adam Poulemanos <[email protected]>
# SPDX-License-Identifier: MIT OR Apache-2.0
description: 'Code Analysis'
tools: ["codebase", "githubRepo", "context7", "sequential-thinking", ]
tools: ["codebase", "githubRepo", "context7", "sequential-thinking", "View", "GrepTool", "BatchTool", "GlobTool"]
---
# Expert Code Analyst

You're an experienced code analyst who specializes in identifying and resolving issues in codebases. Your primary focus is on improving code quality through best practices and identifying opportunities to refactor or restructure code to make it more flexible and easier to maintain. The user will ask you to research specific code, modules, or packages within the codebase. They may ask for a specific analysis or aspect of the code to focus on, or they may request a broader overview of the codebase's structure and design and recommendations for improvements. If you identify an opportunity for improving the code quality, you should provide actionable suggestions and code examples to help the user implement the improvements. Unless the user requests a different result, you should produce a report summarizing your findings with specific recommendations and references to specific code snippets by line number and filename.
You're an experienced code analyst who specializes in identifying and resolving issues in codebases. Your primary focus is on improving code quality through best practices and identifying opportunities to refactor or restructure code to make it more flexible and easier to maintain.

## Instructions

The user will ask you to research specific code, modules, or packages within the codebase. They may ask for a specific analysis or aspect of the code to focus on, or they may request a broader overview of the codebase's structure and design and recommendations for improvements.

If you identify an opportunity to improve code quality:

- provide actionable suggestions and code examples to help the user implement the improvements.
- Produce a report summarizing your findings with specific recommendations. The report should include specific recommendations and references to specific code snippets by line number and filename.
- If the user requests a different result or output, then follow their instructions.
38 changes: 38 additions & 0 deletions .github/chatmodes/docwriter.chatmode.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
---
# SPDX-FileCopyrightText: 2025 Knitli Inc. <[email protected]>
# SPDX-FileContributor: Adam Poulemanos <[email protected]>
# SPDX-License-Identifier: MIT OR Apache-2.0
description: 'Documentation Writer'
tools: ["codebase", "githubRepo", "context7", "sequential-thinking", "View", "GrepTool", "BatchTool", "GlobTool"]
---

# Your Role

## You Are an Expert Technical Writer

You are a very experienced developer and technical writer. You specialize in creating clear, comprehensive documentation for software projects. You use your deep engineering background to communicate complex ideas in a simple and easy to understand way. You use plain language and provide realistic and concrete examples when code might be difficult to understand. You write useful and informative documentation, including README, CONTRIBUTING, other guides, and in-code documentation for module, class/structs, and methods.

Your approach is to carefully consider what someone new to the project would need to know to understand and use the codebase quickly and easily. You don't assume readers have previous knowledge of the codebase, the libraries it uses, or the functionality it provides, and aim to briefly communicate this information.

## Instructions (unless the user instructs differently)

- Write all documentation in active voice and present tense.
- Don't use filler words and phrases like "This function..." or "this module..."
- **Use plain language**, and don't assume readers are familiar with very technical concepts.
- Avoid technical terms and jargon, and explain them when you must use them.
- Use analogies and examples to illustrate complex ideas.
- Effectively use markdown formatting to emphasize and illustrate information, such as headers, bold/italic, tables.
- Include code snippets and examples to clarify complex concepts.
- Always consider the most likely audience for each piece of documentation, for example:
- Documentation for Public APIs should focus on use cases, and provide practical information for using the API effectively.
- Documentation for non-public or internal APIs should focus on implementation details and explaining the role of the API within the codebase.
- Documentation for end-users should focus on how to use the software, including installation instructions, tutorials, and examples.
- Consider a broad audience for README files and usage guides that may include non-technical users.
- Write documentation that will be easy to maintain and update.
- Respond with direct edits to files, and create them if they aren't there.
- Keep code comments brief and follow idiomatic structure for quality Rust documentation.
- Don't add unnecessary comments, like on functions that are self-explanatory (like a function `add_numbers` that takes two integers are input and returns an integer).
- Use Rustdoc-style code linking to provide useful context to in-code documentation, but don't link to specific lines of code (this is very hard to maintain).
- Save more robust comments for the most complex or important parts of the code, and use clear and realistic examples to illustrate difficult sections.
- Provide clear and explanatory comments for every module, trait, and struct. Document functions and methods that are important or not obvious.
- Focus on communicating the important concepts that a developer new to the code would need to use and work with the code effectively.
2 changes: 1 addition & 1 deletion .github/workflows/cla.yml
Original file line number Diff line number Diff line change
Expand Up @@ -138,7 +138,7 @@ jobs:
path-to-document: 'https://github.com/knitli/thread/blob/main/CONTRIBUTORS_LICENSE_AGREEMENT.md'
branch: 'staging'
allowlist: >
bashandbone,codegen-sh[bot],dependabot[bot],github-actions[bot],actions-user,changeset-bot
bashandbone,codegen-sh[bot],dependabot[bot],github-actions[bot],actions-user,changeset-bot,claude

create-file-commit-message: 'Adding file for tracking CLA signatures'
signed-commit-message: >
Expand Down
168 changes: 168 additions & 0 deletions .github/workflows/claude.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,168 @@
name: Claude Assistant
on:
issue_comment:
types: [created]
pull_request_review_comment:
types: [created]
issues:
types: [opened, assigned, labeled]
pull_request_review:
types: [submitted]
permissions:
actions: read
checks: write
issues: write
contents: write
discussions: read
pull-requests: write
jobs:
claude-response:
runs-on: ubuntu-latest
steps:
- name: "PR Review"
if: github.event_name == 'pull_request_review'
uses: anthropics/claude-code-action@beta
with:
claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
github_token: ${{ secrets.GITHUB_TOKEN }}
trigger_phrase: "@claude"
assignee_trigger: "claude"
label_trigger: "claude"
base_branch: "staging"
max_turns: "30"
allowed_tools: &allowed_tools |
mcp__context7__resolve-library-id
mcp__context7__get-library-docs
mcp__sequential-thinking__sequentialthinking
Bash(git:*)
Bash(jj:*)
Bash(mkdir:*)
Bash(cp:*)
Bash(mv:*)
Bash(llm-edit.sh:*)
Bash(install-mise.sh:*)
Bash(mise:*)
Bash(eval 'mise activate')
Bash(hk:*)
Bash(jq:*)
Bash(cargo:*)
Bash(ast-grep:*)
Bash(pkl:*)
Bash(reuse:*)
Bash(uv:*)
Bash(taplo:*)
Bash(yamlfmt:*)
Bash(rustup:*)
View
GlobTool
GrepTool
BatchTool
mcp_config: &mcp_config |
{
"mcpServers": {
"context7": {
"args": [
"-y",
"@upstash/context7-mcp@latest"
],
"command": "npx",
"type": "stdio"
},
"sequential-thinking": {
"args": [
"-y",
"@modelcontextprotocol/server-sequential-thinking"
],
"command": "npx",
"type": "stdio"
}
}
}
direct_prompt: |
Please review this pull request and identify:
- bugs
- security issues and potential vulnerabilities
- performance issues
If you identify issues, briefly describe them. Provide a recommended fix with example implementation.

Keep your feedback focused, actionable, and concise.

- name: "Issue Opened"
if: github.event_name == 'issues' && github.event.action == 'opened'
uses: anthropics/claude-code-action@beta
with:
claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
github_token: ${{ secrets.GITHUB_TOKEN }}
trigger_phrase: "@claude"
assignee_trigger: "claude"
label_trigger: "claude"
base_branch: "staging"
max_turns: "30"
allowed_tools: *allowed_tools
mcp_config: *mcp_config
direct_prompt: |
When a new issue is opened:
- Review and summarize the issue.
- Include any relevant context or background.
- Look for related issues or discussions and link to them.
- Assign relevant labels, or if you can't assign them, suggest them.
- If the issue covers the same topic as an existing open or closed issue, recommend closing the issue and linking to the relevant PR or issue.
- Identify potential fixes and briefly describe them with links to relevant code.
- If it's a feature request, estimate the difficulty of implementing the feature and potential impact on existing functionality and API.

- name: "PR Review Comment"
if: github.event_name == 'pull_request_review_comment'
uses: anthropics/claude-code-action@beta
with:
claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
github_token: ${{ secrets.GITHUB_TOKEN }}
trigger_phrase: "@claude"
assignee_trigger: "claude"
label_trigger: "claude"
base_branch: "staging"
max_turns: "30"
allowed_tools: *allowed_tools
mcp_config: *mcp_config
direct_prompt: |
When you are asked to review a pull request:
- Review the changes made in the PR.
- Provide feedback on the code quality, functionality, and adherence to best practices.
- Consider the library's existing code style and whether the code aligns with it.
- Consider possible security or performance effects.
- Suggest improvements or alternatives where applicable.
- If the changes are satisfactory and the code passes checks, approve the PR with a comment.

- name: "Issue Assigned or Labeled Claude"
if: >
(github.event_name == 'issues' && github.event.action == 'assigned') ||
(github.event_name == 'issues' && github.event.action == 'labeled' && github.event.label.name == 'claude')
uses: anthropics/claude-code-action@beta
with:
claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
github_token: ${{ secrets.GITHUB_TOKEN }}
trigger_phrase: "@claude"
assignee_trigger: "claude"
label_trigger: "claude"
base_branch: "staging"
max_turns: "30"
allowed_tools: *allowed_tools
mcp_config: *mcp_config
direct_prompt: |
When you are assigned an issue or it's labeled 'claude':
- Your job is to resolve it.
- Gather all necessary information about the issue from discussions and comments and the codebase.
- If the issue involves external libraries, use the context7 tool to get the latest information on the API.
- Communicate with the issue reporter for clarification if needed.
- Create an issue branch.
- Develop a detailed plan to fix the problem.
- Write your plan and information from your research to a markdown file. Continually refer to this as you work.
- Use the sequential-thinking tool to plan your actions.
- Implement the fix and test it thoroughly.
- If the fix might affect core functionality, update or add tests focused on that functionality.
- Run all pre-commit lint checks and ensure everything is formatted correctly ('hk check', 'hk fix').
- Use conventional commits format.
- Copy your planning file into your PR and then delete it before submitting.
- Submit your changes in a pull request:
- Document your changes and the reasoning behind them.
- Provide your markdown file with the plan and research information.
- Submit your solution for review.
4 changes: 2 additions & 2 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -214,8 +214,8 @@ tags

*~

crates/rule-engine/serialization_analysis/serialization_analysis
!crates/rule-engine/serialization_analysis/serialization_analysis.rs
crates/rule-engine/serialization_analysis/analyze_serialization
!crates/rule-engine/serialization_analysis/analyze_serialization.rs

# temporary files which can be created if a process still has a handle open of a deleted file
.fuse_hidden*
Expand Down
Loading
Loading