AI SDLC Strategy Team: 10 people · Hybrid · AWS · Claude + Copilot
AI SDLC Strategy · v2.0
AI as a full participant,
not a helper
The old approach: AI as a helper per role. The new approach: AI with its own zones of responsibility in every phase of the sprint cycle. The question is not "who uses Claude" — it's "how do we redesign the process assuming AI does real work."
Core Principle

Every phase has a human layer where people work with Claude interactively, and a fixed human gate where no AI output passes without a person signing off. Claude generates first drafts — humans review, validate, and decide. Always.

How It Works
✍️
AI writes, humans review
Claude generates first drafts across all phases. Every role shifts from author to editor — not from thinker to approver.
🔒
Human gates are non-negotiable
5 mandatory points where no AI output passes without sign-off: Requirements, Architecture, Code Review, QA, and Production Release.
🎯
Context in, quality out
Claude's output quality is directly proportional to the specificity of input. Vague prompt → vague output. Structured prompt → structured output.
📈
Incremental automation
Start with human + Claude interaction. Automate pipelines only after the team builds confidence in AI output quality for this specific context.
Parallel Tracks
Multiple roles work simultaneously
This is an agile process — not waterfall. Several phases have parallel tracks where different roles work concurrently, merging at gate points.
02 · TechLead + Designer in parallel 03 · TL + BE + FE + DevOps in parallel 04 · QA Lead + QA Eng in parallel
Feedback Loops — Expected, Not Exceptions
🔄
Sprint Loop
After every sprint, the cycle repeats from Phase 01. This is the fundamental agile heartbeat — the wheel never stops turning.
Phase 06 Monitor → Phase 01 Discovery
🐛
Bug Fix Loop
QA Engineer finds a bug and creates a structured bug report (Claude). Development fixes it. QA retests. This loop is normal — not a failure.
Phase 04 Testing → Phase 03 Development
🔍
Gap Found Loop
When gap analysis (BA + TechLead) reveals incomplete or contradictory requirements, BA returns to Phase 01 to update User Stories before development begins.
Phase 02 Design → Phase 01 Discovery
Human Gates — Where AI Does Not Decide
📋 Requirements Gate
Owner → BA
🏗 Architecture Gate
Owner → TechLead
🔍 Code Review Gate
Owner → TechLead
✅ QA Gate
Owner → QA Lead
🚀 Production Release Gate
Owner → Manager
Technology
Interactive Layer — Now
Claude (personal) Copilot
Automation Layer — Future
Amazon Bedrock AWS Lambda EventBridge Step Functions
Sprint Cycle — Click a phase to explore
ONE-TIME
🎯
00
Project
Setup
🏆
CL
Project
Closure
ONE-TIME
Sprint loop
Bug fix
Gap found
👆
Click any phase on the sprint wheel to see who's involved and where Claude operates.
Anatomy of a Claude Skill
A Skill is a .md file with instructions that Claude reads before executing a task. Skills don't store state between sessions — they give Claude a role, a process, and an output format. Context comes in per-conversation via documents and files.
🧠
Role & Thinking
Who Claude is in this context. How it reasons, what it prioritizes, what it refuses to guess.
BA: "Analyze requirements for contradictions and gaps — don't just record what the client said."
📥
Input Definition
What the person must bring to the conversation. Without a clear input spec, the skill produces unpredictable output.
BA: session recordings, previous docs, SOW, DoR/DoD
⚙️
Process Steps
How Claude processes input. Makes output predictable across sessions and people. Stop conditions included.
Find contradictions → ask for missing info → structure → generate sections
📤
Output Format
Exact sections, headings, depth. Most critical for consistency across team members and sessions.
BRD: Overview / Stakeholders / Requirements / AC / Risks / Open Questions
🚫
Stop Conditions
When Claude must pause and ask rather than generate. Prevents confident hallucination on incomplete input.
"If a requirement is ambiguous — ask. Do not assume or invent."
📏
Optimal Size
200–400 lines for role skills. Too short → Claude improvises. Too long → Claude gets lost in instructions.
Shared skills (templates + examples) can be longer — they're reference material
Two Types of Skills
Skills separate into two distinct types based on scope and ownership. Role skills belong to one person. Shared skills belong to the team. Never duplicate shared logic into role skills.
🎭 Role Skill
What this role does and how it thinks
Describes reasoning, document structure, and process for a specific role. Portable across projects — a new project means a new project-context, not a new role skill.
ba-skill.md
qalead-skill.md
qa-skill.md
techlead-skill.md
manager-skill.md
devops-skill.md
dev-skill.md
designer-skill.md
🌐 Shared Skill
Team-wide conventions, not role-specific
Style guides, client communication conventions, document templates. Used by multiple roles. Invoked via @skill-name in conversation — not baked into role skills. Live in docs/.claude/skills/shared/ in the repo.
globallogic-doc.skill
globallogic-pptx.skill
jp-email.skill
jp-translation.skill
What Goes Where
Three mechanisms for loading context into Claude. The rule: if needed in every conversation → automate it. If situational → invoke manually.
📋
Project Instructions
Automatic · Every conversation
Role skill content (copy from .md)
Always active, no user action needed
One per Claude Project
📁
Project Files
Automatic · Every conversation
project-context.md — project overview + references
team.md — roles, names, contacts
client.md — client profile, culture, key contacts
tech-stack.md — finalized stack + key decisions
conventions.md — commit format, git branching, naming, doc language
All set up once at Phase 00 — each file owned by one role
🔗
@ Skills
Manual · Per task
@globallogic-doc → when making a doc
@jp-email → when writing to client
@globallogic-pptx → when making slides
@jp-translation → when translating docs to Japanese
Git Repository Structure
Skills live in the project repository alongside code. This gives versioning, PR reviews, and a single source of truth for the whole team. When a skill changes, every team member updates their Claude Project from the same file.
project-repo/
  README.md
  app/
    ai-sdlc.html ← AI SDLC strategy document
  docs/
    decisions-log.md ← architectural decisions + ideas + todos
    .claude/
      meta/ ← framework design files
        ai-sdlc-infrastructure.md ← framework architectural decisions
        ai-sdlc-instructions.md ← Project Instructions source for meta-project
        roles-claude-context.md ← what each role does with Claude, phase by phase
      setup/
        setup-guide.md ← one guide for all roles
        skill-building-guide.md ← how to build a role skill with Claude
      skills/
        roles/
          ba-skill.md
          designer-skill.md
          dev-skill.md
          devops-skill.md
          manager-skill.md
          qa-skill.md
          qalead-skill.md
          techlead-skill.md
        shared/ ← shared skills (invoked via @)
          globallogic-doc.skill
          globallogic-pptx.skill
          jp-email.skill
          jp-translation.skill
        context/ ← stable project context files
          project-context.md ← overview + references to other files
          team.md ← owned by Manager
          client.md ← owned by Manager
          tech-stack.md ← owned by TechLead
          conventions.md ← owned by TechLead
  infrastructure/ ← Terraform, CI/CD, deploy configs
