featureparity 0.0.27 → 0.0.29

data/skills/fp/SKILL.md

@@ -17,6 +17,14 @@ command -v fp && fp --version
 ```
 
 If missing: `gem install featureparity` (or `bundle exec fp` inside an app that already depends on the gem).
+`fp doctor` checks the install, the config and the repo without an API key. If `fp` fails
+inside a repo but works elsewhere, see Troubleshooting.
+
+**Already read the repo's FeatureParity section?** `fp init` writes one into `AGENTS.md`
+(or `CLAUDE.md`), and it carries the modeling rules (§1), the requirement-writing standard
+(§5), onboarding and troubleshooting from this file word for word, between the same
+`fp-shared` comments. This file is their source. Skip those blocks if you've read them
+there; the rest of this skill is the command reference.
 
 ## Non-interactive rules
 
@@ -49,6 +57,8 @@ every project the user belongs to; never ask for a per-project key.
 fp list --project stowzilla                    # All active requirements
 fp list --project stowzilla --status draft     # Proposed work; avoid duplicates
 fp list --project stowzilla --gaps             # Requirements with a required surface lacking evidence
+fp list --project stowzilla --status draft --gaps  # Drafts with a required surface lacking evidence
+fp coverage --project stowzilla                # Drafts × surfaces, then the drafts with no evidence
 fp show <slug> --project stowzilla             # Requirement details and evidence
 fp history <slug> --project stowzilla          # Origins and pending changes
 fp changes --source-url <work-item-url>         # Activity prompted by one card, issue, or thread
@@ -57,25 +67,32 @@ fp matrix --project stowzilla --csv            # Export as CSV
 fp check --project stowzilla                   # Enforce parity (exits 1 on violations)
 ```
 
-Treat FeatureParity as the human-readable product specification, not a bookkeeping step.
-Before coding, inventory the entire request: user-visible behaviours, policies, limits,
-plans, deadlines, state transitions, permissions, failure modes, and affected surfaces.
-Compare all of it with active and draft requirements, including adjacent requirements the
-change might make inaccurate.
-
-Model that scope deliberately:
-
-- One independently testable or independently failable product promise per focused
-  requirement. Split an acceptance sentence when its clauses could pass or fail separately.
-- Use a parent for a broad capability and children for distinct behaviours, policies, or
-  surface-specific promises. Do not model implementation details with no product promise.
-- Record concrete decisions such as prices, quotas, dates, roles, and fallbacks in acceptance
-  criteria rather than leaving them as assumptions in code or a pull request.
-- Propose changes to existing requirements whose meaning moved; adding a new requirement is
-  not enough if it leaves an old one false.
-- Reconcile again before finishing: every shipped behaviour maps to a current requirement,
-  every changed promise is recorded, and every focused requirement has marked evidence or
-  remains an explicit gap. Never let one broad marker imply coverage of untested clauses.
+<!-- fp-shared:begin modeling -->
+**The requirement catalog is the human-readable product specification, not a box to
+tick with one umbrella record.** It records the team's current shared understanding;
+it is not a finished decree handed from product to engineering. Refine requirements
+through ongoing conversation with customers, domain experts, and builders. The human
+product owner decides value and priority; agents should surface gaps, inconsistencies,
+alternatives, and useful splits rather than silently making product decisions.
+
+Before coding, enumerate the independently meaningful promises in the request:
+user-visible behaviours, policies, limits, plans, deadlines, state transitions,
+permissions, failure modes, and affected surfaces. Then model them:
+
+- Give each independently testable or independently failable product promise its own
+  focused requirement. If one acceptance sentence joins behaviours that could pass or
+  fail separately, split it.
+- Use a parent for the broad capability and children for distinct behaviours, policies,
+  or surface-specific promises. Do not create requirements for implementation details
+  or refactors that make no product promise.
+- Put concrete product decisions — prices, quotas, dates, roles, fallbacks — in the
+  requirement acceptance criteria. Never leave them only as assumptions in code or a PR.
+- Check adjacent requirements and their history. New requirements do not excuse an old
+  requirement that the work makes inaccurate; propose a change to keep the whole catalog true.
+- Before finishing, reconcile the implementation against the catalog: every shipped
+  behaviour maps to a current requirement, every changed promise is recorded, and every
+  focused requirement has appropriate marked evidence or an explicit gap. A broad marker
+  must never appear to prove several acceptance clauses that its test does not exercise.
 
 **Prevent contradictions before they enter the catalog.** Before proposing a new or changed
 promise, compare its intended acceptance criteria with related active and draft requirements
