---
title: "swd"
description: "Software development skills: product specs, deep planning, root-cause analysis, agent-oriented repo docs, spec-aware rebasing, PR review, PR submission, review revision, and end-user e2e testing."
canonical: https://agentpluginsdirectory.com/plugins/swd
last-updated: 2026-09-22
---

# swd
Software development skills: product specs, deep planning, root-cause analysis, agent-oriented repo docs, spec-aware rebasing, PR review, PR submission, review revision, and end-user e2e testing.
- Slug: swd
- Publisher: korya
- Repository: https://github.com/korya/swd-skills
- Manifest: plugin.json
- Version: 0.8.0
- License: AGPL-3.0-or-later
- Category (editorial): code-review
- Skills: 9 (blueprint, e2e-test, examine, rca, rebase, repo-docs, revise, spec, submit)
- MCP servers: 0
- Stars: 2
- Repository created: 2026-05-21
- Repository last pushed: 2026-09-09
- Publisher type: User
- Listing: https://agentpluginsdirectory.com/plugins/swd
- Schema: https://agent-plugins.org/schemas/1.0.0/plugin.schema.json

## What swd does, in the publisher's words

A plugin of skills covering the full development cycle, spec, plan, build, submit, review, test, nine shipped, one planned. Runs on Claude Code, Codex CLI, and any Agent Plugins client.

Invocation differs per host: in Claude Code the skills fire on /blueprint, /rca, /examine, … (or on the natural-language triggers above); in Codex they are namespaced mentions, $swd:spec, $swd:blueprint, $swd:rca, $swd:submit, $swd:revise, $swd:examine, $swd:e2e-test, $swd:rebase, $swd:repo-docs.

Claude Code: in the session:

From the project README, punctuation lightly normalized. Full text: https://raw.githubusercontent.com/korya/swd-skills/HEAD/README.md

## Skills

- blueprint: Plan a non-trivial code change rigorously: understand the problem, form a hypothesis, validate assumptions through real experiments and doc/code reads, and cross-check the proposed solution against product specs, architecture, and the existing codebase before writing any plan. Use when the user sa…
- e2e-test: Validate a product end-to-end the way its real user uses it, a web app through the browser, a CLI through its binary, a library by writing consumer programs, black-box, deriving cases from the change's blast radius and spec acceptance criteria, and reporting every case as PASS, FAILURE, or BLOCKE…
- examine: Review a code change rigorously: a PR, branch, commit range, or the working tree. Confirm the problem is real, sketch the obvious solutions before reading the diff, then audit it for correctness, completeness, architecture, conventions, security, privacy, testing, reversibility, and dependencies,…
- rca: Conduct a root-cause analysis on a bug, incident, or regression, reproduce the failure, reconstruct the timeline, run a 5-whys chain, distinguish symptom from proximate cause from root cause, sweep for siblings, and propose a fix that addresses the cause (not the symptom). Use when the user says "…
- rebase: Rebase a work-in-progress or completed branch onto a new base, ensuring the rebased changes still satisfy their original spec, comply with the (possibly updated) architecture, conventions, and invariants of the new base, and introduce no regressions. Use when the user says "rebase this branch on X"…
- repo-docs: Bootstrap or extend a repo's documentation for coding agents. Creates AGENTS.md + docs/ structure (architecture, guidelines, product-specs with stable IDs and invariants). Use when the user asks to "document the project for coding agents", "set up agent docs", "add AGENTS.md", "create docs/ structu…
- revise: Address PR review feedback without swallowing it whole, cross-validate every claim and assumption against the code, design, and specs; give each finding an explicit justified verdict (ACCEPT, PARTIAL, REJECT, DEFER); fix accepted items at the root; reply where the feedback lives; re-submit. Use wh…
- spec: Turn a fuzzy feature request into a reviewable product spec, goals, non-goals, testable acceptance criteria with stable IDs, invariants, that later skills cite by path and ID. Use when the user says "/spec", "spec this out", "write a product spec", "turn this idea into requirements", or brings a…
- submit: Open every pull request through this skill, invoke it the moment completed changes need to become a PR, instead of running `git push` or `gh pr create` yourself, and once per PR in a stack. Never open a PR by hand while this skill is installed, it owns the branch and commit shape (Conventional Co…

Descriptions come from the frontmatter of each SKILL.md, punctuation lightly normalized.