multica-ai/multica · error

update skill: %w

Error message

update skill: %w

What it means

Returned by the `multica skill update` CLI subcommand when the HTTP PUT to `/api/skills/{id}` fails. The underlying error is wrapped with %w, so the cause is one of: transport failure (server unreachable, timeout, TLS), a non-2xx API response (most often 404 unknown skill ID or 400 invalid field), or a JSON decode failure of the response body. The CLI has already validated that at least one of --name/--description/--content/--config was provided, so the failure is on the API side, not local flag validation.

Source

Thrown at server/cmd/multica/cmd_skill.go:384

	if cmd.Flags().Changed("config") {
		v, _ := cmd.Flags().GetString("config")
		var config any
		if err := json.Unmarshal([]byte(v), &config); err != nil {
			return fmt.Errorf("--config must be valid JSON: %w", err)
		}
		body["config"] = config
	}

	if len(body) == 0 {
		return fmt.Errorf("no fields to update; use --name, --description, --content, or --config")
	}

	ctx, cancel := cli.APIContext(context.Background())
	defer cancel()

	var result map[string]any
	if err := client.PutJSON(ctx, "/api/skills/"+args[0], body, &result); err != nil {
		return fmt.Errorf("update skill: %w", err)
	}

	output, _ := cmd.Flags().GetString("output")
	if output == "json" {
		return cli.PrintJSON(os.Stdout, result)
	}

	fmt.Printf("Skill updated: %s (%s)\n", strVal(result, "name"), strVal(result, "id"))
	return nil
}

func runSkillDelete(cmd *cobra.Command, args []string) error {
	yes, _ := cmd.Flags().GetBool("yes")
	if !yes {
		fmt.Printf("Are you sure you want to delete skill %s? This cannot be undone. [y/N] ", args[0])
		reader := bufio.NewReader(os.Stdin)
		answer, _ := reader.ReadString('\n')
		answer = strings.TrimSpace(strings.ToLower(answer))

View on GitHub (pinned to 2c0912b6ec)

Solutions

1. Verify the skill exists first: `multica skill list --output json` (or `multica skill get <id>`) and confirm the exact ID.
2. Check server reachability and environment: confirm the CLI's --api-url / auth flags point at the server that actually owns the skill.
3. If --config was passed, validate it is well-formed before sending (e.g. `cat config.json | jq .`) since malformed config triggers a 400.
4. Inspect the wrapped error text: a 404 means bad ID, a 400 means invalid payload, a connection refused means wrong host/port.

Example fix

// before
multica skill update abc123 --config '{bad json'

// after
multica skill get abc123   # confirm the ID resolves
jq . config.json            # confirm the config payload is valid
multica skill update abc123 --config "$$(cat config.json)"

# confirm the target exists and the payload is well-formed before updating
multica skill get "$SKILL_ID" --output json > /dev/null || exit 1
jq -e . config.json > /dev/null || { echo 'invalid config JSON'; exit 1; }

In Go or shell wrappers, capture the wrapped error and branch on cause: if strings.Contains(err.Error(), "404") treat as bad-ID (re-list skills), if "connection refused" fix environment, else surface the message. Since the CLI uses %w wrapping, Go callers can errors.As/errors.Is on the underlying client error type.

When it happens

Trigger: Running `multica skill update <id> --description "..."` where <id> does not exist (404); server not running or wrong --api-url; API key lacks permission; sending a --config value the server rejects as invalid JSON/YAML; request exceeded the default API context timeout.

Common situations: Typo'd or stale skill ID copied from an earlier `skill list` output; local dev server restarted with a fresh database so previous IDs no longer resolve; CLI pointed at a different environment (prod vs localhost) than the one holding the skill; expired or missing auth token.

Related errors

• delete skill: %w
• refresh skill: %w
• import skill: %w
• search skills: %w
• list skill files: %w

AI-assisted analysis of multica-ai/multica@2c0912b6ec (2026-08-15). Data as JSON: /api/errors/f51e8b45b9e3ce09. Report an issue: GitHub.