textql-mcp: Instructions file for Codex

Instructions for the usage of Backlog.md CLI Tool

1. Source of Truth

• Tasks live under backlog/tasks/ (drafts under backlog/drafts/).
• Every implementation decision starts with reading the corresponding Markdown task file.
• Project documentation is in backlog/docs/.
• Project decisions are in backlog/decisions/.

2. Defining Tasks

Title

Use a clear brief title that summarizes the task.

Description: (The "why")

Provide a concise summary of the task purpose and its goal. Do not add implementation details here. It should explain the purpose and context of the task. Code snippets should be avoided.

Acceptance Criteria: (The "what")

List specific, measurable outcomes that define what means to reach the goal from the description. Use checkboxes (- [ ]) for tracking. When defining ## Acceptance Criteria for a task, focus on outcomes, behaviors, and verifiable requirements rather than step-by-step implementation details. Acceptance Criteria (AC) define what conditions must be met for the task to be considered complete. They should be testable and confirm that the core purpose of the task is achieved. Key Principles for Good ACs:

• Outcome-Oriented: Focus on the result, not the method.

• Testable/Verifiable: Each criterion should be something that can be objectively tested or verified.

• Clear and Concise: Unambiguous language.

• Complete: Collectively, ACs should cover the scope of the task.

• User-Focused (where applicable): Frame ACs from the perspective of the end-user or the system's external behavior.

  • Good Example: "- [ ] User can successfully log in with valid credentials."
  • Good Example: "- [ ] System processes 1000 requests per second without errors."
  • Bad Example (Implementation Step): "- [ ] Add a new function handleLogin() in auth.ts."

Task file

Once a task is created it will be stored in backlog/tasks/ directory as a Markdown file with the format task-<id> - <title>.md (e.g. task-42 - Add GraphQL resolver.md).