xiduzo

This skill should be used when a user wants to set up WTF in a new repository, verify their environment is ready, check that GitHub CLI is installed and authenticated, install required gh extensions, or ensure the .github/ISSUE_TEMPLATE/ templates are in place — for example "set up wtf", "run setup", "check my environment", "install wtf templates", "verify everything is configured", "initialize wtf", "onboard to wtf", "first time setup", "configure gh for wtf", "prepare this repo for wtf", "is wtf ready", "get wtf running", or "a new dev joined, set them up". Run once per repo when onboarding, or when a contributor joins the project.

This skill should be used when a developer wants to autonomously execute all tasks under a fully-specified Epic or Feature — for example "go", "start building", "implement everything", "run the loop", "execute the feature", "build it all", "kick it off". Requires that the Epic/Feature/Task tree is fully written before starting. Chains implement → verify → PR for every task in dependency order, with targeted human-in-the-loop gates for contradictions and ambiguities.

This skill should be used when a user wants to decompose an Epic into its complete set of Features all at once, invoked automatically after write-epic completes, or triggered by phrases like "create all features for this epic", "walk me through all the features", "let's break down this epic", or "plan the features for epic

This skill should be used when a developer or lead wants a project status overview — for example "what's the state of the project", "show me what's blocked", "project health check", "what tasks are stuck", "standup summary", "how many issues are unverified", "what's left in this epic", "show me what needs attention", "what's been implemented but not verified", or "what's blocking the release". Scans all open WTF issues and produces a triage-ready health report with actionable next steps.

Use when new insights change the scope, acceptance criteria, domain language, or technical constraints of an existing Epic, Feature, or Task — for example "refine epic

This skill should be used when a developer or QA engineer wants to report a bug, create a bug ticket, document a test failure, log a defect, file an issue found during a QA session, or report something that is broken — for example "report a bug", "create a bug ticket", "I found a defect", "something is broken in task

This skill should be used when a team wants to close out a completed Epic or sprint, capture what was planned vs. what shipped, learn from deviations, and formally mark the Epic done — for example "run a retro on this epic", "close out the epic", "what deviated from the plan", "retrospective for epic

This skill should be used when a developer or tech lead needs to investigate a technical unknown before committing to an approach — for example "run a spike on X", "I need to research this before writing the epic", "we don't know how to approach this yet", "investigate if we can use X for Y", "time-box this exploration", "what's the right architecture for this?", or "should we use A or B?". Produces a findings document and a concrete recommendation that feeds directly into write-epic or write-task.

This skill should be used when a developer wants to open a pull request for a completed task branch — for example "create a PR", "open a pull request", "submit this for review", "make a PR for task

This skill should be used when a designer is picking up a Task issue to add design coverage. Triggers on phrases like "I want to design task

This skill should be used when a user wants to decompose an Epic into its complete set of Features all at once, invoked automatically after write-epic completes, or triggered by phrases like "create all features for this epic", "walk me through all the features", "let's break down this epic", or "plan the features for epic

This skill should be used when a user wants to plan and create the complete set of Tasks for a Feature all at once, systematically walk through every implementable slice of work for a Feature, or create tasks in batch with step-by-step confirmation. Triggers on phrases like "plan all tasks for this feature", "create all tasks for feature

This skill should be used when a developer is ready to implement a GitHub Task issue and needs to read the full spec hierarchy (Task + Feature + Epic), explore the codebase, produce a concrete Technical Approach with real file paths, and drive TDD implementation against Gherkin scenarios. Triggers on phrases like "implement task

Use when new insights change the scope, acceptance criteria, domain language, or technical constraints of an existing Epic, Feature, or Task — for example "refine epic

This skill should be used when a developer wants to capture learnings from a difficult session, record what Claude got wrong, save implementation gotchas, or update the steering docs with hard-won knowledge — for example "let's reflect", "capture what we learned", "that was painful, save this", "update the steering docs with what went wrong", or when prompted by the intervention tracker after multiple corrections. Routes each learning into the right steering doc (TECH, QA, DESIGN, or VISION) under a "Hard-Won Lessons" section.

This skill should be used when a developer or QA engineer wants to report a bug, create a bug ticket, document a test failure, log a defect, file an issue found during a QA session, or report something that is broken — for example "report a bug", "create a bug ticket", "I found a defect", "something is broken in task

Critique an existing developer blog post against Michael Lynch's "Refactoring English" principles and return a per-principle rubric followed by a prioritized fix list. Use whenever the user shares a draft or published post and asks for review, feedback, critique, edit, "is this any good?", "why isn't this getting traction?", "rip this apart," "review my post," or pastes a URL/markdown asking what to improve. Also trigger when a user has written a technical article, dev-log, engineering write-up, or case study and wants a quality check before publishing. Output is honest and concrete — every issue cites a specific line or section.

Write technical blog posts that developers actually read, following Michael Lynch's "Refactoring English" principles (300k+ readers/year, 30+ HN front page hits). Use whenever the user wants to draft, plan, outline, or rewrite a developer-focused blog post, dev-log entry, technical article, engineering write-up, case study, or post-mortem — even if they don't say "blog post." Trigger on phrases like "write a post about X," "turn this into an article," "draft a blog," "I want to publish," "write up my project," or pasting raw notes asking for a published version. Optimizes for skimmer-friendly structure, audience reach, and a title+intro that earns the click.

Critique a portfolio case study for a creative technologist (design + code hybrid) against six principles tuned to that role, and return a per-principle rubric followed by a prioritized fix list. Use whenever the user shares a draft or published portfolio piece, project page, case study, or "/project/<name>" page and asks for review, feedback, critique, edit, "is this any good?", "rip this apart," "review my project page," "why isn't this landing with hiring managers?", or pastes a URL/Markdown/JSX asking what to improve. Also trigger when a user has written up a project, work sample, or engineering write-up and wants a quality check before publishing. Output is honest and concrete — every issue cites a specific line or section.

Write portfolio case studies for a creative technologist (design + code hybrid) — projects that must prove integration, not just process. Use whenever the user wants to draft, plan, outline, or rewrite a portfolio piece, project page, case study, project write-up, work sample, or "/project/<name>" page on this site — even if they don't say "case study." Trigger on phrases like "write up Microflow," "turn this project into a case study," "draft the Fissa page," "I want to publish this project," "make this into a portfolio piece," or pasting raw project notes / a README asking for a published version. Optimizes for hiring-manager scan, design-and-engineering integration signals, and decision traceability over polished screenshots.