AI Rookie: Flow of skills & features?

[zyxep]

Hi everyone :)

I am not sure if my title is understanding.
But I'm trying to work on a private project with the mindset of being a team and so on.
I have read the stuff on the docs site regarding Getting Started, The Main Flow

I am confused about git workflow within the skills.
There are the issues created, based on /to-tickets coming from /to-spec etc, that i get.
I also somewhat understand /implement <issue>.

So I did /implement 2 it created a new branch, named feat/2-<title> then i also worked on /implement 3 it continued to use feat/2-<title> as working branch.
which is fine for now, those issues were connected together.

When do I push the branch and create a PR for ready to merge.
And when does it create a new branch to work on a feature?
I can understand by searching a little that there are no straight up /to-pr and so on i also did /ask-matt and it told me to just run git push etc by hand.

and there are no definition of these in any of the md files for the agent.

[AlexLimaTKZ]

I think your confusion is valid the current /implement skill does not actually define the full Git delivery workflow.
Looking at the current implement/SKILL.md, its responsibility ends roughly at:

implement the ticket/spec
run tests/typechecking
run /code-review
commit the work to the current branch

It does not currently define when to push, when to open a PR, or when a new branch should be created.

So the way I would treat it today is:

One branch = one logical PR, not necessarily one ticket.
If ticket #3 is tightly related to #2 and both should be reviewed/merged together, continuing on feat/2-... is reasonable.
If the next ticket is an independent feature/slice, finish the current branch first, push it, open the PR, then start a fresh branch from the updated default branch.

For example:

after the related tickets are implemented/reviewed/committed

git push -u origin feat/2-something

open PR manually

for the next independent piece of work

git switch main
git pull
git switch -c feat/4-next-feature

So I would not expect /implement itself to decide the PR boundary for you at the moment. That boundary is still a human/project decision.

Interestingly, there is already an open proposal for /to-commit and /to-pr, which seems aimed exactly at filling this gap.

In short:

tickets → /implement → review → commit → [human decides branch/PR boundary] → push → PR

So what you observed with /ask-matt telling you to use normal Git commands manually seems consistent with the current implementation.

[sylvesterkaczmarek]

/implement works on the branch you're already on and commits there; it doesn't create branches or PRs itself. So use one ticket per session, switch/create the branch yourself when needed, then push and open the PR manually when that branch is ready.

[Bibek200619]

I think the key detail is that the current workflow deliberately does not own the Git branch/PR lifecycle.

According to the implement docs, /implement commits to the branch you're already on. It does not create a branch or decide which branch the ticket belongs to.

So I would treat the workflow as:

git switch main
git pull
git switch -c feat/2-some-feature

[AlakhiarovSalekh]

You're not missing a hidden /to-pr step.

The current workflow separates these concerns:

• /implement is for implementing one ticket/work item. It works on the current branch and finishes by committing the implementation after review.
• /pr only defines/formats the pull-request body. It does not push the branch or open the PR.
• /implement-spec is the workflow for an entire spec with multiple tickets. It uses an integration branch, lets individual tickets run on their own branches/worktrees, merges them back, runs the final review, and can open/use a draft PR for the whole spec.

So if /implement 2 and /implement 3 stayed on the same branch, that is not necessarily a bug: /implement does not guarantee one new branch per issue.

For independent tickets, I would start each fresh implementation session on its own branch. For tightly connected tickets, keeping them on one feature/integration branch is reasonable.

Once a logical unit is reviewed and committed, push the branch and open the PR manually (or ask the agent to do it). If you want the whole spec landed through one PR, /implement-spec is the better fit.