DeliPLRequest access

How does it work?

From a Jira task to merge — a repeatable, multi-stage process. Deli does the work; you make the decisions at the marked points.

  1. 1

    Picking up the task

    Deli fetches the project’s open issues from Jira — manually or every few minutes via the scheduler. A story with sub-tasks becomes one unit of work (WorkUnit).

    • issue content, comments and labels
    • related issues: parent, links, siblings
    Jira integration
  2. 2

    Analysis

    The model summarises the task, identifies the business goal and dependencies, picks the code repositories to change (possibly several), searches the documentation and lists the applicable guidelines.

    • overlap with other work in Deli (duplicate mechanism, same rule, same code area)
    • contradictions between Jira and the documentation
    • rules from guideline repositories and Definition of Done criteria
    Conflict detection
  3. 3

    Proposed solutionYour decision

    Claude reads the code and prepares a complete solution: goal, steps, flow diagram, existing mechanisms to reuse, file changes, requirements with sources, tests and a risk assessment.

    • by default waits for “Approve solution”
    • instead of approving you can describe what to change — the step runs again
  4. 4

    DecisionsYour decision

    When something is unclear or sources conflict, Deli asks a question with 2–4 options, a recommendation and evidence: what Jira says, what the docs say, what the code says.

    • blocking questions pause work until answered
    • non-blocking ones wait up to 24 h, then Deli adopts the recommendation and logs it
  5. 5

    Implementation

    Claude works in a separate git worktree of each repository being changed, on a shared feature/<KEY>-<description> branch: writes code and tests following the solution, decisions and guidelines, and commits.

    • limit of 60 turns and 45 minutes, no network access and no push
    • Deli runs the build; on failure Claude gets the log and has 2 fix attempts, without disabling tests
  6. 6

    Merge request and AI review

    In each changed repository Deli pushes the branch and opens a draft merge request on GitLab or pull request on GitHub, describing the goal, solution, changes and decisions. A separate model call reviews the whole change.

    • review: correctness, requirements coverage, edge cases, transactions, concurrency, error handling
    • the verdict is also posted as an MR/PR comment
  7. 7

    Knowledge transferYour decision

    You discuss the change with the AI — the model knows the solution, review and diff, and corrects misunderstandings. It ends with a 5-question quiz; a score of at least 80% passes.

  8. 8

    MergeYour decision

    The “Merge” button unlocks only after the quiz is passed. Deli removes the draft status, merges the MR/PR and cleans up the task’s working directory.

You control the flow

Every stage can be stopped, retried or skipped. You choose the working mode in settings.

Test mode

The default, recommended to start with. After each step the flow stops and waits for “Next”. Only draft MRs/PRs are opened — nothing is merged without you.

Auto mode

The solution goes to implementation without approval. Blocking questions and the knowledge-transfer quiz still wait for you.

Queue and kill switch

Tasks wait in a queue; auto mode can run several in parallel up to the project limit. The kill switch pauses every step that calls the model.

See what Deli does at every stage

Feature and integration details.

FeaturesRequest access