AI Project Showcase Skill

Purpose

Take an AI-assisted product (WordPress plugin, web app, chatbot, desktop app, API, etc.) and produce a credible, evidence-grounded showcase document that explains *what it is, why it exists, how it was built, and how it has evolved.* The output is suitable for portfolio publication, client briefings, internal capability inventory, or pre-sale collateral.

The cardinal rule: never invent. Every claim in the populated showcase must trace to a file, commit, config value, or explicit inference marker. Ungrounded prose destroys the document’s credibility — and credibility is the entire point.

Source Template

The canonical template lives at: ITI/operations/documentation/AI Project Showcase.md

Always start by reading the current template — it is the source of truth for section structure, placeholders, and validation rules. This skill codifies the methodology for populating it; the template defines the shape.

When to Use This Skill

• Adding a project to the ITI portfolio or capabilities catalog
• Producing a pre-sale case study or client showcase
• Writing an internal “how this was built” retrospective
• Onboarding a new collaborator to an existing project
• Auditing a project’s documentation completeness
• Generating marketing collateral grounded in real engineering work

Do not use this skill when:

• The user wants forward-looking strategy (use proposal-evaluation or planning skills)
• The user needs a code review (use code-review)
• The user is asking for marketing copy unmoored from a real codebase (use copywriting)

Inputs

• Required: absolute path to the project’s working directory
• Optional: target audience (internal / portfolio / client / pitch)
• Optional: focus emphasis (technical depth vs. product narrative vs. ideation arc)
• Optional: desired output path (defaults to /SHOWCASE.md)

Methodology

Phase 1 — Pre-population audit (Section 0 of template)

Do not write a single word of showcase content until this phase is complete. Run all seven examinations in order. Record what was found and what was not.

Step	Goal	Commands / actions
0.1 Project root recon	Map structure, locate context docs	ls -la; find CLAUDE.md, README, .md (depth ≤3), PRD, SPEC, SRS, REQUIREMENTS, CHANGELOG, HISTORY
0.2 Knowledge system discovery	Locate KB, prompt, vector store, workflow files	find dirs kb, knowledge, context, prompts; find .kb, .context, system_prompt, agent_prompt, .jsonl, .faiss, .pkl; check workflows/.json, flowise.json
0.3 Version & evolution history	Build chronology	git log --oneline --no-merges; git log --diff-filter=A -- "*.md" (when docs added); git log --format="%ad %s" --date=short; git tag -l --sort=-version:refname; if no git, find versioned files
0.4 Tech & dependency stack	Identify frameworks, AI providers, infra	Read package.json, requirements.txt, composer.json; locate docker-compose, Dockerfile; grep .env* for OPENAI, ANTHROPIC, CLAUDE, GPT, GEMINI, PLANTNET, PLANT_ID, etc.; grep dep manifests for flowise, n8n, langchain, llamaindex
0.5 Product artifacts	Locate screenshots, exports, decks	Find *.png/jpg/webp/gif matching `screen	mock	design	wireframe	demo	preview`; sample CSV/JSON outputs; PDF/PPTX decks
0.6 Read core context	Absorb CLAUDE.md, READMEs, PRDs	Read each file fully — these anchor every later section
0.7 Market & competitive research	Locate any external research already in repo	Find competi, market, research, analysis files; research/, market/ directories

Output of Phase 1: a Sources Examined table (which becomes the audit trail at the end of the showcase document) plus a working evidence inventory the assistant uses to populate every later section.

Phase 2 — Section-by-section population

Populate the 12 sections of the template in order. For each section, follow the inline comments — they are operative instructions, not commentary.

