Claude
Skills
Sign in
Back

teamcraft:check-project-context

Included with Lifetime
$97 forever

Diagnostic tool — tests whether Claude has absorbed this project's conventions, decisions, and constraints from .claude/rules/ and CLAUDE.md, and reports the certification status of the captured-knowledge docs. Use when the user says 'quiz yourself on the project rules', 'check project context', 'verify the project setup', 'did you absorb the rules', or 'pop quiz'. This is specifically for testing rule absorption, not for general questions about the codebase.

General

What this skill does


## 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.

## Where to Go Next

Close by pointing the developer to the right next step based on what the diagnostic found:

- **Gaps or `Unverified`/`Absent` docs** → the matching capture skill to fill or certify them: `/capture-team-conventions`, `/capture-technical-design`, `/capture-requirements`. If the always-loaded rules looked stale, `/refresh-project-rules`.
- **Context is solid** → on to the work: `/plan-iteration` to scope an iteration, or `/pick-next-issue` to grab the next item.

Related in General