Merge remote-tracking branch 'origin/staging' into develop

This commit is contained in:
Andrey Antukh 2026-09-08 23:01:03 +02:00
commit 8fac9cf178
3 changed files with 84 additions and 46 deletions

View File

@ -34,7 +34,7 @@ JSON, REPL access, and so on.
|---|---|---| |---|---|---|
| [`make-a-plan`](skills/make-a-plan/SKILL.md) | Researches the task, writes an implementation plan, asks you the open questions in plain language, and saves the plan to `.agents/plans/`. | "make a plan for the token refresh bug" | | [`make-a-plan`](skills/make-a-plan/SKILL.md) | Researches the task, writes an implementation plan, asks you the open questions in plain language, and saves the plan to `.agents/plans/`. | "make a plan for the token refresh bug" |
| [`review-plan`](skills/review-plan/SKILL.md) | Evaluates a plan before anyone writes code: completeness, ordering, risks. Approves it or asks for changes. | "review this plan before we start" | | [`review-plan`](skills/review-plan/SKILL.md) | Evaluates a plan before anyone writes code: completeness, ordering, risks. Approves it or asks for changes. | "review this plan before we start" |
| [`implement-plan`](skills/implement-plan/SKILL.md) | Executes a ready plan and ends with one commit. Starting from a base branch (`main`, `develop`, `staging`), it first creates a GitHub issue and a matching `issue-NNNN` branch; already on a feature branch, it continues there without creating anything. | "implement the plan" | | [`implement-plan`](skills/implement-plan/SKILL.md) | Shows you the full flow first — the issue and branch it will create (or the branch it continues on), the execution style, and the task checklist — and, after your go-ahead, executes a ready plan. Default: every task, one commit. On request ("step by step"): one task, one commit, your confirmation between tasks. | "implement the plan" · "step by step, one commit per task" |
| [`review-code`](skills/review-code/SKILL.md) | Reviews a diff, branch, or PR and returns findings ranked by impact. | "review my changes before I push" | | [`review-code`](skills/review-code/SKILL.md) | Reviews a diff, branch, or PR and returns findings ranked by impact. | "review my changes before I push" |
| [`create-pr`](skills/create-pr/SKILL.md) | Opens a pull request for the current branch — with checks on base branch, commits, issue, and push state — or updates an existing PR's title and description. | "open a PR for this branch" | | [`create-pr`](skills/create-pr/SKILL.md) | Opens a pull request for the current branch — with checks on base branch, commits, issue, and push state — or updates an existing PR's title and description. | "open a PR for this branch" |
| [`resolve-git-conflicts`](skills/resolve-git-conflicts/SKILL.md) | Untangles merge or rebase conflicts: explains both sides, proposes a resolution, applies it after you approve. Never runs `git rebase --continue`. | "resolve these conflicts" | | [`resolve-git-conflicts`](skills/resolve-git-conflicts/SKILL.md) | Untangles merge or rebase conflicts: explains both sides, proposes a resolution, applies it after you approve. Never runs `git rebase --continue`. | "resolve these conflicts" |

View File

