embedded-linux-login-debug

Name: embedded-linux-login-debug
Author: easyzoom

22stars2forks

How to install embedded-linux-login-debug?

easyzoom/aix-skills/embedded-linux-login-debug

$npx -y skills add easyzoom/aix-skills --skill embedded-linux-login-debug

Installs into the current project.

Summary

Use when logging into, connecting to, or preparing to debug an embedded Linux device

Files · 1

View on GitHub

SKILL.md

1	# Embedded Linux Login Debug
2
3	## Overview
4
5	Use this skill to choose a safe login path for an embedded Linux device before debugging. The agent should identify the available access method, collect only the required connection details, and start with read-only checks after login.
6
7	## When To Use
8
9	Use this skill when:
10
11	- The user wants to log in to an embedded Linux device, development board, router, gateway, camera, or appliance.
12	- The user mentions SSH, serial console, UART, ADB, Telnet, local console, recovery console, or vendor web debug access.
13	- The task requires checking runtime state on a target device before changing files, services, partitions, networking, or firmware.
14
15	Do not use this skill when:
16
17	- The target is a normal cloud server or desktop Linux machine with a known access path.
18	- The user only needs static source-code analysis and no device access.
19	- The request is to flash firmware, erase storage, modify bootloader settings, or change partitions without a separate safety plan.
20
21	## Login Method Decision
22
23	Ask which access methods are available. If the user is unsure, suggest this order:
24
25	1. SSH over network, if the device has an IP address and SSH server.
26	2. Serial UART console, if network access is unavailable or boot logs are needed.
27	3. ADB, if the target is Android-based or exposes Android Debug Bridge.
28	4. Telnet, only for trusted lab networks or legacy devices.
29	5. Local console with display and keyboard, if physically accessible.
30	6. Vendor web or recovery console, if shell access is not exposed directly.
31
32	## Required Inputs By Method
33
34	### SSH
35
36	Ask for:
37
38	- Device IP address or hostname.
39	- SSH port, defaulting to `22` if unknown.
40	- Username.
41	- Authentication method: password, private key, or agent-forwarded key.
42	- Whether the network is reachable from the current machine.
43
44	If a password is required, ask the user to type it into the SSH prompt when possible. Do not ask the user to paste reusable passwords into chat unless there is no alternative.
45
46	Command pattern:
47
48	```bash
49	ssh -p <port> <user>@<ip>
50	```
51
52	### Serial UART
53
54	Ask for:
55
56	- Local serial device path, such as `/dev/ttyUSB0`, `/dev/ttyACM0`, or `/dev/tty.usbserial-*`.
57	- Baud rate, commonly `115200`.
58	- Data format if known, commonly `8N1`.
59	- Whether the user has permission to access the serial device.
60	- Whether the board needs reset or power cycle to see boot logs.
61
62	Command patterns:
63
64	```bash
65	picocom -b 115200 /dev/ttyUSB0
66	screen /dev/ttyUSB0 115200
67	minicom -D /dev/ttyUSB0 -b 115200
68	```
69
70	### ADB
71
72	Ask for:
73
74	- Whether the device is connected by USB or ADB-over-TCP.
75	- Whether USB debugging or ADB is enabled.
76	- Device serial or IP and port, if multiple devices exist.
77	- Whether shell access requires `su`.
78
79	Command patterns:
80
81	```bash
82	adb devices
83	adb shell
84	adb connect <ip>:5555
85	adb -s <serial> shell
86	```
87
88	### Telnet
89
90	Ask for:
91
92	- Device IP address or hostname.
93	- Telnet port, defaulting to `23` if unknown.
94	- Username and password, if required.
95	- Confirmation that this is a trusted lab network.
96
97	Warn that Telnet sends credentials in plaintext. Prefer SSH when available.
98
99	Command pattern:
100
101	```bash
102	telnet <ip> <port>
103	```
104
105	### Local Console Or Vendor Console
106
107	Ask for:
108
109	- Physical access method: HDMI, LCD, keyboard, recovery menu, web UI, or vendor debug page.
110	- Login account, role, or recovery mode requirements.
111	- Whether the console can run shell commands or only displays status.
112	- Any device-specific constraints, such as maintenance windows or watchdog resets.
113
114	## Workflow
115
116	1. Identify the target.
117	Ask what device or board is being debugged, what problem is being investigated, and whether the device is already booted.
118
119	1. Select the login method.
120	Use the decision list above. If multiple methods are available, prefer the least invasive path that gives enough visibility.
121
122	1. Collect required inputs.
123	Ask only for the fields required by the selected method. Do not request passwords unless the login tool cannot prompt interactively.
124
125	1. Check reachability before login.
126	For network methods, use safe checks such as `ping`, `nc -vz <ip> <port>`, or `ssh -v` when appropriate. For serial, confirm the device path exists and is not already in use.
127
128	1. Log in.
129	Provide the exact command with placeholders or user-provided values. Avoid embedding secrets in commands, shell history, scripts, or logs.
130
131	1. Run read-only baseline checks.
132	After shell access is confirmed, collect:
133
134	```bash
135	whoami
136	hostname
137	uname -a
138	cat /etc/os-release 2>/dev/null \|\| cat /etc/issue 2>/dev/null
139	ip addr
140	ip route
141	mount
142	df -h
143	ps
144	dmesg \| tail -n 80
145	```
146
147	1. Summarize the session.
148	Record login method, target identifier, current user, kernel version, OS identity, network addresses, and any immediate anomalies.
149
150	## Safety Rules
151
152	- Do not reboot, power-cycle, reset, flash, erase, remount read-write, change network settings, kill processes, or

People who liked this also viewed

6 picks

Type

azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026472k1.3k
systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026197k259k
safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026161k507
explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026161k507
minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026161k507
insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 202618k31

embedded-linux-login-debug

22stars2forks

View on GitHub

How to install embedded-linux-login-debug?

easyzoom/aix-skills/embedded-linux-login-debug

$npx -y skills add easyzoom/aix-skills --skill embedded-linux-login-debug

Installs into the current project.

Summary

Use when logging into, connecting to, or preparing to debug an embedded Linux device

Files · 1

View on GitHub

SKILL.md

1	# Embedded Linux Login Debug
2
3	## Overview
4
5	Use this skill to choose a safe login path for an embedded Linux device before debugging. The agent should identify the available access method, collect only the required connection details, and start with read-only checks after login.
6
7	## When To Use
8
9	Use this skill when:
10
11	- The user wants to log in to an embedded Linux device, development board, router, gateway, camera, or appliance.
12	- The user mentions SSH, serial console, UART, ADB, Telnet, local console, recovery console, or vendor web debug access.
13	- The task requires checking runtime state on a target device before changing files, services, partitions, networking, or firmware.
14
15	Do not use this skill when:
16
17	- The target is a normal cloud server or desktop Linux machine with a known access path.
18	- The user only needs static source-code analysis and no device access.
19	- The request is to flash firmware, erase storage, modify bootloader settings, or change partitions without a separate safety plan.
20
21	## Login Method Decision
22
23	Ask which access methods are available. If the user is unsure, suggest this order:
24
25	1. SSH over network, if the device has an IP address and SSH server.
26	2. Serial UART console, if network access is unavailable or boot logs are needed.
27	3. ADB, if the target is Android-based or exposes Android Debug Bridge.
28	4. Telnet, only for trusted lab networks or legacy devices.
29	5. Local console with display and keyboard, if physically accessible.
30	6. Vendor web or recovery console, if shell access is not exposed directly.
31
32	## Required Inputs By Method
33
34	### SSH
35
36	Ask for:
37
38	- Device IP address or hostname.
39	- SSH port, defaulting to `22` if unknown.
40	- Username.
41	- Authentication method: password, private key, or agent-forwarded key.
42	- Whether the network is reachable from the current machine.
43
44	If a password is required, ask the user to type it into the SSH prompt when possible. Do not ask the user to paste reusable passwords into chat unless there is no alternative.
45
46	Command pattern:
47
48	```bash
49	ssh -p <port> <user>@<ip>
50	```
51
52	### Serial UART
53
54	Ask for:
55
56	- Local serial device path, such as `/dev/ttyUSB0`, `/dev/ttyACM0`, or `/dev/tty.usbserial-*`.
57	- Baud rate, commonly `115200`.
58	- Data format if known, commonly `8N1`.
59	- Whether the user has permission to access the serial device.
60	- Whether the board needs reset or power cycle to see boot logs.
61
62	Command patterns:
63
64	```bash
65	picocom -b 115200 /dev/ttyUSB0
66	screen /dev/ttyUSB0 115200
67	minicom -D /dev/ttyUSB0 -b 115200
68	```
69
70	### ADB
71
72	Ask for:
73
74	- Whether the device is connected by USB or ADB-over-TCP.
75	- Whether USB debugging or ADB is enabled.
76	- Device serial or IP and port, if multiple devices exist.
77	- Whether shell access requires `su`.
78
79	Command patterns:
80
81	```bash
82	adb devices
83	adb shell
84	adb connect <ip>:5555
85	adb -s <serial> shell
86	```
87
88	### Telnet
89
90	Ask for:
91
92	- Device IP address or hostname.
93	- Telnet port, defaulting to `23` if unknown.
94	- Username and password, if required.
95	- Confirmation that this is a trusted lab network.
96
97	Warn that Telnet sends credentials in plaintext. Prefer SSH when available.
98
99	Command pattern:
100
101	```bash
102	telnet <ip> <port>
103	```
104
105	### Local Console Or Vendor Console
106
107	Ask for:
108
109	- Physical access method: HDMI, LCD, keyboard, recovery menu, web UI, or vendor debug page.
110	- Login account, role, or recovery mode requirements.
111	- Whether the console can run shell commands or only displays status.
112	- Any device-specific constraints, such as maintenance windows or watchdog resets.
113
114	## Workflow
115
116	1. Identify the target.
117	Ask what device or board is being debugged, what problem is being investigated, and whether the device is already booted.
118
119	1. Select the login method.
120	Use the decision list above. If multiple methods are available, prefer the least invasive path that gives enough visibility.
121
122	1. Collect required inputs.
123	Ask only for the fields required by the selected method. Do not request passwords unless the login tool cannot prompt interactively.
124
125	1. Check reachability before login.
126	For network methods, use safe checks such as `ping`, `nc -vz <ip> <port>`, or `ssh -v` when appropriate. For serial, confirm the device path exists and is not already in use.
127
128	1. Log in.
129	Provide the exact command with placeholders or user-provided values. Avoid embedding secrets in commands, shell history, scripts, or logs.
130
131	1. Run read-only baseline checks.
132	After shell access is confirmed, collect:
133
134	```bash
135	whoami
136	hostname
137	uname -a
138	cat /etc/os-release 2>/dev/null \|\| cat /etc/issue 2>/dev/null
139	ip addr
140	ip route
141	mount
142	df -h
143	ps
144	dmesg \| tail -n 80
145	```
146
147	1. Summarize the session.
148	Record login method, target identifier, current user, kernel version, OS identity, network addresses, and any immediate anomalies.
149
150	## Safety Rules
151
152	- Do not reboot, power-cycle, reset, flash, erase, remount read-write, change network settings, kill processes, or

People who liked this also viewed

6 picks

Type