✨ Make implement-plan flow-aware and add open-pr command

/implement-plan now detects the flow from the current branch instead
of always creating an issue: on a base branch it starts standalone
(issue + branch issue-NNNN from HEAD); on a feature branch it
continues on it with no new scaffolding. Arguments override
detection (standalone, continue, no issue, from origin/<base>);
"no issue" on a base branch creates a plan-<slug> branch. Execution
is direct and the closing suggests /review-code or /open-pr.

/open-pr opens the PR for the current task branch: it detects the
base with scripts/detect-target-branch (canonical: develop, staging,
main), validates commits, issue and remote state, and stops with one
message listing everything missing. It never pushes.

AI-assisted-by: omen-alpha

.opencode/commands/implement-plan.md

@@ -1,39 +1,79 @@
 ---
-description: Execute a ready plan end-to-end — create a GitHub issue, branch issue-NNNN, implement the plan, then commit via the create-commit skill
+description: Execute a ready plan — create issue + branch when on a base branch, or continue on the current branch; implement and commit
 agent: build
 ---
 
 This command is run once a plan is ready (for example, from plan mode). Execute
-the plan already prepared in the current session context. Follow these steps in order.
+the plan already prepared in the current session context. This command ends
+with exactly one commit. It never pushes — the user pushes.
 
-## 1. Create the issue
+## 1. Detect the flow (no questions)
 
-Use 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).
+Inspect the current branch with `git rev-parse --abbrev-ref HEAD`, pick the
+mode, and announce it in one line before acting.
 
-## 2. Create the branch
+- **On a base branch** (`main`, `develop`, `staging`) → **standalone mode**:
+  create the issue and the branch, then implement and commit.
+- **On any other branch** (a feature branch, typically `issue-NNNN`) →
+  **continue mode**: implement on the current branch and commit. No issue or
+  branch is created.
 
-Create and switch to a branch named after the issue:
+Arguments override detection: `standalone`, `continue`,
+`no issue` / `without issue`, or an explicit base such as
+`from origin/develop`.
 
-```
-git checkout -b issue-NNNN
-```
+### Standalone mode
 
-(Replace NNNN with the issue number from step 1.)
+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:
 
-## 3. Execute the plan
+   ```
+   git checkout -b issue-NNNN
+   ```
 
-Implement the prepared plan from the session context. Work methodically, keeping
-changes focused on what the issue requires. Do not commit — the commit happens in
-step 4.
+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.
 
-## 4. Commit with the create-commit skill
+**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
+example `from origin/develop` — then branch from that base instead of HEAD.
+
+### Continue mode
+
+No issue and no branch. Implement on the current branch. The branch name
+provides the issue reference when it follows the `issue-NNNN` pattern.
+
+## 2. Execute the plan
+
+Implement the prepared plan from the session context. Work methodically,
+keeping changes focused on what the issue requires. Respect the plan's
+proposed parallelization when it applies. Do not commit — the commit happens
+in the next step.
+
+## 3. Commit with the create-commit skill
 
 After 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`), and the model name you
-are running as so the `AI-assisted-by` trailer is set correctly.
+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.
 
 Do not push. Pushing is handled separately by the user.
+
+## When you are done
+
+End by suggesting the next steps (suggestions, not a required pipeline — any
+instruction from me overrides them):
+
+- `/review-code` — to review the changes just committed; it routes to
+  `/make-a-plan` by itself if the findings need one.
+- `/open-pr` — when the task is done and the branch is ready to merge.
+
+## User input, overrides and additional context
+
+$ARGUMENTS

.opencode/commands/open-pr.md

@@ -0,0 +1,60 @@
+---
+description: Open the PR for the current task branch — detects the base branch, requires a clear issue, never pushes
+agent: build
+---
+
+Open the pull request for the current task branch. Gather information,
+validate, and create the PR in one pass. If validation fails, STOP with a
+single coherent message that lists every problem and states exactly what
+information is missing — never fix or work around problems silently.
+
+## 1. Gather context (read-only)
+
+- Current branch: `git rev-parse --abbrev-ref HEAD`.
+- Target base branch: run `./scripts/detect-target-branch` from the repo root.
+  It prints the nearest ancestor branch of HEAD (exit 0) or fails (exit 1).
+- Commits: `git log --oneline <base>..HEAD`.
+- Remote state: `git ls-remote origin <branch>`.
+- Issue: from the session context, or from the branch name — `issue-NNNN`
+  maps to issue NNNN; recover its title and body with `gh issue view NNNN`.
+
+## 2. Validate — stop with one message if anything fails
+
+Run all checks before reporting, then report every failure together:
+
+1. **Base branch not usable.** If the script fails (exit 1) or its output is
+   not one of the canonical branches (`develop`, `staging`, `main`), stop and
+   ask the user to re-run with more context — for example, passing the base
+   branch explicitly in the arguments. An explicit base given in the
+   arguments overrides the script's output.
+2. **On a base branch.** There is no task branch to merge — say so and stop.
+3. **No commits.** The branch has no commits ahead of the base — say so and
+   stop.
+4. **No clear issue.** There is no issue in the session context, and the
+   branch name has no `issue-NNNN` pattern (or `gh issue view` finds nothing)
+   — say so and stop. Exception: the arguments say `no issue` /
+   `without issue` — then continue without an issue reference.
+5. **Branch not pushed.** `git ls-remote origin <branch>` finds nothing —
+   never push yourself; ask the user to push and to re-run `/open-pr`
+   afterwards, then stop.
+
+## 3. Already-open PR
+
+Check whether a PR already exists for this branch (`gh pr list --head
+<branch>`). If one exists, report its URL and stop — do not create a second
+one.
+
+## 4. Create the PR
+
+Load the **`create-pr`** skill and follow its workflow
+(`mem:workflow/creating-prs` has the title format and body structure). Derive
+the title and body from the commits and, when there is one, from the issue
+body. Reference the issue with `Closes #NNNN`.
+
+## 5. Report
+
+Report the PR URL and stop.
+
+## User input, overrides and additional context
+
+$ARGUMENTS