CRAFT

Claude 101 — A Cheat Sheet

New to Claude? Start here. Already familiar? This is the shared vocabulary we'll use across the org.

The terms, in plain language

Claude (the model)

The AI itself. We use Anthropic's claude-sonnet-4-6 and claude-opus-4-6 by default. Sonnet for everyday work; Opus for hard problems (design, code, code review).

Claude.ai

The web/desktop chat interface. Where BAs, Architects, PMs do most of their AIDLC work. Has Projects, Skills, and Connectors built in.

Claude Code

A CLI / IDE-integrated version of Claude that lives in your terminal or VS Code. Sees the local repo. Runs commands. This is where developers spend most of their AIDLC time.

Project

A scoped workspace in Claude with its own knowledge files and instructions. We use Projects to implement our 3-tier context model: one Project per implementation (Tier 2), one shared Project for platform standards (Tier 1).

Context

The information loaded into a conversation: project knowledge (attached documents), system prompts, the messages so far. AIDLC's job is to make sure the right context is loaded for the right task — without you having to wrangle it manually.

Skill

A reusable, versioned playbook for one job. Example: prs-generator is a skill that turns an RFP into a PRS. Skills are invoked like slash-commands in Claude. They live in a git repo and the CoE governs them.

Plugin pack

A bundle of skills shipped together. Cardy AIDLC has 6 plugin packs: cardy-platform-base, cardy-pmo-pack, cardy-arch-pack, cardy-dev-pack, cardy-qa-pack, cardy-release-pack.

MCP (Model Context Protocol)

The open protocol that lets Claude talk to external tools and data sources. Each connector (Jira, Bitbucket, Slack, Gmail, Google Drive) is an MCP server. When you wire Jira to Claude, you're using MCP.

Connector

An MCP-based bridge to a specific tool. In AIDLC we use 5 connectors: Google Drive, Jira, Bitbucket, Slack, Gmail. Scoped per project; SSO-authenticated; audit-logged.

HITL gate

Human-In-The-Loop gate. A required human approval between two AIDLC stages. Example: BA Lead approves the PRS before fit-gap begins. Encoded in Jira workflow, not goodwill.

Eval

A measurable quality check. Each AIDLC skill has a rubric and a golden set of 20–50 example inputs. Skills are scored before they can ship.

Tier 1 / 2 / 3

The knowledge architecture. Tier 1 = org-level (Empower platform, coding guidelines, HHS domain). Tier 2 = per implementation (RFP, contract, configuration). Tier 3 = your daily working memory.

When to use which surface

What a typical CRAFT interaction looks like

You open Claude.ai. You switch to the right Project (e.g., "San Diego Implementation"). The Project loads the RFP, response, config decisions automatically as context. You invoke a skill — type /prs-generator or @claude draft AC for this story. Claude pulls from Tier 1 (platform standards) + Tier 2 (this project) and produces the artifact. You review, edit, accept. The system of record (Jira / Drive / Bitbucket) gets updated. Nothing new to learn beyond the slash-commands.

The AIDLC Methodology

12 stages. 6 buckets. 3 tiers. A human approver at every gate. Synthetic data only. That's the whole methodology.

The 12 stages

Stages 1–3 are linear. After classification, work fans out into 6 parallel sub-pipelines — one per bucket. Stages 4–12 are bucket-aware.

The 6 buckets

Every requirement, after fit-gap, lives in exactly one bucket. Buckets matter because they have different estimation rhythms, approvers, and skill clusters.

The 3-tier knowledge model

HITL gates — non-negotiable

• BA Lead approves PRS before fit-gap begins.
• Solution Architect approves fit-gap classification.
• Implementation Architect approves HLD; Empower Product Architect also approves Platform / Product Feature items.
• BA Lead + PM approve stories before development.
• Tech Lead approves LLD (bucket-specific).
• QA Lead approves test cases before they enter the master suite.
• Two human reviewers required to merge a PR; Claude can be one, never both.
• DevOps Engineer + Implementation Manager approve release.

How to Think — A Senior Architect's View

The single most-confused boundary in any Claude rollout: what is a skill, what is context, what is a connector? Get it wrong and you ship 200 "skills" that are really FAQ entries. Get it right and the library compounds in quality every quarter. Read this before you propose your first skill.

1. The five primitives

2. The 5-test — is X actually a skill?

A capability deserves to be a skill only if it passes all five. Fail any one and it's something else: context, FAQ, prompt template, or a connector call.

Worked example: is rfp-ingest a skill?

Counter-examples — what is NOT a skill

• "The Empower RBAC capability list" → that's context. Belongs in Tier 1 project knowledge.
• "How do I install Claude Code on my laptop?" → that's FAQ. Belongs in this portal.
• "Translate this paragraph into Spanish" → that's a one-off prompt. No recurrence, no structure.
• "Open this Jira ticket" → that's a connector call. The connector does it; no skill needed.
• "Summarize this Slack thread" → borderline. Ad hoc = one-off. "Weekly client status digest in this exact format" = skill.

