Skillstead

English · 한국어

Practical, portable skills for agentic coding workflows — create clearer artifacts, check public claims, guide safer GitHub releases, and turn rough or translated text into natural, precise writing.

[!TIP] Skillstead = skill + homestead. A small, durable place for skills that coding agents can carry into real repositories. Each public support claim is tied to examples and runtime evidence.

Start here

1. Choose one skill for the task in front of you. Each skill works independently.
2. Follow the installation guide to copy that skill's complete folder at a pinned version.
3. Open the skill's README, copy a request that is close to your task, and adapt it to your material.
4. Check the skill's stated limits before relying on the result in a release or other consequential workflow.

Looking for a particular guide? The documentation index separates user guides from maintainer references.

Highlights

Explore the SVG gallery

svg-infographic covers more than conventional architecture boxes. The gallery includes sketch-style incident flows, agent-system maps, cloud topology, decision matrices, migration views, roadmaps, and Korean/CJK-ready technical one-pagers. Browse the 14-example English/Korean gallery.

Use one skill—or combine them across a release

Each skill installs and works independently. When a project needs a wider path, use writing-quality-editor for clear prose, svg-infographic for visual explanation, docs-claim-check for evidence-bounded public claims, and github-release-guide for approval-gated release decisions. This is not a required pipeline: start with the skill you need, skip the others, and recheck an earlier artifact when it changes.

Choose a skill

Each skill is self-contained and can be installed independently. You do not need to install the entire catalog—copy only the complete folder for the skill you want to use. See docs/INSTALL.md for global/project paths, pinned tags, clean updates, Windows commands, and the per-skill runtime matrix.

The Version column above is per skill, not a catalog version. See docs/VERSIONING.md for what it means and how it changes.

For more examples—including natural requests, the WQE shorthand, and requests that involve more than one skill—see the repository-only intent and invocation contract.

GitHub's Latest badge identifies the most recently published individual skill release. It does not represent a catalog version.

Skill details

svg-infographic

Technical diagrams often begin as prose and end as hard-to-edit screenshots. svg-infographic computes a layout before drawing, authors structured SVG, checks the source, then exports a dimension-verified 2× PNG.

Use it for architecture and cloud topology, process or approval flows, before/after migrations, roadmaps, layer models, qualitative matrices, and Korean/CJK-ready technical one-pagers.

• Friendly guide: svg-infographic README
• Examples: 14-example English/Korean gallery
• Name the skill: Use svg-infographic to turn this migration plan into an editable technical infographic.
• Or ask naturally: Turn this migration plan into an editable technical SVG and verified 2× PNG. Show the output path before creating files.

docs-claim-check

Release-facing docs can sound certain even when their evidence is partial or stale. docs-claim-check splits objective statements into atomic claims and labels each one verified, unsupported, stale-suspected, or needs-human within an explicit reviewed-input scope.

Use it before publishing a README, install guide, release note, or announcement. It is advisory only: the contract runs no commands during assessment and does not generate fixes, code review, or security verdicts.

• Friendly guide: docs-claim-check README
• Validation material: synthetic AcmeTask fixture and worked assessment
• Name the skill: Use docs-claim-check to assess these release-note claims against the supplied tag and CI evidence.
• Or ask naturally: Check whether these README claims are supported by the evidence below. Report findings only; do not rewrite the document.

github-release-guide

GitHub releases combine documentation work with changes to visibility, branches, tags, settings, and GitHub Releases that can be difficult to undo. github-release-guide first checks readiness without changing the repository. It then shows each proposed change, checks the current state again, asks for direct approval, and verifies the result before moving on.

V1 can be used at two points: when an existing private github.com repository becomes public for the first time, and whenever that public repository publishes a new version afterward. It does not bootstrap repositories, publish packages, sign binaries, deploy cloud services, claim a security audit, force-push, or rewrite history.

Choose the mode and profile	Follow the approval safety loop

• Friendly guide: github-release-guide README
• Validation material and diagrams: synthetic scenarios, answer key, and worked outputs
• Natural readiness check: Check whether this public GitHub repository is ready for its next version release. Inspect only and do not change it.
• Assess example: Use github-release-guide in Assess mode for this public repository's upcoming version release.
• Guided example: Use github-release-guide in Guided mode to prepare this private repository for first publication. Start with Assess, then show only the first proposed change. Do not change the repository until I approve that exact step.
• Safety boundary: immediately before a repository becomes public, the guide explains what cannot be undone and asks the user to approve that visibility change separately. The release decision remains with the user.

writing-quality-editor

Writing can start generic, over-structured, or translated sentence by sentence. writing-quality-editor composes new documents directly from reliable briefs or reviewed public sources and improves existing prose so it reads like careful work by a skilled writer or editor while preserving facts, intent, author voice, commands, conditions, limitations, risks, and next actions.

Its Adapt mode rewrites between English and Korean for the target-language reader instead of copying the source sentence structure. It may change information order, sentence rhythm, idioms, and explanation density, but it does not invent claims or hide ambiguity. AI-detector gaming and provenance concealment are explicit non-goals.

• Friendly guide: writing-quality-editor README
• Validation material: 27 scenarios and a separate answer key
• Name the skill: Use writing-quality-editor to make the document below read naturally. Preserve its core facts, conditions, and requirements.
• Use the shorthand: Use WQE to review this onboarding guide. Identify problems, but do not revise it yet.
• Or ask naturally: Review this README. Do not revise the prose yet. · Write a new README using only information supported by the material below. · Rewrite this English release note so it reads naturally to Korean readers. Preserve its meaning and conditions.
• Specify a mode only when needed: Use writing-quality-editor in Assess mode to review this release note. Do not draft revisions.

Playbooks (maintainer reference)

playbooks/public-release contains the canonical public-release playbook: generic checklists and templates for taking a private repository public and verifying it afterward. These are reference documents for maintainers — not installable skills, and installing any skill never requires them. The `githu