kernelbot 1.0.22 → 1.0.24

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,235 @@
1
+ # Core Craft Principles
2
+
3
+ These apply regardless of design direction. This is the quality floor.
4
+
5
+ ---
6
+
7
+ ## Surface & Token Architecture
8
+
9
+ Professional interfaces don't pick colors randomly — they build systems. Understanding this architecture is the difference between "looks okay" and "feels like a real product."
10
+
11
+ ### The Primitive Foundation
12
+
13
+ Every color in your interface should trace back to a small set of primitives:
14
+
15
+ - **Foreground** — text colors (primary, secondary, muted)
16
+ - **Background** — surface colors (base, elevated, overlay)
17
+ - **Border** — edge colors (default, subtle, strong)
18
+ - **Brand** — your primary accent
19
+ - **Semantic** — functional colors (destructive, warning, success)
20
+
21
+ Don't invent new colors. Map everything to these primitives.
22
+
23
+ ### Surface Elevation Hierarchy
24
+
25
+ Surfaces stack. A dropdown sits above a card which sits above the page. Build a numbered system:
26
+
27
+ ```
28
+ Level 0: Base background (the app canvas)
29
+ Level 1: Cards, panels (same visual plane as base)
30
+ Level 2: Dropdowns, popovers (floating above)
31
+ Level 3: Nested dropdowns, stacked overlays
32
+ Level 4: Highest elevation (rare)
33
+ ```
34
+
35
+ In dark mode, higher elevation = slightly lighter. In light mode, higher elevation = slightly lighter or uses shadow. The principle: **elevated surfaces need visual distinction from what's beneath them.**
36
+
37
+ ### The Subtlety Principle
38
+
39
+ This is where most interfaces fail. Study Vercel, Supabase, Linear — their surfaces are **barely different** but still distinguishable. Their borders are **light but not invisible**.
40
+
41
+ **For surfaces:** The difference between elevation levels should be subtle — a few percentage points of lightness, not dramatic jumps. In dark mode, surface-100 might be 7% lighter than base, surface-200 might be 9%, surface-300 might be 12%. You can barely see it, but you feel it.
42
+
43
+ **For borders:** Borders should define regions without demanding attention. Use low opacity (0.05-0.12 alpha for dark mode, slightly higher for light). The border should disappear when you're not looking for it, but be findable when you need to understand the structure.
44
+
45
+ **The test:** Squint at your interface. You should still perceive the hierarchy — what's above what, where regions begin and end. But no single border or surface should jump out at you. If borders are the first thing you notice, they're too strong. If you can't find where one region ends and another begins, they're too subtle.
46
+
47
+ **Common AI mistakes to avoid:**
48
+ - Borders that are too visible (1px solid gray instead of subtle rgba)
49
+ - Surface jumps that are too dramatic (going from dark to light instead of dark to slightly-less-dark)
50
+ - Using different hues for different surfaces (gray card on blue background)
51
+ - Harsh dividers where subtle borders would do
52
+
53
+ ### Text Hierarchy via Tokens
54
+
55
+ Don't just have "text" and "gray text." Build four levels:
56
+
57
+ - **Primary** — default text, highest contrast
58
+ - **Secondary** — supporting text, slightly muted
59
+ - **Tertiary** — metadata, timestamps, less important
60
+ - **Muted** — disabled, placeholder, lowest contrast
61
+
62
+ Use all four consistently. If you're only using two, your hierarchy is too flat.
63
+
64
+ ### Border Progression
65
+
66
+ Borders aren't binary. Build a scale:
67
+
68
+ - **Default** — standard borders
69
+ - **Subtle/Muted** — softer separation
70
+ - **Strong** — emphasis, hover states
71
+ - **Stronger** — maximum emphasis, focus rings
72
+
73
+ Match border intensity to the importance of the boundary.
74
+
75
+ ### Dedicated Control Tokens
76
+
77
+ Form controls (inputs, checkboxes, selects) have specific needs. Don't just reuse surface tokens — create dedicated ones:
78
+
79
+ - **Control background** — often different from surface backgrounds
80
+ - **Control border** — needs to feel interactive
81
+ - **Control focus** — clear focus indication
82
+
83
+ This separation lets you tune controls independently from layout surfaces.
84
+
85
+ ### Context-Aware Bases
86
+
87
+ Different areas of your app might need different base surfaces:
88
+
89
+ - **Marketing pages** — might use darker/richer backgrounds
90
+ - **Dashboard/app** — might use neutral working backgrounds
91
+ - **Sidebar** — might differ from main canvas
92
+
93
+ The surface hierarchy works the same way — it just starts from a different base.
94
+
95
+ ### Alternative Backgrounds for Depth
96
+
97
+ Beyond shadows, use contrasting backgrounds to create depth. An "alternative" or "inset" background makes content feel recessed. Useful for:
98
+
99
+ - Empty states in data grids
100
+ - Code blocks
101
+ - Inset panels
102
+ - Visual grouping without borders
103
+
104
+ ---
105
+
106
+ ## Spacing System
107
+
108
+ Pick a base unit (4px and 8px are common) and use multiples throughout. The specific number matters less than consistency — every spacing value should be explainable as "X times the base unit."
109
+
110
+ Build a scale for different contexts:
111
+ - Micro spacing (icon gaps, tight element pairs)
112
+ - Component spacing (within buttons, inputs, cards)
113
+ - Section spacing (between related groups)
114
+ - Major separation (between distinct sections)
115
+
116
+ ## Symmetrical Padding
117
+
118
+ TLBR must match. If top padding is 16px, left/bottom/right must also be 16px. Exception: when content naturally creates visual balance.
119
+
120
+ ```css
121
+ /* Good */
122
+ padding: 16px;
123
+ padding: 12px 16px; /* Only when horizontal needs more room */
124
+
125
+ /* Bad */
126
+ padding: 24px 16px 12px 16px;
127
+ ```
128
+
129
+ ## Border Radius Consistency
130
+
131
+ Sharper corners feel technical, rounder corners feel friendly. Pick a scale that fits your product's personality and use it consistently.
132
+
133
+ The key is having a system: small radius for inputs and buttons, medium for cards, large for modals or containers. Don't mix sharp and soft randomly — inconsistent radius is as jarring as inconsistent spacing.
134
+
135
+ ## Depth & Elevation Strategy
136
+
137
+ Match your depth approach to your design direction. Choose ONE and commit:
138
+
139
+ **Borders-only (flat)** — Clean, technical, dense. Works for utility-focused tools where information density matters more than visual lift. Linear, Raycast, and many developer tools use almost no shadows — just subtle borders to define regions.
140
+
141
+ **Subtle single shadows** — Soft lift without complexity. A simple `0 1px 3px rgba(0,0,0,0.08)` can be enough. Works for approachable products that want gentle depth.
142
+
143
+ **Layered shadows** — Rich, premium, dimensional. Multiple shadow layers create realistic depth. Stripe and Mercury use this approach. Best for cards that need to feel like physical objects.
144
+
145
+ **Surface color shifts** — Background tints establish hierarchy without any shadows. A card at `#fff` on a `#f8fafc` background already feels elevated.
146
+
147
+ ```css
148
+ /* Borders-only approach */
149
+ --border: rgba(0, 0, 0, 0.08);
150
+ --border-subtle: rgba(0, 0, 0, 0.05);
151
+ border: 0.5px solid var(--border);
152
+
153
+ /* Single shadow approach */
154
+ --shadow: 0 1px 3px rgba(0, 0, 0, 0.08);
155
+
156
+ /* Layered shadow approach */
157
+ --shadow-layered:
158
+ 0 0 0 0.5px rgba(0, 0, 0, 0.05),
159
+ 0 1px 2px rgba(0, 0, 0, 0.04),
160
+ 0 2px 4px rgba(0, 0, 0, 0.03),
161
+ 0 4px 8px rgba(0, 0, 0, 0.02);
162
+ ```
163
+
164
+ ## Card Layouts
165
+
166
+ Monotonous card layouts are lazy design. A metric card doesn't have to look like a plan card doesn't have to look like a settings card.
167
+
168
+ Design each card's internal structure for its specific content — but keep the surface treatment consistent: same border weight, shadow depth, corner radius, padding scale, typography.
169
+
170
+ ## Isolated Controls
171
+
172
+ UI controls deserve container treatment. Date pickers, filters, dropdowns — these should feel like crafted objects.
173
+
174
+ **Never use native form elements for styled UI.** Native `<select>`, `<input type="date">`, and similar elements render OS-native dropdowns that cannot be styled. Build custom components instead:
175
+
176
+ - Custom select: trigger button + positioned dropdown menu
177
+ - Custom date picker: input + calendar popover
178
+ - Custom checkbox/radio: styled div with state management
179
+
180
+ Custom select triggers must use `display: inline-flex` with `white-space: nowrap` to keep text and chevron icons on the same row.
181
+
182
+ ## Typography Hierarchy
183
+
184
+ Build distinct levels that are visually distinguishable at a glance:
185
+
186
+ - **Headlines** — heavier weight, tighter letter-spacing for presence
187
+ - **Body** — comfortable weight for readability
188
+ - **Labels/UI** — medium weight, works at smaller sizes
189
+ - **Data** — often monospace, needs `tabular-nums` for alignment
190
+
191
+ Don't rely on size alone. Combine size, weight, and letter-spacing to create clear hierarchy. If you squint and can't tell headline from body, the hierarchy is too weak.
192
+
193
+ ## Monospace for Data
194
+
195
+ Numbers, IDs, codes, timestamps belong in monospace. Use `tabular-nums` for columnar alignment. Mono signals "this is data."
196
+
197
+ ## Iconography
198
+
199
+ Icons clarify, not decorate — if removing an icon loses no meaning, remove it. Choose a consistent icon set and stick with it throughout the product.
200
+
201
+ Give standalone icons presence with subtle background containers. Icons next to text should align optically, not mathematically.
202
+
203
+ ## Animation
204
+
205
+ Keep it fast and functional. Micro-interactions (hover, focus) should feel instant — around 150ms. Larger transitions (modals, panels) can be slightly longer — 200-250ms.
206
+
207
+ Use smooth deceleration easing (ease-out variants). Avoid spring/bounce effects in professional interfaces — they feel playful, not serious.
208
+
209
+ ## Contrast Hierarchy
210
+
211
+ Build a four-level system: foreground (primary) → secondary → muted → faint. Use all four consistently.
212
+
213
+ ## Color Carries Meaning
214
+
215
+ Gray builds structure. Color communicates — status, action, emphasis, identity. Unmotivated color is noise. Color that reinforces the product's world is character.
216
+
217
+ ## Navigation Context
218
+
219
+ Screens need grounding. A data table floating in space feels like a component demo, not a product. Consider including:
220
+
221
+ - **Navigation** — sidebar or top nav showing where you are in the app
222
+ - **Location indicator** — breadcrumbs, page title, or active nav state
223
+ - **User context** — who's logged in, what workspace/org
224
+
225
+ When building sidebars, consider using the same background as the main content area. Rely on a subtle border for separation rather than different background colors.
226
+
227
+ ## Dark Mode
228
+
229
+ Dark interfaces have different needs:
230
+
231
+ **Borders over shadows** — Shadows are less visible on dark backgrounds. Lean more on borders for definition.
232
+
233
+ **Adjust semantic colors** — Status colors (success, warning, error) often need to be slightly desaturated for dark backgrounds.
234
+
235
+ **Same structure, different values** — The hierarchy system still applies, just with inverted values.
@@ -0,0 +1,48 @@
1
+ # Memory Management
2
+
3
+ When and how to update `.interface-design/system.md`.
4
+
5
+ ## When to Add Patterns
6
+
7
+ Add to system.md when:
8
+ - Component used 2+ times
9
+ - Pattern is reusable across the project
10
+ - Has specific measurements worth remembering
11
+
12
+ ## Pattern Format
13
+
14
+ ```markdown
15
+ ### Button Primary
16
+ - Height: 36px
17
+ - Padding: 12px 16px
18
+ - Radius: 6px
19
+ - Font: 14px, 500 weight
20
+ ```
21
+
22
+ ## Don't Document
23
+
24
+ - One-off components
25
+ - Temporary experiments
26
+ - Variations better handled with props
27
+
28
+ ## Pattern Reuse
29
+
30
+ Before creating a component, check system.md:
31
+ - Pattern exists? Use it.
32
+ - Need variation? Extend, don't create new.
33
+
34
+ Memory compounds: each pattern saved makes future work faster and more consistent.
35
+
36
+ ---
37
+
38
+ # Validation Checks
39
+
40
+ If system.md defines specific values, check consistency:
41
+
42
+ **Spacing** — All values multiples of the defined base?
43
+
44
+ **Depth** — Using the declared strategy throughout? (borders-only means no shadows)
45
+
46
+ **Colors** — Using defined palette, not random hex codes?
47
+
48
+ **Patterns** — Reusing documented patterns instead of creating new?
package/.env.example CHANGED
@@ -1,3 +1,6 @@
1
1
  ANTHROPIC_API_KEY=sk-ant-...
