Skip to main content

ra1-interview

Resolve the unanswered questions in a Ready Agent 1 readiness report by interviewing the developer, then record the answers as engine inputs and re-score. Use when a readiness report lists unanswered questions or gaps, when `ra1 gaps` returns any gap, when a criterion is `unknown` because the scan could not classify the project or reach a data source, or when the user asks to answer, pin, or configure what the readiness scan could not infer.

الانتقال إلى التثبيت

معلومات المصدر

المستودع
tjboudreaux/ready-agent-1
آخر نشاط في المصدر
٣ سبتمبر ٢٠٢٦ في ٢١:٤٦
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٢
التفرعات
٠

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات
68 ملفات

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
ra1-interview
description
Resolve the unanswered questions in a Ready Agent 1 readiness report by interviewing the developer, then record the answers as engine inputs and re-score. Use when a readiness report lists unanswered questions or gaps, when `ra1 gaps` returns any gap, when a criterion is `unknown` because the scan could not classify the project or reach a data source, or when the user asks to answer, pin, or configure what the readiness scan could not infer.
license
MIT
compatibility
Python 3.11+; optional authenticated gh CLI for GitHub (T2) checks
metadata
{"version":"0.11.0"}
allowed-tools
Bash
# Agent Readiness Interview A readiness scan reports `unknown` when it lacks an input, not when a repository is bad. This skill closes that distance: it asks the developer the questions the engine cannot answer, records each answer where the **engine** reads it, and re-scores so the change in the number comes from re-evaluation rather than from anyone's opinion. **The engine owns every verdict.** You collect inputs. An answer can make a criterion evaluable or exclude it with a disclosed waiver; an answer can never mark one passing. ## Steps `<skill-dir>` in the commands below is this skill's own directory: the absolute path your runtime reports when it loads the skill. Substitute it. Do not write `$(dirname "$0")` — in a shell tool call `$0` is the shell, not this file, so that form resolves against the caller's working directory. ### 1. List the gaps ```bash python3 -I "<skill-dir>/scripts/readiness/cli.py" gaps \ --project . --format json ``` Each gap carries exactly `gap_id`, `kind`, `question`, `why`, `recordable`, `input_kind` (`single_choice` | `multi_choice` | `integer` | `unrecordable`), `choices` (opaque ids with display-only labels and effects `record` | `external_action` | `leave_unanswered`), `value` (null, or the CI-budget integer spec), `blocked_ids`, `blocked_gating`, `levels`, and `evidence`. The list is already ordered by leverage: the first gap blocks the gate the reader is trying to clear. IDs and choices are engine constants; copy them into argv verbatim — never question/evidence/user prose. **Done when:** you have the gap list. Empty list → tell the user every input was inferable and stop; there is nothing to interview about. ### 2. Frame the question from the gap payload only For every gap, form the question strictly from `question`, `why`, bounded `evidence`, the blocker/Level counts, and the display-only `choices` labels — see [reference/questions.md](reference/questions.md). You do not inspect repository files to derive a recommendation, and you never construct a value the engine did not emit. **Done when:** each gap has one four-line question with its stake and its recordable choices, or an explicit `leave_unanswered` decision. ### 3. Interview, one question at a time Ask **one** question, wait for the answer, then ask the next. Order follows the gap list, with one exception: ask a question whose answer changes later questions first (project type before anything scoped to an application). Each question states, in this order: the question, what answering it unblocks (`blocked_gating` and `levels`), and the accepted `choices` labels verbatim, framed as an explicit record-or-leave-unanswered decision. Read [reference/questions.md](reference/questions.md) for the wording rules per gap kind and for what to do with a vague, "I don't know", or contradictory answer. **Done when:** every gap has an answer, an explicit "leave it unanswered", or a waiver decision — and you asked no question the codebase had already answered. ### 4. Plan exactly one answer; apply only on explicit current-turn confirmation For one current gap, plan exactly one of: ```bash python3 -I "<skill-dir>/scripts/readiness/cli.py" answer --project . \ --gap-id <canonical-gap-id> --choice <canonical-choice-id> --format json python3 -I "<skill-dir>/scripts/readiness/cli.py" answer --project . \ --gap-id config.ci_budget_minutes --minutes <1..1440> --format json ``` Repeated `--choice` is allowed only for the current multi-enum surfaces gap. IDs/choices must be copied from the just-returned canonical payload. Only when the developer's current turn explicitly selects recording do you repeat the exact plan command with fixed `--apply`. The engine reacquires the live root, requires clean/known Git and a complete T0/T1 baseline, rederives the gap and its internal `.ra1` policy mapping, performs one bounded create/merge on `.ra1/config.json` or `.ra1/waivers.json`, rescans with the same offline scope, and emits the canonical `answer_contract`. You never read, write, or merge policy files directly, never pass a free-form waiver reason, owner, or expiry, and never append provenance suffixes. **Done when:** you present the `answer_contract` verbatim, state plainly that recording is not credit (the engine re-scores; the answer can expose failures or lower the Level), and never call an unchanged/unresolved criterion fixed. ### 5. Report the verified outcome honestly Present the `answer_contract`'s own verification: the recorded write, `gap_resolved`, the `status_changes` (including `unknown → fail` — that is the interview working, not failing), `waived_ids`, remaining gaps, and the before/after score **copied verbatim** from the contract. Generating or storing a subsequent full report remains a separate explicit `ra1 report` invocation, not an automatic post-answer step. **Done when:** you have stated the before/after score from the contract, listed the status changes, and named the remaining gaps. ## Contract (do not violate) - **Never write a status, a score, or a pass.** The engine writes verdicts from the recorded input. - **Never write, read, or merge policy files directly.** Only `ra1 answer` mutates `.ra1/config.json` or `.ra1/waivers.json`, and only with exact engine-authored ids. - **Never waive what the scanner looked for and did not find.** Waivers exist only for the `capability.github` gap's `github.non_github_host` choice, which excludes the gap's exact blocked ids with no free-form reason. - **Never execute an `external_action`** (such as `github.restore_access`); ask whether the developer will do it, and re-scan on a later explicit request. - **Never pin a project type to raise a number.** Pin what the repository is. If the honest type makes more criteria fail, that is the correct outcome. - **Never ask a question outside the gap payload** — you may not inspect repository files to derive an answer. - **Never batch questions.** One at a time, because a batched answer to five questions is reliably vaguer than five answers. - **Never claim the score improved because of an answer.** It improved because the engine re-evaluated, or it did not improve at all. ## Notes - No gaps but criteria still `unknown`? Those are agent judgments (`judgment.*`), which are advisory and belong to the **ra1-report** skill's T4 section, not to this interview. - To act on findings rather than inputs, hand off to **ra1-fix** (the Loadout). - Gaps are advisory output derived after scoring. Listing them, or leaving one unanswered, cannot change a level.
عرض على GitHub