3. Decision tree — when you're not sure

1. Is X done repeatedly across engagements? No → it's a one-off, just prompt it. Yes → continue.
2. Does X produce a defined artifact others depend on? No → private workflow, not a skill yet. Yes → continue.
3. What grounding material does X need? Universal → Tier 1 context. Per-engagement → Tier 2 context. (Skills reference context, never embed it.)
4. Can quality be scored? No → ship experimental, can't graduate to GA without evals. Yes → write the golden set and rubric alongside the skill.
5. Should the prompt + output shape evolve? No → it's a template, drop an .md in a shared folder. Yes → make it a versioned skill, CoE-reviewed PRs.

4. Skill anatomy — the 8 sections of a well-formed skill

5. Placement rules — what goes where

6. The output-quality stack

CRAFT output quality comes from four layers stacked correctly. When something feels off, diagnose from the bottom up — most failures are a Layer 2 or 3 problem, not a Layer 4 (model) problem.

Failure-mode → layer map

7. Authoring sequence — Wave A through D

The right order to author skills, optimized for shortest path to demonstrable value.

After Wave D you have ~20 skills covering the full spine on OOTB and Extension buckets. Enough to demo end-to-end and start measuring with evals. The remaining ~65 skills (other buckets, deliverables planning, governance, analytics) come in Phase 2.

8. The 5-file deliverable per skill

1. The skill markdown — skills/<skill-name>.md
2. The eval rubric — evals/<skill-name>_rubric.md
3. The golden set seed — evals/golden/<skill-name>/seed.json (start with 5 items; 20 for beta; 50 for GA)
4. The judge prompt — entry in agent_prompts registry with agent_id="evals_judge_<skill>"
5. The example invocations — skills/<skill-name>.examples.md with 3 realistic user prompts and expected outputs

Do's & Don'ts — Guardrails

The rules of the road. Read this before you start. CRAFT's leverage depends on these holding — for our clients, for our employees, and for Cardinality's IP.

The six guardrail domains

1. Security guardrails

What protects Cardinality's environment from compromise via or through Claude.

How we secure the platform

• Claude Enterprise tier with SAML/OIDC SSO. No password-only access.
• Audit logs exported to corporate SIEM. Every prompt, every tool call, every approval is recorded.
• Retention policies set at tenant level. 90-day chat retention; project archives separately governed.
• Model exclusion from training confirmed at provisioning. Anthropic does not train on Cardinality content.
• BAA signed with Anthropic as defense-in-depth (even though PHI is out of scope).
• Connector scoping: per-project access to Jira / Bitbucket / Drive / Slack / Gmail. No org-wide tokens.
• Prompt-injection defense: every AIDLC skill includes a preamble telling Claude to treat retrieved content as data, not instructions. Quarterly red-team evals.
• No autonomous destructive actions: Claude cannot push to main, merge PRs, send emails, or modify production. Enforced via connector permissions, not goodwill.

2. Data guardrails

The synthetic-only promise. This is the brand commitment behind AIDLC.

The data scope, in one sentence

No real PHI, FTI, CJI, or client production data ever enters Claude. AIDLC works on contracts (de-identified), design docs, code, configuration, synthetic personas, synthetic test data, and Cardinality-owned platform context — and nothing else.

What this looks like in practice

3. Intellectual Property guardrails

Empower is Cardinality's platform. AIDLC skills are Cardinality's methodology. Client deliverables are work-for-hire under contract. The IP rules:

4. Skill governance

How we keep the skill library trusted as it grows from 20 to 85+ skills.

• Source of truth: cardy/aidlc-skills git repo. PR-reviewed. Semver'd.
• Promotion gates: experimental → beta → GA. Each promotion requires a passing eval against the current golden set.
• Signed CoE approval: default-model and default-prompt changes require a passing eval run + CoE sign-off (enforced by trigger).
• Deprecation: 30-day deprecation window with named replacement; removal is logged.
• Champion fast-track: squad champions can ship squad-specific tweaks faster, but cross-cutting changes go through CoE.
• Audit: every skill invocation is logged with skill version, model, project, approver, eval-score-at-time-of-use.

5. People & HITL guardrails

AIDLC is human-supervised by design. The HITL gates are non-negotiable.

6. Incident response

Things will go wrong. Here's the playbook.

Severity levels

What to do if you suspect a violation

1. Don't try to clean it up alone. Reporting an honest mistake is welcomed; covering one up is not.
2. Capture evidence. Screenshot the chat, note the project, note the skill if applicable.
3. Post to #cardy-aidlc-help with the severity tag (SEV-1 etc.) and the evidence. CoE on-call is paged automatically for SEV-1/2.
4. Stop the relevant work until CoE clears it.
5. Cooperate with the post-mortem. Every SEV-1/2 gets a written post-mortem; we focus on the system, not the person.