2
2
  TELEGRAM_BOT_TOKEN=123456:ABC-DEF...
3
3
  GITHUB_TOKEN=ghp_...
4
+ JIRA_BASE_URL=https://yourcompany.atlassian.net
5
+ JIRA_EMAIL=you@company.com
6
+ JIRA_API_TOKEN=your-jira-api-token
package/README.md CHANGED
@@ -1,31 +1,134 @@
1
1
  # KernelBot
2
2
 
3
- AI engineering agent a Telegram bot backed by Claude Sonnet with full OS control via tool use.
4
-
5
- Send a message in Telegram, and KernelBot will read files, write code, run commands, and respond with the results. It's your personal engineering assistant with direct access to your machine.
3
+ [kernelbot.io](https://kernelbot.io) | [npm](https://www.npmjs.com/package/kernelbot) | [GitHub](https://github.com/KernelCode/KERNEL)
4
+
5
+ AI engineering agent a Telegram bot backed by Claude with full OS control via tool use.
6
+
7
+ Send a message in Telegram, and KernelBot will read files, write code, run commands, browse the web, manage infrastructure, and respond with the results. It's your personal engineering assistant with direct access to your machine.
8
+
9
+ ## Features
10
+
11
+ - **Autonomous agent loop** — send one message and KernelBot chains tool calls until the task is done, no hand-holding needed
12
+ - **Full shell access** — run any command, install packages, build projects, run tests
13
+ - **File management** — read, write, and create files with automatic directory creation
14
+ - **Web browsing** — navigate pages, extract content, take screenshots, interact with forms and buttons (Puppeteer)
15
+ - **Git workflow** — clone repos, create branches, commit, push, and view diffs
16
+ - **GitHub integration** — create repos, open PRs, post code reviews, list and inspect pull requests
17
+ - **JIRA integration** — read tickets, search with JQL, list assigned/project tickets (Cloud + Server)
18
+ - **Claude Code sub-agent** — spawn a dedicated Claude Code CLI session for complex coding tasks (write, edit, debug, refactor)
19
+ - **Docker management** — list containers, read logs, exec into containers, run compose commands
20
+ - **Process control** — list, kill, and manage system processes and systemd services
21
+ - **System monitoring** — check CPU, RAM, disk usage, and read system logs
22
+ - **Networking** — make HTTP requests, check ports, test and reload nginx
23
+ - **Send images** — share screenshots and files directly in the Telegram chat
24
+ - **Conversation memory** — per-chat history that persists across restarts
25
+ - **Live status updates** — Claude Code activity consolidated into a single updating message instead of spam
26
+ - **Security built-in** — user allowlist, blocked paths, dangerous operation confirmation, audit logging, secret redaction
27
+ - **Zero config setup** — auto-detects config, prompts for missing credentials on first run
28
+ - **Credential management** — auto-prompts for missing API keys (GitHub, Anthropic, Telegram, JIRA) and saves them
6
29
 
7
30
  ## How It Works
8
31
 
9
32
  ```text
10
- You (Telegram) → KernelBot → Claude Sonnet (Anthropic API)
33
+ You (Telegram) → KernelBot → Claude (Anthropic API)
34
+
35
+ Tools (shell, files, git, docker, browser, etc.)
11
36
 
12
- OS Tools (shell, files, directories)
37
+ Claude Code CLI (coding tasks)
13
38
  ```
14
39
 
15
40
  KernelBot runs a **tool-use loop**: Claude decides which tools to call, KernelBot executes them on your OS, feeds results back, and Claude continues until the task is done. One message can trigger dozens of tool calls autonomously.
16
41
 
42
+ For complex coding tasks, KernelBot can spawn **Claude Code CLI** as a sub-agent — giving it a dedicated coding environment with its own tool loop for writing, editing, and debugging code.
43
+
17
44
  ## Tools
18
45
 
19
- | Tool | Description |
20
- | ----------------- | --------------------------------------------------- |
21
- | `execute_command` | Run any shell command (git, npm, python, etc.) |
22
- | `read_file` | Read file contents with optional line limits |
23
- | `write_file` | Write/create files, auto-creates parent directories |
24
- | `list_directory` | List directory contents, optionally recursive |
46
+ ### File System & Shell
47
+
48
+ | Tool | Description |
49
+ | --- | --- |
50
+ | `execute_command` | Run any shell command (git, npm, python, etc.) |
51
+ | `read_file` | Read file contents with optional line limits |
52
+ | `write_file` | Write/create files, auto-creates parent directories |
53
+ | `list_directory` | List directory contents, optionally recursive |
54
+
55
+ ### Git & GitHub
56
+
57
+ | Tool | Description |
58
+ | --- | --- |
59
+ | `git_clone` | Clone a repo (`org/repo` shorthand or full URL) |
60
+ | `git_checkout` | Checkout or create branches |
61
+ | `git_commit` | Stage all changes and commit |
62
+ | `git_push` | Push current branch to remote |
63
+ | `git_diff` | Show uncommitted changes |
64
+ | `github_create_pr` | Create a pull request |
65
+ | `github_get_pr_diff` | Get the diff of a PR |
66
+ | `github_post_review` | Post a review on a PR |
67
+ | `github_create_repo` | Create a new GitHub repository |
68
+ | `github_list_prs` | List pull requests for a repo |
69
+
70
+ ### Web Browsing
71
+
72
+ | Tool | Description |
73
+ | --- | --- |
74
+ | `browse_website` | Navigate to a URL and extract page content (title, headings, text, links) |
75
+ | `screenshot_website` | Take a screenshot of a website, supports full-page and element capture |
76
+ | `extract_content` | Extract specific content using CSS selectors |
77
+ | `interact_with_page` | Click, type, scroll, and run JS on a webpage |
78
+ | `send_image` | Send an image/screenshot directly to the Telegram chat |
79
+
80
+ ### JIRA
81
+
82
+ | Tool | Description |
83
+ | --- | --- |
84
+ | `jira_get_ticket` | Get details of a specific JIRA ticket |
85
+ | `jira_search_tickets` | Search tickets using JQL queries |
86
+ | `jira_list_my_tickets` | List tickets assigned to the current user |
87
+ | `jira_get_project_tickets` | Get tickets from a specific JIRA project |
88
+
89
+ ### Docker
90
+
91
+ | Tool | Description |
92
+ | --- | --- |
93
+ | `docker_ps` | List containers |
94
+ | `docker_logs` | Get container logs |
95
+ | `docker_exec` | Execute a command inside a running container |
96
+ | `docker_compose` | Run docker compose commands |
97
+
98
+ ### Process & System
99
+
100
+ | Tool | Description |
101
+ | --- | --- |
102
+ | `process_list` | List running processes, optionally filter by name |
103
+ | `kill_process` | Kill a process by PID or name |
104
+ | `service_control` | Manage systemd services (start, stop, restart, status) |
105
+
106
+ ### Monitoring
107
+
108
+ | Tool | Description |
109
+ | --- | --- |
110
+ | `disk_usage` | Show disk space usage |
111
+ | `memory_usage` | Show RAM usage |
112
+ | `cpu_usage` | Show CPU load |
113
+ | `system_logs` | Read system or application logs |
114
+
115
+ ### Networking
116
+
117
+ | Tool | Description |
118
+ | --- | --- |
119
+ | `check_port` | Check if a port is open and listening |
120
+ | `curl_url` | Make HTTP requests and return the response |
121
+ | `nginx_reload` | Test nginx config and reload if valid |
122
+
123
+ ### Coding
124
+
125
+ | Tool | Description |
126
+ | --- | --- |
127
+ | `spawn_claude_code` | Spawn Claude Code CLI for coding tasks — writing, fixing, reviewing, and scaffolding code |
25
128
 
26
129
  ## Disclaimer
27
130
 
28
- > **WARNING:** KernelBot has full access to your operating system. It can execute shell commands, read/write files, manage processes, control Docker containers, and interact with external services (GitHub, Telegram) on your behalf. Only run KernelBot on machines you own and control. Always configure `allowed_users` in production to restrict who can interact with the bot. The authors are not responsible for any damage caused by misuse.
131
+ > **WARNING:** KernelBot has full access to your operating system. It can execute shell commands, read/write files, manage processes, control Docker containers, browse the web, and interact with external services (GitHub, Telegram) on your behalf. Only run KernelBot on machines you own and control. Always configure `allowed_users` in production to restrict who can interact with the bot. The authors are not responsible for any damage caused by misuse.
29
132
 
30
133
  ## Installation
31
134
 
@@ -57,6 +160,10 @@ Set these in `.env` or as system environment variables:
57
160
  ```text
58
161
  ANTHROPIC_API_KEY=sk-ant-...
59
162
  TELEGRAM_BOT_TOKEN=123456:ABC-DEF...
163
+ GITHUB_TOKEN=ghp_... # optional, for GitHub tools
164
+ JIRA_BASE_URL=https://yourcompany.atlassian.net # optional, for JIRA tools
165
+ JIRA_EMAIL=you@company.com
166
+ JIRA_API_TOKEN=your-jira-api-token
60
167
  ```
61
168
 
62
169
  ### `config.yaml` (optional)
@@ -77,11 +184,21 @@ telegram:
77
184
  allowed_users: [] # empty = allow all (dev mode)
78
185
  # allowed_users: [123456789] # lock to specific Telegram user IDs
79
186
 
187
+ jira:
188
+ base_url: https://yourcompany.atlassian.net
189
+ email: you@company.com
190
+ api_token: your-api-token
191
+
80
192
  security:
81
193
  blocked_paths: # paths the agent cannot touch
82
194
  - /etc/shadow
83
195
  - /etc/passwd
84
196
 
197
+ claude_code:
198
+ max_turns: 50
199
+ timeout_seconds: 600
200
+ # model: claude-sonnet-4-20250514 # optional model override
201
+
85
202
  logging:
86
203
  level: info
87
204
  max_file_size: 5242880 # 5 MB
@@ -90,35 +207,81 @@ conversation:
90
207
  max_history: 50 # messages per chat
91
208
  ```
92
209
 
210
+ ## Telegram Commands
211
+
212
+ | Command | Description |
213
+ | --- | --- |
214
+ | `/clean` | Clear conversation and start fresh |
215
+ | `/history` | Show message count in memory |
216
+ | `/help` | Show help message |
217
+
93
218
  ## Security
94
219
 
95
220
  - **User allowlist** — restrict bot access to specific Telegram user IDs. Empty list = dev mode (anyone can use it).
96
221
  - **Blocked paths** — files/directories the agent is forbidden from reading or writing (e.g., `/etc/shadow`, SSH keys).
222
+ - **Dangerous operation confirmation** — destructive actions require user confirmation before execution.
223
+ - **Browser URL blocklist** — internal/private network addresses are blocked from browsing.
97
224
  - **Audit logging** — every tool call is logged to `kernel-audit.log` with user, tool, params, result, and duration. Secrets in params are automatically redacted.
98
225
  - **Command timeout** — shell commands are killed after 30 seconds by default.
99
226
 
227
+ ## JIRA Integration
228
+
229
+ KernelBot can read and search JIRA tickets. Supports both Atlassian Cloud (`*.atlassian.net`) and self-hosted JIRA Server instances.
230
+
231
+ ### Setup
232
+
233
+ 1. **Get an API token** — for Atlassian Cloud, generate one at [id.atlassian.net/manage-profile/security/api-tokens](https://id.atlassian.net/manage-profile/security/api-tokens). For JIRA Server, use your password or a personal access token.
234
+
235
+ 2. **Configure** via environment variables or `config.yaml`:
236
+
237
+ ```text
238
+ JIRA_BASE_URL=https://yourcompany.atlassian.net
239
+ JIRA_EMAIL=you@company.com
240
+ JIRA_API_TOKEN=your-api-token
241
+ ```
242
+
243
+ If credentials are missing when a JIRA tool is called, KernelBot will prompt for them via Telegram.
244
+
245
+ ### Available Tools
246
+
247
+ - **`jira_get_ticket`** — Fetch a single ticket by key (e.g. `PROJ-123`). Returns summary, description, status, assignee, priority, and dates.
248
+ - **`jira_search_tickets`** — Search using JQL (e.g. `project = PROJ AND status = "In Progress"`). Returns up to `max_results` tickets.
249
+ - **`jira_list_my_tickets`** — List tickets assigned to the current user (or a specified assignee).
250
+ - **`jira_get_project_tickets`** — List all tickets in a project, ordered by last update.
251
+
100
252
  ## Project Structure
101
253
 
102
254
  ```text
103
255
  KernelBot/
104
256
  ├── bin/
105
- │ └── kernel.js # Entry point
257
+ │ └── kernel.js # Entry point + CLI menu
106
258
  ├── src/
107
- │ ├── agent.js # Sonnet tool-use loop
108
- │ ├── bot.js # Telegram bot (polling, auth, message handling)
109
- │ ├── conversation.js # Per-chat conversation history
259
+ │ ├── agent.js # Claude tool-use loop
260
+ │ ├── bot.js # Telegram bot (polling, auth, message handling)
261
+ │ ├── coder.js # Claude Code CLI spawner + smart output
262
+ │ ├── conversation.js # Per-chat conversation history
110
263
  │ ├── prompts/
111
- │ │ └── system.js # System prompt
264
+ │ │ └── system.js # System prompt
112
265
  │ ├── security/
113
- │ │ ├── auth.js # User allowlist
114
- │ │ └── audit.js # Tool call audit logging
266
+ │ │ ├── auth.js # User allowlist
267
+ │ │ ├── audit.js # Tool call audit logging
268
+ │ │ └── confirm.js # Dangerous operation detection
115
269
  │ ├── tools/
116
- │ │ ├── os.js # OS tool definitions + handlers
117
- │ │ └── index.js # Tool registry + dispatcher
270
+ │ │ ├── os.js # File system + shell tools
271
+ │ │ ├── git.js # Git operations
272
+ │ │ ├── github.js # GitHub API (PRs, repos, reviews)
273
+ │ │ ├── browser.js # Web browsing (Puppeteer)
274
+ │ │ ├── docker.js # Docker management
275
+ │ │ ├── process.js # Process management
276
+ │ │ ├── monitor.js # System monitoring (CPU, RAM, disk)
277
+ │ │ ├── network.js # Network tools (HTTP, ports, nginx)
278
+ │ │ ├── coding.js # Claude Code CLI handler
279
+ │ │ ├── jira.js # JIRA ticket reading + search
280
+ │ │ └── index.js # Tool registry + dispatcher
118
281
  │ └── utils/
119
- │ ├── config.js # Config loading (auto-detect + prompt)
120
- │ ├── display.js # CLI display (logo, spinners, banners)
121
- │ └── logger.js # Winston logger
282
+ │ ├── config.js # Config loading (auto-detect + prompt)
283
+ │ ├── display.js # CLI display (logo, spinners, banners)
284
+ │ └── logger.js # Winston logger
122
285
  ├── config.example.yaml
123
286
  ├── .env.example
124
287
  └── package.json
@@ -129,6 +292,14 @@ KernelBot/
129
292
  - Node.js 18+
130
293
  - [Anthropic API key](https://console.anthropic.com/)
131
294
  - [Telegram Bot Token](https://t.me/BotFather)
295
+ - Chromium/Chrome (for browser tools — installed automatically by Puppeteer)
296
+ - [GitHub Token](https://github.com/settings/tokens) (optional, for GitHub tools)
297
+ - [JIRA API Token](https://id.atlassian.net/manage-profile/security/api-tokens) (optional, for JIRA integration)
298
+ - [Claude Code CLI](https://www.npmjs.com/package/@anthropic-ai/claude-code) (optional, for coding tasks)
299
+
300
+ ## License
301
+
302
+ MIT
132
303
 
133
304
  ## Author
134
305
 
@@ -20,6 +20,11 @@ github:
20
20
  default_branch: main
21
21
  # default_org: my-org
22
22
 
23
+ jira:
24
+ # base_url: https://yourcompany.atlassian.net # or self-hosted JIRA server URL
25
+ # email: you@company.com # JIRA account email (Cloud) or username (Server)
26
+ # api_token: your-api-token # API token from https://id.atlassian.net/manage-profile/security/api-tokens
27
+
23
28
  telegram:
24
29
  # List Telegram user IDs allowed to interact. Empty = allow all (dev mode).
25
30
  allowed_users: []
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "kernelbot",
3
- "version": "1.0.22",
3
+ "version": "1.0.24",
4
4
  "description": "KernelBot — AI engineering agent with full OS control",
5
5
  "type": "module",
6
6
  "author": "Abdullah Al-Taheri <abdullah@altaheri.me>",
@@ -24,7 +24,7 @@
24
24
  "bugs": {
25
25
  "url": "https://github.com/KernelCode/KernelBot/issues"
26
26
  },
27
- "homepage": "https://github.com/KernelCode/KernelBot#readme",
27
+ "homepage": "https://kernelbot.io",
28
28
  "license": "MIT",
29
29
  "dependencies": {
30
30
  "@anthropic-ai/sdk": "^0.39.0",
@@ -7,6 +7,7 @@ import { definitions as gitDefinitions, handlers as gitHandlers } from './git.js
7
7
  import { definitions as githubDefinitions, handlers as githubHandlers } from './github.js';
8
8
  import { definitions as codingDefinitions, handlers as codingHandlers } from './coding.js';
9
9
  import { definitions as browserDefinitions, handlers as browserHandlers } from './browser.js';
10
+ import { definitions as jiraDefinitions, handlers as jiraHandlers } from './jira.js';
10
11
  import { logToolCall } from '../security/audit.js';
11
12
  import { requiresConfirmation } from '../security/confirm.js';
12
13
 
@@ -20,6 +21,7 @@ export const toolDefinitions = [
20
21
  ...githubDefinitions,
21
22
  ...codingDefinitions,
22
23
  ...browserDefinitions,
24
+ ...jiraDefinitions,
23
25
  ];
24
26
 
25
27
  const handlerMap = {
@@ -32,6 +34,7 @@ const handlerMap = {
32
34
  ...githubHandlers,
33
35
  ...codingHandlers,
34
36
  ...browserHandlers,
37
+ ...jiraHandlers,
35
38
  };
36
39
 
37
40
  export function checkConfirmation(name, params, config) {