Remove internal-only tooling from the external build (#352)
* Remove internal-only tooling without changing external runtime contracts This trims the lowest-risk internal-only surfaces first: deleted internal modules are replaced by build-time no-op stubs, the bundled stuck skill is removed, and the insights S3 upload path now stays local-only. The privacy verifier is expanded and the remaining bundled internal Slack/Artifactory strings are neutralized without broad repo-wide renames. Constraint: Keep the first PR deletion-heavy and avoid mass rewrites of USER_TYPE, tengu, or claude_code identifiers Rejected: One-shot DMCA cleanup branch | too much semantic risk for a first PR Confidence: medium Scope-risk: moderate Reversibility: clean Directive: Treat full-repo typecheck as a baseline issue on this upstream snapshot; do not claim this commit introduced the existing non-Phase-A errors without isolating them first Tested: bun run build Tested: bun run smoke Tested: bun run verify:privacy Not-tested: Full repo typecheck (currently fails on widespread pre-existing upstream errors outside this change set) * Keep minimal source shims so CI can import Phase A cleanup paths The first PR removed internal-only source files entirely, but CI provider and context tests import those modules directly from source rather than through the build-time no-telemetry stubs. This restores tiny no-op source shims so tests and local source imports resolve while preserving the same external runtime behavior. Constraint: GitHub Actions runs source-level tests in addition to bundled build/privacy checks Rejected: Revert the entire deletion pass | unnecessary once the import contract is satisfied by small shims Confidence: high Scope-risk: narrow Reversibility: clean Directive: For later cleanup phases, treat build-time stubs and source-test imports as separate compatibility surfaces Tested: bun run build Tested: bun run smoke Tested: bun run verify:privacy Tested: bun run test:provider Tested: bun run test:provider-recommendation Not-tested: Full repo typecheck (still noisy on this upstream snapshot) --------- Co-authored-by: anandh8x <test@example.com>
This commit is contained in:
Anandan
GitHub
@@ -8,7 +8,6 @@ import { registerLoremIpsumSkill } from './loremIpsum.js'
|
||||
import { registerRememberSkill } from './remember.js'
|
||||
import { registerSimplifySkill } from './simplify.js'
|
||||
import { registerSkillifySkill } from './skillify.js'
|
||||
import { registerStuckSkill } from './stuck.js'
|
||||
import { registerUpdateConfigSkill } from './updateConfig.js'
|
||||
import { registerVerifySkill } from './verify.js'
|
||||
|
||||
@@ -31,7 +30,6 @@ export function initBundledSkills(): void {
|
||||
registerRememberSkill()
|
||||
registerSimplifySkill()
|
||||
registerBatchSkill()
|
||||
registerStuckSkill()
|
||||
if (feature('KAIROS') || feature('KAIROS_DREAM')) {
|
||||
/* eslint-disable @typescript-eslint/no-require-imports */
|
||||
const { registerDreamSkill } = require('./dream.js')
|
||||
|
||||
@@ -1,79 +1 @@
|
||||
import { registerBundledSkill } from '../bundledSkills.js'
|
||||
|
||||
// Prompt text contains `ps` commands as instructions for Claude to run,
|
||||
// not commands this file executes.
|
||||
// eslint-disable-next-line custom-rules/no-direct-ps-commands
|
||||
const STUCK_PROMPT = `# /stuck — diagnose frozen/slow Claude Code sessions
|
||||
|
||||
The user thinks another Claude Code session on this machine is frozen, stuck, or very slow. Investigate and post a report to #claude-code-feedback.
|
||||
|
||||
## What to look for
|
||||
|
||||
Scan for other Claude Code processes (excluding the current one — PID is in \`process.pid\` but for shell commands just exclude the PID you see running this prompt). Process names are typically \`claude\` (installed) or \`cli\` (native dev build).
|
||||
|
||||
Signs of a stuck session:
|
||||
- **High CPU (≥90%) sustained** — likely an infinite loop. Sample twice, 1-2s apart, to confirm it's not a transient spike.
|
||||
- **Process state \`D\` (uninterruptible sleep)** — often an I/O hang. The \`state\` column in \`ps\` output; first character matters (ignore modifiers like \`+\`, \`s\`, \`<\`).
|
||||
- **Process state \`T\` (stopped)** — user probably hit Ctrl+Z by accident.
|
||||
- **Process state \`Z\` (zombie)** — parent isn't reaping.
|
||||
- **Very high RSS (≥4GB)** — possible memory leak making the session sluggish.
|
||||
- **Stuck child process** — a hung \`git\`, \`node\`, or shell subprocess can freeze the parent. Check \`pgrep -lP <pid>\` for each session.
|
||||
|
||||
## Investigation steps
|
||||
|
||||
1. **List all Claude Code processes** (macOS/Linux):
|
||||
\`\`\`
|
||||
ps -axo pid=,pcpu=,rss=,etime=,state=,comm=,command= | grep -E '(claude|cli)' | grep -v grep
|
||||
\`\`\`
|
||||
Filter to rows where \`comm\` is \`claude\` or (\`cli\` AND the command path contains "claude").
|
||||
|
||||
2. **For anything suspicious**, gather more context:
|
||||
- Child processes: \`pgrep -lP <pid>\`
|
||||
- If high CPU: sample again after 1-2s to confirm it's sustained
|
||||
- If a child looks hung (e.g., a git command), note its full command line with \`ps -p <child_pid> -o command=\`
|
||||
- Check the session's debug log if you can infer the session ID: \`~/.claude/debug/<session-id>.txt\` (the last few hundred lines often show what it was doing before hanging)
|
||||
|
||||
3. **Consider a stack dump** for a truly frozen process (advanced, optional):
|
||||
- macOS: \`sample <pid> 3\` gives a 3-second native stack sample
|
||||
- This is big — only grab it if the process is clearly hung and you want to know *why*
|
||||
|
||||
## Report
|
||||
|
||||
**Only post to Slack if you actually found something stuck.** If every session looks healthy, tell the user that directly — do not post an all-clear to the channel.
|
||||
|
||||
If you did find a stuck/slow session, post to **#claude-code-feedback** (channel ID: \`C07VBSHV7EV\`) using the Slack MCP tool. Use ToolSearch to find \`slack_send_message\` if it's not already loaded.
|
||||
|
||||
**Use a two-message structure** to keep the channel scannable:
|
||||
|
||||
1. **Top-level message** — one short line: hostname, Claude Code version, and a terse symptom (e.g. "session PID 12345 pegged at 100% CPU for 10min" or "git subprocess hung in D state"). No code blocks, no details.
|
||||
2. **Thread reply** — the full diagnostic dump. Pass the top-level message's \`ts\` as \`thread_ts\`. Include:
|
||||
- PID, CPU%, RSS, state, uptime, command line, child processes
|
||||
- Your diagnosis of what's likely wrong
|
||||
- Relevant debug log tail or \`sample\` output if you captured it
|
||||
|
||||
If Slack MCP isn't available, format the report as a message the user can copy-paste into #claude-code-feedback (and let them know to thread the details themselves).
|
||||
|
||||
## Notes
|
||||
- Don't kill or signal any processes — this is diagnostic only.
|
||||
- If the user gave an argument (e.g., a specific PID or symptom), focus there first.
|
||||
`
|
||||
|
||||
export function registerStuckSkill(): void {
|
||||
if (process.env.USER_TYPE !== 'ant') {
|
||||
return
|
||||
}
|
||||
|
||||
registerBundledSkill({
|
||||
name: 'stuck',
|
||||
description:
|
||||
'[ANT-ONLY] Investigate frozen/stuck/slow Claude Code sessions on this machine and post a diagnostic report to #claude-code-feedback.',
|
||||
userInvocable: true,
|
||||
async getPromptForCommand(args) {
|
||||
let prompt = STUCK_PROMPT
|
||||
if (args) {
|
||||
prompt += `\n## User-provided context\n\n${args}\n`
|
||||
}
|
||||
return [{ type: 'text', text: prompt }]
|
||||
},
|
||||
})
|
||||
}
|
||||
export function registerStuckSkill(): void {}
|
||||
|
||||
Reference in New Issue
Block a user