Cc sample triage bug

Skill RobertIonutF/codecurrent-studio-sample/skills/cc-sample-triage-bug

Evidence-aware AI workflow sample for software bug triage by CodeCurrent Studio

Install

npx -y skills add RobertIonutF/codecurrent-studio-sample --skill cc-sample-triage-bug

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

15 days oldThe repository was created 15 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Turn a vague software bug report into an evidence-aware triage report and minimal reproduction plan. Use when symptoms are incomplete, intermittent, or not yet tied to a proven root cause, and the user needs the next diagnostic step rather than an invented fix.

SKILL.md

2.8 KB, as published. Nobody here has run it

Sample Bug Triage

Goal

Turn an incomplete report into a reviewable triage artifact that another developer can reproduce, challenge, and continue.

Inputs

Inspect the conversation and any accessible project evidence for:

observed behavior and expected behavior;
environment, version, route, account/role, and input conditions;
frequency, timing, first known occurrence, and recent changes;
logs, errors, screenshots, traces, monitoring, and test results;
business impact and any safety, data, or security risk.

Ask only for missing facts that would materially change the reproduction path, urgency, or safety posture. If the user cannot provide them, continue with labeled gaps.

Workflow

Restate the symptom using only observed facts. Do not smuggle a diagnosis into the problem statement.
Build three separate lists: Verified facts, Assumptions, and Hypotheses.
Define the smallest reproducible boundary: entry point, preconditions, input, action, expected result, observed result, and frequency.
Identify one comparison that could disprove at least one leading hypothesis: known-good version, environment, role, input class, route, or timing window.
Select the next diagnostic step with the highest information gain and lowest risk. State what each possible result would mean.
Mark the current disposition as one of: needs evidence, reproduction ready, reproduced, or blocked.
Stop before proposing a code change unless evidence supports a bounded root-cause claim. When a fix is requested without that evidence, explain the smallest missing proof.

Output contract

Use the headings and fields in ../../references/bug-report-template.md.

The final artifact must include:

observed and expected behavior;
verified facts, assumptions, and hypotheses;
a numbered reproduction attempt;
the next discriminating diagnostic step;
safety/impact notes;
current disposition and evidence gaps.

Safety and honesty

Never claim a command, test, log query, deployment, or reproduction was run unless it was actually run and its result is available.
Do not invent repository structure, production behavior, stakeholder decisions, dates, or error messages.
Do not execute destructive, production, security-sensitive, billing, or external-state actions without explicit authorization.
Respect the assistant's existing workspace permissions and safety controls.
When evidence conflicts, preserve the conflict and lower confidence.