accept-feature

Other Community

Repo stars 12
Author repo temple8

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Validate business behavior against BDD examples from the end user's perspective Available knowledge: [[requirements/gherkin#key-…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The source has limited section structure, so treat it as an invocation rule: trigger, execution boundary, then validation.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name accept-feature directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “accept-feature” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Other
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @nullhack · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview accept-feature.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# Accept Feature

Available knowledge: [[requirements/gherkin#key-takeaways]], [[software-craft/test-design#key-takeaways]], [[software-craft/test-stubs#concepts]]. `in` artifacts: read all before starting work.

1. Run `task test-build` to verify all tests pass with coverage.
2. Verify all BDD examples pass from the end user's perspective, not the test harness, per [[software-craft/test-design#key-takeaways]].
3. IF an example passes in the test harness but fails from the user's perspective → flag it as a semantic alignment gap per [[software-craft/test-design#concepts]].
4. Verify structural traceability: run `beehave status --json` for stage overview, then `beehave check` for detailed violations per [[software-craft/test-stubs#concepts]]. Every Example in the feature file must have exactly one corresponding test function, and every test function must trace back to an Example. The feature stage must be `ok` and `beehave check` must produce no output.
5. Verify semantic depth per [[software-craft/test-design#concepts]].
6. Verify quality attributes are met.
7. Verify definition of done criteria are satisfied.
8. Produce a traceability matrix: for each stakeholder Q&A topic from interview notes, map to:
   - **Behavioral Q&A**: a passing test (Example title → test function name).
   - **Technology Q&A**: implementation evidence (import, module structure, config) where the technology named in the Q&A is exercised in code. Technology Q&As are verified by reading the feature file's `# Constraints:` and checking the corresponding implementation — NOT through behavioral tests.
   - **Explicit stakeholder deferral**: with the reason it was deferred.
   Untraced Q&As of either type → incomplete delivery.

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> no H2/H3 headings
terms    -> Behavioral Q&A · Technology Q&A · Explicit stakeholder deferral · 1. Run task test-build to verify all tests pass with coverage.
files/cmd -> task test-build · beehave status --json · beehave check · # Constraints:
body sha256 -> f0bca069aa8a

Decide Fit First

Design Intent

How To Use It

Boundaries And Review

Accept Feature

Discussion