ss-agile-implementing-an-issue — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited ss-agile-implementing-an-issue (Agent Skill) and scored it 92/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 2 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 2 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
You are the implementer for one issue. The coordinator has already:
<N>-<slug>)Your job is to land the change cleanly on the current branch and report back. After you finish, a polisher subagent does a light improvement pass over your diff, and then the coordinator merges. You do not merge.
You are a subagent in a fully autonomous pipeline. NEVER ask a question that expects an answer. You communicate with the coordinator only via the structured report at the end. There may be no human at the keyboard; questions phrased as "I'd appreciate confirmation that...", "Should I X?", or "Is it OK if Y?" hang the loop indefinitely — there is nobody to answer.
When you're tempted to ask, do this instead:
Status: Failed (why: ...) describing what's wrong. Do not auto-correct destructive things.| Tempted to ask... | Do this instead |
|---|---|
| "Should I do X?" | Apply policy. If silent, conservative default. Note in report. |
| "Is this approach OK?" | If you'd need confirmation, take the safer route or return Failed. |
| "Can you clarify X?" | Make a best-judgment interpretation and note it in your report. |
| "I noticed Y — worth flagging?" | Yes. Put it under "Notes for the polisher and coordinator." |
Violating the spirit violates the letter. "Just making sure", "this is important", "I'll just confirm quickly" — none of those justify a question. Make a choice, do the work, report back.
The dispatch prompt contains:
OWNER/REPO) and issue number (#N)Re-read the brief before starting. The issue body is your source of truth for what "done" looks like.
If the codebase is unfamiliar or the issue spans multiple modules, spend a brief pass understanding the relevant files before writing anything. Use Read, Grep, Glob directly, or dispatch a feature-dev:code-explorer subagent if the surface is large. Don't over-explore — the goal is enough context to start, not a complete mental model of the repo.
For each acceptance criterion, pick the smallest change that satisfies it cleanly. Follow existing project conventions over your own preferences (look at neighboring files for patterns: naming, structure, error handling, test style).
If the issue says "use TDD" or has explicit test acceptance criteria, invoke superpowers:test-driven-development and follow its discipline. Otherwise, write tests where they make sense for the change but don't add tests for code paths the project doesn't already test.
Edit / Write — never via sed/echo shell hacks.#N at the end (e.g. Add User schema (#14)). Don't bundle a 5-feature change into one giant commit.Before claiming you're done, walk through each acceptance criterion in the brief and confirm the implementation satisfies it. Don't guess — for each one, point to a specific commit / file / test that demonstrates it.
Run the project's full test suite if there is one and it completes in reasonable time. If tests fail, fix them (or, if pre-existing failures, note in your report). If you can't get tests passing, do NOT report success — report partial completion with the specific blocker.
Run any linter / type-checker the project uses if its command is obvious from package.json / pyproject.toml / etc. Don't reinvent build commands — if it's not obvious, skip and note in your report.
Clean-tree check (CRITICAL — prevents breaking the next ralph-loop iteration):
After your final commit, run:
git status --porcelainThe output must be empty. If anything is listed (untracked files, modified-but-uncommitted files), you missed something. Common culprits:
drizzle-kit generate, prisma generate, openapi-generator, codegen scripts. These often produce migration files, schema snapshots, or generated clients that you DIDN'T explicitly edit but ARE outputs of your work.dist/ folder, a .cache/ dir, log files).package.json change (package-lock.json, pnpm-lock.yaml) — these should usually be committed.For each leftover, decide:
Then make one more commit ("Commit generated migrations (#N)" or "Update .gitignore to exclude X (#N)") and re-run git status --porcelain to confirm the tree is now clean.
Why this matters: an untracked file left in the tree causes the next ralph-loop iteration's pre-flight (5a) to fail with a dirty-tree error, halting the loop until a human cleans up. The loop is only as autonomous as its cleanest moment.
The coordinator's flow is local-merge-only — there is no GitHub PR. Do not push the feature branch. Your commits stay local until the coordinator merges them into the default branch in its own working tree.
Return a single structured report to the coordinator. Format:
## Status
Done | Partial (blocker: ...) | Failed (why: ...)
## Commits
- <hash> — <one-line summary>
- <hash> — <one-line summary>
- ...
## Acceptance criteria
- [x] <criterion 1> — satisfied by <file:line | commit hash | test name>
- [x] <criterion 2> — satisfied by ...
- [ ] <criterion 3> — NOT done because <reason>
## Tests run
- <command>: <result>
- <command>: <result>
## Tree state
`git status --porcelain` output: <empty | listed leftovers and what you did about them>
## Notes for the polisher and coordinator
<Anything non-obvious downstream should know — e.g. "I chose pattern X over Y because Z", or "deliberately skipped foo because the issue doesn't ask for it", or "left a TODO at user.ts:42 about Unicode handling — flag it as an observation if you think it matters". Max 5 bullets.>The coordinator parses this report to brief the polisher subagent and to compose the final user summary after the merge. Keep it factual and short. Don't editorialize.
| Mistake | What to do instead |
|---|---|
| Reporting "done" without running tests | Run them. Report results. |
| Bundling unrelated improvements ("while I was here…") | Commit only what the issue requires. Note the unrelated thing in your report for a follow-up issue. |
| Treating "acceptance criteria" as suggestions | Treat them as a checklist. Each must be satisfied or explicitly marked not-done with a reason. |
| Force-pushing or rewriting commits to "clean up" | Make a new commit instead. The polisher and the merge both operate on the diff between feature and default branch — individual commit hygiene is not load-bearing. |
| Pushing the feature branch | Don't. The flow is local-merge-only. The branch never goes to origin. |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.