agentleFS
sumithrsumithr/sumo-qa/.github/copilot-instructions.md

sumo-qa

Copilot instructions7 starsChanged 40 days agoApache-2.0View on GitHub

Hard rule: for any QA-shaped request — testing, test plan, test strategy, test approach, regression scope, risk-based testing, exploratory testing, code review for safety-to-merge, scaffolding tests, TDD, mutation testing, finding or validating test data, QA audit, test pyramid design — you MUST call using_sumo_qa (the entry router) before answering. Do not produce QA advice from general training-data knowledge. When citing principles, techniques, classifications, or approaches, load them first via the sumo_qa_load_* tools and cite the loaded catalogue verbatim; say "not…

The file

We split this copilot-instructions.md into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    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:

    When creating GitHub issues, use the closest template in .github/ISSUE_TEMPLATE/ and include every required field in the issue body.

    line 62

≈ “Common” is an estimate: at least 1 in 5 of the 3,779 Copilot instructions 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
copilot-instructions.md

QA tasks via sumo-qa MCP

Hard rule: for any QA-shaped request — testing, test plan, test strategy, test approach, regression scope, risk-based testing, exploratory testing, code review for safety-to-merge, scaffolding tests, TDD, mutation testing, finding or validating test data, QA audit, test pyramid design — you MUST call using_sumo_qa (the entry router) before answering. Do not produce QA advice from general training-data knowledge. When citing principles, techniques, classifications, or approaches, load them first via the sumo_qa_load_* tools and cite the loaded catalogue verbatim; say "not in the catalogue" rather than supplementing from memory.

First hop: every QA-shaped request, including a development-framed one such as "I'm adding X, how should I test it?", "what tests do I need?" or "write the failing tests first", calls using_sumo_qa before any other sumo-qa tool and before any QA advice, then sumo_qa_deciding_approach, then the one skill it routes to. No specialist skill is entered directly. An underspecified QA request still takes the first hop before you ask the user anything; sumo_qa_deciding_approach, or the skill it routes to, asks the one clarifying question it needs.

For QA-shaped requests in this repo (test plans, code review, scaffolding tests, finding test data, deciding QA approach), call the relevant skill tool on the sumo-qa MCP server and follow the checklist it returns.

Available skills (each registered as an MCP tool named after the skill, hyphens replaced by underscores). Every skill after the first two is reached through sumo_qa_deciding_approach, never called as the first hop:

  • using_sumo_qa — entry router; load this first for any QA intent
  • sumo_qa_deciding_approach — pick the QA approach for the work
  • sumo_qa_preparing_for_work — plan QA before coding starts
  • sumo_qa_creating_test_plan — produce entry/exit criteria, phases, deliverables
  • sumo_qa_implementing_with_tdd — red-green-refactor cycle
  • sumo_qa_reviewing_before_merge — review local diff
  • sumo_qa_strengthening_tests — mutation-testing follow-up
  • sumo_qa_finding_test_data — known-good test data discovery and validation
  • sumo_qa_answering_testing_question — generic "how do I test this?"
  • sumo_qa_strategising — repo-wide QA strategy
  • sumo_qa_planning_qa_rollout — turn a QA chunk into a written plan of bite-sized tasks
  • sumo_qa_executing_qa_rollout — dispatch a signed-off plan task-by-task to fresh subagents
  • sumo_qa_finishing_qa_work — capture evidence and write a PR-ready summary
  • sumo_qa_measuring_coverage — run the repo's coverage/mutation tools, collect the results, persist them for the QA report
  • sumo_qa_suggesting_external_skill — fallback when no native skill fits the intent
  • sumo_qa_closing_qa_gaps — close a named uncovered-behavior gap, one evidenced loop at a time
  • sumo_qa_triaging_test_failures — triage a failing/flaky test: classify the cause, name the smallest isolation step before any fix
  • sumo_qa_security_testing: select deeper security evidence for explicit security testing or a grounded security gap

The skills carry the senior-QA discipline (Iron Laws, checklists, Red Flags). Knowledge catalogues are accessed via the sumo_qa_load_* tools — use them for principles, techniques, classifications, approaches, and specialty tool fits before relying on training-data knowledge.

Repo-map accelerators: when a .sumo-qa/repo-map.json artifact is present, sumo_qa_scan_repo, sumo_qa_analyze_diff_impact, and sumo_qa_query_repo_map provide fast, deterministic evidence over the codebase (inventory, changed-file impact, ranked search) for the review, strategy, and prepare-for-work skills. sumo_qa_generate_qa_report composes the persisted .sumo-qa artifacts into the static local QA report (.sumo-qa/qa-report.html) when the user asks for a QA report or dashboard.

When creating GitHub issues, use the closest template in .github/ISSUE_TEMPLATE/ and include every required field in the issue body. For implementation tasks raised by an AI agent, use .github/ISSUE_TEMPLATE/ai-task.yml unless a more specific template fits better.

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.