agentleFS
Sign inStart free
mehrad-dmmehrad-dm/mastermind/skills/analyze/SKILL.md

analyze

Skill23 starsChanged 2 months agoMITView on GitHub

Use when a feature's spec, plan and task list all exist and need checking against each other before code is written: \"check the spec and plan agree\", \"is this ready to build?\", \"find gaps before we start\", \"analyze the feature docs\", or before building anything that touches money, auth or data from a task list. Not for checking code against intent after building (that's `converge`), not for analyzing code, performance or a bug.

70 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use revise, write and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • stormlightlabsSkill

    revise

    Address review comments on an open pull request and push the fixes. Use for /edit, /revise, or when asked to respond to review feedback on a PR number.

    Also in 3 projects that use this

  • DockerSkill

    write

    Write or edit reader-facing technical prose for immediate comprehension. Use for documentation, PR titles and descriptions, release notes, design documents, user-facing explanations, and substantive comments. Also use when asked to make writing clearer, more natural, less AI-generated, or easier to read. For documentation fixes, handles edits, formatting, self-review, and commits after research identifies what to change. Do not use for code-only tasks with no prose deliverable.

    Also in 6 projects that use this

  • H-mmerSkill

    submit

    Draft and submit a vulnerability report to the bug bounty platform. Reads scope.yaml for platform/program, uses brain + findings for content. Always drafts first for review.

    Also in 3 projects that use this

  • GoogleSkill

    quality

    Evaluates whether a GitHub issue is spam, empty, needs more information, or is OK to proceed.

    Also in 3 projects that use this

  • JosBen74Skill

    osint

    OSINT-sökning och informationsinhämtning från öppna källor för Länsstyrelsen VG

    Also in 3 projects that use this

  • AICreator-WindSkill

    careful

    安全护栏工具。危险操作警告。

    Also in 4 projects that use this

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 60 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

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

    Coverage: Every FR-### and US#/AC# maps to at least one task.

    line 30

“Common” is measured: kept by at least 6 in 10 of the 60 edited versions of this file we could read. “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

MasterMind: Analyze

A read-only consistency pass over spec.md, plan.md, tasks.md and the constitution, run before any code exists, when a gap still costs a sentence instead of a rewrite. Layout and IDs: ~/.mastermind/engineering/core/spec-driven.md. Feature: $ARGUMENTS.

It never edits a file. It reports, then offers fixes the user approves.

Who runs it

The context that wrote the documents already believes they agree. Dispatch a fresh-context subagent with the four files and this skill's six passes, and nothing about how they were written. Where no isolated context exists, run it yourself and label the report self-graded.

The six passes

  1. Duplication. Two requirements saying the same thing in different words. Keep the clearer one.
  2. Ambiguity. Adjectives with no number ("fast", "secure", "scalable"), and unfilled template text: TODO, ???, a template's own <placeholder> lines, unresolved [NEEDS CLARIFICATION]. Angle brackets in command syntax such as notes add <text> are not placeholders.
  3. Underspecification. A requirement with a verb and no measurable outcome, a story with no acceptance criterion, a task naming a file or component the spec and plan never define.
  4. Constitution. Any requirement, plan decision or task that conflicts with a MUST, or a principle the plan's gate marked pass that the tasks then break.
  5. Coverage. Every FR-### and US#/AC# maps to at least one task. Every task maps to a requirement or story, or is setup, foundation or polish. Success criteria needing build work have tasks.
  6. Inconsistency. The same thing named two ways (check the brief's glossary), an entity in the plan absent from the spec, a task ordered before the task it depends on, two requirements that contradict.

Severity

LevelWhen
CRITICALbreaks a constitution MUST, a core file is missing, or a P1 requirement has no task
HIGHa duplicate or conflicting requirement, an untestable acceptance criterion, a security or data ambiguity
MEDIUMterminology drift, a non-functional requirement with no task, an underspecified edge case
LOWwording, a minor redundancy

The report

| ID | Pass | Severity | Where | Finding | Fix |
| A1 | coverage | CRITICAL | spec.md FR-004 | no task implements export limits | add a task to US2 |

At most 50 rows, highest severity first; summarize the rest by pass. Then the counts: requirements, tasks, coverage percentage, findings by severity. End with one verdict: ready to build, fix first (any CRITICAL), or ready with known gaps (named).

Gotchas

  • Report what is there. A missing section is reported as missing. Never inferred, never invented.
  • The constitution is not negotiable here. A conflict with a MUST is fixed in the spec, plan or tasks, or the constitution is amended on purpose. analyze never softens the principle.
  • Twelve LOW findings bury one CRITICAL. Lead with severity; collapse the low ones to a count.
  • Same input, same findings. Re-running on unchanged files with different results means the passes were applied loosely. Apply each pass to every requirement, in order.

After the report

Offer the concrete edits for the top findings and apply only the ones the user approves. After an approved edit to spec.md or plan.md, re-run breakdown's coverage check so the tasks still match. A fix that changes behavior the user already had is a product decision: ask before applying it.

Then run mastermind next and end with the step it names, so the user sees where the feature stands.

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.

Check your setup, free