nsheaps/incident-tracker
plugins/agentic-behavior/skills/incident-tracker/SKILL.md
Use this skill when the user wants to log a behavioral incident, document a correction in a structured incident report, or maintain learned rules with footnote references back to source incidents. Trigger phrases include "log an incident", "log this incident", "track an incident", "behavioral incident", "document this correction as an incident", "create incident report", "file an incident", or when the user explicitly asks for a structured incident record with severity classification and rule derivation.
$ install --global
skillsauthnpx skillsauth add nsheaps/ai-mktpl incident-trackerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 6, 2026, 7:09 AM301.1s2 files scanned
SKILL.md
- name:
- incident-tracker
- description:
- >-
- argument-hint:
- <short description of the behavioral correction>
- user-invocable:
- true
- allowed-tools:
- Read, Write, Edit, Glob, Grep, Bash(mkdir:*), Bash(ls:*), Bash(date:*), Bash(pwd:*), Bash(git status:*), Bash(git rev-parse:*), AskUserQuestion
incident-tracker
Track behavioral incidents with structured incident files, derive reusable rules, and maintain footnote references between rules and the incidents that produced them.
When to use this skill vs. correct-behavior
Both skills handle behavior corrections. They are complementary:
agentic-behavior:correct-behavior— broader corrective workflow (reflect, scope, search, derive rule, edit rules/skills/plugins/hooks). Use when the goal is fixing the behavior across the system.agentic-behavior:incident-tracker— structured incident log format (severity, tags, footnoted rules). Use when the goal is producing a durable audit trail of what happened, in addition to or instead of fixing the behavior in code.
When in doubt, prefer correct-behavior for active fixes and add an incident
record via this skill if the handler asks for one explicitly or if the
incident is significant enough to deserve a permanent record.
Workflow
When given a behavioral correction:
1. Stop the current task
Do not continue with the previous task. Acknowledge the correction first.
2. Gather context
Capture, in your own words:
- What did the user ask you to do?
- What did you actually do?
- What did the user say was wrong?
- Quote the user's exact phrasing if available — their words matter.
3. Discover the workspace rules file
The rules file is where derived rules get appended (with footnote references back to the incident file). Discover it in this order:
- If
CLAUDE.mdexists at the repo root, use that. - Else if
AGENTS.mdexists at the repo root, use that. - Else if a settings entry
agentic-behavior.rulesFileis configured in~/.claude/plugins.settings.yamlor project-level.claude/plugins.settings.yaml, use that. - Else create
AGENTS.mdat the repo root and use that. Tell the user you created it so they aren't surprised.
Do not silently overwrite an existing rules file you didn't discover — ask the handler before clobbering anything unexpected.
4. Create the incident file
Place it under incidents/behavioral/ at the repo root. Naming pattern:
YYYY-MM-DD--short-description.md
Use the structured template at
references/incident-template.md — copy it as the starting point, then fill
in every section. Do not leave placeholder text in the file.
5. Append a derived rule to the rules file
Under a ## Learned Behaviors section in the rules file (create the section
if it doesn't exist), add the rule using this format:
N. **<Rule title>** — <Rule description>. [^rule-N]
[^rule-N]: [YYYY-MM-DD -- Incident Title](incidents/behavioral/YYYY-MM-DD--short-description.md)
Number rules sequentially within the file. Footnote IDs (^rule-N) must be
unique within the file. The footnote definition can live at the bottom of
the file with the other footnote definitions.
6. Confirm with the user
Before resuming any other work, confirm:
- Where the incident file lives (path)
- The derived rule (text and number)
- Which rules file you wrote to
- That the user agrees with your characterization
If the user disagrees, edit the incident file and rule before continuing.
Severity Levels
| Level | When to Use |
| -------- | ------------------------------------------------------ |
| low | Minor inconvenience, no lasting impact |
| medium | Affected user workflow, required correction |
| high | Data loss, security issue, or significant trust impact |
Pick the most accurate severity based on impact, not on how badly you feel about the mistake. If the user explicitly classifies it differently, use their classification.
Notes
- Every incident must derive at least one rule. If you can't articulate a rule, the incident isn't done — keep working with the user until the rule is clear.
- Rules should be actionable and specific. "Be more careful" is not a
rule. "Always confirm before running
git push --force" is a rule. - Footnote references link rules back to incidents. Future maintainers (and future you) need to know why a rule exists.
- Never skip the confirmation step. A mischaracterized incident is worse than no incident — it teaches the wrong lesson.
References
references/incident-template.md— structured template for incident filesagentic-behavior:correct-behavior— broader behavior-correction skill for fixing the behavior in rules/skills/plugins/hooks
Related Skills
nsheaps/claude-code
tools
VerifiedTrustedCommunity
Reference material for Claude Code internals — the on-disk layout under ~/.claude and project-scope .claude, the plugin cache, session-env propagation, and the full hook lifecycle. Auto-recall when working on Claude-Code-related tasks: writing or debugging hooks, authoring plugins, inspecting session state, troubleshooting why an env var is or isn't visible to a Bash tool call, or when paths under ~/.claude or ~/.claude/plugins/ come up.
3SKILL.mdUpdated May 6, 2026
nsheaps/github-app-token
development
VerifiedTrustedCommunity
Manage GitHub App installation tokens in Claude Code sessions. Use when tokens expire, auth errors occur in long-running sessions, or when setting up GitHub App credentials for agent teams. <example>my github token expired</example> <example>refresh the github app token</example> <example>check token status</example> <example>set up github app authentication for this session</example>
3SKILL.mdUpdated Apr 22, 2026
nsheaps/auto-config
tools
VerifiedTrustedCommunity
Auto-detect project formatting tools and configure edit-utils settings
3SKILL.mdUpdated Apr 22, 2026
nsheaps/op
tools
VerifiedTrustedCommunity
Use this skill when the user asks about 1Password, secrets management, retrieving credentials, using op CLI, service accounts, secret references, vault operations, or any task involving the 1Password CLI (op). Also use when needing to inject secrets into environment variables, read passwords or API keys from 1Password, or manage 1Password items from the command line.
3SKILL.mdUpdated Apr 22, 2026