issue 100/100 — SaferSkills

Is issue safe to install?

SaferSkills independently audited issue (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

pilot-plan/skills/issue/SKILL.md · 1 file

pilot-plan/skills/issue/SKILL.md5.4 KB · Markdown

name: issue

description: |

Create, file, open, log, or track GitHub issue. Always-gated by `core:socratic` skill — concrete intent passes ≤ 1 turn, vague intent triggers dialogue until convergence. Triggers when user mentions GitHub issues, bug reports, feature requests, or wants to track work on GitHub. Phrasings: "file an issue", "open a bug", "track this on GitHub".

argument-hint: <issue description | vague intent>

allowed-tools: AskUserQuestion, Bash(gh *), Read, Grep, Glob, Skill

model: opus

GitHub issue. Two-phase: socratic gate sharpens intent (§1); investigate codebase and file issue downstream (§2-§8).

Process

Socratic gate (always-on, not skip flag, not --quick bypass):

not $ARGUMENTS → ask user for issue intent (problem, idea, bug, feature) before gate runs.
Invoke core:socratic skill w/ $ARGUMENTS. Gate runs single-Q loop until convergence triple satisfied:

explicit goal — observable symptom (bug) or concrete behavior delta (feature/refactor)
acceptance criterion or repro step — one verifiable outcome or reproducible failure
§V/§T citation or not -spec flag — cite invariant/task this concerns, or flag explicitly out-of-spec

Concrete first-turn input passes ≤ 1 turn; vague → dialogue continues until convergence. Per skill spec: ≥ 3 turns w/o convergence → escape protocol offered.
Escape protocol ("just file it" or "skip questions" or "I know what I want"): stops dialogue but not bypasses gate — unmet criteria become explicit ## Unresolved callouts in §5 issue body. Gaps stay visible to team.
Rationale: GitHub issues = team-shared artifacts; validity bar > author keystroke savings.

Investigate codebase:

Search relevant files via Grep / Glob
Read related code → understand current implementation
Check git log for recent changes in affected areas
Identify affected components / modules

Gather details:

Type: bug, feature, enhancement, refactor
Affected files and code paths
Bugs → grep error patterns, failing conditions
Features → identify where changes needed

Ask clarifying questions if needed (decision-gate per decision-gate invariant — worked example: AskUserQuestion every ambiguous-requirement Phase 2 framing):

AskUserQuestion for ambiguous requirements — 2–4 options, label is action description, optional preview field is command + args.
Confirm scope if investigation reveals multiple approaches.
Bug → ask for repro steps (free-form text input — not finite mutually-exclusive options so decision-gate not applicable; plain prose prompt OK).
prose reply Y/N / type ok form not allowed every finite mutually-exclusive choice — consequence-bearing per decision-gate invariant.

Generate content:

Title: Conventional Commits → type(area): concise imperative description
type: fix, feat, refactor, chore, docs, test
area: affected module (e.g. <area>)
Body sections:
Summary: 2-3 sentence description
Context: Relevant code paths and files from investigation
Proposed Solution (?): based on codebase analysis
Acceptance Criteria: clear, testable
Affected Files: list of files needing changes

Determine labels:

gh label list → read existing labels. not invent new ones
Pick every label that genuinely applies. ≥ 1 type label (e.g. bug, enhancement, refactor, documentation)
Apply area / scope labels if defined
not matching type label → ask user before gh label create

Create issue:

gh issue create --title "..." --label "label1" --label "label2" --body "$(cat <<'EOF'...EOF)"
Each label as separate --label flag (or comma-separated in single value)
Output URL and number

Post insights as comment:

After create → add comment w/ notable insights
gh issue comment <number> --body "$(cat <<'EOF'...EOF)"
Include any of:
Architectural context discovered
Related code patterns / dependencies not obvious
Risks or complexity affecting impl
Alternative approaches to note
Concise and actionable. Skip if not meaningful insights.

Write-time glyph gate

Pre-publish: rg --pcre2 '[∀∃∴⊥∈∉∧∨≤≥≠≡¬]' <body> on issue body (§7) and insights comment (§8); match → bail and rewrite per core:steno register before gh issue create or gh issue comment mutation.

Style

Apply core:steno to issue title and body. Conventional Commits prefix (type(area):) and identifiers / paths / #refs preserved verbatim.

Requirements

Investigate before asking — gather context first
Keep investigation focused on description
Steno style for body (→ core:steno skill)
Markdown formatting in body
Cite specific files / line numbers when relevant

OUTPUT — "Next" block

Heading ## Next; 1–5 atomic items (one sentence each, no Reply prefix); positional dispatch (run <int> or run /<plugin>:<cmd> [args]). Issue filed → follow-up usually /gh:pr <number> (start work on the issue) or assign reviewer or link to related issues.

Canonical example after issue filed (number 42):

## Next

1. /gh:pr 42 — branch off main + open a PR resolving the issue
2. gh issue edit 42 --add-assignee @me — claim it
3. gh issue comment 42 --body "<note>" — add context to the thread

issue— agent skill

Is issue safe to install?

Process

Write-time glyph gate

Style

Requirements

OUTPUT — "Next" block

Audit the pieces. Scan the whole. Decide.