메뉴
Publish a planning spec or plan to uselink so stakeholders can read it without repo access. Use when the user says 'share spec', 'publish the plan', 'send this spec to PM', or wants a shareable link for a .planning artifact.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Agent skills for publishing engineering artifacts to uselink — repo summaries, PR digests, changelogs, API docs, onboarding guides, reports, and specs. Each skill gathers data, generates HTML, and publishes via the uselink CLI.
Scan backend controllers/routes, generate API documentation as HTML, and publish to uselink. Use when the user wants to share API docs with frontend devs, partners, or stakeholders who need to understand the API contract.
Generate a changelog or release notes from git history and publish to uselink. Use when the user wants to share release notes, a changelog between versions, or a 'what shipped this week' summary with stakeholders.
Scan a codebase and generate a new-developer onboarding guide as HTML, then publish to uselink. Use when the user wants to create a getting-started guide, onboard a new team member, or share 'how to work in this repo' docs.
Summarize a pull request as a stakeholder-friendly HTML page and publish to uselink. Use when the user wants to share PR changes with PMs, reviewers, or business stakeholders who don't read diffs.
Scan a GitHub repo (local or remote), generate an architecture overview as HTML, and publish to uselink. Use when the user wants to share a repo summary, architecture overview, or codebase tour with stakeholders who don't have repo access.
| name | uselink-share-spec |
| description | Publish a planning spec or plan to uselink so stakeholders can read it without repo access. Use when the user says 'share spec', 'publish the plan', 'send this spec to PM', or wants a shareable link for a .planning artifact. |
| allowed-tools | ["Bash","Read","Glob"] |
Publish specs and plans from .planning/ to uselink so PMs, stakeholders, and business people can read them without cloning the repo.
Check CLI installed and configured before anything else:
which uselink || echo "MISSING"
test -f ~/.uselink/config.json && echo "OK" || echo "NO_CONFIG"
If uselink is missing, tell the user to install it. If config is missing, tell them to run uselink login.
Scan both directories:
ls .planning/specs/*.md .planning/plans/*.md 2>/dev/null
If the user gave a name (e.g. "versioning"), fuzzy-match against filenames. If multiple files match, list them and ask which one. If zero match, ask for the path.
Strip prefixes and convert to human-readable Title Case:
| Filename | Title |
|---|---|
done_04_publishing.md | Publishing |
10_versioning.md | Versioning |
billing-hardening.md | Billing Hardening |
spec-11-polish-v2.md | Polish V2 |
Rules: drop done_ prefix, drop leading number + underscore (04_), drop spec-NN- prefix, convert kebab/snake to spaces, Title Case the result.
uselink publish <file> --title "<clean title>"
Capture the URL from stdout.
Report the published URL to the user. If the file was a done_* spec, mention it was a completed spec.
done_ prefix means the spec is implemented, not that it shouldn't be shared. Stakeholders often want to review completed specs for reference or onboarding. Publish it normally but mention the spec is marked as done.~/.uselink/config.json, not ~/.config/uselink/. If the user says "I already logged in" but the config check fails, they may have installed a different version or the config landed in the wrong directory. Check both paths before giving up..md only -- .planning/ also contains .html files (like the PRD). The uselink CLI handles HTML too, but the title-cleaning logic assumes markdown naming conventions. If the user asks to share an HTML file, skip the title cleaning and use the filename as-is.public-profile.md, billing-hardening.md). The title cleaner must handle both numbered (10_versioning.md) and unnumbered (billing-hardening.md) filenames without mangling either.