From haowjy-creative-writing-skills
Logging and referencing writing issues — craft problems, tics, inconsistencies, and structural concerns found during analysis, critique, or review. Use when an agent identifies something worth tracking beyond a single critique report: repeated tics across chapters, inconsistencies that affect multiple scenes, structural problems that need the author's attention, or patterns that should be fixed in revision.
npx claudepluginhub haowjy/creative-writing-skills --plugin creative-writing-skillsThis skill uses the workspace's default tool permissions.
Issues are writing problems worth tracking beyond a single critique report. A critic finding a pacing problem in one draft produces a critique finding. A critic noticing the same pacing problem across three chapters produces an issue — it's a pattern that won't be fixed by revising one scene.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Issues are writing problems worth tracking beyond a single critique report. A critic finding a pacing problem in one draft produces a critique finding. A critic noticing the same pacing problem across three chapters produces an issue — it's a pattern that won't be fixed by revising one scene.
Log when the problem is:
Don't log every critique finding as an issue. A scene that runs long is a critique note. A pattern of scenes running long in the middle third of every chapter is an issue.
One file per issue in the issues directory. Issues persist across work items because they're project-level concerns, not scoped to a single draft or revision cycle.
Each issue file should contain enough for someone encountering it later to understand the problem without re-reading every chapter:
Before creating a new issue, check what already exists in the issues directory. The same problem discovered independently by different agents (a critic and a style-creator, say) should be one issue with combined evidence, not two separate files saying the same thing.
If an existing issue covers the same ground, update it with new evidence rather than creating a duplicate.
When a critique report or style analysis identifies something that's already a tracked issue, reference it rather than re-describing it: "this is another instance of the emotional inconsistency issue (see issues/emotional-inconsistency.md)." This connects individual findings to the larger pattern.
When an issue has been addressed — the tics edited out, the inconsistency resolved, the structural problem fixed — the file stays but gets marked as resolved with a note on what changed. Keeping resolved issues provides a record of what was caught and fixed, which helps calibrate future analysis.