agentic-workflow — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited agentic-workflow (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 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 operating under a structured workflow that treats you as a highly capable engineer that lacks object permanence. To produce senior-level results, you follow a rigid scaffolding of context, constraints, and deterministic planning.
Some aspects of this workflow are user-configurable via /workflow-config. When a preference is set, it is stored in your agent's persistent memory. Check memory for these settings and respect them across all phases:
Every significant change follows this cycle: Brainstorm → Plan → Build → 3rd-Person Review → Verify. You must never skip phases or collapse them together.
You MUST drive phase transitions forward automatically. Within the build loop (implement → test → self-review → next phase), do not wait for the user to tell you to proceed — own the process. For cross-phase transitions (e.g., brainstorm → plan), suggest and confirm. Use this guide:
| Current State | Signal to Transition | Suggest |
|---|---|---|
| Open-ended discussion | User describes a problem or feature need | → /brainstorm |
| Brainstorm complete | Options explored, user has picked a direction | → /write-plan |
| Plan approved | User says "approved", "let's build", or "proceed" | Move plan from new/ to docs/plans/ with mv (plain shell — not git mv; the plan may not be tracked yet). → /build-phase |
| Implementing code | About to write production code | → /test-driven-development (default) or BDD-style tests (if BDD is configured in memory) |
| Phase complete | Tests pass, self-review clear | → next /build-phase or "all phases complete" |
| All build phases complete (main model) | /build-phase reported completion, full suite passes | → /3p-review → /handoff-summary (build record) → /verification-before-completion |
| Dedicated build model session | User launched the session to build a plan with a smaller/faster model | This is not your workflow — use /build-model, which drives /build-phase → /3p-review → /handoff-summary → STOP |
| User returns with handoff summary | Build was done by a different model (e.g. a dedicated build model) | → /3p-review with the handoff summary as argument (review the full output and address all concerns from the summary), then /verification-before-completion |
| Code written (any context) | User wants quality assurance | → /3p-review |
| 3p-review passed | Review clean, zero open findings | → /verification-before-completion — the FINAL fresh-evidence gate, not a re-review. Run the full suite once more now and tick the plan's requirements line by line. Always; do not skip on the grounds that review already ran tests. |
| Bug, test failure, unexpected behavior | Something is broken | → /systematic-debugging (investigate before fixing) |
| Verify passed | Evidence confirms feature works | Move plan from docs/plans/ to docs/plans/done/ with mv (plain shell — not git mv; the plan may not be tracked yet). Feature complete. |
| Context loaded with project files | User asks "what should I work on?" | → /triage |
| Low context / fresh conversation | Bugs exist in backlog | → /triage (will recommend bugs) |
docs/plans/new/ as versioned project assets./3p-review runs after ALL phases are complete./test-driven-development by default, or BDD-style specifications if configured./systematic-debugging — investigate root cause before proposing fixes./verification-before-completion before any "done" claim, commit, or PR. It is not a second review — it is the honesty gate on the final claim: run the verification command fresh in this message and read the output. It adds two things /3p-review does not guarantee: (a) a fresh full-suite run at the actual moment of completion — review may have passed several edits ago; and (b) a line-by-line check against the plan's requirements — review judges completeness only qualitatively. It also covers the bug / quick-fix path, which skips full review./3p-review passing the handoff summary as argument so it reviews the full feature AND addresses every concern from the summary. Then /verification-before-completion, then archive the plan. Do not wait to be told./3p-review finds issues and they are fixed, re-review from scratch. Repeat until clean. Do not stop after one round.new/ → plans/ → done/. Move to plans/ when build starts. Move to done/ after verify passes. Use plain mv (not git mv) — the plan file may not be tracked by git yet. Do not leave plans stranded in the wrong directory./3p-review → /verification-before-completion → archive plan. /3p-review proves the code is good; verification proves the claim of "done" is true right now — a fresh run plus a plan-requirements checklist. "Review already ran the tests" is exactly the rationalization to refuse: review's green is point-in-time and its completeness check is qualitative. Do not stop after review and wait to be asked, and do not skip plan archival.Plans accumulate in new/ — this is intentional. With AI-assisted development, "later" means minutes or hours, not months. Accumulating plans is staging work for rapid parallel execution.
When tokens or context are constrained, pick bugs — they are small, self-contained, and don't require the full Brainstorm → Plan → Build cycle.
When resources are plentiful, pick features and plans — they require sustained attention and the full workflow.
Always minimize context thrash: prefer work that aligns with what's already loaded in the conversation.
For best results, list the workflow skills in your project's config file (CLAUDE.md, .cursorrules, GEMINI.md, or .github/copilot-instructions.md) so they are loaded automatically:
## Workflow Skills
- `agentic-workflow` — orchestrates the structured development lifecycle
- `/workflow-config` — configure workflow preferences (TDD/BDD, caveman output style)
- `/brainstorm` — explore problem space, challenge the design, produce decision documents
- `/write-plan` — write phased plans to docs/plans/new/
- `/build-phase` — execute plan phases with test + self-review; produces a build completion report (no review/handoff)
- `/build-model` — dedicated build-model workflow: build-phase → 3p-review → handoff-summary → stop (alternative entry point to this workflow, for a smaller/faster build session)
- `/3p-review` — independent third-person code review (after all build phases)
- `/handoff-summary` — emit the fixed Build Handoff Summary artifact after review passes
- `/test-driven-development` — RED-GREEN-REFACTOR, test first always (from superpowers)
- `/systematic-debugging` — 4-phase root cause investigation (from superpowers)
- `/verification-before-completion` — evidence before claims (from superpowers)
- `/triage` — recommend next task minimizing context thrash~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.