Quick reference card

Your Role — What Changes

Pick your role to personalize. We'll surface your skill pack, your daily flow, your access date, and where to go next. Your selection persists across visits and across tabs.

All roles

The full reference. Your selected role above gets highlighted; the rest are visible for context.

Pilot: San Diego implementation

Our real pilot engagement — a San Diego county HHS implementation kicking off now. Follow this end-to-end and you'll see exactly what your role does at each stage. The engagement is real; the working artifacts in CRAFT (extracts, examples, fixtures) are de-identified per our data-scope policy.

Setup — the Tier 1 and Tier 2 documents

Tier 1 Org-level documents (set by Empower Product + CoE — once for the whole org)

Tier 2 San Diego documents (set by the implementation squad lead + PM at kickoff)

All 12 docs live in Google Drive folders that are wired to the Tier 1 and Tier 2 Claude Projects. Once they're in, every skill in the workflow grounds against them automatically.

Now the flow — stage by stage

$ claude
> /code-extension SD-7

$ git push origin feature/SD-7-safety-risk-assessment

The parallel Deliverables Track

Running alongside Stages 1–12 is the Contract Deliverables Track. PMO invokes planning skills for each contract deliverable. AIDLC does NOT generate the SSP itself; it generates a planning artifact that names contributors, sections, data sources, prior reference materials, and a draft outline. Humans author the final docs.

Timeline — PLACEHOLDER

All dates and day-counts below are PLACEHOLDER. Final dates will be confirmed and replaced once kickoff is signed off.

What you should do before your access date

• BAs & Architects: Read the Methodology and Pilot tabs by Day 20. Block 30% of your calendar for the week of Day 25–32.
• Developers / Config Specialists / Empower Platform Engineers: Install Claude Code by Day 30. Read the Pilot tab Stage 9 section. Block 30% of your calendar for the week of Day 35–42.
• QA / DevOps / PM: Read the Pilot tab end-to-end by Day 45. Identify one story per current sprint to run through CRAFT in the week of Day 50–55.

FAQ

The questions people are actually asking. If yours isn't here, post in #cardy-aidlc-help.

Resources

Links, channels, and the CoE.

Documents (Google Drive)

→ Open the CRAFT Drive folder

• Strategy doc. Full Cardy AIDLC strategy and rollout plan. Open ›
• Skill catalog. The 85-skill catalog by bucket × stage × persona. Open ›
• Evals plan. How quality is measured — rubrics, golden sets, promotion gates. Open ›
• Procurement & Day-0 checklist. Pre-flight punch list for the Foundations phase. Open ›
• Pilot pack (San Diego). De-identified RFP excerpts, Tier 1 stub, sample skill markdowns. Open ›
• This portal. Linked from the top of #cardy-aidlc-announce. Open ›

Slack channels — keep it simple

Three channels. That's it. Everything else (skill PRs, eval digest, pilot updates) is threaded inside these.

• #cardy-aidlc-announce — Announcements only. Read-only broadcast: leadership readouts, phase launches, GA promotions, eval digest summaries.
• #cardy-aidlc-coe — CoE folks only. Methodology, governance, eval rubrics, skill PR triage, model-routing decisions.
• #cardy-aidlc-help — Open to everyone, for any help and guidance. Questions, skill usage, skill proposals, drift reports, pilot chatter, office-hour overflow. CoE on-call rotation publishes here. Not the approval channel — release and stage approvals happen in each implementation project team's own channels and Jira workflow.

Claude resources

• docs.claude.com — Official Anthropic documentation for Claude, Claude Code, and Claude API.
• Prompt engineering guide — for when you want to author or refine a skill.
• support.claude.com — for account, billing, technical issues.

The CoE — Office of Innovations & AI (placeholder)

• Head of AI: · cy-platform@cardyai.com
• AI Architect
• Prompt Engineer
• Evals Lead
• Enablement Lead
• Champions: One per implementation squad — names in #cardy-aidlc-coe.

Office hours (placeholder)

• BA / Architect
• Developer / Config Specialist
• QA / DevOps / PM
• Empower Product / Platform-Product Feature

What to do right now

1. Join #cardy-aidlc-announce. You'll get every phase launch and milestone here.
2. Read the Pilot tab. It's the single highest-leverage 10 minutes you'll spend on CRAFT.
3. Mark your access date. Block 30% of your calendar for the week your role's pack ships (Timeline tab).
4. Ask one question. In #cardy-aidlc-help. We want every question now, not on your access date.

Why CRAFT

Sometimes a picture says it faster than the strategy doc. Share these in Slack, drop them in a deck, pin them above your monitor.