@@ -83,31 +100,35 @@ and read their history. Ask whether both promises can be true at the same time f
 user, state, and conditions. If not, do not add another requirement.
 
 A failing test bound to an existing requirement, or an implementation that only works by
-changing one, is a contradiction signal — not permission to weaken the test or write a second
-requirement around it. Identify which promise matches product intent, then use
-`fp propose-change` (or `--removal`) with the source and reason to put that decision before a
-human. If the intent is unclear, stop and ask rather than making the catalog say both things.
+changing one, is a contradiction signal — not permission to weaken the test or write a
+second requirement around it. Identify which promise matches product intent, then use
+`fp propose-change` (or `--removal`) with the source and reason to put that decision before
+a human. If the intent is unclear, stop and ask rather than making the catalog say both things.
 
 **Treat existing tests as protected product evidence.** Before editing an existing test,
 determine what expectation it already records and whether CI has passing evidence for it.
 
-- If the test backs passing evidence, do not rewrite it to make the current implementation or a
-  new requirement fit. Explicitly flag the intended test edit in the work item and pull request.
-  If its expected behaviour would change, propose the requirement change and wait for explicit
-  human approval before editing the test; a newly green run must not hide that the proof changed.
-- When FeatureParity reports a changed bound test, run `fp changed-tests` (or add `--json`) and
-  compare its accepted and candidate revisions with the requirement. Record a plain-language
-  assessment for the exact candidate fingerprint with `fp changed-tests assess`: `still_proves`
-  resolves only that fingerprint; `no_longer_proves` and `uncertain` remain open for a human
-  product decision. A later fingerprint always needs a new assessment.
-- A new requirement does not retroactively own or supersede a pre-existing failing test, whether
-  it is draft or active. Do not change that test, or adopt it as the new requirement's proof,
-  merely to make new work pass. Surface the conflict and wait for explicit human approval to
-  change the existing expectation.
-
-A changed-test finding is an audit signal alongside the independent CI outcome, not a failed
-test. It is also separate from `suspect`, which means requirement wording changed and its
-evidence needs re-verification. Neither permits rewriting a test before product intent is decided.
+- If the test backs passing evidence, do not rewrite it to make the current implementation
+  or a new requirement fit. Explicitly flag the intended test edit in the work item and pull
+  request. If its expected behaviour would change, propose the requirement change and wait
+  for explicit human approval before editing the test; a newly green run must not hide that
+  the proof itself changed.
+- When FeatureParity reports a changed bound test, run `fp changed-tests` (or add `--json`)
+  and compare the accepted and candidate source revisions with the requirement. Record the
+  exact candidate through `fp changed-tests assess <id> --candidate-fingerprint <sha256>`
+  with a plain-language explanation and one classification: `still_proves`,
+  `no_longer_proves`, or `uncertain`. The first resolves only that fingerprint; the others
+  remain open for a human product decision. A later fingerprint needs a new assessment.
+- A new requirement does not retroactively own or supersede a pre-existing failing test —
+  whether the requirement is draft or active. Do not change that test, or adopt it as the new
+  requirement's proof, merely to make the new work pass. Surface the conflict and wait for
+  explicit human approval to change the existing expectation.
+
+A changed-test finding is an audit signal alongside the testcase's independent CI outcome.
+It is not a failed test and is separate from `suspect`, which means requirement wording
+changed and its evidence needs re-verification. Neither permits rewriting a test before
+product intent is decided.
+<!-- fp-shared:end modeling -->
 
 ### 2. Add the fp:<slug> marker to tests
 
@@ -151,16 +172,26 @@ first CI run, or local work where CI isn't wired up. When you do report over a C
 cell anyway, `fp report` now tells you it was superseded (the status stays CI's, your
 report lands as metadata only) so you can see the no-op instead of assuming it took.
 
-### 4. Report evidence from JUnit XML (batch upload without CI)
+### 4. Report evidence from a test run (batch upload without CI)
+
+When CI isn't available, run the suite locally and upload the report. `fp run` adds a
+report formatter to rspec, pytest, vitest or playwright itself, so the project needs no
+new dependency, then reports exactly as `fp report --junit` would:
+
+```bash
+fp run --surface api --repo stowzilla/marketplace \
+  --work-item https://app.fizzy.do/123/cards/456 -- bundle exec rspec
+```
 
