Consider a dedicated ci subcommand that bundles CI-appropriate defaults

[dacharyc]

Context

After implementing --strict, --emit-annotations, and -o markdown, a typical CI workflow step for a published skill looks like:

skill-validator check --strict --emit-annotations my-skill/
skill-validator check --strict --emit-annotations -o markdown my-skill/ >> "$GITHUB_STEP_SUMMARY"

That's a lot of flags to get right consistently across multiple workflow jobs, and the two-step pattern (once for annotations, once for the summary) is awkward.

Proposed solution (tentative)

A ci subcommand that bundles sensible CI defaults:

• --emit-annotations on by default
• Appends markdown report to $GITHUB_STEP_SUMMARY automatically if that env var is set
• --strict controlled by a --mode flag (published or in-progress) rather than requiring the caller to know which flag to pass

skill-validator ci --mode published my-skill/
skill-validator ci --mode in-progress my-skill/

Why this is tentative

This is a larger API surface decision. The underlying check command stays composable for local use and custom pipelines; ci would be an ergonomic shortcut for the 80% case. It's worth seeing how the annotation flag and strict flag feel in practice before committing to a dedicated subcommand.

Tracking here so the option isn't forgotten when the other CI enhancements are in place.

[dacharyc]

After reviewing the current state of the codebase, I'd recommend holding off on a dedicated ci subcommand for now. Here's the reasoning:

Why wait

1. The building blocks are brand new. --strict, --emit-annotations, and -o markdown all landed in v0.8.0. The issue itself notes it's worth seeing how these flags feel in practice before committing to a new subcommand. There's no real user feedback yet.

2. The pain is small. The two-line workflow snippet is verbose but not error-prone. Anyone copying from docs or an example workflow gets it right once and doesn't touch it again. A dedicated subcommand saves maybe 30 characters per invocation.

3. --mode published|in-progress is a leaky abstraction. It maps to --strict on or off. Adding a second way to express the same thing increases cognitive load for users who already know the check flags. If more modes are needed later, the mapping gets harder to reason about.

4. Auto-writing to $GITHUB_STEP_SUMMARY is a side effect. The check command currently writes to stdout and lets the caller control piping. Having ci silently append to an env-var-defined file is a different contract. Users may want to control ordering in the summary, prepend a header, or conditionally skip it. Piping with >> is more transparent.

5. API surface cost. A new top-level subcommand is a commitment. If the flags evolve (new output formats, new strictness levels), the ci command has to track those changes or risk becoming a stale shortcut.

What we're doing instead

Adding a ready-to-copy CI workflow snippet to the README so users don't have to assemble the flags themselves. That solves the discoverability problem without new code.

When to revisit

If users consistently ask "why do I have to pass all these flags?" or if the flag combination grows beyond what's there today, that's a stronger signal for a dedicated subcommand.

For anyone interested in this functionality

I'm leaving this open for now - if you want to comment or react, that will give me some signal for when to revisit this.