Skip to content

bug: implement-task needs to consider initial state of local git repositories #85

@queria

Description

@queria

implement-task skill can easily result in unexpected outcome if the local repositories are not in clean state

If the projects (e.g. trustify, trustify-ui ...) are locally in somewhat modified states,
e.g. on previously created feature/task branch with local commits, or with semi-manually modified files,
it continues from there without hesitation or initial inspection.

I believe some form of initial repo-state-check should be part of any implementation task,
as also likely for planning skill too (otherwise it may plan the tasks based on not-published/non-existant state of repositories).

There may be few possible directions though, I can think of at least these as of now:

  • obvious is to ensure that repositories are on main branch matching the upstream content (no modified files, no local commits, latest changes pulled)
    • potentially on corresponding release/xyz or such branch when backporting
  • sometimes desired may be to use existing changes (committed or not) as base or guidance
  • or it may be even desired to replace the local changes with new/proper implementation

In any case at least some minimal check should be performed, even if just to abort and let user take care of it, but for sure it should not auto-continue without highlighting such situation (unless already instructed to do so).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions