agentleFS
Sign inStart free
akovalionakovalion/paranoid-qa/skills/interview/SKILL.md

interview

Skill16 starsChanged 24 days agoMITView on GitHub

Structured requirements gathering through a series of questions. Use when the task is described verbally/informally (not from an issue tracker ticket) and scope, AC, and edge cases need clarifying before work starts.

94 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use fetch-library-docs, contributor and 10 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.
  • Rehan-Ul-HaqSkill

    fetch-library-docs

    Fetches official documentation for external libraries and frameworks (React, Next.js, Prisma, FastAPI, Express, Tailwind, MongoDB, etc.) with 60-90% token savings via content-type filtering. Use this skill when implementing features using library APIs, debugging library-specific errors, troubleshooting configuration issues, installing or setting up frameworks, integrating third-party packages, upgrading between library versions, or looking up correct API patterns and best practices. Triggers automatically during coding work - fetch docs before writing library code to get correct patterns, not after guessing wrong.

    Also in 4 projects that use this

  • NimbleBrainIncSkill

    contributor

    Get started contributing to NimbleBrain open source — find an integration to build, set up your environment, propose an idea, or check on your work. Use when onboarding as a contributor. Triggers include "I'm a new contributor", "what should I build", "show me open issues", "file an issue".

    Also in 3 projects that use this

  • mjunaidcaSkill

    browsing-with-playwright

    Browser automation using Playwright MCP. Navigate websites, fill forms, click elements, take screenshots, and extract data. Use when tasks require web browsing, form submission, web scraping, UI testing, or any browser interaction. NOT when only fetching static content (use curl/wget instead).

    Also in 4 projects that use this

  • qa-amanSkill

    teach-me

    Teach a topic, video, article, codebase change, spec, or transcript until the user demonstrably understands it, using staged instruction, a running checklist doc, and quizzes. Use whenever the user says "teach me", "explain this in detail", "help me understand X", "/teach-me", "walk me through this", "I want to learn X", "understand this deeply", or pastes a YouTube URL, article, paper, PR, or spec and asks to understand it rather than summarize it. Also use when the user wants study notes or raw material from a source they are learning. Do NOT use for a quick factual lookup, a summary request, or when the user just wants the answer.

    Also in 8 projects that use this

  • trebaudSkill

    find-unknowns

    Workflow for surfacing a task's unknowns before, during, and after implementation — blind spot pass, brainstorm/prototype, interview, references, implementation plan, deviation notes, quiz. Use when starting work in an unfamiliar domain or codebase, when a task feels underspecified, when the user says "find my unknowns", "blindspot pass", "what am I missing", "help me scope this", or when a long task came back wrong.

    Also in 3 projects that use this

  • donatassimkusSkill

    offer

    Offer design, pricing strategy, and business model architecture. Invoke when asked about making an offer better, pricing a product or service, naming an offer, raising prices, generating fast cash, increasing lifetime value, finding the right customer, qualifying buyers, or designing a business model where customers pay for their own acquisition. Use when someone says their offer isn't converting, they need to charge more, they want to add bonuses or guarantees, or they need a money model for their business.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 80 edited versions we read keep these.

  • 4

    Distinctive

    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. Distinctive:

    No AC, no mockups, no clear scope

    line 15
  2. Very specific:

    If the task already comes from an issue tracker (Jira etc.) with a full description — this skill is not needed: gather context straight …

    line 18
  3. Very specific:

    Round 1: scope and context: Ask 3-4 questions via AskUserQuestion:

    line 22
  4. Distinctive:

    Round 3: clarifications on remaining gaps: Only if critical gaps remain after rounds 1-2.

    line 34
  5. Distinctive:

    If the user answers "don't know" — log it as a question for the analyst, do not push

    line 76
  6. Distinctive:

    Use concrete answer options in questions (AskUserQuestion options), not open-ended wording

    line 77

“Common” is measured: kept by at least 6 in 10 of the 80 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

Interview: requirements gathering through questions

Help the user turn an informal task description into complete requirements ready to hand off to the test-cases or testing skills.

When to apply

  • The task is described verbally or in general terms, without a ticket
  • No AC, no mockups, no clear scope
  • The user is unsure what exactly to test/automate

If the task already comes from an issue tracker (Jira etc.) with a full description — this skill is not needed: gather context straight from the ticket (via the tracker's MCP: description, comments, attachments, linked issues) and hand off to test-cases.

Process

Round 1: scope and context. Ask 3-4 questions via AskUserQuestion:

  • What exactly is being checked (feature, page, element)
  • Where it lives (URL, screen, navigation path)
  • Task type (new functionality / regression / bug)
  • Platforms (desktop / mobile / both)

Round 2: behavior and AC. Based on the round 1 answers:

  • Happy path — what behavior counts as correct
  • Edge cases — which negative scenarios matter
  • UI states (loading, error, empty, disabled) — if applicable
  • Integrations — any APIs / external services

Round 3: clarifications on remaining gaps. Only if critical gaps remain after rounds 1-2. Group related questions.

Maximum 3 rounds. If the requirements are still incomplete — log the gaps as "Questions for the analyst/PM" and work with what you have.

Output format

Once the interview is done, assemble a structured summary:

# Requirements: <short task name>

## Context
- Type: <new feature / regression / bug>
- Platforms: <desktop / mobile / both>
- URL / location: <…>

## Scope
<what exactly is being checked, briefly>

## Acceptance Criteria
- <AC 1>
- <AC 2>

## Scenarios
**Happy path:** <description>

**Edge cases:**
- <case 1>
- <case 2>

## Integrations
<APIs, external services — if any>

## Open questions for the analyst/PM
- <question 1>

Save the summary to an md file (e.g. requirements_<task_name>.md in the current working directory) and offer to hand it off to test-cases or testing.

What to prefer

  • 4 precise questions beat 10 boilerplate ones
  • Tie questions to the previous round's answers instead of running down a checklist
  • If the user answers "don't know" — log it as a question for the analyst, do not push
  • Use concrete answer options in questions (AskUserQuestion options), not open-ended wording

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