-When CI isn't available, run the suite locally and upload the report:
+Or make the report yourself. `--junit` takes JUnit XML or RSpec's built-in JSON, which
+needs no extra gem (`fp init --detect` prints the command for each runner it finds):
 
 ```bash
-# 1. Generate JUnit XML
-rspec --format RspecJunitFormatter --out junit.xml
+# 1. Write a report
+bundle exec rspec --format progress --format json --out rspec.json
 
 # 2. Upload — one call covers every marked test
-fp report --junit junit.xml \
+fp report --junit rspec.json \
   --project stowzilla \
   --surface api \
   --repo stowzilla/marketplace \
@@ -173,79 +204,95 @@ fp report --junit junit.xml \
 - `--surface` is the default; markers can override with `@suffix`
 - `--base-dir DIR` sets where relative paths resolve from
 
+#### Optional: attach screenshots and video, with permission
+
+<!-- fp-shared:begin media -->
+**Media is optional, and only with permission.** A test that drives a user interface can
+carry the screenshots and videos it recorded as visual evidence, shown under that test's
+receipt on the requirement page. Nothing requires it: a receipt counts the same with or
+without media, and a capture never changes a cell's state. Uploading stores the files in
+FeatureParity, so:
+
+- **Ask first.** Upload only when the person you're working for has said yes, for this
+  project. Don't do it by default, and don't take "the run recorded something" as permission.
+- **Never capture someone's own screen.** No screenshots or recordings of their desktop,
+  terminal, browser session or other windows. Only what an automated test drove (a
+  Playwright browser, a simulator or emulator the test launched) can be attached, and only
+  with that permission.
+- **Look before you upload.** Don't attach a capture that shows real people's data, secrets
+  or anything outside the test.
+
+When you have the go-ahead:
+
+- **Playwright** lists its recorded files in the JUnit report as `[[ATTACHMENT|…]]`.
+  `fp report --junit results.xml --surface web --repo <org/repo> --attach-media` uploads
+  one set per bound test, titled with the test's name. It also works with `fp run ... -- npx playwright test`.
+  Without `--attach-media`, nothing is uploaded; fp only says how many captures it found.
+- **One capture from a test** (for example an XCUITest or Espresso recording):
+  `fp attach <slug> <file> --surface <surface> --example-title "<test name>"`.
+- png, jpg, gif, webp, mp4, webm or mov, up to 100 MB. `fp attachments <slug>` lists them;
+  `fp attach rm <slug> <id>` removes one.
+<!-- fp-shared:end media -->
+
 ### 5. Write and propose decision-ready requirements
 
-A requirement is a product decision a reviewer can approve, not a design task for an
-engineer to carry out. It should sound like a capable teammate wrote it: natural, direct,
-and specific enough to protect an outcome without dictating an accidental solution.
-
-Treat the catalog as the current record of shared understanding, not a finished specification
-handed from a product owner to implementers. Requirements are discovered and refined through
-ongoing conversation among customers, domain experts, and builders. The human product owner
-makes the final value and priority decisions; agents participate by exposing gaps,
-inconsistencies, alternatives, and useful splits. Prefer customer outcomes over devotion to a
-feature list.
-
-Before drafting:
-
-- Learn from the request, related requirements and history, support reports, research, and
-  observed user behaviour when available. Look for what people attempt, where they abandon a
-  task, what they actually use, and what experiments reveal. That evidence may expose a
-  different need from the first solution they suggested.
-- Separate facts and decided policy from open questions. Never turn a missing decision into
-  a plausible-sounding price, quota, timeout, count, date, role, or fallback. Ask when the
-  answer changes the product promise.
-- Identify the actor, the situation that triggers the need, the valuable outcome, and material
-  boundaries such as permissions, failures, and affected surfaces.
-- Keep one independently failable promise per requirement. Use a parent and focused children
-  when a capability contains several decisions.
-
-Write each field for a reviewer, not for the implementation:
-
-- **Title:** one clear product promise in present tense, with a concrete subject and active
-  verb. Name the capability or outcome, not the project (`Dispatchers see current shipment
-  status`, not `Implement status polling`).
-- **Why:** one natural sentence saying who needs this, the problem or risk, and the outcome
-  worth protecting. Do not repeat the title, narrate the request or bug history, advertise
-  the feature, or explain how it will be built. Delete AI filler such as “ensure a seamless,
-  robust experience.”
-- **Acceptance:** one independently verifiable rule of observable behaviour that lets someone
-  decide whether the promise is true. State the relevant trigger or situation, the result, and
-  material boundaries that qualify that same promise. Given/When/Then may clarify those parts, but it
-  is not a mandatory template. Split a second result that could fail independently into its
-  own requirement instead of comma-chaining it here.
-- **Example:** supply one concise concrete case that would pass the general rule, and put it
-  after the rule in Acceptance as `Example: ...`. Use the domain's real terms and
-  representative data, but ask rather than invent consequential policy. Do not mistake a few
-  examples for the rule or let executable tests stand for every case; neither replaces the
-  general rule and continued conversation.
-- **Numbers and policy:** include a number only when the source made it a real product decision
-  or an external constraint requires it. Do not invent implementation defaults and present
-  them as scope.
-- **Implementation detail:** omit components, data models, algorithms, endpoints, polling
-  intervals, and UI controls unless that interface or constraint is itself user-visible policy.
+<!-- fp-shared:begin writing -->
+**Write a requirement as a product decision someone can approve, not as a design
+task.** It should read like a capable teammate wrote it: direct, specific, and free
+of boilerplate such as “ensure a seamless experience.”
+
+- **Title:** one clear product promise in present tense, with a concrete subject and
+  active verb. Name the user-visible capability, not the work (`“Dispatchers see
+  current shipment status”`, not `“Implement status polling”`).
+- **Why:** one natural sentence naming who needs this, the problem or risk, and the
+  outcome worth protecting. Do not repeat the title, narrate the request or bug
+  history, sell the feature, or explain the mechanism.
+- **Acceptance:** one independently verifiable rule of observable behaviour that lets a
+  reviewer decide whether the promise is true. State the trigger or situation, the result, and material
+  boundaries that qualify that same promise. Given/When/Then may clarify those parts,
+  but it is not a mandatory template. Split a second result that could fail
+  independently into its own requirement instead of comma-chaining it here.
+- **Example:** supply one concise concrete case that would pass the general rule, and
+  put it after the rule in Acceptance as `Example: ...`. Use the domain's real terms
+  and representative data, but ask rather than invent consequential policy. Do not mistake a few examples for the rule
+  or let marked tests stand for every case; neither replaces the general rule and
+  continued conversation.
+- **Numbers and policy:** include a price, limit, timeout, date, role, or fallback only
+  when the source made it a real product decision or an external constraint requires it.
+  Never invent a plausible value to fill a gap. If the decision matters and the source is
+  silent, ask.
+- **Implementation detail:** leave out components, data models, algorithms, endpoints,
+  and UI controls unless that interface or constraint is itself part of the promise.
+
+Learn from the request, existing requirements and history, and available evidence about
+what users actually do. Look for what they attempt, where they abandon a task, what they
+use, and what experiments reveal. Treat the first proposed solution as input, not
+unquestionable scope. Preserve important uncertainty as a question rather than
+laundering a guess into acceptance criteria.
 
 State the promise itself rather than commentary about it. Avoid openings such as “This
 feature…”, “This requirement…”, “The goal is…”, “Users should be able to…”, and “The
 system should…”. Use the real actor or product as the subject and an active verb.
 
-A good requirement is concise, not merely short. Keep every sentence that changes a decision;
-remove everything that only sounds thorough.
-
 - ✅ **Title:** `Dispatchers see current shipment status`
   **Why:** `Dispatchers need to spot delayed shipments before they miss a delivery window.`
   **Acceptance:** `When a shipment's status changes, the dashboard shows the new status; if status is unavailable, it says so instead of presenting stale data as current.`
 - ❌ **Title:** `Implement Redis-backed 30-second status polling`
   **Why:** `This important feature ensures a seamless, robust experience.`
   **Acceptance:** `Use a background worker and refresh every 30 seconds.`
