pie-framework

Answer questions about QTI 2.x/3.0 specification semantics, compliance requirements, and correct implementation patterns in this codebase. Use when the user asks how a QTI feature should work, whether an implementation matches the spec, what a QTI term means, or how to handle a spec-defined edge case (adaptive items, response processing rules, cardinality, navigation modes, etc.).

Reviews educational assessment interfaces for WCAG 2.2 Level AA compliance and assessment-specific accessibility needs. Use when implementing new interactions, reviewing UI changes, or conducting accessibility audits of test-taking interfaces.

Reviews public APIs in framework code for consistency, usability, type safety, breaking changes, and maintainability. Use when designing new APIs, reviewing API changes, or conducting framework code reviews.

Reviews and validates assessment items for both technical correctness (QTI/PIE compliance, functionality) and pedagogical quality (appropriate difficulty, clear instructions, realistic scenarios, K-12 appropriateness). Use when creating example items, reviewing test fixtures, debugging broken assessments, or ensuring items are usable and make sense from an educational perspective.

This skill should be used when the user asks to "check certification compliance for X", "verify feature X against the conformance criteria", "run a certification check on Q6", "are we ready to certify T9", "what do we need for Q2 certification", "check if we pass the conformance criteria for A-8", or any similar request to evaluate a specific QTI feature ID against the 1EdTech certification acceptance criteria.

Use when the user asks to "grill me", "stress-test this plan", harden a design, resolve terminology, or decide whether CONTEXT.md or a PRD should capture durable QTI/PIE domain knowledge.

Use only when the user explicitly asks to run loop-review-agents, invokes /loop-review-agents, or requests repeated independent review rounds over changes, a commit, a plan, a PRD, or another review target.

Answer questions about PIE (Portable Interactions & Elements) framework semantics: how Elements, Controllers, Sessions, Models, and Environments work; how PIE concepts map to QTI; how the pie-elements-ng and pie-players ecosystems are structured. Use when the user asks how a PIE concept works, how to implement a Controller, what goes in a Session vs a Model, how Mode/Role affect rendering, how to bridge PIE and QTI, or how the SectionPlayer/AssessmentPlayer orchestration works.

Reviews educational assessment interfaces for WCAG 2.2 Level AA compliance and assessment-specific accessibility needs. Use when implementing new interactions, reviewing UI changes, or conducting accessibility audits of test-taking interfaces.

Use when the user asks to turn a conversation, feature discussion, or implementation plan into a draft PIE Elements NG PRD under docs/prds/.

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

Reviews a PIE controller implementation for correctness, scoring accuracy, and contract compliance. Use when implementing or reviewing controller.ts files — especially outcome(), model(), and createCorrectResponseSession().

Implements a new PIE element (or non-trivial extension) end-to-end: PRD review → Model/Session/Controller → Svelte delivery component → authoring surface → tests. Use when adding a new @pie-element/* package or extending an existing element with a new mode or config surface.

Drafts or updates a PIE element PRD following the project conventions in docs/prds/README.md. Use when starting a new element that meets the PRD bar, or when a substantial change requires updating an existing PRD.

Interview the user relentlessly about a plan or design until shared understanding is reached.

Guides an upstream sync operation — pulling updated elements or lib packages from ../pie-elements or ../pie-lib into this repo. Use when running or debugging upstream:update, upstream:sync, or upstream:check CLI commands.

Use when reviewing public APIs, package exports, custom-element properties/events/slots, or cross-package contracts in PIE Players.

Workflow for adding or modifying a custom-element package — registration entrypoints, package `exports`, build artifacts, and pre-flight checks. Use when creating a new `@pie-players/*` CE package, adding a new `*-element.ts` registration entry, modifying the `exports` map of a publishable package, or validating CE consumer wiring. Trigger on cues like "register custom element", "add CE entry", "package exports", "components/*-element", "publishable package", "CE registration".

Reviews educational assessment interfaces for WCAG 2.2 Level AA compliance and assessment-specific accessibility needs. Use when implementing new interactions, reviewing UI changes, or conducting accessibility audits of test-taking interfaces.

Use when the user asks to grill or stress-test a plan/design, especially when terminology, domain language, CONTEXT.md, or ADR updates may matter.

Use when the user asks to draft, update, or turn a conversation/plan into a PIE Players PRD under docs/prds/ for a public contract, cross-package feature, architecture decision, or implementation-ready contract.

Author changesets and prepare releases under the fixed (lockstep) versioning policy. Use whenever creating a `.changeset/*.md`, scoping a release, choosing a bump level, running `bun run version` / `bun run release` / `bun run release:with-version`, or adding a new publishable package. Trigger on cues like "changeset", "release", "publish", "version bump", "patch", "minor", "major", "fixed versioning", "lockstep".

Runs Jest in this repository using Node v22 via nvm, then npx jest for specific test files or folders. Use when running tests in pie-lib, when Jest fails with a Node syntax error (e.g. optional chaining in jest-cli), or when the user asks to test specific files or packages with the correct Node version.