Skills

Four skills, each with the reason I built it.

• product-sparring challenges a plan, PRD, metric or go/no-go claim as a peer product lead and gives the strongest counter.
  Why I built itOn Parapet I ran several rounds of prompt fixes before I set a kill test, so I built a skill that asks for the test first.

  • None of those rounds improved supplier names or revision tags.
  • A weak plan found before the build costs a conversation. Found after, it costs a sprint.
  • The skill gives a position, the strongest counter and a test that could change the decision.
  • It changes its view only when you show it something new, and names what changed it.
• recipient-panel has AI stand-ins for the people who will receive your work read it before you send it.
  Why I built itAI stand-ins for this site's readers found a step I had missed before any real reader hit it.

  • Each reader sees the draft cold and reports where they stop and what they object to.
  • I fix first the objections that two or more readers raise.
  • The result is a simulation: it shows where a draft loses a reader and says nothing about demand.
  • You name the roles.
  • Claude starts one subagent per role. A subagent is a separate AI helper. At most four run at a time.
  • Each reader reports the line where they stop reading, their objections with the line each rests on, one fix each, what would make them say yes and a score from 1 to 10.
  • Claude merges the reports and tightens the draft.
  • Presets for the readers:
    • Stakeholder doc: the sponsor who decides, the engineering lead, design, finance or legal, the team that does the work.
    • CV or application: a recruiter screen, HR, the PMs who interview you and the hiring manager. The applicant-tracking check stays a separate formatting check.
    • Product, feature or onboarding: three personas from your exact target segment plus one skeptic (four in total, one batch), each with a job to do, a context and a reason to quit.
    • Public page or post: the target reader, a skeptic, a copy editor and a voice check.
  • You check every fact a reader states.
  • Download the zip or see the skill on GitHub.
• distill-to-gh-issue turns one finding, bug report or feedback row into a draft issue that you review before filing.
  Why I built itI used to write every roadmap, spec and issue by hand; now I describe the feature or bug and Claude writes the issue an engineer can start on.

  • Claude gathers the context first: it reads the live code and data before it trusts a doc.
  • It then asks me what the item leaves open, one question at a time, each with a proposed default.
  • The issue states the user problem and the expected behaviour, points to the relevant code and carries a spec where the work needs one.
  • It lists the open decisions for you to settle. You review the draft before it is filed.
  • In my own setup it also attaches prototypes and artifacts. The public skill stops at the issue.
  • A stop list keeps it out of repos it must never file into.
  • Claude Code only: it needs the GitHub command line (gh) and a local copy of the repository.
• voice drafts emails and posts in your voice from rules extracted from your own sent writing.
  Why I built itI rewrote most AI drafts, so I turned about 25 of my sent emails into writing rules.

  • Example rules: lead with the point, numbers over adjectives, no em-dashes.
  • The skill loads the rules, drafts and then checks the draft against them.
  • I now edit drafts where I used to rewrite them.
  • Use writing you own. Check your employer's policy before you paste work email into an AI tool.
  • It carries a self-check and a slop hook (a small script that runs on its own and flags weak wording) for what the rules miss.