cc-os/plugins/os-sdlc/reference/plugin-factory.md

plugin factory

Status: direction — as of 2026-07-16 Connects to: deterministic-gates, self-improvement-loops, pipeline-stages, overview

Purpose

States that os-sdlc is the same factory cc-os uses to build its own os-* plugins, not a separate meta-tool — and how that reflexive use case is possible without a second pipeline. Load this before scaffolding a new os-* plugin, or before designing anything that looks like a "plugin builder" separate from the ticket pipeline in pipeline-stages.

Design

• The same factory builds cc-os plugins from a PRD. This works because the green command is pluggable per project (see deterministic-gates): for a normal application repo it's rake test + lint; for an AiDD-type project (a cc-os plugin) the eval harness IS the test suite. TDD becomes eval-driven development — write the eval, watch it fail for the right reason, build the skill until it passes — with no separate pipeline, no special-cased plugin-building mode. The pipeline stages in pipeline-stages run unchanged; only the green-command config value differs.
• Plugins self-evolve after they ship. Once a plugin exists, its own operation becomes input back into the same factory: audits of sessions it participated in (loop a), ADR-corpus audits touching its decisions (loop b), its own eval-harness regressions (loop c), and direct user feedback all generate improvement tickets. Those tickets re-enter factory intake exactly like any other ticket — a plugin is never "done," it's a standing client of its own factory. See self-improvement-loops for the four loops that produce this feedback.
• This closes the loop cc-os has been running informally (build a plugin, notice drift in use, fix it in a follow-up session) into something the factory itself can drive end-to-end: PRD → spec → tickets → implement → ship → audit → new tickets.

Open questions

• PRD template for plugins specifically — likely narrower than a general product PRD (needs to name: the eval harness location, the green command, which existing os-* plugins it composes with per ADR-0037's composability constraint).
• Eval-first scaffolding: the red-assert analog for eval-driven development — does to-tickets//implement need a variant stage that writes the eval scenario before the skill exists, mirroring the test-writer stage in pipeline-stages?
• How improvement tickets are auto-generated from audit findings — format, who/what creates the issue (a code-actor script parsing an audit report, or an agent stage), and how duplicate/overlapping findings across the four loops get deduplicated before hitting the tracker.

Sources

• ADR-0037 (docs/adr/0037-os-sdlc-lives-inside-cc-os-as-a-new-plugin-not-a-separate-cc-sdlc-marketplace.md)
• plugins/os-sdlc/OVERVIEW.md
• plugins/os-vault/eval/, plugins/os-adr/eval/, plugins/os-context/eval/
• 2026-07-16 design session (this doc's origin)