Knowledge Sharing & Continuous Improvement

Close the sample project. Verify the knowledge base. Bridge to real projects.

GATE → VERIFY → RETRO → NEXT

Module Overview

Module 7 closes the loop. The Sprint 1 Readiness gate confirms the artifact chain is complete and traceable; then the knowledge-sharing track turns three weeks of individual learning into organizational capability — each participant presents the assets they built, the team runs an AI retro, and everything is committed so the next cohort starts ahead. It also bridges from the training sandbox to real billable projects.

At a glance
Covers	The Sprint 1 Readiness gate; asset design reviews; the AI retro (what worked / what didn’t / action items); committing to the knowledge base; the bridge to real projects
When it runs	Week 3 Friday (in-person) — the final session
Builds on	Everything — the full chain and the assets from Module 6
Leads into	Real client projects (and Module 8 for brownfield work)

What you'll produce

A signed-off Sprint 1 Readiness verdict, your three AI assets committed to the knowledge base with a peer-reviewed design review, and a team retro document in knowledge/retros/ that the next facilitator reads first.

How This Session Runs

Week 3 Friday. The final session. Two tracks:

Track	Duration	What happens
1 — Sprint 1 Readiness Gate	First half	Each role presents Week 3 deliverables. Artifact chain review. Sprint 1 Readiness verdict.
2 — Knowledge Sharing	Second half	Verify knowledge directory. Present built assets. Project retro. Bridge to Module 8.

This is a human session. Checklists and templates below — not AI prompts. The work here is presenting, reviewing, and reflecting as a team.

Checklist 1 — Sprint 1 Readiness Gate

Walk through each item as a team. Mark pass or fail. Any failed item in the first section is a gate blocker.

Artifact Chain

BRD exists in docs/brd/ with numbered requirements (BR-XX)
PRD exists in docs/prd/ with user stories referencing BRD requirements
Architecture Document + per-epic ADRs exist in docs/arch-docs/
Per-epic Dev Tasks CSVs exist in docs/dev-tasks/ with acceptance criteria, dependencies, and role assignments
Full traceability: pick 3 Dev Tasks, trace each back through PRD → BRD

Code and Tests

All planned Dev Tasks are merged OR explicitly deferred with a documented reason
Every merged PR references a Dev Task ID in the commit message
Every Dev Task has a test file with acceptance-criteria-based tests
All tests pass locally
Code review completed — no unresolved Critical or High findings

Verdict

Sprint 1 Ready — all items pass. Record on sign-off form.

Not Ready — list blockers with owners and re-review date. Not a failure — an honest assessment.

Checklist 2 — Knowledge Directory Verification

Verify that the knowledge directory is properly structured and populated. Every participant should have contributed at least one rule extension, one agent, and one skill.

Directory Structure

knowledge/
├── README.md                          # Overview of what’s here
├── prompts/
│   ├── dev/                           # Developer prompt templates
│   ├── solutions-designer/
│   ├── solutions-architect/
│   ├── tech-lead/
│   ├── product/
│   └── project-manager/
├── patterns/                          # Multi-step workflows
├── rules/                             # Coding standards + rationale
├── agents/
│   ├── dev/
│   ├── solutions-designer/
│   ├── solutions-architect/
│   ├── tech-lead/
│   └── product/
├── skills/                            # SKILL.md per skill
├── retros/                            # Project retro documents
└── templates/                         # Reusable document templates

Per-Participant Verification

Item	Check
Rule extension	Added to AGENTS.md. Specific, verifiable, scoped correctly. Tested in a fresh session.
Agent	Committed to knowledge/agents/{role}/. Has frontmatter (name, description, tools). Has system prompt with what-you-do, never-do, output format.
Skill	Committed to knowledge/skills/{name}/SKILL.md. Has frontmatter (name, description). Has what-to-do, inputs, output format, constraints.
README updated	Role subfolder README lists the contribution: file name, purpose, best used for.
Peer reviewed	At least one other participant reviewed the assets before commit.

Quality over quantity

3 well-structured, peer-reviewed assets per participant is the bar. Raw output, unparameterized prompts, and untested agents do not count.

Judge contributed prompts and agent system prompts against the Module 3 (Prompt Engineering Fundamentals) craft — clear structure, the right technique, no vague instructions. A prompt that wouldn’t pass the Module 3 bar isn’t contribution-ready.

Project Retro Template

Run the retro as a team conversation. One specific observation per person per question. No repeats. 7–8 minutes per question. Facilitator captures notes.

Question	What to share
What AI techniques worked on this project?	Specific: which prompt pattern, agent, or workflow produced consistently good results on actual tasks
Where did AI slow us down?	Where correction time exceeded writing from scratch. Where sessions degraded. Where context went wrong.
What would we do differently on the next project?	Approach, tooling, task structure, context strategy, team workflow changes
What should the next team know?	Lessons that transfer to any AI-assisted project — not project-specific details

After the discussion, capture the output in this format and commit to knowledge/retros/:

# knowledge/retros/{project-date}-retro.md
 
## Project
[name, date, team composition]
 
## What Worked
- [specific technique + which tasks it helped]
 
## What Didn’t Work
- [specific problem + what it cost in time or quality]
 
## What We’d Do Differently
- [change] — Owner: [name]
 
## Top 3 Reusable Assets
[agents, skills, or prompts that worked well and transfer to other projects]
 
## Top 3 Pitfalls
[what to avoid on the next AI-assisted project]

What’s Next — Applying the Framework to Real Projects

The training taught the framework through a greenfield sample project — building the full artifact chain from scratch. Your real billable projects are different: code already exists, documentation is scattered or missing, architecture decisions were made without ADRs.

Module 8 covers exactly this: how to retrofit the AI SDLC framework onto an existing project. The principle is the same chain (BRD → PRD → Architecture → Dev Tasks → Code → Tests), but instead of building forward from a brief, you work backward from the codebase first.

The Retrofit Process at a Glance

Step	What you do
1. Audit	Scan the existing project. Which artifacts exist? Which are missing? Where is traceability broken?
2. Prioritize	Pick the highest-value gap to close first. Never retrofit everything at once.
3. Reverse-engineer	Use AI to generate the missing artifact from the codebase and existing docs.
4. Validate with the team	Code tells you what IS, not what SHOULD BE. The team corrects inaccuracies.
5. Enforce going forward	All new work follows the full framework. Existing code converges as it gets touched.

Monday morning

When you sit down at your real project, the first question is not “how do I use AI on the next feature.” The first question is “where is the artifact chain broken, and what do I retrofit first?” Module 8 gives you the prompts and process to answer that.

What You Take With You

From the training	How it applies to real projects
The Evaluate → Plan → Apply → Validate cycle	Same cycle, every task, every project. When something goes wrong, ask: which step was skipped?
The artifact chain (BRD → PRD → Architecture → Dev Tasks → Code → Tests)	Retrofit it backward from existing code, then enforce it forward on new work.
AGENTS.md and coding standards	Carry them to every project. Extend per project. They compound.
Your built agents, skills, and prompts	They live in knowledge/. Bring them. Refine them on real tasks. Contribute improvements back.
The knowledge directory structure	Set it up on Day 1 of every new project. It’s where the team’s AI effectiveness lives.