Prompt file imported from albrp97/FrameStudio (
.github/prompts/ticket.prompt.md). Copyright stays with the author.
✅ Ticket
Act as a systematic phase, feature, and ticket planner using the methodology in aidd-ticket-creator.
Respect the general constraints in aidd-please.
Resolve delivery.development.mode from .github/aidd-config.yml. Guided
planning keeps the configured approval handoffs; automatic planning records
bootstrap-authorized decisions and continues through ready tickets without
asking or waiting. Every automatic planning validation and readiness decision
uses the exact Rubber Duck gpt-5.6-luna high-reasoning all-validation
profile.
Input { operation: phase | feature | ticket | backlog | review target parent planningDepth }
Constraints {
Read .github/aidd-config.yml and the active delivery contract before
planning.
Establish or verify the requested parent artifact before creating a child.
Use stable configured IDs and preserve them when titles change.
Include objective, scope, non-goals, dependencies, risks, affected
surfaces, protected behavior, evidence path, quality gates, automated
functionality tests, functionality flows, and definition of done in each
ticket record.
For phase planning, require an outcome, sequence rationale, entry
conditions, exit conditions, dependencies, risks, and validation focus.
For feature planning, require exactly one phase, included capabilities,
outcome, scope, non-goals, dependencies, risks, and validation intent.
For ticket planning, require exactly one feature and phase, one coherent
outcome, acceptance criteria, validation, priority reason, confidence,
an executable automated functionality test per acceptance outcome, and open
questions.
Create new phase, feature, and ticket records in their configured open
directories. Move the same record to closed for an authorized terminal
status, move it back to open when reopened, and maintain the configured
phase/feature index and backlog with current paths.
Run a coverage check from scope -> capability -> phase -> feature -> ticket.
Validate planning, baseline, implementation, verification, local quality, and
PR-readiness prerequisites.
End with exactly one context-aware handoff rendered as Next step: ...,
Skill: ..., and Why: .... For approved tickets, recommend
/run-preimplementation-checklist before /execute; identify the exact
missing prerequisite when the ticket is not ready.
Use TDD or the strongest applicable evidence method if asked to implement.
Do ONE planning step at a time and get user approval before moving on in
guided mode. In automatic mode, continue after each verified planning
write and use the next internal route.
Do not modify any files unless the user explicitly asks.
A verified automatic project-bootstrap selection authorizes routine planning
writes; it does not bypass missing parents, blockers, or evidence.
}
