codingthefuturewithai/teamcraft:check-project-context

Goal

Prove that you understand how this project works — not by reading files on the spot, but from what's already in your context right now. The developer will verify whether you're right.

Part 1 — Report What You Know

Without using any tools, report everything you understand about this project:

1. How does this team test? What frameworks, what tiers, what approach?
2. How does this team branch and merge?
3. What's the tech stack and key libraries? Why were they chosen?
4. What are the non-obvious constraints — things that look wrong but are intentional?
5. Where do work items and documentation live? (Hint: Teamcraft uses .teamcraft/work/ for work items and /docs/ for project documentation.)
6. What decisions has the team already made around conventions or special ways of doing things?

Be specific. "The team uses Vitest" isn't enough. The developer needs to verify you actually absorbed the detail, not just the headlines.

Part 2 — Captured-doc certification status

Part 1 is a no-tools memory test. This part is different — here you DO read, but only the certification stamps, not the whole docs. Scan the captured-knowledge docs (team conventions, system architecture, technology decisions and each per-area file, product requirements — wherever they live) and report each one's Teamcraft certification per ../references/doc-provenance.md:

• Certified — has a valid teamcraft stamp. Report its kind (created/reviewed) and date. You don't have git here, so don't attempt a history comparison — just report the date, and flag staleness only if something you've already read makes a doc obviously outdated.
• Unverified — present but missing or malformed stamp. These may be inherited or stale; the developer should run the matching capture skill to review and certify them.
• Absent — the category isn't documented yet.

This is read-only diagnostics. Don't modify or certify anything here — just report. Certifying is the capture skills' job.

What This Tells the Developer

If your Part 1 answers are accurate and specific, the always-loaded context is working. If you're vague, wrong, or missing things the team carefully documented, something is broken and the developer knows to investigate before trusting you with real work. Part 2 tells them whether the captured docs the build loop will rely on are actually certified — or whether Claude has been quietly trusting inherited content.