Add a lighter-ceremony Code Cannon skill group for solo but professional-facing projects

[sebastientaggart]

Problem to Fix

Code Cannon ships one workflow with full agile ceremony — a ticket for every change, structured issues, pull requests, and blocking reviews. That fits high-ceremony team work, but it is heavy for solo projects that still want to look professional (tickets and pull requests worth showing to colleagues) without every guardrail meant for large teams. Today the only choices are full ceremony or none at all.

Why it Matters

Projects come at different ceremony levels: strictly governed team work, solo-but-professional work (like Code Cannon itself, which is seen by colleagues and reflects on the maintainer's professional capabilities), and just-for-fun projects. Forcing full ceremony on solo work makes the tool feel slow and discourages using it where it would still add value. A middle tier lets the same tooling serve more real projects — and, longer term, lets a team standardize on one skill set at several ceremony levels.

General Approach

Add a second, lighter skill group alongside the existing full-ceremony one. Keep the parts that demonstrate professionalism — tickets, branches, pull requests — but relax the heavyweight gates (for example, make review advisory rather than blocking, and reduce mandatory structure). Projects choose their ceremony level by selecting the group at setup; there is no runtime toggle, so each group stays simple and readable on its own. Both groups target the same code-hosting substrate, so no new enforcement mechanism is required.

Complexity

Verification / QA effort: moderate
A new group means a parallel set of skills to keep coherent and to test across every supported agent tool, but it reuses the existing code-hosting gates rather than introducing new ones.

Acceptance Criteria

• A project can select a lighter-ceremony workflow at setup and get tickets, branches, and pull requests without blocking review gates.
• The existing full-ceremony workflow is unchanged for projects that use it.
• Each ceremony level is defined as its own self-contained skill group, not a runtime switch buried in conditionals.
• The lighter group generates correctly for every supported agent tool.

[sebastientaggart]

Agent Implementation Notes

Origin: Strategy discussion on graduated ceremony. The maintainer runs projects at distinct ceremony levels: strictly-governed team work (full github-agile), solo-but-professional (CC itself, Deckhand's "serious" tier), and just-for-fun. Full ceremony on solo work is felt as drag.

Chosen architecture: a second skill group, NOT a runtime dial

We evaluated a runtime CEREMONY_LEVEL dial and rejected it:

• sync.py's template engine is truthiness-only ({{#if KEY}} / {{#if !KEY}}, no ==/enum equality — sync.py ~line 161-166). A graduated (3-tier) dial would require extending the engine + retesting every skill.
• A dial turns each skill into "two workflows in one file," doubling the conditional surface and the level × adapters test matrix. Estimated 4-6 focused days, with the "what does lite mean per skill" policy-design step being the part that balloons.

A separate group keeps each workflow linear and readable, needs no engine changes, and validation is already per-group (sync.py globs skills/<group>/*.md; placeholder validation only checks placeholders actually used by the enabled group). Cost is some prose duplication between groups — acceptable, since skills are prose and readability beats DRY here. Estimated ~1-2 days.

What "lite" relaxes (starting point — refine during implementation)

• Review becomes advisory (posts findings, does not block merge) rather than the blocking ai gate.
• Keep: tickets, feature branches, PRs (the professional-signal artifacts).
• Relax/optional: mandatory structured-issue sections, agent-notes comments, human gates, one-ticket-per-changeset strictness.

Same substrate

Both groups are git projects → they share the code-hosting enforcement substrate. No new gate mechanism needed (contrast the deferred proposal-writing group, which lacks a substrate). If the enforcement-backbone ticket lands first, github-lite inherits whatever portable gates it defines.

Naming

Working name github-lite (sibling to github-agile under skills/). Consider github-solo if that reads better at setup.

Dependencies / relationships

• Not strictly blocked by the enforcement-backbone ticket, but cleaner if that lands first so both groups share one gate pattern.
• Independent of the review-delegation ticket.

[sebastientaggart]

Investigation Findings — scope pivot

Investigation before starting found the ticket's founding premise has eroded since it (and the agent notes above) were written. Re-scoping accordingly.

• The premise "full ceremony or none at all" is no longer true. Code Cannon has since grown the very runtime dials the agent notes rejected: REVIEW_GATE: "ai" | "advisory" | "off", trunk mode via empty BRANCH_DEV, and optional QA labels / milestones / ticket labels — each softening ceremony independently.
• setup.md already ships a three-tier UX built on those dials, no separate group: Lightweight (advisory review, merge to main, no QA) / Standard / Governed. The Lightweight profile already satisfies most of this ticket's acceptance criteria (tickets + branches + PRs, no blocking review; full ceremony untouched) through config, not a parallel skill group.
• A parallel github-lite group would duplicate ~10 skill files (start, submit-for-review, deploy, qa, review, review-agent, status, story, delegate, checkpoint), permanently doubling maintenance and the level×adapter test matrix — a cost the notes accepted before advisory-review + trunk mode existed.
• The genuine remaining gap is small and /start-shaped: the human "go" gates, the mandatory 5-section issue body, and the agent-notes comment. That is exactly what the truthiness engine handles well.

Decision (operator-approved): do not build github-lite. Instead extend the existing single group with two new truthiness toggles, defaulting to "true" so all existing projects are unchanged, wired into the Lightweight setup profile:

1. START_APPROVAL_GATE (default "true") — when "false", /start skips the Case A / Case B human "go" gates and proceeds straight to issue → branch → code.
2. ISSUE_FULL_STRUCTURE (default "true") — when "false", /start writes a brief freeform issue body and skips the Agent Implementation Notes comment. (Collapses "mandatory structure" and "agent-notes" into one axis to avoid needless conditional surface.)

Kept for Lightweight: tickets, feature branches, PRs — the professional-signal artifacts.

[sebastientaggart]

Resolution

Rather than building a whole separate lighter-ceremony toolset, Code Cannon now offers two simple on/off settings that let a project dial down the friction of starting work: one skips the "confirm before I begin" checkpoints, and the other lets tickets be written as a quick note instead of a full structured form. Solo, professional-facing projects can turn both off (it happens automatically when you pick the "Lightweight" setup profile) and still get proper tickets, branches, and pull requests — just without the heavier gates. Every existing project is untouched, since both settings default to the full-ceremony behavior.

See #211 for full technical details.