-  This invents policy, prescribes a design, and never states the outcome.
+  This invents policy, prescribes a design, and never states the product outcome.
 
-Before saving, answer three questions against the actual fields: Who is this promise for? How
-would the concrete example prove it done? Why does the outcome matter? If any answer is missing
-or vague, revise the draft or ask the user. Then read it as a manager deciding scope: Is the
-value clear? Can the result be observed? Are real product decisions distinguished from guesses?
-Could every clause fail independently and, if so, should it be split? Does every sentence earn
-its place? Do not create the record until the draft passes this review.
+A good requirement is concise, not merely short: keep every sentence that changes a
+decision and remove everything that only sounds thorough.
+
+Before proposing, answer three questions against the actual fields: Who is this promise
+for? How would the concrete example prove it done? Why does the outcome matter? If any
+answer is missing or vague, revise the draft or ask the user. Then read it as a manager deciding scope:
+is the value clear, can the result be observed, are product decisions
+distinguished from guesses, could any clause fail on its own (then split it), and does
+every sentence earn its place? If the draft fails
+this review, revise it or ask before writing the record.
+<!-- fp-shared:end writing -->
 
 Then create the proposal as a draft:
 
@@ -262,6 +309,37 @@ fp propose --project stowzilla \
 
 **Agents always create requirements as draft.** A human must activate them in the web app.
 
