feat: add generic authoring skill

Author: devkade

skills/issue-pr-revision-authoring/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: issue-pr-revision-authoring
+description: Write implementation-ready GitHub issues, engineering-report PR bodies, and current-head revision comments without importing repo-specific policy.
+version: 1.0.0
+license: MIT
+metadata:
+  tags: [github, issue-authoring, pull-requests, revision-comments, engineering-reports]
+---
+# Issue / PR / Revision Authoring
+Use this skill when drafting or revising GitHub issues, pull request bodies, or review-response comments. The goal is **execution-design authoring**: enough concrete contract, evidence, and verification detail for an implementer or reviewer to proceed without a separate meeting.
+
+This skill standardizes writing quality only; it does not define branch protection, reviewer bots, merge gates, deployment policy, webhook behavior, or profile authority semantics.
+
+## Choose the smallest useful structure
+Use the smallest section set that makes the work executable and reviewable. Add paths, commands, examples, acceptance criteria, and evidence whenever they prevent ambiguity.
+
+## Issue authoring modes
+### 1. Execution-design issue
+Use when implementation should be possible directly from the issue. Include: summary/motivation, observed problem, proposed solution, CLI/API/UX examples, likely files or surfaces, dependencies/configuration, security/performance/compatibility considerations, non-goals, acceptance criteria, and verification plan.
+
+### 2. Current-state tracker issue
+Use when work is partially implemented and the issue tracks remaining gaps. Include: current status summary, feature/surface table, completed vs remaining work, architecture or surface map, acceptance criteria with status, and available evidence.
+
+### 3. Evidence-driven investigation issue
+Use for performance, correctness, production behavior, or uncertain root cause work where implementation should not start from guesses. Include: environment, measurements/reproduction evidence, observations separated from hypotheses, suggested investigations, reproduction commands, and related issues/PRs/docs.
+
+## PR body authoring
+A PR body is an **engineering report, not a changelog**. Explain final behavior, linked issue/close intent, problem and defect split, changes by file/surface, design decisions and rejected alternatives, tests, exact verification commands, acceptance status, and remaining risks or follow-up. Use `templates/pr-body.md`; use `Refs #N` instead of `Closes #N` for partial work.
+
+## Revision comment authoring
+A revision comment should be current-head, feedback-addressing, and evidence-bearing. Do not merely say “fixed.” Include current head SHA, intent, findings addressed, changed files/surfaces, tests/verification, docs/release-note impact, remaining items, and ready-for-review statement. If a repository requires a review trigger phrase, follow that repository's workflow; do not bake a specific bot name or trigger phrase into this generic template.
+
+## Genericity boundaries
+Keep these layers out unless a downstream repo adds them in its own workflow docs:
+- reviewer bot names or trigger phrases;
+- branch protection, rulesets, merge gates, or deployment rules;
+- GitHub App internals, webhook behavior, or CI rerun mechanics;
+- organization-specific authority or chat-lane policy;
+- product-specific reusable code identifiers.
+
+## Bundled templates
+- `templates/issue.md` — execution-design, current-state tracker, and evidence-driven investigation issue sections.
+- `templates/pr-body.md` — engineering-report PR body sections.
+- `templates/revision-comment.md` — current-head review-response/finalization comment.

skills/issue-pr-revision-authoring/templates/issue.md

@@ -0,0 +1,56 @@
+# Issue Authoring Template
+Use the smallest section set that makes the work executable. Prefer concrete contracts over vague tickets.
+
+## Summary
+<What should change and where.>
+## Problem
+<What is wrong, missing, slow, ambiguous, or risky. Separate observed facts from guesses.>
+## Context / Current state
+<Why this matters now. Include status, links, or code paths.>
+| Feature / surface | Status | Location / evidence |
+|---|---|---|
+| <feature> | ✅ Complete / 🚧 Partial / ❌ Missing | `<path>` / <link> |
+## Proposed solution
+<The intended direction, detailed enough that implementation can start.>
+## Contract / Examples
+```bash
+<command or usage example>
+```
+```text
+<expected output shape or behavior comparison>
+```
+## Implementation details
+### Files / surfaces to modify
+```text
+<path>  # <expected change>
+<path>  # <expected change>
+```
+### Dependencies / configuration
+```toml
+<dependency> = "<version>"
+```
+### Design decisions / options
+1. **<Option A>** — <trade-off>
+2. **<Option B>** — <trade-off>
+Selected/default direction: <option or pending decision>.
+## Security / Performance / Compatibility considerations
+- <consideration>
+- <consideration>
+## Non-goals
+- <what this issue should not do>
+## Acceptance criteria
+- [ ] <observable completion criterion>
+- [ ] <test or behavior criterion>
+- [ ] <boundary/non-goal criterion>
+## Verification plan
+- [ ] `<exact command or check>` — <expected result>
+- [ ] <manual verification if needed>
+## Evidence-driven investigation addendum
+Use when implementation should wait for performance/correctness/production evidence.
+- Environment: <OS/runtime/version/config>
+- Measurements / reproduction: `<command>` plus observed output, timing, trace, or error.
+- Observations: <facts from evidence>
+- Hypotheses: <possible causes, explicitly marked>
+- Suggested investigations: <next checks>
+## Related
+- <issue/PR/doc link>

