/g The Contract Codex ← 返回动态 Catalog

Feature Flag System

Implement boolean, percentage, and user-based feature flags with service logic, API middleware, a React hook, docs, and tests.

难度:intermediate 分类:product 来源:OpenHands tutorial library

完整 Prompt(可直接复制)

/goal
GOAL:
Complete Feature Flag System for a product planning and implementation repo: Implement boolean, percentage, and user-based feature flags with service logic, API middleware, a React hook, docs, and tests.

CONTEXT:
- Before editing, read the nearest AGENTS.md/CLAUDE.md, current issue or PLAN.md, and any failing logs already in the repo.
- Inspect PRDs, analytics events, permission models, and acceptance criteria.
- Establish a baseline by running or locating evidence for: `feature flag service, hook, middleware, and rollout tests`.

CONSTRAINTS:
- Keep the scope limited to this goal; do not expand into unrelated cleanup.
- Do not weaken tests, delete assertions, or mask errors to make verification pass.
- Respect the repository's AGENTS.md/CLAUDE.md instructions and existing patterns.
- Do not implement new product scope unless it is in the stated acceptance criteria.
- Separate product decisions from engineering assumptions.

DONE WHEN:
- The implementation or documentation directly satisfies: Implement boolean, percentage, and user-based feature flags with service logic, API middleware, a React hook, docs, and tests.
- The verification command or evidence path succeeds: `feature flag service, hook, middleware, and rollout tests`.
- The final diff is scoped to the relevant files and has no unrelated formatting churn.

VERIFY:
- Run `feature flag service, hook, middleware, and rollout tests` or the closest repo-local equivalent if the exact command is not available.
- Capture before/after evidence for the behavior, metric, report, or artifact involved.
- If verification cannot run locally, stop and report the missing dependency instead of guessing success.

OUTPUT:
- Summarize changed files, key decisions, verification output, and remaining risks.
- Include any follow-up that is required for production rollout or human review.

STOP RULES:
- Pause if secrets, production access, stakeholder decisions, or destructive data operations are required.
- Pause after three failed fix attempts on the same symptom and challenge the root-cause hypothesis.
- Do not mark the goal complete until the current repository state has been audited against DONE WHEN.

来源与证据

原始来源: OpenHands tutorial library

证据摘要: Implement a feature flag system for our application; source: OpenHands tutorial library; type: official-agent-task; verification: feature flag service, hook, middleware, and rollout tests