How Context Moves Between Roles
Claude instances don't talk to each other. Handoffs happen through artifacts — files that one role generates and the next role loads into their conversation. The shared docs location (Drive, Confluence, or repo /docs) is the bridge. Gates are the triggers — when a gate passes, an artifact is ready to be picked up by the next role.
BA
Generates
BRD.docx
Shared Docs
Saves to
Drive / Confluence / /docs
TechLead
Loads into
conversation
TechLead
Generates
tech-spec.md
Shared Docs
Saves to
next roles pick up
Gate → Artifact trigger
Gate Who saves Artifact Who picks up
Requirements Gate BA brd.docx TechLead, QA Lead, Manager
Architecture Gate TechLead tech-spec.md, arch-decisions.md BE Dev, FE Dev, Designer, DevOps, QA
Code Review Gate TechLead merged code + API docs QA Lead, QA Engineer
QA Gate QA Lead qa-sign-off.md, test-results DevOps, Manager
Staging Gate DevOps release-notes.md, rollback-plan.md Manager (final go decision)
How Skills Are Updated
Skills version with the codebase. Changes go through PR — same discipline as code. After merge, affected team members update their Claude Project instructions manually (copy-paste from updated .md file).
1. QA Lead notices qa-skill generates test cases without edge cases
2. QA Lead updates docs/.claude/skills/roles/qa-skill.md locally
3. Opens PR → team reviews → merges
4. git tag v1.1 ← new version tagged
5. QA Lead + QA Eng copy new content → paste into Claude Project instructions

Who can update what:
Role skill → the role that owns it (PR → approver → merge)
Shared skill → any role via PR; Manager or TechLead approves (affects everyone)
project-context / team / client → Manager (on project changes)
tech-stack / conventions → TechLead (on architecture changes)
Building a skill from scratch
Follow docs/.claude/setup/skill-building-guide.md — it walks through all 5 parts with Claude, one at a time. Expect 1–2 hours for a first skill.
Recommended Google Drive Structure
Google Drive stores project artifacts only — no Claude skills or context files (those live in Git). Structure mirrors SDLC phases so any team member knows where to find and save documents without asking.
[Project Name]/
  00_Setup/
    contracts/ ← NDA, MSA, SOW
    governance/ ← RACI, Comm Plan, DoR, DoD
    access/ ← Access Matrix
  01_Discovery/
    sessions/ ← recordings, transcripts
    brd/ ← brd-v1.docx, brd-v2.docx...
    roadmap/ ← Project Roadmap, Release Plan
  02_Design/
    architecture/ ← Tech Spec, ADR, Architecture Overview
    test-plans/ ← test-plan-[feature-name].md
  03_Development/
    status-reports/ ← weekly/sprint client reports
  04_Release/
    release-notes/ ← technical + client versions
    deployment/ ← Deployment Guide, Rollback Plan
  05_Monitoring/
    incidents/ ← incident reports
    retros/ ← sprint retro summaries
  06_Closure/
    knowledge-transfer/ ← Runbook, Maintenance Guide
    acceptance/ ← Client Acceptance Sign-off
    lessons-learned/ ← final lessons learned doc
Setup Guide
Steps 1–7 are identical for every role. After completing them, find your role in the diff section below and complete only what's listed there.
Claude Products
💬 Claude Chat
claude.ai
Conversations, document generation, analysis. Base tool for all roles. Uses Claude Projects for persistent role context.
🖥️ Claude Cowork
Claude Desktop app
Multi-step tasks with local files and apps. No terminal. For recurring workflows and tasks spanning multiple files or sources.
⌨️ Claude Code
Terminal / CLI
Agentic coding at project level. Reads full codebase, plans across files, runs tests. For devs, QA, and DevOps working directly with code.
🎨 Claude Design
claude.ai/design
Creates prototypes, wireframes, slides through conversation. Reads codebase and design files to apply team's design system automatically.
✏️ GitHub Copilot
IDE extension
Inline code suggestions as you type. Complements Claude Code — Copilot handles autocomplete, Claude Code handles full task execution.
Connectors (MCP)
🔌 Ticketing MCP
All roles
Tasks, AC, sprint data, bug reports directly in Claude — no copy-paste from the ticketing system.
🔌 Figma MCP
Designer · FE Dev
Designer creates and edits components, tokens, mackets. FE Dev reads specs and assets for implementation.
🔌 Google Drive MCP
All roles
Read and write project artifacts directly from Claude — no manual file uploads per conversation.
Meta-Project Setup — one time only
Before the team can build or update role skills, one person sets up the Claude Project where framework design happens. This is separate from individual team members' implementation projects.

