Claymore Plugins — Role-Based AI Tooling Design Doc#

Status: Draft v2 — all review round decisions integrated, ready for Phase 1 build Owner: Dan (Human), Clay (AI Partner) Date: 2026-04-10

TL;DR — Decompose the CSDLC process into a complete, testable skill/command system bundled as plugins. Foundry is the required knowledge layer. /standup is the entry point that activates the full process. The first target role is "Software Developer using CSDLC." If we nail this, any role can get a curated AI workflow by installing a plugin bundle.

Problem Statement#

Dan's CIO wants to roll out AI tools like Claude Code to developers. But giving someone CC without a workflow is like giving someone a compiler without a language — technically powerful, practically useless. The tooling needs to come with opinions about how to use it.

CSDLC is that opinion. The goal: turn it from a methodology document into a complete plugin system where every pipeline step has a corresponding skill or command. A developer installs the plugin, runs /standup, and the full workflow is active.

Scale goal: The CSDLC core is domain-agnostic (thesis Insight #6: "Beyond Code"). Code-specific skills live in the role bundle. The same pattern applies to any role — data engineer, QA lead, product manager, even non-technical roles like HR. Possible future rebrand to "Claymore Process" since CSDLC has "Software" in the name.

Foundry as the Knowledge Layer#

Foundry is required, not optional. This is a load-bearing architectural decision grounded in the CSDLC thesis (Insight #4: "Documentation as an Intelligence Layer").

Why Required#

1. Solves the cold start problem. Every AI session starts from zero. Foundry holds institutional memory — design docs, session state, stories, reviews.
2. Shared surface for CC and Cowork. Both tools speak Foundry MCP. It bridges refinement (iPad/Cowork) and execution (Mac/CC).
3. Cross-project visibility. Developer A's docs are visible to developer B's AI Lead. Organizational knowledge infrastructure.
4. Skills are Foundry-native. Skill outputs write TO Foundry (sections, annotations, reviews). Skills read FROM Foundry (design docs, NEXT.md, stories).
5. The Dispatch workflow depends on it. Foundry is the async queue between iPad and Mac.

Multi-User Knowledge Base#

Per-user state is separated while project docs are shared:

status/
  dan/next.md              ← Dan's session state
  sarah/next.md            ← Sarah's session state
projects/
  foundry/design.md        ← Shared project design doc
  routr/design.md          ← Different project, same Foundry

Each developer's AI Lead reads THEIR status/{username}/next.md for standup. Cross-project visibility works — read anyone's NEXT.md to see what they're up to.

NEXT.md: Foundry is Canonical, Local is Fallback#

• Cowork can only see Foundry (can't read local files)
• CC can see both (local files AND Foundry via MCP)
• If Foundry is unreachable, standup falls back to local NEXT.md
• But Foundry is the source of truth

Foundry Instances#

v1: One Foundry instance per team, split by domain (software team's KB, HR's KB, etc.). Multi-instance architecture deferred.

How the Process Activates#

/standup is the Entry Point#

The CSDLC process does NOT auto-activate. This is deliberate:

1. Dev starts CC with the CSDLC plugin installed
2. Agent sees skill list but doesn't auto-load anything
3. Dev says /standup (or /standup clay for persona)
4. Standup skill loads → reads process reference → reads NEXT.md from Foundry → delivers 5-part standup
5. Agent now has full CSDLC context and is operating under the methodology

Why this matters: It enables A/B testing — use CC normally for quick tasks, /standup when you want the full workflow. No forced overhead. Clean separation.

/standup [persona] — Persona as Argument#

Commands support arguments via $ARGUMENTS / $0 placeholders in SKILL.md (string-substituted before the agent sees the prompt):

• /standup = start CSDLC, neutral AI Lead
• /standup clay = start CSDLC as Clay
• /standup [custom] = start CSDLC as any team-defined persona

One entry point. Don't touch CLAUDE.md — /standup is all you need.

What Exists Today#

Current Plugin Structure#

claymore-plugins/
├── csdlc/
│   ├── commands/
│   │   ├── standup.md       # /standup → csdlc-standup
│   │   ├── retro.md         # /retro → csdlc-retro
│   │   ├── doc.md           # /doc → csdlc-doc
│   │   └── refine.md        # /refine → csdlc-refine
│   └── skills/
│       ├── csdlc-process/        # Methodology reference
│       ├── csdlc-standup/        # Standup ritual (renamed)
│       ├── csdlc-retro/          # Session handoff (renamed)
│       └── csdlc-craft-agent-prompt/
└── foundry/
    └── skills/
        └── foundry-mcp-reference/

Coverage Gaps#

5 of 7 pipeline steps have no skill support.

Design Principles#

1. Skills support the process. PROCESS.md is the source of truth. Every skill maps to a step, role, or ritual.
2. Templates live IN the skills. Plugin repo is the source of truth for templates. Self-contained and portable.
3. Commands are shortcuts, skills are capabilities. Commands invoke skills; they don't contain logic.
4. Skills are testable. Clear input → output contracts.
5. Skills are Foundry-native. Outputs write to Foundry. Inputs read from Foundry.
6. CSDLC core is domain-agnostic. Code-specific skills go in the role bundle.
7. Composition through prompting. Skills reference other skills by name. The agent chains via reasoning.

Commands vs. Skills#

Command Map#

Session:
  /standup [persona]  — Start CSDLC, load context, deliver standup
                        Optional persona: /standup clay
  /retro              — End session, write handoff to Foundry NEXT.md

Design:
  /doc                — Generate a Step 0 design doc
  /refine             — Challenge and refine any artifact
  /bootstrap          — Set up CSDLC for an existing project

Execution:
  /intern             — Hand off a single story to a sub-agent
  /shipit             — Run all stories in an epic autonomously (Hurricane Pattern)

Quality:
  /review             — Structured review of agent output
  /qa                 — QA checklist against acceptance criteria
  /present            — Package work for async human review

The Complete Skill Map#

Tier 1: Already Built#

Tier 2: Core Gaps (build these to complete the pipeline)#

Tier 3: Process Support#

Tier 4: Role-Specific Extensions#

Template Bundling#

Templates live IN the skills. Plugin repo is the source of truth.

csdlc-doc/
├── SKILL.md
└── templates/
    ├── project-design.md
    ├── epic-design.md
    └── subsystem-design.md

Skill Versioning#

1. Tag PROCESS.md with process_version: X.Y
2. Each SKILL.md declares which version it targets
3. Lint step flags skills behind current process version
4. Updates require human/AI judgment (not auto-rebuild — skills encode HOW, not just WHAT)

Skill Composition — How It Works#

CC's plugin system has no native skill-to-skill dependencies. Here's what works:

Arguments: $ARGUMENTS / $0 / $1 placeholders. String-substituted before the agent sees the prompt. /standup clay just works.

Skill chaining: A skill's SKILL.md can instruct the agent to invoke another skill by name. The agent sees all installed skills and follows the instruction. Example: /intern says "use csdlc-craft-agent-prompt to assemble the prompt."

Hooks: Shell commands on events (e.g., UserPromptSubmit). Regex matchers for tighter orchestration if prompt-based chaining isn't enough.

Not supported: No dependencies in plugin.json. No guaranteed invocation. No skill-to-skill message passing.

Testing#

Four Levels#

1. Structural (automated): SKILL.md parses? Command references real skill? Templates exist? process_version declared?
2. Contract (semi-automated): Known input → output matches schema. "Does /standup produce all 5 parts?"
3. Integration (manual): Full pipeline: /bootstrap → /doc → /refine → /breakdown → /intern → /review → /qa → /present
4. User acceptance (real usage): Deploy to Dan, then colleagues. Iterate on feedback.

Plugin Composition Model#

Base Layer — Methodology. CSDLC process, values, rituals. Domain-agnostic.

Tool Layer — MCP Platforms. Foundry (knowledge layer), GitHub, etc. Capabilities that skills consume via MCP tools.

Role Layer — Role Bundle. Base + tools + role-specific skills. "Software Developer" = CSDLC + Foundry + dev skills.

Project Layer — Per-Project. WORKFLOW.md + CLAUDE.md in the project repo. Adapts the bundle to a specific codebase.

Project Layer:   WORKFLOW.md + CLAUDE.md
                   ↑
Role Layer:      "software-developer" (CSDLC + Foundry + dev skills)
                   ↑
Tool Layer:      Foundry MCP, GitHub MCP
                   ↑
Base Layer:      CSDLC core (process, values, rituals)

Future Role Bundles#

The "Software Developer" Role Bundle#

What's In It#

Software Developer Role
├── csdlc plugin
│   ├── /standup [persona] (entry point)
│   ├── /retro, /bootstrap, /doc, /refine
│   ├── /breakdown, /intern, /shipit
│   ├── /review, /qa, /present
│   └── /process (reference)
├── foundry plugin
│   ├── MCP reference + patterns
│   └── foundry-review
└── project WORKFLOW.md (generated by /bootstrap)

First Session#

Developer: /standup
Agent: No NEXT.md found — fresh setup.
       1. What project are you working on?
       2. Existing design doc or starting fresh?
       3. What's your Foundry instance URL?
       
       Run /bootstrap to set up WORKFLOW.md and Foundry project space.

Distribution (v1)#

Private GitHub repo. git clone + point CC at it. Updates via git pull.

Build Plan#

Phase 1: Complete the Core Pipeline#

1. csdlc-bootstrap — project onboarding
2. csdlc-doc — Step 0 with bundled templates
3. csdlc-breakdown — Step 1 story decomposition
4. csdlc-intern — Step 3 sub-agent handoff
5. csdlc-review — Step 4 structured review
6. csdlc-qa — Step 5 QA
7. csdlc-present — Step 6 async presentation
8. foundry-review — annotation conventions
9. Rename existing skills, bundle templates

Phase 2: Testing Infrastructure#

1. Structural lint for SKILL.md files
2. Contract test framework
3. Process version tagging + staleness lint

Phase 3: Role Bundle + Onboarding#

1. "Software Developer" bundle manifest
2. First-session onboarding flow
3. Test with Dan, then colleagues

Phase 4: Scale#

1. "How to build a role plugin" documentation
2. One non-dev role bundle as proof of portability
3. Internal rollout plan

Decisions Log#

All open questions resolved across 2 review rounds (23 annotations). Ready for Phase 1 build.