patterninc/clarity--ticket-writer
.agents/skills/clarity--ticket-writer/SKILL.md
Collaborates with a product owner, TPM, or engineer to refine vague requests into high-quality work tickets optimized for agent one-shot execution. Use when writing tickets, refining requirements, reviewing feature requests, or when a stakeholder submits a new task. Do not use when debugging an existing issue (use autonomy--sre-agent) or when auditing codebase readiness (use legibility--auditor).
$ install --global
skillsauthnpx skillsauth add patterninc/code-mint clarity--ticket-writerInstall 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: Apr 16, 2026, 7:17 PM22.0s2 files scanned
SKILL.md
- name:
- clarity--ticket-writer
- description:
- Collaborates with a product owner, TPM, or engineer to refine vague requests into high-quality work tickets optimized for agent one-shot execution. Use when writing tickets, refining requirements, reviewing feature requests, or when a stakeholder submits a new task. Do not use when debugging an existing issue (use autonomy--sre-agent) or when auditing codebase readiness (use legibility--auditor).
Ticket Writer
Collaborate with a product owner, TPM, or engineer to define work tickets that an agent can execute reliably. Vague input produces vague output — this skill ensures tickets are precise enough for autonomous completion.
Core Principles
Proportional Rigor: Adapt strictness based on request complexity. Complex features require aggressive pushback on edge cases. Trivial requests require zero pushback.
Extend Before Creating: Prefer extending existing code over adding new files. Check AGENTS.md guidance before finalizing file placement.
Simplify for the PM: Push back on requirements, tradeoffs, and scope, but abstract technical details away from the product manager.
Step 1: Triage
When the stakeholder makes a request, silently assess which tier it falls into before responding.
- Tier 1 — Trivial / Cosmetic: Typos, simple text changes, color tweaks, replacing static images, simple CSS fixes.
- Tier 2 — Standard Bug / Enhancement: Existing feature modifications, fixing broken logic, adding a data field to an existing form.
- Tier 3 — Complex Feature: New user flows, third-party integrations, new database entities, complex state changes.
Step 2: Evaluate and Push Back
Tier 1 — The Express Lane
Do NOT ask about edge cases, loading states, error handling, or BDD scenarios.
Verify only three things:
- Where is it? (Page/Component)
- What is it currently?
- What should it be?
Use codebase knowledge to quickly locate the file. Example: "I see 'Enterprize' spelled wrong in pricing_tier.tsx. Should I draft the ticket to change it to 'Enterprise', or is there another typo?"
Tier 2 and Tier 3 — Rigorous Evaluation
Silently evaluate against this checklist. If any item applies, push back:
- Happy Path and Edge Cases: Are the exact user actions defined? What happens if the user does something unexpected?
- Error Handling: What happens if the API fails or validation fails? What is the exact error message?
- State Management: Are loading states or empty states defined?
- Codebase Conflicts: Does this contradict existing logic? Would it violate dependency direction or duplicate logic? Translate conflicts into product questions.
Anti-Pedantry Rule: Never ask a question if you can reasonably assume the answer based on standard UI/UX conventions or codebase knowledge. State your assumption in the ticket for stakeholder approval.
Step 3: Transition to Ticket
Tier 1: Transition immediately once you know the location and the fix.
Tier 2 and 3: Transition ONLY when:
- The core user journey is clear.
- Edge cases and error states are defined (if applicable).
- No unaddressed codebase conflicts found.
- The stakeholder has answered pushback questions.
Wait for stakeholder confirmation before drafting.
Step 4: Write the Ticket
Use Format A for Tier 1, Format B for Tier 2 and 3. Both formats are in references/ticket-formats.md.
For every ticket:
- Include the Complexity Tier classification
- Specify Target File(s) based on codebase knowledge
- State any assumptions made under the Anti-Pedantry Rule
Detailed Formats
See references/ticket-formats.md for Format A (Trivial) and Format B (Standard/Complex) templates with examples.
Related Skills
patterninc/meta--skill-creator
development
VerifiedTrustedCommunity
Best practices and template for creating new agent skills in the code-mint framework. Use when creating a new skill, authoring SKILL.md files, or structuring skill directories. Do not use when editing an existing skill's logic (edit directly instead) or when creating AGENTS.md files (use legibility--enhancer).
55SKILL.mdUpdated Apr 16, 2026
patterninc/meta--onboarding
development
VerifiedTrustedCommunity
Step-by-step playbook that transforms a repository for AI-first development. It scopes the repository, runs read-only audits, maintains an outcome-driven checklist, guides collaborative improvements, and verifies the results with evidence. Use when onboarding a new repository, when a user says "set up this repo for agents," or when starting a harness engineering transformation. Do not use when the repo is already onboarded and the goal is to run a single specific skill.
55SKILL.mdUpdated Apr 16, 2026
patterninc/legibility--enhancer
development
VerifiedTrustedCommunity
Collaboratively walks a human through creating high-quality AGENTS.md files throughout a codebase, implementing progressive disclosure architecture. Use when creating or updating AGENTS.md files, onboarding a repository to agent-first practices, or remediating findings from legibility--auditor. Do not use when evaluating existing documentation coverage (use legibility--auditor) or when creating agent skills (use meta--skill-creator).
55SKILL.mdUpdated Apr 16, 2026
patterninc/legibility--auditor
development
VerifiedTrustedCommunity
Audits a repository's documentation coverage and agent-readiness by evaluating AGENTS.md placement, progressive disclosure quality, and UX intent documentation. Use when evaluating repository structure, auditing documentation coverage, assessing agent-readiness, or onboarding a codebase to agent-first practices. Do not use when creating or editing AGENTS.md files directly (use legibility--enhancer instead).
55SKILL.mdUpdated Apr 16, 2026