Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

codewith-self-heal

Estrellas0

Forks0

Actualizado10 de junio de 2026 a las 16:50

Diagnose and safely repair Codewith config.toml and MCP startup failures. Use only when the user explicitly starts the self-heal workflow or asks to fix Codewith configuration/MCP breakage.

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

hasna

hasna/codewith

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Administradores de redes y sistemas informáticosOcupaciones informáticas y matemáticas·SOC 15-1244

SKILL.md

readonly

name	codewith-self-heal
description	Diagnose and safely repair Codewith config.toml and MCP startup failures. Use only when the user explicitly starts the self-heal workflow or asks to fix Codewith configuration/MCP breakage.

Codewith Self-Heal

Use this skill only for Codewith recovery work involving config.toml, strict-config failures, MCP server configuration, or MCP startup/doctor failures. Treat the supplied doctor report as redacted diagnostic context; do not ask the user to paste secrets.

Workflow

Diagnose first. Identify whether the breakage is TOML syntax/deserialization, an unknown config key, MCP command/cwd/env configuration, MCP HTTP reachability, or an unsupported inline secret such as bearer_token.
Present the proposed repair before changing files. Include the target file path, the exact keys or MCP servers affected, and the validation command you will run afterward.
Ask for user confirmation before editing config.toml, disabling MCP servers, moving files, or writing replacement config. If the user does not confirm, do not write.
Before every config write, create a timestamped backup next to the original file and report the backup path.
Keep repairs narrow and reversible. Prefer fixing one broken key, replacing unsupported inline secrets with env-var references, correcting obvious command/cwd values, or disabling an optional broken MCP server. Do not delete the user's config or silently disable required MCP servers.
Avoid exposing secrets. Redact token values, bearer tokens, cookies, API keys, and URL credentials in explanations and command output.
Use structured config helpers when available. Prefer Codewith's config edit or MCP edit APIs and TOML-aware edits over ad hoc string rewrites.
After applying a repair, rerun the relevant validation: parse/load config, codewith doctor, or the MCP-specific doctor check when available. Report remaining issues plainly.

Safe Repair Guidance

TOML syntax failure: if the syntax issue is obvious, propose the smallest TOML-aware edit. If it is not obvious and Codewith cannot start, propose backing up the malformed file and writing a minimal valid config so the user can start Codewith, then recover settings from the backup.
Unknown strict-config key: propose removing or renaming only the unknown key. Mention that removing it may change behavior tied to older or newer Codewith versions.
Inline MCP bearer_token: propose moving the secret out of config.toml, replacing it with bearer_token_env_var, and telling the user which env var to set. Do not print the old token value.
Missing MCP env var: explain the env var that must be set. Disable the server only if it is optional and the user confirms that Codewith should start without it.
Missing MCP command or cwd: propose the likely corrected command/path only when it is clear. Otherwise explain how the user can install the command or choose a valid path.
MCP HTTP reachability: do not rewrite URLs unless the corrected URL is obvious from user input. Optional unreachable servers may be disabled after confirmation; required servers should stay enabled unless the user explicitly changes their requirement.

Confirmation Template

Before writes, use a concise confirmation request:

I can apply this repair:
- Back up <config-path> to a timestamped .bak file.
- Change <specific key/server/action>.
- Rerun <validation command>.

Confirm that I should apply this change.

Más de este repositorio

mismo repositorio

codewith-rust-test-speed

hasna/codewith

Optimize slow Rust test workflows in Codewith codex-rs. Use when tests feel slow, compile/link dominates execution, app-server integration tests are filtered but still build huge binaries, or when deciding local/CI test strategy, target dirs, nextest filters, or Codewith skill guidance for test speed.

2026-07-210

merge-pr

hasna/codewith

Use when the user asks to merge a GitHub PR, merge when green, enable auto-merge, add to a merge queue, or decide whether a PR is mergeable. Do not use for ordinary PR review unless there is explicit merge intent.

2026-07-200

open-codewith-runtime-development

hasna/codewith

Route and verify development work in the hasna/codewith fork across Rust runtime, provider/model/auth/profile behavior, TUI, app-server protocol, MCP lifecycle, goals/native loops, upstream merges, and release gates. Use when implementing, debugging, reviewing, or shipping work in any of these Codewith runtime domains, especially changes that cross crates or user-facing surfaces and need the correct project skills, focused tests, snapshots, schemas, or fork-preservation checks.

2026-07-200

codewith-rust-build

hasna/codewith

Build, format, lint, and test Codewith Rust crates in codex-rs. Use when making or verifying Rust changes, resolving Codewith build errors, updating Cargo or Bazel locks, building release binaries, or validating Rust before npm publish.

2026-06-150

codewith-pr-body

hasna/codewith

Update the title and body of one or more pull requests.

2026-06-060

codewith-git-ship

hasna/codewith

Create logical commits and push Codewith changes safely. Use when asked to review current changes, split work into commits, avoid unrelated local work, push to GitHub, reconcile a dirty hasna/codewith checkout, or prepare commits before publishing.

2026-06-030

Codewith Self-Heal

Workflow

Diagnose first. Identify whether the breakage is TOML syntax/deserialization, an unknown config key, MCP command/cwd/env configuration, MCP HTTP reachability, or an unsupported inline secret such as bearer_token.

Present the proposed repair before changing files. Include the target file path, the exact keys or MCP servers affected, and the validation command you will run afterward.

Ask for user confirmation before editing config.toml, disabling MCP servers, moving files, or writing replacement config. If the user does not confirm, do not write.

Before every config write, create a timestamped backup next to the original file and report the backup path.

Keep repairs narrow and reversible. Prefer fixing one broken key, replacing unsupported inline secrets with env-var references, correcting obvious command/cwd values, or disabling an optional broken MCP server. Do not delete the user's config or silently disable required MCP servers.

Avoid exposing secrets. Redact token values, bearer tokens, cookies, API keys, and URL credentials in explanations and command output.

Use structured config helpers when available. Prefer Codewith's config edit or MCP edit APIs and TOML-aware edits over ad hoc string rewrites.

After applying a repair, rerun the relevant validation: parse/load config, codewith doctor, or the MCP-specific doctor check when available. Report remaining issues plainly.

Safe Repair Guidance

TOML syntax failure: if the syntax issue is obvious, propose the smallest TOML-aware edit. If it is not obvious and Codewith cannot start, propose backing up the malformed file and writing a minimal valid config so the user can start Codewith, then recover settings from the backup.

Unknown strict-config key: propose removing or renaming only the unknown key. Mention that removing it may change behavior tied to older or newer Codewith versions.

Inline MCP bearer_token: propose moving the secret out of config.toml, replacing it with bearer_token_env_var, and telling the user which env var to set. Do not print the old token value.

Missing MCP env var: explain the env var that must be set. Disable the server only if it is optional and the user confirms that Codewith should start without it.

Missing MCP command or cwd: propose the likely corrected command/path only when it is clear. Otherwise explain how the user can install the command or choose a valid path.

MCP HTTP reachability: do not rewrite URLs unless the corrected URL is obvious from user input. Optional unreachable servers may be disabled after confirmation; required servers should stay enabled unless the user explicitly changes their requirement.

Confirmation Template

Before writes, use a concise confirmation request:

I can apply this repair: - Back up <config-path> to a timestamped .bak file. - Change <specific key/server/action>. - Rerun <validation command>. Confirm that I should apply this change.