Skip to content

feat(propose): /ccmagic:propose, turn an idea, a ticket, or a document into OpenSpec changes or Linear tickets (RV-99) - #105

Merged
devondragon merged 9 commits into
mainfrom
feat/rv-99-propose
Oct 13, 2026
Merged

devondragon merged 9 commits into
mainfrom
feat/rv-99-propose

Conversation

@devondragon

Copy link
Copy Markdown
Owner

Adds /ccmagic:propose <input> (RV-99), a standalone interactive skill built like spec-baseline. The input is a sentence, a ticket identifier, or a path to a document such as a BRD.

What the skill does

  1. Reads the input and the repository. On an OpenSpec repo that includes every current spec, the active changes, and the archive folder names, so a new change never collides with a planned one.
  2. Asks only what the repository cannot settle (owner intent, business constraints, risk), one question at a time.
  3. Splits the work into shippable increments, each with two or three one-PR sections, and stops (Stop 1) for approval before writing.
  4. OpenSpec mode (the repo has openspec/specs/ or openspec/changes/): writes each change folder under openspec/changes/<name>/ (its only Write and Edit grant), runs openspec validate <name> --strict --no-interactive, ccm-propose-check, and reeve openspec render --dir . --change <name> --as <repo> with --grade when the Reeve CLI (reeve on PATH, or a REEVE_CLI command) and its config and keys are present. A missing CLI or config skips the render or the grading with a note saying how to run it, so ccmagic does not require Reeve. It fixes and repeats until all pass, stops again (Stop 2), then opens one PR per change. It never merges.
  5. Ticket mode (no OpenSpec): drafts tickets in the form Reeve's intake grades well (the five rubric dimensions, testable acceptance criteria, context with paths), stops for confirmation, then creates them in Backlog on the repo's Linear team and project with blocking relations and prints their identifiers. Team and project come from the new linear_team and linear_project config keys, or the skill asks. GitHub Issues and JIRA are best effort.
  6. For a document input: a requirement list (R1, R2, ...) is built first; proposal.md gets a ## Coverage table (tickets get a Covers section), and the final report lists what nothing covers.

The steps are numbered so RV-98 (unattended proposal sessions) can follow the same procedure later; nothing unattended is built here.

ccm-propose-check

A deterministic check run before each commit. JSON output; exit 0 clean, 1 findings, 3 unreadable, 4 usage. Rules: outside-change, no-change-folder, change-name (kebab-case, and Reeve's refused words), name-collision (archive, an active change at the base, or an archive folder of that name), missing-file, meta (schema: spec-driven, only keys OpenSpec knows, boolean flags), Reeve's parseTasks rules (same names), task-checked, section-count (more than 3), capability-name, new-capability-purpose, requirement-not-found (MODIFIED, REMOVED, and RENAMED FROM names must be in the current spec at the base), skip-specs-deltas, dash, and personal-identifier (spec-baseline's patterns). --probe-reeve reports whether the Reeve CLI, its config, and the API keys are present without printing a value.

Files

  • skills/propose/SKILL.md, change-format.md, ticket-format.md: the skill and its format rules.
  • bin/ccm-propose-check: the checker.
  • bin/ccm-lib.sh: now holds ccm-openspec-scope's Reeve task parser and archive-name rule, and ccm-baseline-check's diff base and email patterns, moved unchanged so the new check shares them; both scripts call them from there. Also the linear_team and linear_project defaults.
  • bin/ccm-openspec-scope, bin/ccm-baseline-check: use the moved helpers; no behavior change (their existing tests pass, including the byte-for-byte comparison with v3.16.0's scope output).
  • tests/run.sh, tests/fixtures/propose/: 16 tests for the checker and the skill, plus propose registered as a standalone skill. The standalone check now looks for a skill as ccmagic:<name> or skills/<name>, since "propose" is an ordinary word in work-ticket's prose.
  • tests/every-ticket-since-baseline.diff: regenerated for the help entry.
  • README.md, skills/help/SKILL.md, CHANGELOG.md, docs/ccmagic.local.md.example, .claude-plugin/*.json: docs and version 3.21.0.

Tests

  • bash tests/run.sh: 405 passed, 0 failed (macOS, Docker available; one validate test skips for lack of /proc, as before).
  • shellcheck -x bin/ccm-* hooks/*.sh tests/run.sh tests/relay-smoke.sh tests/stubs/gh evals/run.sh: clean.
  • The fixture change passes openspec validate --strict on 1.14.1, and Reeve's openspec render --dir renders it (run by hand from a local Reeve checkout, without --grade).

Open: live acceptance runs (Devon, after merge)

  • A real change on 10MinuteMailAWS, through validate, render with --grade, and the PR.
  • A Linear-only run on a repo without OpenSpec, creating tickets in Backlog with blocking relations.
  • A sample BRD, checking the coverage table and the uncovered list.

…ccm-lib.sh (RV-99)

ccm-openspec-scope's port of Reeve's parseTasks and archiveFolderMatches, and ccm-baseline-check's diff base and email patterns, move to ccm-lib.sh unchanged so the propose check can use them.
Checks the change folders /ccmagic:propose writes against Reeve's planner rules (change name, tasks.md, new-capability-purpose), the strict .openspec.yaml keys, exact MODIFIED, REMOVED, and RENAMED names, the section limit, dashes and written addresses, and that nothing outside the new folders changed.
Turns an idea, a ticket, or a document into OpenSpec changes (one PR per change) or Linear tickets, with a stop after the split and before anything is opened or created. Writes only under openspec/changes/.
# Conflicts:
#	.claude-plugin/marketplace.json
#	.claude-plugin/plugin.json
#	CHANGELOG.md
@devondragon
devondragon merged commit 892524a into main Oct 13, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant