featureparity 0.0.26 → 0.0.27

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 2403a7e55f95df5cf1821375442902c0a06784c26186f1e2fc1ae2e474ee937b
-  data.tar.gz: 4cbb3354c710f6d6e19114b2e2c28e533251c10bfa4a93c0a917ff73e5ebce93
+  metadata.gz: 4b09491a1b44b4ba693dfd567cdec5068d3410c577066435b541b2e9520ae04f
+  data.tar.gz: c9b7fb84bee3dbb3e8dfd8ee29f7c4d878747c0157efaa63fb020ead7934b2e7
 SHA512:
-  metadata.gz: 8a065b839f21e0bdf4194f65b93c233abf3e09ef11a50f96d0259d68609fc1c6e89e3d07e760a5a8d3b3bb12b849b7fdb7ea1c3a5fa65fc59b4befa053595366
-  data.tar.gz: 50e977bdf9a66c6f24a8a264d9334a506d5f15379f8e9aeaa8635d6cf84b5f9eee526e990c6e9b1a041631f1e15b7115e3ed3484311130f1fd23ca0ad7d35cde
+  metadata.gz: cdf6cc31e230d20555285da1b44ee1816e94a88d3a5e3c02b22569cc63034d2f038d5183c12191f9ba446e5fdbc78a44ebe0b485e476f0dd5b9e021675338500
+  data.tar.gz: c9b9337383f9e7aecfa8caec130d99e3a1e93452481d14ffe1e0f95bd63c495480241d3b1578f0ff01ca5c7f81cc3b969a78cf232947a563cd307ade34b255c1

data/lib/fp/commands/help.rb

@@ -289,24 +289,32 @@ module Fp
             #
             # Write the requirement as a product decision someone can approve, not a design
             # task. It should sound like a capable teammate, not AI boilerplate.
-            #   title: one product promise in present tense, not the implementation project
-            #   why: one or two natural sentences naming the user need/problem and outcome
-            #   acceptance: trigger or situation + observable result + material boundaries
-            # Use examples and tests to ground and double-check the general rule, not to replace
-            # it or ongoing conversation. Leave out components, data models, algorithms, endpoints,
-            # and UI controls unless they are themselves part of the user-visible contract.
-            # Include a price, quota, timeout, count, date,
-            # role, or fallback only when the source made it a real product decision; if an
-            # important policy is missing, ask instead of inventing a plausible value.
+            #   title: one product promise in present tense, with a concrete subject and active verb
+            #   why: one natural sentence naming the user need/problem and protected outcome
+            #   acceptance: one independently verifiable rule of observable behaviour;
+            #               append one concise concrete case as "Example: ..."
+            # Given/When/Then may clarify a rule, but is not mandatory. Split another result that
+            # could fail independently rather than comma-chaining it into the same requirement.
+            # Use the domain's real terms in examples and ask rather than invent consequential
+            # policy. Examples and tests ground and double-check the rule; they do not replace it.
+            # State each field directly. Avoid “This feature…”, “The goal is…”, “Users should be
+            # able to…”, “The system should…”, and task titles beginning “Enable” or “Implement”.
+            # Leave out components, data models, algorithms, endpoints, and UI controls unless
+            # they are themselves part of the user-visible contract.
+            # Include a price, quota, timeout, count, date, role, or fallback only when the source
+            # made it a real product decision; if important policy is missing, ask instead of
+            # inventing a plausible value.
             #
             #   good title:      "Dispatchers see current shipment status"
             #   good why:        "Dispatchers need to spot delayed shipments before they miss a delivery window."
             #   good acceptance: "When status changes, the dashboard shows it; when unavailable, it says so instead of showing stale data as current."
             #   bad: "Implement Redis polling every 30 seconds to ensure a seamless experience."
             #        (invented policy, implementation detail, and filler; no product outcome)
-            # Before saving, read it as a manager deciding scope: is the value clear, is the
-            # result observable, are decisions separated from guesses, and does every sentence
-            # earn its place?
+            # Before saving, answer against the actual fields: who is this promise for, how would
+            # the concrete example prove it done, and why does the outcome matter? If an answer is
+            # vague, revise or ask. Then read it as a manager deciding scope: is the value clear,
+            # is the result observable, are decisions separated from guesses, and does every
+            # sentence earn its place? Do not save until the draft passes this review.
             fp propose --project stowzilla \\
               --slug print_container_qr \\
               --name "Print QR code on container label" \\

data/lib/fp/commands/init.rb

@@ -470,18 +470,22 @@ module Fp
           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. Name the user-visible
-            capability, not the work (`“Dispatchers see current shipment status”`, not
-            `“Implement status polling”`).
-          - **Why:** one or two natural sentences naming who needs this, the problem or risk,
-            and the outcome worth protecting. Do not repeat the title, sell the feature, or
-            explain the mechanism.
-          - **Acceptance:** the observable behaviour that would let a reviewer decide whether
-            the promise is true. State the trigger or situation, the result, and material
-            boundaries such as permissions, failure states, and affected surfaces. Use examples
-            and marked tests to ground and double-check the rule. Do not mistake a few examples for the rule
-            or let tests stand for every case; neither replaces the general rule and continued
-            conversation.
+          - **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. Never invent a plausible value to
             fill a gap. If the decision matters and the source is silent, ask.
@@ -494,6 +498,10 @@ module Fp
           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.
+
           - ✅ **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.`
@@ -502,9 +510,12 @@ module Fp
             **Acceptance:** `Use a background worker and refresh every 30 seconds.`
             This invents policy, prescribes a design, and never states the product outcome.
 
-          Before proposing, read the draft once as a manager deciding scope: is the value clear,
-          can the result be observed, are product decisions distinguished from guesses, and can
-          every sentence earn its place? If not, revise or ask before writing the record.
+          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, and does every sentence earn its place? If the draft fails
+          this review, revise it or ask before writing the record.
 
           ### 2. If the requirement is wrong, propose a change — don't silently edit it
 

data/lib/fp/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Fp
-  VERSION = '0.0.26'
+  VERSION = '0.0.27'
 end

data/skills/fp/SKILL.md

@@ -202,23 +202,33 @@ Before drafting:
 
 Write each field for a reviewer, not for the implementation:
 
-- **Title:** one clear product promise in present tense. Name the capability or outcome, not
-  the project (`Dispatchers see current shipment status`, not `Implement status polling`).
-- **Why:** one or two natural sentences saying who needs this, the problem or risk, and the
-  outcome worth protecting. Do not repeat the title, advertise the feature, or explain how
-  it will be built. Delete AI filler such as “ensure a seamless, robust experience.”
-- **Acceptance:** observable behaviour that lets someone decide whether the promise is true.
-  State the relevant trigger or situation, the result, and material boundaries. Include
-  failure behaviour, permissions, or cross-surface consistency when those affect the promise.
-- **Examples:** use concrete examples or Given/When/Then cases when they clarify a rule or an
-  edge. Examples and executable tests ground and double-check the specification; they do not
-  define every case or replace the general rule and continued conversation.
+- **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.
 
+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.
 
@@ -230,10 +240,12 @@ remove everything that only sounds thorough.
   **Acceptance:** `Use a background worker and refresh every 30 seconds.`
   This invents policy, prescribes a design, and never states the outcome.
 
-Before saving, read the draft 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? Revise or ask
-before creating the record if the answer is no.
+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.
 
 Then create the proposal as a draft:
 

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: featureparity
 version: !ruby/object:Gem::Version
-  version: 0.0.26
+  version: 0.0.27
 platform: ruby
 authors:
 - Stowzilla
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2026-10-27 00:00:00.000000000 Z
+date: 2026-11-02 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: net-http