write-bug
Write Bug (FOLIO)
A FOLIO bug report must be reproducible, specific, and evidence-backed. The reader should be able to recreate the defect without guessing.
Bug Structure
Every FOLIO bug must have these sections (in order). Sections marked (optional) are omitted when they add no value.
More from folio-org/folio-eureka-ai-dev
write-user-story
Use when creating, writing, or refining a user story or ticket. Produces structured stories with purpose/overview, functional requirements, Given-When-Then acceptance criteria, and manual testing guidance. Also use when asked to define acceptance criteria, scope a feature, or prepare a story for development.
24document-feature
Use when the user asks to document an implemented feature. Analyze the diff from the base branch, infer the feature boundary and name, and generate behavioral feature documentation under docs/features/.
20unit-testing
Use when writing or reviewing Java unit tests. Enforces Mockito/JUnit 5 best practices - strict stubbing, no lenient mode, specific matchers, complete flow stubbing, Arrange-Act-Assert structure, and clear test naming.
17code-review
Use when the user asks to perform a code review, review code changes, analyze a diff, or audit code quality. Runs a structured review of git diff output covering security, correctness, performance, maintainability, and style. Produces a markdown report saved as a .md file named after the current branch.
13skill-feedback
Use when a user has finished using one installed skill and wants to preserve actionable feedback about that skill while the session context is still fresh
5liquibase-migration
>-
5