Free SKILL.md scraped from GitHub. Clone the repo or copy the file directly into your Claude Code skills directory.
npx versuz@latest install codingthefuturewithai-claude-code-primitives-plugins-teamcraft-skills-check-project-contextgit clone https://github.com/codingthefuturewithai/claude-code-primitives.gitcp claude-code-primitives/SKILL.MD ~/.claude/skills/codingthefuturewithai-claude-code-primitives-plugins-teamcraft-skills-check-project-context/SKILL.md--- name: teamcraft:check-project-context description: Diagnostic tool — tests whether Claude has absorbed this project's conventions, decisions, and constraints from .claude/rules/ and CLAUDE.md. 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. argument-hint: "(no arguments)" disable-model-invocation: false user-invocable: true --- ## 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. ## What This Tells the Developer If your answers are accurate and specific, the project 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.