issue-log

Records deduplicated, redacted runtime deviations from notion-dev workflows into a persistent Markdown issue log.

Updated Jul 19, 2026
One-click install
npx skills add https://github.com/forhas/pure-dev --skill issue-log-forhas
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: issue-log
Source: https://github.com/forhas/pure-dev/tree/main/plugins/notion-dev/skills/issue-log
Command: npx skills add https://github.com/forhas/pure-dev --skill issue-log-forhas

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Runtime degradations in the notion-dev plugin — MCP errors, missing or wrongly typed Notion database properties, retries, fallbacks, and aborts — vanish without a trace, leaving the plugin author unable to diagnose failures across client installations. This Skill captures each deviation as a structured, deduplicated, redacted entry in a durable log file. ## Core Features & Use Cases - Signature-based deduplication: Each condition gets a <class>:<subject> signature; repeats update only Last seen and Occurrences instead of appending new entries. - Structural redaction: A per-field whitelist guarantees no ticket titles, bodies, ids, URLs, or personal data ever reach the log, so clients can forward it safely. - Enumerated signature registry: references/signatures.md defines known degradation points so common cases group under stable names instead of fragmenting. - Use Case: During a /notion-dev:ticket run, the parentTaskProperty is absent from the live Notion database; the skill writes a missing-property:parentTaskProperty entry to $REPO_ROOT/.claude/notion-dev/notion-dev-issues.md without interrupting the run. ## Quick Start Ask the agent to record the unexpected condition it just hit by writing an entry to the notion-dev issue log following the signature grammar and redaction rules.

Frequently Asked Questions about issue-log

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I log a runtime error from a Notion MCP workflow?

Write an entry at the moment of the deviation using a `<class>:<subject>` signature such as `mcp-error:notion-fetch-object-not-found`. The entry goes into `$REPO_ROOT/.claude/notion-dev/notion-dev-issues.md` with Kind, timestamps, and redacted Observed fields.

What is the issue-log signature grammar in notion-dev?

Signatures follow `<class>:<subject>` with no spaces. Classes come from a closed list like `missing-property`, `wrong-type`, `mcp-error`, and `fallback`; subjects are either kebab-case fixed names or borrowed identifiers reproduced verbatim, such as camelCase config keys.

Does the issue log contain ticket content or personal data?

No. Redaction is structural via a per-field whitelist: ticket titles, bodies, PR content, user ids, emails, full database or page ids, paths, and URLs are forbidden without exception. Only identifiers like config keys and truncated database suffixes are permitted.

Why are some empty results never logged as issues?

The plugin treats routine absences — like tickets without an epic or an unset parent property — as normal operation, and logging them would bury real entries. The SKILL.md file enumerates exactly which conditions are routine and must never be recorded.

What happens if writing the issue log itself fails?

Nothing — the log is best-effort. A failure to create, read, or write the file never fails the run, and a failure of the log is never itself logged, so the skill never recurses.

How does deduplication work for repeated runtime issues?

The signature is the identity: the writer searches for an exact `## <signature>` heading and, if found, only updates `Last seen` and increments `Occurrences`. A materially different condition gets a new signature with a kebab-case discriminator, never a second section under the same heading.