From cogni-help
File and track GitHub issues (bugs, feature requests, change requests, questions) against insight-wave ecosystem plugins using browser automation (claude-in-chrome). Guides users through a short consultation to capture the right details, resolves the target plugin's repository automatically, drafts issues from templates, creates them via browser automation on github.com, and tracks them locally. Use this skill whenever the user wants to report a bug, request a feature, file a change request, ask a question about a plugin, list filed issues, or check issue status. Also trigger when the user says things like "this plugin is broken", "I found a problem with {plugin}", "can we get X added to {plugin}", "{plugin} doesn't work", "open an issue", "something is wrong with {plugin}", "das Plugin funktioniert nicht", "Fehler in {plugin}", "set up GitHub issues", "configure issue filing", "ich kann kein Issue erstellen", or any complaint/suggestion about a specific plugin — even if they don't use the word "issue".
How this skill is triggered — by the user, by Claude, or both
Slash command
/cogni-help:cogni-issuesThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Manage the lifecycle of GitHub issues for insight-wave ecosystem plugins: consult with the
Manage the lifecycle of GitHub issues for insight-wave ecosystem plugins: consult with the user to understand the problem clearly, resolve which repository the plugin belongs to, draft issues from templates, create them via browser cobrowsing on github.com, and track them locally.
All GitHub operations use browser automation via claude-in-chrome — navigating to
github.com, reading pages, and filling forms directly in the user's Chrome browser.
The user must have the Claude-in-Chrome extension installed and be logged into GitHub
in Chrome. No Personal Access Tokens or gh CLI needed.
Important: Do NOT use gh CLI commands — all GitHub operations go through
browser automation. The gh CLI is not required and should not be invoked.
Read the workspace language from .workspace-config.json in the workspace root
(language field — "en" or "de") as the default interaction language. If the
user's message is in a different language, prefer the user's language (message
detection overrides the workspace setting — someone writing in German wants a
German response even if the workspace is set to English).
If .workspace-config.json is missing, fall back to detecting the user's language
from their message. If still unclear, default to English.
Conduct the entire interaction in the chosen language — consultation questions, acknowledgments, draft body, and confirmation prompts.
Exceptions where English stays:
[Bug], [Feature], [Change], [Question] — conventions for
GitHub label automation and cross-team readability.The skill scripts live at ${CLAUDE_PLUGIN_ROOT}/skills/cogni-issues/scripts/.
CLAUDE_PLUGIN_ROOT points to the cogni-help plugin directory. If you can't
find the scripts, tell the user — don't guess paths.
All GitHub operations use claude-in-chrome tools:
| Operation | Tools | URL Pattern |
|---|---|---|
| Create issue | tabs_create_mcp, navigate, read_page, computer, form_input | github.com/{owner}/{repo}/issues/new |
| List issues | tabs_create_mcp, navigate, read_page | github.com/{owner}/{repo}/issues |
| Search issues | tabs_create_mcp, navigate, read_page | github.com/{owner}/{repo}/issues?q={keywords} |
| Get issue | tabs_create_mcp, navigate, read_page | github.com/{owner}/{repo}/issues/{number} |
The claude-in-chrome tools are declared in the skill's allowed-tools. Always open a
new tab via tabs_create_mcp before navigating — never hijack the user's active tab.
| Mode | Triggers | Action |
|---|---|---|
| setup | claude-in-chrome not available or user not logged into GitHub, "set up issues", "ich kann kein Issue erstellen" | Verify claude-in-chrome, guide user to log into GitHub in Chrome |
| create | reporting bugs, requesting features, filing change requests, asking plugin questions | Consult, resolve, draft, confirm, create, log |
| list | "my issues", "show issues", "what have I filed" | Read local state, display grouped by plugin |
| status | "check issue #N", "any updates on my issue" | Fetch from GitHub via browser, update local record |
| browse | "open issue", "show in browser" | Navigate to the GitHub issue in the browser |
Default to list when intent is unclear.
Before any GitHub operation, verify claude-in-chrome availability and GitHub login:
mcp__claude-in-chrome__tabs_context_mcp to check browser availabilitymcp__claude-in-chrome__tabs_create_mcphttps://github.com with mcp__claude-in-chrome__navigatemcp__claude-in-chrome__read_page to check the pageclaude-in-chrome uses the user's Chrome browser directly — the user can see all actions and is already authenticated via their Chrome session.
Try mcp__claude-in-chrome__tabs_context_mcp. If the tool is not available,
inform the user that the Claude-in-Chrome extension is required:
This skill requires the Claude-in-Chrome browser extension. Please install it in Chrome and make sure it's active, then try again.
Open a new tab with tabs_create_mcp, navigate to https://github.com, and use
read_page to check the page. Look for signs of a logged-in session (profile
avatar, user menu) vs "Sign in" link.
If the page shows the user is already logged in, tell them they're all set and offer to file an issue.
Ask the user to log into GitHub in their Chrome browser:
You're not logged into GitHub in Chrome. Please sign in at github.com in your browser, then let me know when you're ready.
Since claude-in-chrome uses the user's actual Chrome session, they handle authentication directly — including 2FA and SSO. No credential handling needed.
Re-check with read_page on https://github.com. If the page shows a
logged-in state, confirm success.
If the user came here because they were trying to file an issue, continue with the create flow.
Run once before any operation (idempotent):
bash "${SKILL_DIR}/scripts/issue-store.sh" init "${working_dir}"
working_dir defaults to the current working directory. State lives in {working_dir}/cogni-issues/.
First, verify browser access and GitHub login (see Prerequisites). If not ready, enter setup mode and return here once the user is logged in.
If the user hasn't named a specific plugin, ask which plugin this is about. Then resolve it:
bash "${SKILL_DIR}/scripts/resolve-plugin.sh" "<plugin_name>"
Handle: "ambiguous": true -> present matches and ask; "error" -> list available plugins
and ask; success -> extract owner_repo, version, marketplace.
Before investing in consultation and drafting, search for existing issues via the browser:
https://github.com/{owner}/{repo}/issues?q=is%3Aopen+{url_encoded_keywords}
using 2-3 keywords from the user's complaintread_page to read the search results pageIf you find a likely match, show it to the user and ask: "This looks similar — is it the same problem, or something different?" If it's the same, link them to the existing issue instead of creating a duplicate.
Infer the type from context (match intent across languages, not specific keywords):
| Type | Signals |
|---|---|
bug | something is broken, errors, crashes, doesn't work, fails, wrong output |
feature | add something new, would be nice, request, support for |
change-request | change existing behavior, modify, adjust, different behavior wanted |
question | how to, why does, confused, wondering |
If genuinely ambiguous, ask. Otherwise trust your judgment.
When the complaint involves config changes or unexpected output, do a quick sanity
check before classifying: scan the plugin's data model or config schema to verify the
user's premise. For example, if a user says "I updated the logo in the config but it
still shows the old one," check whether the config actually has a logo field. The user's
mental model of how the plugin works may not match reality — what looks like a bug might
be a feature gap, a wrong-config-file situation, or a misunderstanding of which component
owns that functionality. A 30-second Grep or Read of the relevant schema can save
everyone from filing a misleading issue.
Help the user articulate what they need. Many users know something is wrong but haven't organized their thoughts. Your job is to be a helpful interviewer, not a form.
First, mine the conversation for existing evidence. Check recent tool outputs for error messages, stack traces, or failed commands. Look at what the user was working on — the conversation often contains the exact workflow that triggered the problem. If you see a traceback from earlier, use it — don't ask "did you see an error?"
If you did a premise check (above) and found a mismatch, incorporate that finding into your consultation. Instead of generic "what happened?" questions, tell the user what you found and ask targeted questions to resolve the gap — e.g., "I checked the portfolio config schema and it doesn't have a logo field. Where exactly are you seeing the logo, and which file did you edit?"
Then ask only what's missing — 2-3 questions max, batched in one turn:
Skip consultation entirely if the user (or conversation context) already provides enough detail. Acknowledge it: "You've given me a clear picture — let me draft this up."
Read the template from references/issue-templates.md for the determined type.
Fill in from conversation + resolver output. Omit sections you can't fill meaningfully — shorter with real content beats complete with placeholders.
Auto-detect environment:
uname -s && uname -r && node -v 2>/dev/null
Write in the user's language (except title prefixes and technical terms).
Transform vague input into precise descriptions. This is the core value you add:
| User says | You write |
|---|---|
| "it doesn't work" | "The skill exits with a non-zero status code without producing output when invoked with default arguments" |
| "it's slow" | "Rendering takes 45+ seconds for a 3-station brief, compared to ~15s previously — a 3x regression" |
| "the output looks wrong" | "Generated propositions show placeholder text ('Lorem ipsum') instead of configured descriptions" |
| "es funktioniert nicht mehr" | "Das Skill bricht beim Aufruf mit einem TypeError ab und erzeugt keine Ausgabe" |
The pattern: replace subjective impressions with observable facts, measurable quantities, or specific error details.
Add a root cause hypothesis when you can. If the error or context suggests a likely
cause, include it in "Additional context" — e.g., "The TypeError on narrative_arc
suggests a property was renamed or removed in the latest update, possibly a breaking
change in the data model." This helps maintainers triage faster. Only do this when the
evidence supports it — don't speculate wildly.
Show the complete draft (title + body) and ask for approval in the user's language. Never create without explicit confirmation. If the user wants changes, apply them and show the updated draft.
Open a new tab with tabs_create_mcp and navigate to https://github.com/{owner}/{repo}/issues/new:
read_page to verify the "New Issue" form has loaded — look for the
title input field and body textareaform_input to enter the title in the title fieldform_input to enter the full drafted body in the body textareacomputer to click the "Labels" gear icon in the sidebar,
then use form_input to type the label name and computer to click the matching
label. Label mapping is in references/issue-templates.md.
If the interaction fails, skip it — the issue can be created without labels.computer to click the "Submit new issue" buttonread_page to read the new issue page. Extract github_number (from the
URL or heading) and github_urlIf creation fails entirely, show the error and suggest next steps — don't retry blindly.
ID_JSON=$(bash "${SKILL_DIR}/scripts/issue-store.sh" gen-id)
Then pipe the issue record as JSON via stdin:
echo '<json_record>' | bash "${SKILL_DIR}/scripts/issue-store.sh" add "${working_dir}"
The record includes: id, plugin, marketplace, repository, github_number,
github_url, type, title, status ("open"), created_at, updated_at.
Parse github_number and github_url from the browser redirect URL after submission.
Return the GitHub issue URL and local issue ID.
bash "${SKILL_DIR}/scripts/issue-store.sh" read "${working_dir}"
Display issues grouped by plugin: title, type badge, GitHub number + URL, status, date. If empty, suggest the create flow.
owner, repo, and github_numbertabs_create_mcp and navigate to https://github.com/{owner}/{repo}/issues/{github_number}read_page to read the issue page — extract state (open/closed), labels,
latest comments, and last update timestampupdate-statusOpen a new tab with tabs_create_mcp and navigate to the GitHub issue URL using
navigate. The URL follows the pattern: https://github.com/<owner>/<repo>/issues/<number>
If claude-in-chrome is unavailable, provide the URL as text instead.
read_page to inspect the current structure and adapt element references.scripts/setup-gh.sh — Platform info script. Returns JSON with OS detection. The primary readiness check is done via claude-in-chrome tools (tabs_context_mcp + read_page).scripts/resolve-plugin.sh — Resolves a plugin name to its GitHub repo by scanning marketplace.json files. All insight-wave plugins resolve to the monorepo cogni-work/insight-wave.scripts/issue-store.sh — Local JSON state management (init, gen-id, add, read, update-status). The add command reads JSON from stdin for safety.references/issue-templates.md — Templates for the four issue types with auto-fill placeholders and label mappingnpx claudepluginhub cogni-work/insight-wave --plugin cogni-helpGenerates structured issue reports for GitHub/GitLab repos with code references, media attachments, and session context. Works for bugs, features, and improvements.
Investigates and resolves GitHub issues with systematic triage, root cause analysis, test-driven fixes, and pull request management. Use when given an issue ID or URL.
Manages full GitHub issue lifecycle: create with conventional commit titles, sub-issues, cross-repo links, edit/view/list, dump trees to markdown/YAML, push from files, comment/label/close.