What causes "read stdin for --content-stdin: %w" in multica-ai/multica?

Check the wrapped errno; EPIPE usually means the upstream producer exited early.

read stdin for --content-stdin: %w

Error message

read stdin for --content-stdin: %w

What it means

Returned when --content-stdin is used and io.ReadAll(os.Stdin) fails before the content can be validated. This is a low-level stdin read failure (not empty input — empty input is a separate '%s is empty' error). The %w wraps the OS-level read error.

Source

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

	sources := 0
	if inlineSet {
		sources++
	}
	if useStdin {
		sources++
	}
	if filePath != "" {
		sources++
	}
	if sources > 1 {
		return "", false, fmt.Errorf("--content, --content-stdin, and --content-file are mutually exclusive")
	}

	if useStdin {
		data, err := io.ReadAll(os.Stdin)
		if err != nil {
			return "", false, fmt.Errorf("read stdin for --content-stdin: %w", err)
		}
		return skillContentBytesToString(data, "stdin content for --content-stdin")
	}
	if filePath != "" {
		data, err := os.ReadFile(filePath)
		if err != nil {
			return "", false, fmt.Errorf("read file for --content-file: %w", err)
		}
		return skillContentBytesToString(data, "file content for --content-file")
	}
	if inlineSet {
		return inline, true, nil
	}
	return "", false, nil
}

func skillContentBytesToString(data []byte, label string) (string, bool, error) {
	if len(data) == 0 {

View on GitHub (pinned to 2c0912b6ec)

Solutions

Check the wrapped errno; EPIPE usually means the upstream producer exited early.
Capture content to a temp file and use --content-file instead when the producer is flaky.
For non-interactive automation, prefer --content-file over --content-stdin.
Verify stdin is actually connected: re-run interactively or with `< /dev/null` to see the empty-content error instead.

Example fix

# before: producer may close pipe early
curl -s https://x/skill.md | multica skill create --name s --content-stdin
# after
curl -s https://x/skill.md -o /tmp/skill.md && multica skill create --name s --content-file /tmp/skill.md

Defensive patterns

Strategy: fallback

Validate before calling

# Verify the pipe producer emits data with a good exit code before piping
producer > /tmp/skill.$$ || { rm -f /tmp/skill.$$; echo "producer failed"; exit 2; }
multica skill create --name s --content-file /tmp/skill.$$; rc=$?; rm -f /tmp/skill.$$; exit $rc

Try / catch

On 'read stdin' errors (typically EPIPE), fall back to materializing the producer's output to a temp file and re-running with --content-file; retry only after the producer is fixed.

Prevention

In automation prefer --content-file over --content-stdin.
Ensure the producing command succeeds before piping into multica.
Avoid --content-stdin in contexts without a real stdin (cron, daemons).

When it happens

Trigger: `multica skill create --content-stdin` where stdin is a broken/closed pipe, a redirected file that becomes unreadable, or the process was spawned with an invalid stdin descriptor.

Common situations: Piping from a process that exits and closes the pipe prematurely (`cat file | head`-style truncation); CI runners that give the CLI no stdin; a closed fd 0 in daemonized contexts.

Related errors

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