[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CVJWZ9BP3AY6JHEX7Z3GC3":3,"skill-same:01M6CVJWZ9BP3AY6JHEX7Z3GC3":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6CVJWZ9BP3AY6JHEX7Z3GC3","issue-workflow",null,"Continuous issue awareness with proactive issue-linked commit and push; natural-language modes (start, commit, finish) remain as manual overrides. Use when a commit, push or closure is pending, when work starts or resumes, or when the user says \"issue start\", \"neues issue\", \"issue commit\", \"checkpoint\", \"finish issue\" or \"issue fertig\". Do not use in read-only grading skills or on student repositories.","georgernstgraf\u002Fopencode-helpers","georgernstgraf","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F115418377?v=4","01M6CVHJ34JS0CF98EFFN0FZ76","Georg Graf SPG","01M6CVHJ7VV5VK6RXY62SR0NE2",1,"MIT","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fissue-workflow\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"issue workflow","issue","workflow","proactive","overrides","with","modes","manual","as","natural-language","language","finish","start","github","opencode","commit","awareness","commit and push","push","2026-11-10 10:12:30",false,"---\nname: issue-workflow\ndescription: Continuous issue awareness with proactive issue-linked commit and\n  push; natural-language modes (start, commit, finish) remain as manual\n  overrides. Use when a commit, push or closure is pending, when work starts or\n  resumes, or when the user says \"issue start\", \"neues issue\", \"issue commit\",\n  \"checkpoint\", \"finish issue\" or \"issue fertig\". Do not use in read-only\n  grading skills or on student repositories.\nlicense: MIT\ncompatibility: opencode\nmetadata:\n  category: workflow\n  scope: github\n---\n\n# Issue Workflow Skill\n\n## Purpose\n\nThis skill governs issue-centered work as a **continuous state**, not a\nuser-invoked sequence. At any point in a session the agent knows which issue\nit is working under, commits and pushes completed units proactively, and\ncloses the issue autonomously once the completion criteria are met, reporting\nthe closure in its final message. The natural-language\ntriggers (\"issue start\", \"issue commit\", \"issue commit and push\") are manual\noverrides, not activation conditions — the rules below apply even without\nbeing invoked.\n\n## Continuous Issue Awareness (Dauerzustand)\n\n- At any point in a session, the agent must know which GitHub issue it is\n  currently working under, and announce it (e.g., \"Working under issue\n  #123: \u003Ctitle>\").\n- Before starting work, resolve the current issue: run the **Duplicate Check**\n  (below) and reuse a matching open issue instead of creating a new one.\n- Only when the Duplicate Check finds no match and the task is clearly a new\n  topic, create a new issue immediately and **without user interaction**, then\n  announce it.\n- Never create an issue while an open issue already tracks all or part of the\n  same goal — see \"Duplicate Check\" for the decision matrix.\n- If the assignment is ambiguous (several candidate issues, or unclear\n  whether a new one is needed), ask the user before touching code.\n- The assignment to an issue may change mid-session when the user redirects\n  the work; resolve the new issue the same way.\n\n## Duplicate Check (Pflicht-Gate vor jeder Issue-Erzeugung)\n\nThis gate is mandatory **before every `gh issue create`** — in the `start`\nmode, in continuous work, and in every other skill or command that creates\nissues (they reference this section instead of re-implementing it). Its scope\nis always the **current repository** (`--repo \u003Cowner>\u002F\u003Crepo>` from\n`gh repo view --json nameWithOwner --jq .nameWithOwner`) — never an org-wide\nsearch.\n\n### 1. Search for candidates (all three, in parallel)\n\n```bash\n# open issues, keyword search\ngh issue list --repo \u003Cowner>\u002F\u003Crepo> --state open --limit 50 \\\n  --search \"\u003Cterms>\" --json number,title,labels,updatedAt\n# full text in title and body\ngh search issues --repo \u003Cowner>\u002F\u003Crepo> --state open \"in:title,body \u003Cterms>\" \\\n  --json number,title,updatedAt\n# in-flight work that is not yet an issue\ngh search prs --repo \u003Cowner>\u002F\u003Crepo> --state open \"\u003Cterms>\" \\\n  --json number,title\n```\n\n- Derive 2–4 **discriminating** terms from the planned title and scope\n  (module, file, feature noun, error string) — not the whole sentence. In\n  mixed-language trackers search German *and* English synonyms.\n- If the first pass returns nothing, repeat with the single broadest term (the\n  feature noun) so that different wording still matches.\n- Read every promising hit (`gh issue view \u003CN> --json title,body,comments`).\n  Titles alone are not evidence; the goal stated in the body decides.\n\n### 2. Decide\n\n| Finding | Action |\n|---|---|\n| 0 plausible candidates | create the new issue |\n| 1 open issue covers the planned goal | **do not create** — work under it, add the new scope as a comment |\n| 1 open issue covers only part of the plan | **do not duplicate** — work under it; create a separate sub-issue only if the parent genuinely requires independent tracking (then link it formally, see \"Sub-Issues\") |\n| ≥2 plausible candidates, or unclear whether a new issue is needed | **stop and ask the user** — per candidate: number, title, `updatedAt`, one-line rationale |\n| only closed issues match | create the new issue; mention the closed one in the body as a regression\u002Frepeat |\n\n**Tie-breaker (asymmetric cost):** when in doubt, comment on the existing\nissue instead of opening a new one. A comment is cheap and reversible; a\nduplicate pollutes the tracker, its boards, and its auto-close logic. There is\nno \"obviously new topic\" shortcut around this matrix — passing it is what\nlicenses creating without asking.\n\n### 3. Record the check (trace line)\n\nThe body of every newly created issue ends with:\n\n```\nDuplicate check (YYYY-MM-DD): no matching open issue. Checked: #12, #34, search \"backup restore\".\n```\n\nWhen an existing issue is reused instead, post a comment that names the planned\nscope and the date. This keeps the check auditable and lets the duplicate rate\nbe measured later.\n\n## Trunk-Based Pull-Prinzip (universell)\n\n- Vor JEDER Arbeitsaufnahme (start-Modus und generell vor jeder Session-Arbeit\n  an einem Repo oder Deployed-Tree): zuerst das Working Copy auf den Trunk heben.\n  - Git (trunk-based, clean-main): `git pull`\n  - SVN: `svn up` im relevanten Working Copy (z. B. `~\u002Fsvn\u002Fgeorg` auf think,\n    `\u002F` auf murl\u002Fclaw im Deployed-Tree)\n- Fehlschlag des Pulls oder Konflikte: SOFORT stoppen und dem Nutzer melden,\n  nicht fortfahren.\n- Begründung: trunk-basierte Workflows leben davon, dass immer vom aktuellen\n  Stand aus gearbeitet wird — sonst entstehen vermeidbare Conflicts und\n  re-discovery von fremden Commits.\n\n## Required Inputs\n\n- `mode`: one of `start`, `commit`, or `finish` — optional, only when the\n  user triggers a manual override by natural language\n- `issue`: optional issue identifier or `new`\n- `context`: optional plain-language task summary, plan, or notes\n\n## Core Rules\n\n- **VCS-Scope:** Dieses Skill ist primär für Git\u002FGitHub-Projekte entworfen\n  (`gh`-CLI). In reinen SVN-Projekten (z. B. `~\u002Fsvn\u002Fgeorg`, Deployed-Trees auf\n  murl\u002Fclaw) existiert **kein Issue-System** — dort entfallen Issue-Nummern und\n  `gh issue`-Befehle vollständig; die Commit-Regel reduziert sich auf eine\n  klare, deutsche Commit-Message (SVN-Stil), und der Pull-Schritt oben ist\n  `svn up`.\n- Every commit created under this workflow must reference a GitHub issue\n  number with a hashtag, e.g. `feat: add report export (#123)`. Never\n  fabricate issue numbers.\n- **Proactive Commit and Push:** After each completed, self-contained unit of\n  work, commit and push immediately — do not wait for the user to request it\n  or for a trigger phrase. This overrides the opencode default \"never commit\n  unless the user asks\". See \"Proactive Commit and Push\" below.\n- **Green commits only:** run the repository's tests\u002Flint for the affected\n  area before committing; never push a broken state.\n- Never create a commit without first identifying an existing issue or\n  creating a new one.\n- If no relevant issue exists and a commit is needed, create the issue first,\n  then use its number in the commit message.\n- Prefer keeping one clear issue per workstream; do not scatter related changes\n  across multiple issues unless the user explicitly requests it.\n- Use `gh` for all GitHub issue operations.\n- **Sub-Issues Rule:** When breaking a task into smaller issues, or when starting work on a task that belongs to a parent epic, you **MUST** establish a formal parent-child relationship using the Sub-Issues API. Mentions in the description are secondary to this formal link. Always use the `issue-workflow` skill for issue creation to ensure this protocol is followed.\n- **Never close an issue that has open sub-issues.** Before closing any issue,\n  list its sub-issues and verify all are closed first.\n- Do not close an issue unless the implementation is actually complete and\n  the completion criteria in \"Issue Completion\" are met.\n\n## Commit Message Rule\n\n- Any commit created by this workflow must include the issue reference, such as\n  `feat: add report export (#123)` or `fix: handle empty inputs (#123)`.\n- If the repository already uses a recognizable commit message style, preserve\n  that style while still including the issue number.\n\n## Proactive Commit and Push (Dauerzustand)\n\nThese rules apply at any time during session work, without a trigger phrase:\n\n- After each completed, self-contained unit of work, commit and push\n  immediately — do not wait for the user to request it or for a mode\n  invocation. This overrides the opencode default \"never commit unless the\n  user asks\".\n- **Green commits only:** run the repository's tests\u002Flint for the affected\n  area first. Commit only when they pass. If verification fails, fix or\n  report — never push a broken state.\n- The commit message must include the issue reference (see Commit Message\n  Rule) and preserve the repository's existing style.\n- No empty commits. If there is nothing to commit, say so instead.\n- Trunk-based: commit and push directly to the tracked trunk line (`main`);\n  no feature branches or PRs — unless the repository follows the\n  `fork-policy` skill (then that policy wins).\n- SVN working copies: the analogue is frequent, clear `svn ci` with a\n  descriptive German commit message.\n- The read-only scope exclusions (`homework`, `repograde`, `grading-shared`,\n  `knowledge-assessment`, `knowledge-exam`, `projectgrade`, student\n  repositories, and explicit \"hold back\" requests) always win over this\n  policy.\n\n## Manual Override Modes\n\nThe modes below are **manual overrides** triggered by natural language.\nThe continuous rules above (issue awareness, proactive commit\u002Fpush) apply\nregardless; the modes force a specific checkpoint behavior.\n\n### 1. `start`\n\nUse this mode to explicitly begin or resume work (e.g., \"issue start\").\n\n- If `issue` is an explicit issue number, fetch it with\n  `gh issue view \u003CN> --json title,body,comments` and read the description plus comments.\n  Check if the issue has a parent or should be linked as a sub-issue to an existing epic.\n- If `issue` is `new`, or if no usable issue exists for the current work,\n  run the Duplicate Check first; only then create a new issue from the\n  provided context. If the new issue is part of a larger epic, link it as a\n  sub-issue immediately.\n- If no issue is supplied, infer whether there is already a current issue for\n  the work (Duplicate Check). Only if none matches, create one before\n  proceeding.\n- Assess the codebase against the issue. If the requested functionality is\n  already complete, comment with the finding and follow the completion\n  criteria in \"Issue Completion\" (check open sub-issues first).\n- Resolve any blocking ambiguity with the user only after doing all safe local\n  discovery work first.\n- Update the issue description or add a progress comment with the current plan,\n  scope, or todo list.\n- Implement the requested changes, then apply the Proactive Commit and Push\n  rules — commit and push with the issue reference without waiting for a\n  further request.\n\n### 2. `commit`\n\nUse this mode to force an immediate checkpoint while the issue remains open\n(e.g., \"issue commit\", \"checkpoint\").\n\n- Ensure a current issue exists; create one if needed from the current context.\n- Comment on the issue with a concise implementation report covering:\n  - what was completed\n  - what remains\n  - known risks, blockers, or follow-ups\n- Persist session knowledge by invoking the `knowledge-persistence` skill.\n  Note: knowledge-persistence **commits and pushes its own knowledge commit**\n  (with the issue reference) and never closes issues; it only adds comments for\n  traceability.\n- Review git status and staged\u002Funstaged changes.\n- Create a commit that includes the issue number for any **remaining**\n  non-knowledge changes. Never create an empty commit — if knowledge-persistence\n  already committed everything, there is nothing to do here.\n- Push to the trunk line.\n- Keep the issue open.\n\n### 3. `finish`\n\nUse this mode to force finalization and issue closure (e.g., \"issue finish\",\n\"issue fertig\").\n\n- Ensure a current issue exists; create one if somehow missing so the completed\n  work still has a tracked issue reference.\n- Comment on the issue with a final implementation report.\n- Persist all newly acquired session knowledge by also using the\n  `knowledge-persistence` skill before finalizing the workflow.\n  Note: knowledge-persistence **commits and pushes its own knowledge commit**\n  (with the issue reference); it never closes issues. The issue closure below is\n  owned exclusively by this `finish` mode.\n- Review git status and remaining changes.\n- Create the final commit including the issue number for any **remaining**\n  non-knowledge changes. Never create an empty commit.\n- Push to the trunk line.\n- **Before closing the issue**, list its sub-issues via:\n  `gh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002F{NUMBER}\u002Fsub_issues --jq '.[].number'`\n  If any sub-issues remain open, the issue **must not** be closed. Report the\n  open sub-issues and keep the parent open.\n- Close the issue with a short closing comment if helpful.\n- **Post-close knowledge follow-up:** because `STATE.md`\u002F`HANDOFF.md` record the\n  *closed* state, run `knowledge-persistence` once more after closing — it ends\n  with its own commit + push, so the recorded closure reaches the trunk. This\n  second run is expected; the first (pre-close) run must not be skipped.\n\n## Issue Completion (Dauerzustand)\n\nApplies at any time, independent of the modes:\n\n- When the agent believes the issue's goal is fully implemented, it **closes\n  the issue autonomously** — it does not wait for the user to ask and does not\n  ask for permission first.\n- The agent may close autonomously only when ALL of these hold:\n  - the implementation covers the issue goal completely,\n  - verification (tests\u002Flint) is green,\n  - the issue has no open sub-issues (always check via the `issue-workflow`\n    sub-issues API first),\n  - the user has not signalled anything that contradicts completion.\n- Before closing, comment on the issue with a final implementation\n  report (persist session knowledge via `knowledge-persistence` when new\n  knowledge exists).\n- Knowledge persistence is not finished until it is **committed and pushed**\n  (its own commit with the issue reference; SVN: `svn ci`). Because\n  `STATE.md`\u002F`HANDOFF.md` describe the closed state, this usually means a\n  **follow-up knowledge commit after the close** — never leave the knowledge\n  files uncommitted\u002Funpushed.\n- The final message to the user **MUST** state that the issue was closed and\n  name its number (e.g. \"Issue #123 closed\"). A silent closure is not enough.\n- If any criterion is not met, do **not** close: report the status, state what\n  is missing, and ask.\n\n## Issue Creation Guidance\n\nWhen creating an issue:\n\n- **Run the Duplicate Check first** (see \"Duplicate Check\"). No issue is\n  created before that gate reports no match — this is the primary anti-\n  duplication rule of this skill.\n- Write a short, outcome-oriented title.\n- Include enough body detail for a future agent to understand scope and intent.\n- **Link as Sub-Issue:** If this issue is a component of a larger task, identify the parent issue and link it as a sub-issue immediately after creation.\n- If a plan already exists, use it as the issue body or convert it into a short\n  checklist.\n\n## Sub-Issues (Parent-Child Linking)\n\nGitHub supports proper parent-child issue relationships via the Sub-Issues REST\nAPI. Simply mentioning a parent issue number in the body text is **not\nsufficient** — it creates only a loose text reference, not a tracked\nrelationship.\n\n### Creating a sub-issue\n\n1. Create the child issue with `gh issue create` as usual.\n2. Look up the **database `id`** (not the issue `number`) of the child:\n   ```bash\n   gh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002FCHILD_NUMBER --jq '.id'\n   ```\n3. Link it to the parent:\n   ```bash\n   gh api --method POST \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\u002FPARENT_NUMBER\u002Fsub_issues \\\n     --input - \u003C\u003C\u003C '{\"sub_issue_id\": CHILD_DATABASE_ID}'\n   ```\n\n**Important:** The `sub_issue_id` field must be an **integer** (the internal\ndatabase ID), not the human-readable issue number. Using `-f sub_issue_id=N`\nsends a string and causes a 422 validation error. Always use `--input` with a\nJSON body instead.\n\n### Listing sub-issues\n\n```bash\ngh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002FPARENT_NUMBER\u002Fsub_issues --jq '.[].number'\n```\n\n### Removing a sub-issue link\n\n```bash\ngh api --method DELETE \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\u002FPARENT_NUMBER\u002Fsub_issue \\\n  --input - \u003C\u003C\u003C '{\"sub_issue_id\": CHILD_DATABASE_ID}'\n```\n\n### When to use sub-issues\n\n- When breaking down a parent epic into individually trackable work items.\n- When the parent issue should show a progress summary\n  (`sub_issues_summary.total` \u002F `completed` \u002F `percent_completed`).\n- Each sub-issue can be assigned, labeled, and closed independently; closing\n  all sub-issues does **not** auto-close the parent.\n- **A parent issue must never be closed while it has open sub-issues.**\n  Either close all children first, or re-parent them before closing the parent.\n\n### Avoiding concurrent-link conflicts\n\nWhen linking multiple sub-issues in rapid succession, avoid sending all\nrequests in parallel — the API uses sequential priority positions and will\nreturn `422 Priority has already been taken`. Link them sequentially or with a\nsmall delay between calls.\n\n## Reporting Guidance\n\nIssue comments should be compact but useful.\n\n- Progress comments should mention completed work, current status, and next\n  steps.\n- Final comments should mention the shipped outcome and any noteworthy caveats.\n\n## Safety Constraints\n\n- Never fabricate issue numbers.\n- Never create an issue before the Duplicate Check ran and reported no match.\n- Never open a second issue for a goal that an open issue already tracks.\n- Never create an empty commit when there are no changes.\n- If there are no local changes in `commit` or `finish` mode, still update the\n  issue comment as needed, but report that there was nothing to commit.\n- Do not push or close issues if the relevant step fails.\n- Never close an issue that has open sub-issues. Always check for open\n  sub-issues before closing.\n\n## Output Expectations\n\nAt the end of the workflow, report:\n\n- the issue number used or created\n- the duplicate check result: which candidates were checked, or that no open\n  issue matched\n- whether a comment was added\n- whether a commit was created, including its message\n- whether knowledge persistence was run, and the hash of its commit (and that\n  it was pushed)\n- the issue number and its final state: when the issue was closed, state this\n  explicitly (e.g. \"Issue #123 closed\"); otherwise note that it remains open\n\n## Done when\n\n- [ ] The current issue is resolved via the Duplicate Check and announced by\n      number.\n- [ ] Every newly created issue carries the duplicate-check trace line, or a\n      reuse comment was posted on the existing issue.\n- [ ] Every commit references a real issue number and passed the affected area's\n      tests\u002Flint first.\n- [ ] Each completed unit is pushed to the trunk line, or a read-only scope\n      exclusion is named in the report.\n- [ ] In `commit`\u002F`finish` mode, knowledge persistence ran and its own commit was\n      pushed.\n- [ ] A parent issue was closed only after its sub-issues were listed and all\n      found closed.\n- [ ] The final report names the issue number, its state, the duplicate-check\n      result, and the commit messages used.\n","# Issue Workflow Skill\n\n## Purpose\n\nThis skill governs issue-centered work as a **continuous state**, not a\nuser-invoked sequence. At any point in a session the agent knows which issue\nit is working under, commits and pushes completed units proactively, and\ncloses the issue autonomously once the completion criteria are met, reporting\nthe closure in its final message. The natural-language\ntriggers (\"issue start\", \"issue commit\", \"issue commit and push\") are manual\noverrides, not activation conditions — the rules below apply even without\nbeing invoked.\n\n## Continuous Issue Awareness (Dauerzustand)\n\n- At any point in a session, the agent must know which GitHub issue it is\n  currently working under, and announce it (e.g., \"Working under issue\n  #123: \u003Ctitle>\").\n- Before starting work, resolve the current issue: run the **Duplicate Check**\n  (below) and reuse a matching open issue instead of creating a new one.\n- Only when the Duplicate Check finds no match and the task is clearly a new\n  topic, create a new issue immediately and **without user interaction**, then\n  announce it.\n- Never create an issue while an open issue already tracks all or part of the\n  same goal — see \"Duplicate Check\" for the decision matrix.\n- If the assignment is ambiguous (several candidate issues, or unclear\n  whether a new one is needed), ask the user before touching code.\n- The assignment to an issue may change mid-session when the user redirects\n  the work; resolve the new issue the same way.\n\n## Duplicate Check (Pflicht-Gate vor jeder Issue-Erzeugung)\n\nThis gate is mandatory **before every `gh issue create`** — in the `start`\nmode, in continuous work, and in every other skill or command that creates\nissues (they reference this section instead of re-implementing it). Its scope\nis always the **current repository** (`--repo \u003Cowner>\u002F\u003Crepo>` from\n`gh repo view --json nameWithOwner --jq .nameWithOwner`) — never an org-wide\nsearch.\n\n### 1. Search for candidates (all three, in parallel)\n\n```bash\n# open issues, keyword search\ngh issue list --repo \u003Cowner>\u002F\u003Crepo> --state open --limit 50 \\\n  --search \"\u003Cterms>\" --json number,title,labels,updatedAt\n# full text in title and body\ngh search issues --repo \u003Cowner>\u002F\u003Crepo> --state open \"in:title,body \u003Cterms>\" \\\n  --json number,title,updatedAt\n# in-flight work that is not yet an issue\ngh search prs --repo \u003Cowner>\u002F\u003Crepo> --state open \"\u003Cterms>\" \\\n  --json number,title\n```\n\n- Derive 2–4 **discriminating** terms from the planned title and scope\n  (module, file, feature noun, error string) — not the whole sentence. In\n  mixed-language trackers search German *and* English synonyms.\n- If the first pass returns nothing, repeat with the single broadest term (the\n  feature noun) so that different wording still matches.\n- Read every promising hit (`gh issue view \u003CN> --json title,body,comments`).\n  Titles alone are not evidence; the goal stated in the body decides.\n\n### 2. Decide\n\n| Finding | Action |\n|---|---|\n| 0 plausible candidates | create the new issue |\n| 1 open issue covers the planned goal | **do not create** — work under it, add the new scope as a comment |\n| 1 open issue covers only part of the plan | **do not duplicate** — work under it; create a separate sub-issue only if the parent genuinely requires independent tracking (then link it formally, see \"Sub-Issues\") |\n| ≥2 plausible candidates, or unclear whether a new issue is needed | **stop and ask the user** — per candidate: number, title, `updatedAt`, one-line rationale |\n| only closed issues match | create the new issue; mention the closed one in the body as a regression\u002Frepeat |\n\n**Tie-breaker (asymmetric cost):** when in doubt, comment on the existing\nissue instead of opening a new one. A comment is cheap and reversible; a\nduplicate pollutes the tracker, its boards, and its auto-close logic. There is\nno \"obviously new topic\" shortcut around this matrix — passing it is what\nlicenses creating without asking.\n\n### 3. Record the check (trace line)\n\nThe body of every newly created issue ends with:\n\n```\nDuplicate check (YYYY-MM-DD): no matching open issue. Checked: #12, #34, search \"backup restore\".\n```\n\nWhen an existing issue is reused instead, post a comment that names the planned\nscope and the date. This keeps the check auditable and lets the duplicate rate\nbe measured later.\n\n## Trunk-Based Pull-Prinzip (universell)\n\n- Vor JEDER Arbeitsaufnahme (start-Modus und generell vor jeder Session-Arbeit\n  an einem Repo oder Deployed-Tree): zuerst das Working Copy auf den Trunk heben.\n  - Git (trunk-based, clean-main): `git pull`\n  - SVN: `svn up` im relevanten Working Copy (z. B. `~\u002Fsvn\u002Fgeorg` auf think,\n    `\u002F` auf murl\u002Fclaw im Deployed-Tree)\n- Fehlschlag des Pulls oder Konflikte: SOFORT stoppen und dem Nutzer melden,\n  nicht fortfahren.\n- Begründung: trunk-basierte Workflows leben davon, dass immer vom aktuellen\n  Stand aus gearbeitet wird — sonst entstehen vermeidbare Conflicts und\n  re-discovery von fremden Commits.\n\n## Required Inputs\n\n- `mode`: one of `start`, `commit`, or `finish` — optional, only when the\n  user triggers a manual override by natural language\n- `issue`: optional issue identifier or `new`\n- `context`: optional plain-language task summary, plan, or notes\n\n## Core Rules\n\n- **VCS-Scope:** Dieses Skill ist primär für Git\u002FGitHub-Projekte entworfen\n  (`gh`-CLI). In reinen SVN-Projekten (z. B. `~\u002Fsvn\u002Fgeorg`, Deployed-Trees auf\n  murl\u002Fclaw) existiert **kein Issue-System** — dort entfallen Issue-Nummern und\n  `gh issue`-Befehle vollständig; die Commit-Regel reduziert sich auf eine\n  klare, deutsche Commit-Message (SVN-Stil), und der Pull-Schritt oben ist\n  `svn up`.\n- Every commit created under this workflow must reference a GitHub issue\n  number with a hashtag, e.g. `feat: add report export (#123)`. Never\n  fabricate issue numbers.\n- **Proactive Commit and Push:** After each completed, self-contained unit of\n  work, commit and push immediately — do not wait for the user to request it\n  or for a trigger phrase. This overrides the opencode default \"never commit\n  unless the user asks\". See \"Proactive Commit and Push\" below.\n- **Green commits only:** run the repository's tests\u002Flint for the affected\n  area before committing; never push a broken state.\n- Never create a commit without first identifying an existing issue or\n  creating a new one.\n- If no relevant issue exists and a commit is needed, create the issue first,\n  then use its number in the commit message.\n- Prefer keeping one clear issue per workstream; do not scatter related changes\n  across multiple issues unless the user explicitly requests it.\n- Use `gh` for all GitHub issue operations.\n- **Sub-Issues Rule:** When breaking a task into smaller issues, or when starting work on a task that belongs to a parent epic, you **MUST** establish a formal parent-child relationship using the Sub-Issues API. Mentions in the description are secondary to this formal link. Always use the `issue-workflow` skill for issue creation to ensure this protocol is followed.\n- **Never close an issue that has open sub-issues.** Before closing any issue,\n  list its sub-issues and verify all are closed first.\n- Do not close an issue unless the implementation is actually complete and\n  the completion criteria in \"Issue Completion\" are met.\n\n## Commit Message Rule\n\n- Any commit created by this workflow must include the issue reference, such as\n  `feat: add report export (#123)` or `fix: handle empty inputs (#123)`.\n- If the repository already uses a recognizable commit message style, preserve\n  that style while still including the issue number.\n\n## Proactive Commit and Push (Dauerzustand)\n\nThese rules apply at any time during session work, without a trigger phrase:\n\n- After each completed, self-contained unit of work, commit and push\n  immediately — do not wait for the user to request it or for a mode\n  invocation. This overrides the opencode default \"never commit unless the\n  user asks\".\n- **Green commits only:** run the repository's tests\u002Flint for the affected\n  area first. Commit only when they pass. If verification fails, fix or\n  report — never push a broken state.\n- The commit message must include the issue reference (see Commit Message\n  Rule) and preserve the repository's existing style.\n- No empty commits. If there is nothing to commit, say so instead.\n- Trunk-based: commit and push directly to the tracked trunk line (`main`);\n  no feature branches or PRs — unless the repository follows the\n  `fork-policy` skill (then that policy wins).\n- SVN working copies: the analogue is frequent, clear `svn ci` with a\n  descriptive German commit message.\n- The read-only scope exclusions (`homework`, `repograde`, `grading-shared`,\n  `knowledge-assessment`, `knowledge-exam`, `projectgrade`, student\n  repositories, and explicit \"hold back\" requests) always win over this\n  policy.\n\n## Manual Override Modes\n\nThe modes below are **manual overrides** triggered by natural language.\nThe continuous rules above (issue awareness, proactive commit\u002Fpush) apply\nregardless; the modes force a specific checkpoint behavior.\n\n### 1. `start`\n\nUse this mode to explicitly begin or resume work (e.g., \"issue start\").\n\n- If `issue` is an explicit issue number, fetch it with\n  `gh issue view \u003CN> --json title,body,comments` and read the description plus comments.\n  Check if the issue has a parent or should be linked as a sub-issue to an existing epic.\n- If `issue` is `new`, or if no usable issue exists for the current work,\n  run the Duplicate Check first; only then create a new issue from the\n  provided context. If the new issue is part of a larger epic, link it as a\n  sub-issue immediately.\n- If no issue is supplied, infer whether there is already a current issue for\n  the work (Duplicate Check). Only if none matches, create one before\n  proceeding.\n- Assess the codebase against the issue. If the requested functionality is\n  already complete, comment with the finding and follow the completion\n  criteria in \"Issue Completion\" (check open sub-issues first).\n- Resolve any blocking ambiguity with the user only after doing all safe local\n  discovery work first.\n- Update the issue description or add a progress comment with the current plan,\n  scope, or todo list.\n- Implement the requested changes, then apply the Proactive Commit and Push\n  rules — commit and push with the issue reference without waiting for a\n  further request.\n\n### 2. `commit`\n\nUse this mode to force an immediate checkpoint while the issue remains open\n(e.g., \"issue commit\", \"checkpoint\").\n\n- Ensure a current issue exists; create one if needed from the current context.\n- Comment on the issue with a concise implementation report covering:\n  - what was completed\n  - what remains\n  - known risks, blockers, or follow-ups\n- Persist session knowledge by invoking the `knowledge-persistence` skill.\n  Note: knowledge-persistence **commits and pushes its own knowledge commit**\n  (with the issue reference) and never closes issues; it only adds comments for\n  traceability.\n- Review git status and staged\u002Funstaged changes.\n- Create a commit that includes the issue number for any **remaining**\n  non-knowledge changes. Never create an empty commit — if knowledge-persistence\n  already committed everything, there is nothing to do here.\n- Push to the trunk line.\n- Keep the issue open.\n\n### 3. `finish`\n\nUse this mode to force finalization and issue closure (e.g., \"issue finish\",\n\"issue fertig\").\n\n- Ensure a current issue exists; create one if somehow missing so the completed\n  work still has a tracked issue reference.\n- Comment on the issue with a final implementation report.\n- Persist all newly acquired session knowledge by also using the\n  `knowledge-persistence` skill before finalizing the workflow.\n  Note: knowledge-persistence **commits and pushes its own knowledge commit**\n  (with the issue reference); it never closes issues. The issue closure below is\n  owned exclusively by this `finish` mode.\n- Review git status and remaining changes.\n- Create the final commit including the issue number for any **remaining**\n  non-knowledge changes. Never create an empty commit.\n- Push to the trunk line.\n- **Before closing the issue**, list its sub-issues via:\n  `gh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002F{NUMBER}\u002Fsub_issues --jq '.[].number'`\n  If any sub-issues remain open, the issue **must not** be closed. Report the\n  open sub-issues and keep the parent open.\n- Close the issue with a short closing comment if helpful.\n- **Post-close knowledge follow-up:** because `STATE.md`\u002F`HANDOFF.md` record the\n  *closed* state, run `knowledge-persistence` once more after closing — it ends\n  with its own commit + push, so the recorded closure reaches the trunk. This\n  second run is expected; the first (pre-close) run must not be skipped.\n\n## Issue Completion (Dauerzustand)\n\nApplies at any time, independent of the modes:\n\n- When the agent believes the issue's goal is fully implemented, it **closes\n  the issue autonomously** — it does not wait for the user to ask and does not\n  ask for permission first.\n- The agent may close autonomously only when ALL of these hold:\n  - the implementation covers the issue goal completely,\n  - verification (tests\u002Flint) is green,\n  - the issue has no open sub-issues (always check via the `issue-workflow`\n    sub-issues API first),\n  - the user has not signalled anything that contradicts completion.\n- Before closing, comment on the issue with a final implementation\n  report (persist session knowledge via `knowledge-persistence` when new\n  knowledge exists).\n- Knowledge persistence is not finished until it is **committed and pushed**\n  (its own commit with the issue reference; SVN: `svn ci`). Because\n  `STATE.md`\u002F`HANDOFF.md` describe the closed state, this usually means a\n  **follow-up knowledge commit after the close** — never leave the knowledge\n  files uncommitted\u002Funpushed.\n- The final message to the user **MUST** state that the issue was closed and\n  name its number (e.g. \"Issue #123 closed\"). A silent closure is not enough.\n- If any criterion is not met, do **not** close: report the status, state what\n  is missing, and ask.\n\n## Issue Creation Guidance\n\nWhen creating an issue:\n\n- **Run the Duplicate Check first** (see \"Duplicate Check\"). No issue is\n  created before that gate reports no match — this is the primary anti-\n  duplication rule of this skill.\n- Write a short, outcome-oriented title.\n- Include enough body detail for a future agent to understand scope and intent.\n- **Link as Sub-Issue:** If this issue is a component of a larger task, identify the parent issue and link it as a sub-issue immediately after creation.\n- If a plan already exists, use it as the issue body or convert it into a short\n  checklist.\n\n## Sub-Issues (Parent-Child Linking)\n\nGitHub supports proper parent-child issue relationships via the Sub-Issues REST\nAPI. Simply mentioning a parent issue number in the body text is **not\nsufficient** — it creates only a loose text reference, not a tracked\nrelationship.\n\n### Creating a sub-issue\n\n1. Create the child issue with `gh issue create` as usual.\n2. Look up the **database `id`** (not the issue `number`) of the child:\n   ```bash\n   gh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002FCHILD_NUMBER --jq '.id'\n   ```\n3. Link it to the parent:\n   ```bash\n   gh api --method POST \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\u002FPARENT_NUMBER\u002Fsub_issues \\\n     --input - \u003C\u003C\u003C '{\"sub_issue_id\": CHILD_DATABASE_ID}'\n   ```\n\n**Important:** The `sub_issue_id` field must be an **integer** (the internal\ndatabase ID), not the human-readable issue number. Using `-f sub_issue_id=N`\nsends a string and causes a 422 validation error. Always use `--input` with a\nJSON body instead.\n\n### Listing sub-issues\n\n```bash\ngh api repos\u002F{owner}\u002F{repo}\u002Fissues\u002FPARENT_NUMBER\u002Fsub_issues --jq '.[].number'\n```\n\n### Removing a sub-issue link\n\n```bash\ngh api --method DELETE \u002Frepos\u002F{owner}\u002F{repo}\u002Fissues\u002FPARENT_NUMBER\u002Fsub_issue \\\n  --input - \u003C\u003C\u003C '{\"sub_issue_id\": CHILD_DATABASE_ID}'\n```\n\n### When to use sub-issues\n\n- When breaking down a parent epic into individually trackable work items.\n- When the parent issue should show a progress summary\n  (`sub_issues_summary.total` \u002F `completed` \u002F `percent_completed`).\n- Each sub-issue can be assigned, labeled, and closed independently; closing\n  all sub-issues does **not** auto-close the parent.\n- **A parent issue must never be closed while it has open sub-issues.**\n  Either close all children first, or re-parent them before closing the parent.\n\n### Avoiding concurrent-link conflicts\n\nWhen linking multiple sub-issues in rapid succession, avoid sending all\nrequests in parallel — the API uses sequential priority positions and will\nreturn `422 Priority has already been taken`. Link them sequentially or with a\nsmall delay between calls.\n\n## Reporting Guidance\n\nIssue comments should be compact but useful.\n\n- Progress comments should mention completed work, current status, and next\n  steps.\n- Final comments should mention the shipped outcome and any noteworthy caveats.\n\n## Safety Constraints\n\n- Never fabricate issue numbers.\n- Never create an issue before the Duplicate Check ran and reported no match.\n- Never open a second issue for a goal that an open issue already tracks.\n- Never create an empty commit when there are no changes.\n- If there are no local changes in `commit` or `finish` mode, still update the\n  issue comment as needed, but report that there was nothing to commit.\n- Do not push or close issues if the relevant step fails.\n- Never close an issue that has open sub-issues. Always check for open\n  sub-issues before closing.\n\n## Output Expectations\n\nAt the end of the workflow, report:\n\n- the issue number used or created\n- the duplicate check result: which candidates were checked, or that no open\n  issue matched\n- whether a comment was added\n- whether a commit was created, including its message\n- whether knowledge persistence was run, and the hash of its commit (and that\n  it was pushed)\n- the issue number and its final state: when the issue was closed, state this\n  explicitly (e.g. \"Issue #123 closed\"); otherwise note that it remains open\n\n## Done when\n\n- [ ] The current issue is resolved via the Duplicate Check and announced by\n      number.\n- [ ] Every newly created issue carries the duplicate-check trace line, or a\n      reuse comment was posted on the existing issue.\n- [ ] Every commit references a real issue number and passed the affected area's\n      tests\u002Flint first.\n- [ ] Each completed unit is pushed to the trunk line, or a read-only scope\n      exclusion is named in the report.\n- [ ] In `commit`\u002F`finish` mode, knowledge persistence ran and its own commit was\n      pushed.\n- [ ] A parent issue was closed only after its sub-issues were listed and all\n      found closed.\n- [ ] The final report names the issue number, its state, the duplicate-check\n      result, and the commit messages used.\n",{"name":5,"license":15,"metadata":48,"description":7,"compatibility":38},{"scope":37,"category":26},"main","adef05bd2193559aced970b8591fc8182a916301","skills\u002Fissue-workflow",0,"https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf","https:\u002F\u002Fwww.spengergasse.at\u002F","2026-11-11 16:51:38",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add georgernstgraf\u002Fopencode-helpers --skill issue-workflow",{"tool":63,"command":64},"bunx","bunx skills add georgernstgraf\u002Fopencode-helpers --skill issue-workflow",{"tool":66,"command":67},"pnpm","pnpm dlx skills add georgernstgraf\u002Fopencode-helpers --skill issue-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fissue-workflow\u002FSKILL.md",true,[],[72,90,117,133,147,159],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":83,"publishedAt":43},"01M6CVKZ762FN4SW18V26P65TD","teach","Teach the user a new skill or concept, within this workspace.","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fteach\u002FSKILL.md",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000039","教师与教育","PROFESSION","适用职业",[74,84,85,86,87,88,89],"false","new","concept","user","new skill","workspace",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":43},"01M6CVKVT6ZVYN2XPESS5EGDKE","sync-upstream-skills","Re-transplant owned skills from their mattpocock upstream after a git pull, applying upstream content changes while preserving opencode-native frontmatter. Also checks for duplicate skill names and dangling cross-skill references. Use when the user says \"sync skills\", \"refresh from upstream\", \"pull matt's skills\", \"sync upstream\", \"update the transplanted skills\", or wants to bring the owned transplanted skills up to date. Do not use to add or rename a transplanted skill — that stays manual.","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fsync-upstream-skills\u002FSKILL.md",[],[97,98,99,100,101,38,102,103,104,105,106,107,108,109,110,111,112,113,87,114,115,116],"sync upstream","sync upstream skills","upstream","sync","refresh","references","pull","duplicate skill","duplicate","frontmatter","native","changes","up","when","re","for","bring","content","use","git",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":43},"01M6CVKNEPEY1WA7E5FWQ85NJW","repograde","Grade student repositories with optional date filtering in single-repo or bulk mode. Use when the user says \"repograde\", \"grade the repos\", \"grade this repo since \u003Cdate>\", \"bewerte die Abgaben\", \"korrigiere die Repos\", or asks for a repo grading run over a class folder or a single student repository. Do not use for project grading with issues and PRs (use projectgrade) or for knowledge-check exams (use knowledge-assessment).","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Frepograde\u002FSKILL.md",[],[119,38,29,124,125,126,127,128,129,130,131,132],"repositories","single","student","mode","bulk","education","execution","repo","filtering",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":43},"01M6CVKF9MVFPHBH3W2D5ETEB6","projectgrade","Grade student project repositories based on Git commits, GitHub Issues, and Pull Requests. Use when the user says \"projectgrade\", \"grade the project\", \"bewerte das Projekt\", \"Projektarbeit benoten\", or asks for a holistic grading of a collaborative repository from inside it, based on commits, issues, reviews and PRs. Do not use for per-lesson assignments (use repograde) or for knowledge-check exams (use knowledge-assessment).","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fprojectgrade\u002FSKILL.md",[],[135,140,141,124,142,126,143,129,116,37,38,144,130,145,146,103],"github issues","requests","git commits","project","pull requests","issues","commits",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":43},"01M6CVKA8J284DZTBE7QRN45SG","lehrplan","Richtet österreichische HTL-Unterrichts-Repositorien ein und pflegt sie — drei Kernaufgaben: das gesetzliche Lehrplan-Material eines Ausbildungszweigs (z. B. WII, WIT, KIF) aus dem RIS beschaffen inklusive jährlichem Novellen-Check, den Lehrplan eines konkreten Gegenstands aus dem Gesetz extrahieren (mit Erläuterung pro Lernziel: was der Inhalt tatsächlich IST, plus praktische Anwendungen), und Semesterpläne interaktiv entwerfen. Use when der Nutzer 'Lehrplan', 'Unterrichtsvorbereitung prüfen', 'Lehrplan auf Novellen prüfen', 'RIS sync', 'Gesetzesmaterial holen', 'Lehrplan extrahieren', 'Jahrespläne neu ziehen', 'Erläuterungen ergänzen', 'Semesterplan erstellen\u002Füberarbeiten' oder 'Einheiten erstellen' sagt, oder wenn in einem Repo gearbeitet wird, das der lehrplan\u002F-Konvention folgt. Do not use for Prepared Lessons (create-lesson), Aufgaben im Kohortenordner (homework) oder Wissensüberprüfungen (knowledge-exam).","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Flehrplan\u002FSKILL.md",[],[149,154,155,156,100,157,129,131,38,158],"material","pro","curriculum","check","drei",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":168,"publishedAt":43},"01M6CVK6QMR16MSMS2MRG097GV","knowledge-persistence","Persist session context into the structured docs\u002Fai knowledge files (OKF bundle; committed and pushed at the end). Use when the user says \"remember\", \"merk dir das\", \"save context\", \"persist knowledge\" or \"update knowledge file\", at a session checkpoint, or when an observation in this session contradicts docs\u002Fai\u002F or AGENTS.md. Do not use for reading the knowledge files at session start — that is plain bootstrapping.","https:\u002F\u002Fgithub.com\u002Fgeorgernstgraf\u002Fopencode-helpers\u002Fblob\u002Fmain\u002Fskills\u002Fknowledge-persistence\u002FSKILL.md",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",[169,170,171,172,173,174,175,38,176,26,177,178,179],"knowledge persistence","knowledge","persistence","persist","structured","context","docs","documentation","files","session context","session"]