Section	What to write	Primary evidence sources
1. Product Overview	Name, tagline, status, third-person product description, differentiation, platform/deployment	CLAUDE.md, README, package.json, top-level PRD
2. User Needs & Problem Statement	Target user, JTBD problem statement, unmet needs table, incumbent behaviour	Persona docs, user-story files, README rationale
3. Market Context & Competitive Landscape	Category, maturity, competitor table, positioning, defensibility	Research files (0.7); fall back to Claude knowledge only when marked ⚡
4. Requirements Framing	Method used, core functional requirements, constraints, non-goals, key decisions	PRD/SRS/SPEC docs, CLAUDE.md constraints, ADRs
5. Knowledge System Architecture	KB type, structure tree, categories, build pipeline (6 steps), system prompt approach	Section 0.2 findings, build/ingestion scripts, prompt files
6. Build Methodology	Approach, build phases table, AI-assisted patterns, technical challenges	Git log, CLAUDE.md, TODO/FIXME comments
7. AI Tools & Techniques	Models/APIs table, orchestration tools, prompting techniques checklist, dev tools	.env*, dep manifests, source imports, prompt files
8. Version History & Evolution	Version timeline grouped from git, pivots, deferred scope	Git log/tags, ROADMAP files, deletion clusters
9. Product Artifacts	Design/UX, doc, and data artifact tables (paths only, never embed binaries)	Section 0.5 findings
10. Product Ideation Story	Origin, market assessment, core bet, evolution narrative	Earliest commits, CLAUDE.md framing, ideation files
11. Lessons & Next Steps	Current state, visible next steps; leave 11.3 blank for manual input	TODO/FIXME, ROADMAP, deferred scope
12. Validation Checklist	Run after population; report any failures at top	All prior sections

Phase 3 — Evidence-grounding rules

These rules are non-negotiable:

1. Replace every [PLACEHOLDER] with discovered content. Never leave a raw placeholder.
2. Mark genuinely missing info as ⚠️ [NOT FOUND — add manually]. Do not invent.
3. Mark inferences explicitly as 💡 [CLAUDE NOTE: inferred from ]. Inferences are allowed; unmarked inferences are not.
4. Mark training-derived competitive content with ⚡ and a 💡 [CLAUDE KNOWLEDGE — verify before publishing] annotation.
5. Preserve all section headers and comments in the output document. They serve as the next reviewer’s audit trail.
6. Section 11.3 (Lessons learned) must be left blank or flagged for manual input by the project owner. Claude cannot manufacture lived experience.
7. Sources Examined table at the bottom must list every file actually read.

Phase 4 — Validation

Before reporting the document complete, run the Section 12 checklist:

• [ ] Every [PLACEHOLDER] replaced or marked ⚠️ [NOT FOUND]
• [ ] All externally-sourced competitive data marked with ⚡
• [ ] All inferences marked with 💡 [CLAUDE NOTE]
• [ ] Section 0 audit trail lists every file examined
• [ ] Version history derived from actual git log, not assumed
• [ ] Knowledge system paths reflect real directory structure
• [ ] AI tools confirmed from code/config, not guessed
• [ ] Section 11.3 left blank or flagged for manual input
• [ ] Document header shows today’s date and files examined

If any item fails, surface it under a ⚠️ REVIEW NEEDED heading at the top of the output document. Do not silently ship a document that failed validation.

Output Format

A single populated Markdown file based on the template, written to:

• /SHOWCASE.md by default, or
• the path the user specified

Header fields the skill must always set:

**Document type:** AI Project Showcase
**Project:** <discovered name>
**Status:** Draft
**Last updated by Claude Code:** <today's date in YYYY-MM-DD>
**Populated from:** <comma-separated list of evidence files>

Quality Bar

A showcase document passes when an outsider reading it can answer:

1. What does this product do, and for whom?
2. Why does it exist (what gap was unfilled)?
3. How is the knowledge system organized and built?
4. What AI models, tools, and techniques power it?
5. How did it evolve from first commit to current state?
6. What artifacts exist to corroborate the story?
7. Where can I trace every claim back to evidence?

If any of those seven questions cannot be answered from the document alone, the showcase is incomplete — return to Phase 2 for the relevant sections.

Red Flags — Stop and Escalate

Pause and ask the user before continuing if you encounter:

• A project with no git history and no CLAUDE.md/README — the evidence base is too thin
• A client project marked HIPAA, attorney-client privileged, or CONFIDENTIAL — confirm publication rights before producing a showcase
• Significant disagreement between README claims and code reality — surface the discrepancy rather than papering over it
• An empty Sources Examined table after Phase 1 — the audit found nothing; do not proceed to Phase 2

Combining With Other Skills

• Pair with claims-integrity-audit before publishing externally — catches unverifiable claims the showcase may have absorbed from upstream docs
• Pair with market-research when Section 3 (competitive landscape) needs to be expanded beyond what is in the repo
• Pair with technical-writing for tone/clarity polish on the populated draft
• Pair with fact-checking when the showcase will be quoted in marketing collateral

Source Template Reference

ITI/operations/documentation/AI Project Showcase.md — Template version 1.0