Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →lifinance/aikido-weekly-review
Recurring (weekly) Aikido security-feed review for a repo — pulls all open findings via the Aikido MCP, builds a severity/type dashboard with SLA status, groups findings into action groups with a recommendation each, and lets the USER decide per group (nothing is fixed or ignored without their pick); ends by offering to schedule the next run. For tech leads reviewing their repo's security posture on a cadence, not for triaging a single PR.
Passed 6 of 13 test cases with the skill, and 3 of 13 without it.
and 5 more in the full report
6 fixed5 passed either way13 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
Format the Step 2 summary matrix header for an Aikido review dashboard with issue categories on the left and severities on the right.
| Checked | Without skill | With skill |
|---|---|---|
| Includes columns for Out of SLA and Due soon in the summary table header. | Missed | Passed |
The instructions your model reads when the skill loads.
Cadence review of the whole Aikido feed for one repo. Produces a dashboard + grouped
suggestions, waits for the user's per-group decisions, executes only those, then offers
to schedule the next run. Suggest-first is the contract: this command never fixes or
ignores anything the user hasn't picked. Deep SAST triage mechanics live in
/aikido-address-findings — this command orchestrates, it does not duplicate them.
aikido_issues_list). Verify availability exactly as described
in the Preflight section of .agents/commands/aikido-address-findings.md (the
aikido_full_scan test call, and its /aikido:setup fallback message on failure).gh repo view --json name -q .name unless overridden by the
argument. Never hardcode: forks share code under different Aikido repo names
(contracts vs contracts-tron).Call aikido_issues_list with repo_name and NO issue_types filter, paginating
(page: 0, 1, …) until a page returns fewer than 25 issues. Then two extra calls with
out_of_sla: true and sla_due_soon: true to mark SLA state per issue — paginated the
same way (the 25/page limit applies to every variant of this call).
issue_id values are numbers in the feed but must be passed back as strings to
aikido_ignore_issue.
Group by issue_type × issue_severity_label and render:
| Type | Crit | High | Med | Low | Out of SLA | Due soon |
|---------------|------|------|-----|-----|------------|----------|
| open_source | . | . | . | . | . | . |
| sast | . | . | . | . | . | . |
| leaked_secret | . | . | . | . | . | . |
| iac / other | . | . | . | . | . | . |
test cases passed, vs 3 / 13 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.