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/github-app-session-env
tools
VerifiedTrustedCommunity
Manually reproduce what the github-app plugin's SessionStart hook does to make a GitHub App installation token usable in the current session — materialize the PEM, generate the token, isolate GH_CONFIG_DIR, write the runtime env file, and wire CLAUDE_ENV_FILE so every Bash call sees GH_TOKEN/GITHUB_TOKEN. Use when the hook did not run, the token is missing from the environment, or a shell/teammate needs the token wired up by hand. <example>GH_TOKEN isn't set even though github-app is configured</example> <example>the github-app SessionStart hook didn't run, set up the token manually</example> <example>wire the github app token into CLAUDE_ENV_FILE</example> <example>gh keeps falling back to the wrong account, isolate GH_CONFIG_DIR</example>
3SKILL.mdUpdated Jun 9, 2026
nsheaps/github-app-git-identity
tools
VerifiedTrustedCommunity
Manually configure the GitHub App bot git identity the way the github-app plugin's SessionStart hook does — resolve the app slug and bot user ID, build the <slug>[bot] name and noreply email, set GIT_AUTHOR_*/GIT_COMMITTER_* env vars, and write an isolated GIT_CONFIG_GLOBAL with the gh auth git-credential helper. Use when commits are attributed to the wrong account, "Author identity unknown" appears, or git identity must be set up by hand. <example>my commits are showing up as the handler, not the bot</example> <example>git says Author identity unknown after the github-app hook ran</example> <example>configure the github app bot git identity manually</example> <example>set up the gh credential helper for git push</example>
3SKILL.mdUpdated Jun 9, 2026
nsheaps/spec-management
tools
VerifiedTrustedCommunity
Manages spec files for requirements capture and validation
3SKILL.mdUpdated Jun 7, 2026
nsheaps/plugins/bash-command-rejection/skills/bash-chaining-alternatives
tools
VerifiedTrustedCommunity
# Bash Chaining Alternatives This skill teaches you how to work around the bash command chaining restriction enforced by this plugin. ## Why Chaining is Blocked The `bash-command-rejection` plugin blocks these operators: | Operator | Name | Why Blocked | | -------- | ---------- | ----------------------------------------------------------------------------------- | | `&&` | AND chain | Runs cmd2 only if cmd1 su
3SKILL.mdUpdated Jun 7, 2026