agentleFS
rhawk117rhawk117/cc-terraform-harness/skills/fix-review-findings/SKILL.md

fix-review-findings

Skill1 starsChanged 28 days agoApache-2.0View on GitHub

Work through a review-module report (APPLY-CALYPSE-REPORT.md) one finding at a time: the user picks the findings and whether to commit, then terraform-author fixes each finding in report order, the module is checked after every fix, and a hand-off table closes the run. Slash command only; invoke it with the path to the report.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read the report once. Then ask one AskUserQuestion dialog with two questions:

    line 20
  2. Distinctive:

    Ask these two questions once, together.

    line 25
  3. Distinctive:

    When commits are on: the instruction to commit this finding alone, with a message that names the rule and the scope.

    line 37
  4. Very specific:

    A <question>: ask the user. Re-dispatch the author once with the answer.

    line 46
  5. Distinctive:

    No finding is set aside without the user choosing it.

    line 56

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Fix review findings

Turn a review-module report into a series of small, separately verified changes. You dispatch and route; terraform-author writes. You never edit the report, and you never write Terraform yourself.

The argument is the path to the report. A finding in it carries an ID, a rule, a severity, Evidence, Plan impact, Fix and Verify (the format in skills/review-module/references/report.md). If the path is missing or holds no findings, say so and stop.

Choose what to fix

Read the report once. Then ask one AskUserQuestion dialog with two questions:

  1. Which findings to fix. List each finding as ID, severity and rule. Offer, recommended first: the Critical and High findings, all findings, or pick by ID.
  2. Whether to commit per finding or leave the changes uncommitted.

Ask these two questions once, together; do not repeat them per finding.

When AskUserQuestion is not available, ask the same two questions in one plain-text message. Number the two questions, write each as a question ending in a question mark, and letter its choices with the recommended choice first, marked recommended. List each finding as ID, severity and rule, as in the dialog. Keep all three choices for question 1, even when two of them select the same findings. Stop until the user answers.

Run the loop

Take the chosen findings in report order. For each one, run the steps below to the end before starting the next.

  1. Dispatch terraform-author once, with these inputs:
    • Scope: the file in the finding's Evidence, and the root module it belongs to.
    • Change: the finding's Fix, quoted, with its rule ID and its Verify line.
    • Expected plan outcome, derived from Plan impact: create-only, no-changes, moves-only, or review-required with the actions named. When Plan impact does not settle it ("none; risk is operational" does not), use review-required and name the actions the Fix implies; if you cannot name them, ask the user.
    • When commits are on: the instruction to commit this finding alone, with a message that names the rule and the scope.
  2. Read the author's report. <status>done</status> with no failing <gate> goes to step 3. Anything else goes to Escalate.
  3. Run the check-module skill on the touched module and compare its result with the finding's Verify line. A failing check is a failed gate for Escalate, and its output is what you hand back. Then run the finding's Verify line yourself when it is a read-only command the session may run (a grep, terraform validate). When it needs a plan or anything not permitted, do not run it: the outcome is "fixed, unverified", and you name the unrun Verify line under the hand-off table.
  4. Record the outcome (fixed, "fixed, unverified", deferred as unresolved, or not reached), the commit SHA when there is one, and any <question> the author left, for the hand-off.

Escalate

Route a blocked or failed author report by its kind:

  • A <question>: ask the user. Re-dispatch the author once with the answer.
  • A fact gap (consumers, addresses, roots the author could not establish): dispatch terraform-researcher with that one question and the path it concerns. Re-dispatch the author once with the facts it returns.
  • A <gate result="fail">: re-dispatch the author once with the failing output.
  • A conflict with the expected plan, or a second failure on the same finding: dispatch terraform-advisor with the question, the finding and the reports so far. Then ask the user, with exactly these choices:
    1. Re-dispatch with the user's answer.
    2. Take the advisor's alternative.
    3. Defer the finding to the hand-off as unresolved.
    4. Stop the loop.
  • Any other blocked report (for example a scope boundary or an unavailable describe named in <blocking>): go straight to the user, quote the author's <blocking> text, and offer the same four choices as the conflict route. Add no fifth choice.

No finding is set aside without the user choosing it. Stopping the loop still ends with the hand-off table.

Hand off

End with one table, one row per chosen finding:

FindingRuleSeverityOutcomeCommit

Outcome is fixed, "fixed, unverified", deferred as unresolved, or not reached. Commit is the SHA, or - when none. Under the table list each open <question>, each deferred finding's reason, each "fixed, unverified" finding's unrun Verify line, and any follow-up the author named for the user to run. The report is unchanged.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.