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.
- package/.agents/skills/interface-design/SKILL.md +391 -0
- package/.agents/skills/interface-design/references/critique.md +67 -0
- package/.agents/skills/interface-design/references/example.md +86 -0
- package/.agents/skills/interface-design/references/principles.md +235 -0
- package/.agents/skills/interface-design/references/validation.md +48 -0
- package/.env.example +3 -0
- package/README.md +195 -24
- package/config.example.yaml +5 -0
- package/package.json +2 -2
- package/src/tools/index.js +3 -0
- package/src/tools/jira.js +232 -0
- package/src/utils/config.js +32 -0
- package/src/utils/display.js +8 -10
- package/kernelbot/hello-world.md +0 -21
- package/kernelbot/newnew-1.md +0 -11
|
@@ -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
package/README.md
CHANGED
|
@@ -1,31 +1,134 @@
|
|
|
1
1
|
# KernelBot
|
|
2
2
|
|
|
3
|
-
|
|
4
|
-
|
|
5
|
-
|
|
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
|
|
33
|
+
You (Telegram) → KernelBot → Claude (Anthropic API)
|
|
34
|
+
↕
|
|
35
|
+
Tools (shell, files, git, docker, browser, etc.)
|
|
11
36
|
↕
|
|
12
|
-
|
|
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
|
-
|
|
20
|
-
|
|
21
|
-
|
|
|
22
|
-
|
|
|
23
|
-
| `
|
|
24
|
-
| `
|
|
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
|
|
257
|
+
│ └── kernel.js # Entry point + CLI menu
|
|
106
258
|
├── src/
|
|
107
|
-
│ ├── agent.js
|
|
108
|
-
│ ├── bot.js
|
|
109
|
-
│ ├──
|
|
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
|
|
264
|
+
│ │ └── system.js # System prompt
|
|
112
265
|
│ ├── security/
|
|
113
|
-
│ │ ├── auth.js
|
|
114
|
-
│ │
|
|
266
|
+
│ │ ├── auth.js # User allowlist
|
|
267
|
+
│ │ ├── audit.js # Tool call audit logging
|
|
268
|
+
│ │ └── confirm.js # Dangerous operation detection
|
|
115
269
|
│ ├── tools/
|
|
116
|
-
│ │ ├── os.js
|
|
117
|
-
│ │
|
|
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
|
|
120
|
-
│ ├── display.js
|
|
121
|
-
│ └── logger.js
|
|
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
|
|
package/config.example.yaml
CHANGED
|
@@ -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.
|
|
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://
|
|
27
|
+
"homepage": "https://kernelbot.io",
|
|
28
28
|
"license": "MIT",
|
|
29
29
|
"dependencies": {
|
|
30
30
|
"@anthropic-ai/sdk": "^0.39.0",
|
package/src/tools/index.js
CHANGED
|
@@ -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) {
|