skills/issue-pr-revision-authoring/templates/pr-body.md

@@ -0,0 +1,40 @@
+# PR Body Template
+A PR body is an engineering report, not a changelog. It should explain the problem, selected design, changes, verification, and remaining risk.
+
+```markdown
+## Summary
+- <1-3 bullets describing final behavior/result>
+- <mention user-visible contract, compatibility, or regression coverage>
+## Linked issue
+Closes #<N>
+<!-- Use Refs #<N> when the PR is partial and should not close the issue. -->
+## Problem
+<Explain what was wrong or missing, where it appeared, and why it mattered.>
+### Defect 1 — <name>
+<fact-based explanation>
+### Defect 2 — <name>
+<fact-based explanation>
+## Changes
+### <Surface or file group> — `<path>`
+- <specific behavior change>
+- <specific guard/contract/test/doc update>
+### <Surface or file group> — `<path>`
+- <specific behavior change>
+## Design decisions
+<Explain selected option, rejected alternatives, and why.>
+| Scenario / path | Before | After |
+|---|---|---|
+| <case> | <old behavior> | <new behavior> |
+## Tests
+- <new test file / test name> — <what it verifies>
+- <existing test suite impact>
+## Verification
+- [x] `<exact command>` — pass, <count/detail if useful>
+- [ ] `<manual check>` — pending/skipped, reason: <reason>
+## Acceptance criteria
+- [x] <criterion from issue>
+- [ ] <remaining/manual criterion if any>
+## Risks / Follow-up
+- <remaining risk, limitation, or `None identified`.>
+- <follow-up issue or `None`.>
+```

skills/issue-pr-revision-authoring/templates/revision-comment.md

@@ -0,0 +1,24 @@
+# Revision Comment Template
+Use after review feedback or follow-up commits. Describe the current head, feedback addressed, and readiness evidence.
+
+```markdown
+## Revision explanation for current head `<HEAD_SHA>`
+### Intent
+<One sentence restating what this revision is closing.>
+### Findings addressed
+- [x] **<Finding title / severity if known>** — <what changed and why it closes the feedback>
+- [x] **<Finding title>** — <resolution>
+### What changed
+- `<path>` — <specific revision change>
+- `<path>` — <specific revision change>
+### Tests / verification
+- [x] `<exact command>` — pass, <count/detail if useful>
+- [ ] `<manual check>` — pending/skipped, reason: <reason>
+### Documentation / release notes
+- `<path>` — <doc/changelog update>
+- `n/a` — <reason if no docs needed>
+### Remaining items
+None.
+### Ready for review
+This revision is ready for review on current head `<HEAD_SHA>`.
+```

test/resource-discovery.test.ts

@@ -74,6 +74,33 @@ test("Kapi bundles Deep Interview skill guidance for in-process interviewing", a
   assert.doesNotMatch(skill, /Unknown agent|subagent interviewer/i);
 });
 
+test("bundles generic issue, PR, and revision authoring guidance", async () => {
+  const skillRoot = path.join(process.cwd(), "skills", "issue-pr-revision-authoring");
+  const skill = await readFile(path.join(skillRoot, "SKILL.md"), "utf8");
+  const issue = await readFile(path.join(skillRoot, "templates", "issue.md"), "utf8");
+  const prBody = await readFile(path.join(skillRoot, "templates", "pr-body.md"), "utf8");
+  const revision = await readFile(path.join(skillRoot, "templates", "revision-comment.md"), "utf8");
+
+  assert.match(skill, /execution-design authoring/i);
+  assert.match(skill, /Execution-design issue/);
+  assert.match(skill, /Current-state tracker issue/);
+  assert.match(skill, /Evidence-driven investigation issue/);
+  assert.match(skill, /engineering report, not a changelog/i);
+  assert.match(skill, /current head SHA/i);
+  assert.match(skill, /does not define branch protection, reviewer bots, merge gates/i);
+  assert.doesNotMatch(skill, /kapi-agent|Discord lane|Ragna\/일출 authority|author: Ilchul/i);
+
+  assert.match(issue, /## Acceptance criteria/);
+  assert.match(issue, /## Verification plan/);
+  assert.match(issue, /## Evidence-driven investigation addendum/);
+  assert.match(prBody, /## Design decisions/);
+  assert.match(prBody, /## Verification/);
+  assert.match(prBody, /## Risks \/ Follow-up/);
+  assert.match(revision, /Revision explanation for current head `<HEAD_SHA>`/);
+  assert.match(revision, /### Findings addressed/);
+  assert.match(revision, /### Ready for review/);
+});
+
 test("Kapi Ralph skills encode planning and build invariants", async () => {
   const ralplan = await readFile(path.join(process.cwd(), "skills", "kapi-ralph", "SKILL.md"), "utf8");
   const ralph = await readFile(path.join(process.cwd(), "skills", "kapi-ralph", "SKILL.md"), "utf8");