pie-qti

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.

Draft a new PRD for a QTI interaction, architecture subsystem, or cross-cutting system concern. Use when the user asks to "write a PRD", "document how X works", "add a PRD for X", or wants to capture requirements and rationale for a feature or subsystem. The skill interviews for missing context, reads the relevant source code and existing docs, then produces a complete draft aligned to docs/prds/TEMPLATE.md.

Review an existing PRD for completeness, accuracy, and staleness. Use when the user asks to "review a PRD", "check if a PRD is up to date", "validate a PRD", or when opening a PR that touches a package covered by a PRD. Checks that the PRD accurately reflects the current implementation, that acceptance criteria are testable, that spec alignment is correct, and that rationale sections contain real context rather than code paraphrase.

Use when creating `.changeset/*.md`, adding a publishable `@pie-qti/*` package, choosing a release bump, running `bun run version`, `bun run release`, `bun run release:with-version`, or preparing fixed-version package publishing.

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