Files live in docs/.claude/meta/ — upload all three as Project Files, paste ai-sdlc-instructions.md as Project Instructions.

Full setup steps: docs/.claude/setup/skill-building-guide.md → Meta-Project Setup section.
Common setup — all roles
1
Get the repo
Pull the project repo. Open docs/.claude/setup/setup-guide.md — it mirrors these steps with role-specific details.
2
Create a Claude Project
claude.ai → New Project → name it after the project — use the name agreed with BA in Phase 00.
3
Project Instructions
Inside the Project → Instructions tab → paste the full contents of docs/.claude/skills/roles/[your-role]-skill.md
4
Project Files
Inside the Project → Files tab → upload all 5 files from docs/.claude/skills/context/
project-context.md · team.md · client.md · tech-stack.md · conventions.md
5
Shared Skills
claude.ai → Settings → Skills → Add skill → paste each file from docs/.claude/skills/shared/ → name = filename without .skill
globallogic-doc · globallogic-pptx · jp-email · jp-translation
6
Google Drive MCP
claude.ai → Settings → Connectors → Google Drive → Connect → authorize → select project folder
7
Smoke test
New conversation inside the Project → "What role are you in, what project are you working on, and what do you need from me to start?" → Claude should respond in your role and ask for the right inputs.
Role diff — additional setup only
Manager
Chat
Cowork
@ Skills
@jp-email
@globallogic-pptx
@globallogic-doc
MCP
Ticketing MCP
Google Drive MCP — Cowork
Gmail MCP
Extra
Download Claude Desktop for Cowork. Sign in with same account. Gmail MCP: claude.ai → Settings → Connectors → Gmail → Connect.
BA
Chat
Cowork
@ Skills
@globallogic-doc
@jp-email
MCP
Ticketing MCP
Google Drive MCP — Cowork
Extra
Download Claude Desktop for Cowork. Sign in with same account.
TechLead
Chat
Code
@ Skills
@globallogic-doc
@globallogic-pptx
MCP
Ticketing MCP
Google Drive MCP
Extra
docs.anthropic.com/claude-code — installation instructions per OS and IDE
BE Dev / FE Dev
Chat
Code
Copilot
@ Skills
none — role skill covers all output
MCP
Ticketing MCP
Google Drive MCP
Figma MCP (FE only)
Extra
Claude Code: docs.anthropic.com/claude-code — instructions per OS and IDE. Copilot: VS Code → Extensions → GitHub Copilot. Two devs, identical setup — tasks differ via the ticketing system.
Designer
Chat
Design
@ Skills
@globallogic-pptx
@globallogic-doc
MCP
Figma MCP
Ticketing MCP
Google Drive MCP
Extra
Claude Design: claude.ai/design → Connect codebase → upload Figma exports + CSS tokens.
QA Lead
Chat
Code
@ Skills
@globallogic-doc
MCP
Ticketing MCP
Google Drive MCP
Extra
Primary tool: Chat for planning, gate decisions, test plan and UAT report generation. Claude Code for autotests code review and coverage analysis. docs.anthropic.com/claude-code — installation instructions per OS and IDE.
QA Engineer
Chat
Code
@ Skills
none — role skill covers all output
MCP
Ticketing MCP
Google Drive MCP
Extra
Primary tool: Claude Code for automated test writing, execution, and bug report generation. docs.anthropic.com/claude-code — installation instructions per OS and IDE.
DevOps
Chat
Code
@ Skills
none — role skill covers all output
MCP
Ticketing MCP
Google Drive MCP
Extra
docs.anthropic.com/claude-code — installation instructions per OS and IDE
What Can and Cannot Go Into Claude
The team uses claude.ai Pro — data is not used for model training. But sending sensitive data is still a risk: data in transit, potential account compromise, and client trust. These are team agreements, not technical restrictions.
🚫 Never send
Client PII — names, emails, phone numbers, personal data
Credentials — API keys, passwords, tokens, secrets
Client financial data — transactions, account numbers, balances
Client source code if NDA explicitly restricts it
Internal HR data — salaries, performance reviews
✓ Safe to send
Anonymized requirements and specifications
Team's own source code
Architecture and technical decisions
Publicly available client information
Generic business logic without sensitive context
Test data — synthetic or anonymized only
Practical rule: If you're unsure — anonymize before sending. Replace real names with placeholders, remove actual credentials, replace real financial figures with examples. Claude works just as well with anonymized input.
How Skills Are Updated and Approved
Each role owns its skill and is responsible for keeping it current. Changes go through a lightweight PR process — same discipline as code. Three triggers, one procedure.
🐛
Error trigger
Claude made the same mistake twice in the same role
Missing stop condition, wrong output format, or invented information
Priority: fix immediately
💡
Improvement trigger
Role found a better process, template, or output structure
New task type not covered by current skill
Priority: next sprint retro
🔄
Project change trigger
Client communication style changed
New conventions agreed by team
Scope or methodology shift
1
Role updates the .md file locally
Edit docs/.claude/skills/roles/[role]-skill.md in the repo. Add a comment at the top of the PR describing what changed and why.
2
Opens PR → approver reviews
Approver checks that the change solves the stated problem without breaking existing behavior. One approval required.
3
Merge → git tag
git tag v[X.Y] -m "qa-skill: added edge case stop condition"
4
Affected roles update their Claude Project
Copy new .md content → paste into Project Instructions. Start a new conversation to pick up changes.
Skill ownership and approvers
Skill Owner Approver
ba-skill.md BA Manager
qalead-skill.md QA Lead Manager
qa-skill.md QA Engineer QA Lead
designer-skill.md Designer BA
manager-skill.md Manager no approval required
dev-skill.md BE Dev / FE Dev TechLead
devops-skill.md DevOps TechLead
techlead-skill.md TechLead Manager
How to Measure Whether AI Is Actually Saving Time
Don't measure "are we using Claude" — measure whether it changes delivery speed and quality. Track before/after at the artifact level, not the conversation level.
📄
Artifact Generation Time
Time from "start writing" to "ready for review" per document type.
BRD: baseline X hours → with Claude Y hours Test Plan: baseline → with Claude Status Report: baseline → with Claude
🔁
Review Iterations
Number of revision cycles before a document is approved at a gate.
Fewer iterations = Claude output is closer to what the team expects. More iterations = skill needs improvement.
🔍
Code Review Time
Time TechLead spends on PR review after Claude Code first pass.
Track: issues caught by Claude vs issues caught by TechLead. Ratio shows Claude Code effectiveness.
🐛
Bugs Reaching QA Gate
Number of bugs found in QA that should have been caught in Dev.
Downward trend = Claude Code review + unit test generation is working. Flat = process gap.
⏱️
Sprint Ceremony Time
Time spent on retros, planning, and status reporting per sprint.
Retro with Claude-generated summary should be shorter and more focused than without.
📊
How to Collect
Don't over-engineer. Simple tracking is enough at L1.
Ticketing system time tracking per story + team retrospective signal ("did Claude help this sprint?") + Manager's subjective delivery assessment
What To Do When Claude Makes a Mistake
Claude will make mistakes. The system is designed to catch them at human gates before they cause damage. Three questions: who catches it, how to fix it, how to prevent recurrence.
1
Catch — who and where
Every gate is a catch point. Requirements Gate catches BA output. Architecture Gate catches TechLead output. QA Gate catches Dev output. Code Review Gate catches every PR. No AI output reaches the next phase without a human signing off.
If a mistake passes a gate — the gate process failed, not just Claude.
2
Fix — in the same conversation
Don't start a new conversation. Point out the error directly: "This section is wrong because X. Correct it based on Y." Claude has full conversation context — correction is faster than regeneration.
If the error is structural (wrong format, wrong logic) — check if the skill prompt caused it before fixing manually.
3
Prevent — update the skill
If the same mistake happens twice — it's a skill problem, not a Claude problem. The skill is missing a constraint, a stop condition, or an output example.
Fix: update the skill .md → PR → merge → team updates their Project Instructions. Tag the change in git with a note about what was corrected.
Error types and responses
Error type Example Response
Factual error Wrong requirement in BRD Correct in same conversation, human reviews again
Format error Wrong document structure Check skill output format section, update if missing
Hallucination Claude invented a requirement Add stop condition to skill: "if not in source material — ask, don't invent"
Systemic error Same mistake across multiple sessions Skill update via PR — fix root cause, not symptoms
Document Registry
All documents produced across the SDLC. Owner = who creates it. Approver = who signs off. Gate = the gate at which the document must be ready.
Document Phase Owner Approver Gate
Phase 00 — Project Setup
NDA 00 Manager Client + Manager Setup Gate
MSA 00 Manager Client + Manager Setup Gate
SOW 00 Manager Client + Manager Setup Gate
RACI Matrix 00 Manager + BA Manager Setup Gate
Communication Plan 00 Manager + BA Manager Setup Gate
Definition of Ready 00 BA + QA Lead + TechLead Manager Setup Gate
Definition of Done 00 TechLead + QA Lead Manager Setup Gate
Access Matrix 00 DevOps Manager Setup Gate
Project Kickoff 00 Manager + Full Team Manager + Client Setup Gate
Phase 01 — Discovery
BRD 01 BA BA + Manager + TechLead + QA Lead Requirements Gate
Project Roadmap 01 Manager + BA Client Requirements Gate
Release Plan (initial) 01 Manager + BA Client Requirements Gate
Open Questions Log 01 BA BA
Out of Scope Register 01 BA BA + Manager
Phase 02 — Design & Architecture
Tech Spec + ADR 02 TechLead TechLead + Manager Architecture Gate
Architecture Overview / SAD 02 TechLead TechLead + Manager Architecture Gate
Release Plan (refined) 02 Manager + BA + TechLead Client Architecture Gate
Phase 03 — Development
Test Plan 03 QA Lead QA Lead + BA
Test Cases 03 QA Lead + QA Engineer QA Lead
Deployment Guide 03 DevOps TechLead
Status Report 03 / 05 Manager Manager
API Docs + Architecture Notes 03 BE Dev / FE Dev TechLead Code Review Gate
Phase 04 — Testing & QA
Test Execution Results 04 QA Engineer QA Lead QA Gate
Test Coverage Report 04 QA Lead QA Lead + TechLead QA Gate
Bug Reports 04 QA Engineer QA Lead
UAT Report 04 QA Lead QA Lead QA Gate
Phase 05 — Release & Deploy
Release Checklist 05 DevOps DevOps + TechLead Staging Gate
Technical Release Notes 05 DevOps + TechLead TechLead Staging Gate
Client Release Notes 05 Manager Manager Staging Gate
Rollback Plan 05 DevOps TechLead
Phase 06 — Monitor & Iterate
Sprint Retro Summary 06 Manager + TechLead Manager
Incident Report 06 DevOps TechLead + Manager
Cross-phase — DevOps Ongoing
Access Change Log Entry Ongoing DevOps DevOps
Documentation Entropy Report Ongoing DevOps DevOps
Cost Report Ongoing DevOps DevOps + Manager
Phase Closure
Knowledge Transfer Package Closure TechLead + DevOps Client Client Acceptance Gate
Client Acceptance Sign-off Closure Manager Client + Manager Client Acceptance Gate
Lessons Learned Closure Manager + TechLead Manager
Offboarding Revocation Checklist Closure DevOps DevOps + Manager