@ -1,13 +1,17 @@
--- ---
name: implement-plan name: implement-plan
description: Implementation flow — execute a ready plan from the session context: detect the flow (new issue + branch when on a base branch, or continue on the current branch), implement, and commit. Use it when the user asks to implement or execute a plan, in any phrasing. description: Implementation flow — execute a ready plan from the session context: read the plan, detect the flow, then present the full picture (issue and branch to create or the branch to continue on, execution style, task checklist) and wait for confirmation. Default is every task with one final commit; on request ("step by step"), one task and one commit at a time with a pause after each. Use it when the user asks to implement or execute a plan, in any phrasing.
--- ---
# Implement Plan # Implement Plan
This flow is run once a plan is ready (for example, from plan mode). Execute This flow is run once a plan is ready (for example, from plan mode). Execute
the plan already prepared in the current session context. This flow ends the plan already prepared in the current session context. It never pushes —
with exactly one commit. It never pushes — the user pushes. the user pushes.
By default it ends with exactly one commit. When the user asks for it
("step by step"), it commits once per task instead and waits for the
user's confirmation after each one (see *Execution modes*).
## When to use ## When to use
@ -19,63 +23,95 @@ with exactly one commit. It never pushes — the user pushes.
Do not use it to produce plans — that is the `make-a-plan` flow. Do not use it to produce plans — that is the `make-a-plan` flow.
## 1. Detect the flow (no questions) ## 1. Read the plan first
Identify the plan to execute — from the file path the user gave, the
arguments, or the session context. Read it completely. Read the required
memories before writing any code: `mem:critical-info` and the core memory
of every module the plan touches, plus the deeper memories they reference
(AGENTS.md governs this).
## 2. Detect the flow (no questions)
Inspect the current branch with `git rev-parse --abbrev-ref HEAD`, pick the Inspect the current branch with `git rev-parse --abbrev-ref HEAD`, pick the
mode, and announce it in one line before acting. mode, and announce it in one line before presenting anything. Detection is
read-only: nothing is created until the user confirms (step 3).
- **On a base branch** (`main`, `develop`, `staging`) → **standalone mode**: - **On a base branch** (`main`, `develop`, `staging`) → **standalone mode**:
create the issue and the branch, then implement and commit. a new GitHub issue and a branch `issue-NNNN` will be created after the
user's confirmation.
- **On any other branch** (a feature branch, typically `issue-NNNN`) → - **On any other branch** (a feature branch, typically `issue-NNNN`) →
**continue mode**: implement on the current branch and commit. No issue or **continue mode**: the implementation continues on the current branch.
branch is created. No issue or branch is created. The branch name provides the issue
reference when it follows the `issue-NNNN` pattern.
Arguments override detection: `standalone`, `continue`, Arguments override detection: `standalone`, `continue`,
`no issue` / `without issue`, or an explicit base such as `no issue` / `without issue`, or an explicit base such as
`from origin/develop`. `from origin/develop`.
### Standalone mode
1. Create the issue with the **`create-issue`** skill, following the
*Creating Issues from Draft Body* flow in `mem:workflow/creating-issues`.
Derive the issue title and body from the plan. Capture the new issue's
number — call it **NNNN** (needed for the branch name and the commit
reference).
2. Create the branch from the current HEAD:
```
git checkout -b issue-NNNN
```
3. If the arguments say `no issue` / `without issue`, skip the issue and
create a branch named `plan-<slug>` instead, where `<slug>` is the plan
title, lowercase and hyphen-separated.
**Standalone while already on a feature branch:** stop and explain that this **Standalone while already on a feature branch:** stop and explain that this
would stack branches. Ask the user to re-run with an explicit base, for would stack branches. Ask the user to re-run with an explicit base, for
example `from origin/develop` — then branch from that base instead of HEAD. example `from origin/develop` — then branch from that base instead of HEAD.
### Continue mode ## 3. Present the checklist and wait
No issue and no branch. Implement on the current branch. The branch name Before touching the repository, show the user the full picture:
provides the issue reference when it follows the `issue-NNNN` pattern.
## 2. Execute the plan - **The flow**: whether the GitHub issue and the branch will be created
(standalone mode — give the planned branch name, `issue-NNNN` or
`plan-<slug>`), or whether you continue on the current branch
(continue mode — name it).
- **The execution style**: batch or step-by-step (see *Execution modes*).
- A checklist (todolist) of the plan's tasks, in order.
Implement the prepared plan from the session context. Work methodically, Then WAIT for the user's explicit confirmation. Do not start until you
keeping changes focused on what the issue requires. Respect the plan's have it. If the plan has no discrete tasks, ask the user how to split
proposed parallelization when it applies. Do not commit — the commit happens it, or propose running it as a single change.
in the next step.
## 3. Commit with the create-commit skill ## 4. Execute the plan
After the implementation is complete, load the **`create-commit`** skill and **Standalone setup, after the confirmation:** create the issue with the
follow its workflow to commit the changes. Provide a brief summary of what was **`create-issue`** skill, following the *Creating Issues from Draft Body*
implemented and why, the issue reference (`issue-NNNN`) when there is one, and flow in `mem:workflow/creating-issues`. Derive the issue title and body
the model name you are running as so the `AI-assisted-by` trailer is set from the plan, capture the new issue's number — call it **NNNN** — and
correctly. create the branch from the current HEAD:
Do not push. Pushing is handled separately by the user. ```
git checkout -b issue-NNNN
```
If the arguments say `no issue` / `without issue`, skip the issue and
create a branch named `plan-<slug>` instead, where `<slug>` is the plan
title, lowercase and hyphen-separated.
### Batch mode (default)
Implement every task in one go. Work methodically, keeping changes
focused on what the issue requires. Respect the plan's proposed
parallelization when it applies.
When the implementation is complete, load the **`create-commit`** skill
and follow its workflow to commit the changes. Provide a brief summary
of what was implemented and why, the issue reference (`issue-NNNN`) when
there is one, and the model name you are running as so the
`AI-assisted-by` trailer is set correctly.
### Step-by-step mode (on request)
When the user asks for it — "step by step", "task by task", "one commit
per task" — loop one task at a time:
- Execute exactly ONE task.
- Commit it now: load the **`create-commit`** skill and follow it —
one commit per task, never two tasks in one commit. Same inputs as
always: what and why, the issue reference, your model name.
- Show the user the result (what changed, files touched, how it was
verified).
- WAIT for the user's confirmation before starting the next task.
Never batch in this mode: no two tasks in one commit, and no new task
before the user confirms. If a task turns out much bigger than planned,
stop and ask the user before splitting it.
## When you are done ## When you are done
@ -88,7 +124,9 @@ instruction from me overrides them):
## User context ## User context
Extra context in the user's invocation (the message that triggered this skill) Extra context in the user's invocation (the message that triggered this
plays the role command arguments play elsewhere: `standalone`, `continue`, skill) plays the role command arguments play elsewhere: `standalone`,
`no issue` / `without issue`, or an explicit base such as `continue`, `no issue` / `without issue`, an explicit base such as
`from origin/develop`. `from origin/develop`, or `step by step` / `one commit per task` for the
step-by-step execution mode. Modes combine freely, for example
"standalone step by step".

View File

@ -1,5 +1,5 @@
--- ---
description: Execute a ready plan — create issue + branch when on a base branch, or continue on the current branch; implement and commit — loads and follows the implement-plan skill description: Execute a ready plan — task checklist, your confirmation, then all tasks with one commit (default) or step by step with a commit and a pause per task; creates issue + branch when on a base branch — loads and follows the implement-plan skill
agent: build agent: build
--- ---