+When no card or issue prompted it — you wrote the requirement by reading the code, as when
+onboarding a repo — pass `--source-type repo_scan` and one `--source-ref path:line` for each
+place you read it from.
+
+Proposing several at once? Put them in a YAML file and run `fp propose --file reqs.yml
+--dry-run` first. It lints every entry's wording and checks slugs and parents against the
+catalog without writing anything. Then run it without `--dry-run`: the batch is created only if
+every entry is valid. Bind tests with `fp mark <slug> <file>:<line>` rather than typing
+markers by hand.
+
+**Confirm draft coverage with `fp coverage`.** The gate measures only active requirements,
+so while everything you proposed is still a draft `fp check` says "Nothing to enforce yet"
+and `fp list --gaps` finds nothing. `fp coverage` shows each draft × surface resolved from
+the evidence you reported, and ends with the drafts that have no evidence on a required
+surface — hand that list to the human as the requirements with no test yet. Drafts are
+reported, never gated. `fp check --include-drafts` appends the same table to the verdict.
+
+**Attach your questions to the drafts they concern.** When a draft leaves a decision only a
+human can make (a limit the source never set, a role it didn't name), don't leave the question
+in chat, where it's cut off from the draft. Ask it on the draft:
+
+```bash
+fp question upload_limits "Is the 5 MB cap per file or per upload?"
+fp questions upload_limits        # open and answered questions, with the answers
+```
+
+The human reviewing that draft in Quick Review sees the question beside it and answers or
+dismisses it there; `fp show` lists the open ones. Agents can ask but never answer. If the
+user asks you for "a list of questions for the human", ask each one on its draft and give
+them the list too. Draft and active requirements take questions.
+
 ### 6. Propose a change to an existing requirement
 
 When a requirement no longer says the right thing, don't silently edit it — propose the
@@ -464,6 +542,40 @@ the command relays the upgrade message if that's used up. `fp projects delete` e
 asks a human to type the slug back (or `--yes` in scripts) and is owner-only — don't reach
 for it to tidy up; a project's requirements, evidence, and history go with it.
 
+### Onboarding a repo (first run)
+
+<!-- fp-shared:begin onboarding -->
+The per-task loop assumes a catalog already describes the product. On a repo's first run
+there isn't one yet, so the job is to write it down, as drafts a human activates, rather
+than to check work against it.
+
+1. `fp doctor` confirms fp runs under the repo's Ruby and shows which API it writes to,
+   then lists the repo's test runners, database and devcontainer.
+2. `fp init --detect` suggests a project slug, surfaces, and the command that makes each
+   test runner write a report. If the project doesn't exist yet, create it with
+   `fp projects create <slug> --name "..." --surfaces <keys>`, then run
+   `fp init --project <slug>`.
+3. Pick surfaces by this rubric, not by the folder layout. A surface is somewhere a user
+   interacts with the product: a web app, an iOS or Android app, a desktop app, a CLI, or
+   an API that customers call directly. An internal API with no separate client is not
+   one; its tests are evidence for the surface the user touches.
+4. Propose what the code already promises as drafts, written to the requirement-writing
+   standard. Review a batch with `fp propose --file <file> --dry-run`, then send it without
+   `--dry-run`. Pass `--source-type repo_scan` and name the files you read in
+   `--source-context`.
+5. Bind the tests that already prove each draft with `fp mark <slug> <file>:<line>`, or
+   write the `fp:<slug>` comment yourself.
+6. Report with `fp run --surface <key> --repo <org/repo> -- <test command>`. It adds the
+   report formatter for rspec, pytest, vitest and playwright, so the project needs no new
+   dependency. For any other runner, use `fp report --junit <file>`.
+7. `fp coverage` lists the drafts that still have no evidence. When the code doesn't settle
+   a product decision (a limit, a role, a fallback), attach the question to the draft with
+   `fp question <slug> "<text>"` instead of guessing an answer.
+8. Commit `.featureparity.yml`, the workflow and the agent docs. Committing the workflow
+   before anyone has added the `FP_API_KEY` secret is fine: the gate skips with an
+   explanation and the build stays green until the secret exists.
+<!-- fp-shared:end onboarding -->
+
 ### Triage requirement quality (`fp analyze`)
 
 `fp analyze` checks how well requirements are written and whether they belong in the
@@ -495,20 +607,47 @@ not as the fix — you still write the proposal.
 | Not a product promise / not observable | A human decides whether it belongs; don't guess |
 | Missing why, vague acceptance, implementation detail, boilerplate | `fp propose-change <slug> --why "..." --acceptance "..."` |
 
+## Troubleshooting
+
+<!-- fp-shared:begin troubleshooting -->
+- **`mise ERROR No version is set for shim: fp`** inside a repo, while `fp` works from
+  another directory (rbenv and asdf say `fp` isn't installed): the repo pins a Ruby in
+  `.ruby-version`, `.tool-versions` or `mise.toml` that the featureparity gem isn't
+  installed under. The version manager's shim fails before fp starts, so fp can't diagnose
+  it from inside. Install the gem under the pinned Ruby by running `gem install featureparity`
+  inside the repo (`mise exec -- gem install featureparity` with mise), or put the bin
+  directory of the Ruby that has it first on `PATH`. `fp doctor`, run from anywhere fp
+  works, prints the exact commands.
+- **The tests need a database.** `fp doctor` says whether they do (pg or mysql gems,
+  `config/database.yml`, docker-compose) and whether a `.devcontainer` can provide one. The
+  generated CI workflow has no database service, so add one to its report job.
+- **The runner can't write JUnit without a new dependency.** RSpec's own
+  `--format json --out rspec.json` report is accepted anywhere `--junit` is, and `fp run`
+  adds the formatter for rspec, pytest, vitest and playwright itself.
+<!-- fp-shared:end troubleshooting -->
+
 ## Quick reference
 
 | Task | Command |
 |------|---------|
+| Check fp, config and the repo | `fp doctor` |
+| Suggest slug, surfaces, test commands | `fp init --detect` |
 | Onboard a repo | `fp init --project X` |
 | List requirements | `fp list --project X` |
 | Show gaps | `fp list --project X --gaps` |
+| Draft coverage | `fp coverage --project X` |
 | Show details | `fp show <slug> --project X` |
 | Report evidence | `fp report <slug> --project X --surface Y --file Z --repo A/B` |
-| Report from JUnit | `fp report --junit file.xml --project X --surface Y --repo A/B` |
+| Report from JUnit / RSpec JSON | `fp report --junit file.xml --project X --surface Y --repo A/B` |
+| Upload a run's screenshots/videos (optional, with permission) | `fp report --junit results.xml ... --attach-media` |
+| Attach a test's capture (optional, with permission) | `fp attach <slug> <file> --project X --surface Y --example-title "<test name>"` |
+| Run tests and report | `fp run --surface Y --repo A/B -- bundle exec rspec` |
 | Propose requirement | `fp propose --project X --slug Y --name "..."` |
 | Propose a change | `fp propose-change <slug> --project X --why "..." --reason "..."` |
 | Propose a deletion | `fp propose-change <slug> --project X --removal --reason "..."` |
 | View change history | `fp history <slug> --project X` |
+| Ask a human about a draft | `fp question <slug> "..." --project X` |
+| Read a draft's questions and answers | `fp questions <slug> --project X` |
 | Triage requirement quality | `fp analyze --project X` |
 | View work-item activity | `fp changes --project X --source-url URL` |
 | Enforce parity | `fp check --project X` |