{
  "markdown": "# Zero-Trust Feature Team\n\nA Claude Code plugin that turns a one-line feature request into a fully-tracked implementation pipeline: **intake -> research -> plan -> review -> implement -> test -> verify**, with persistent state that survives `/clear` and context resets.\n\nWhere the [Zero-Trust Audit Team](https://github.com/bradselph/zero-trust-audit-team) finds and fixes existing bugs, this plugin builds new features the same way: every claim backed by evidence, every step independently verified, no code written until the user explicitly approves the plan.\n\n## Install\n\n```\n/plugin install https://github.com/bradselph/zero-trust-feature-team\n```\n\nOr load locally for testing:\n\n```bash\ngit clone https://github.com/bradselph/zero-trust-feature-team\nclaude --plugin-dir ./zero-trust-feature-team\n```\n\n## Quickstart\n\n```\n/feature:init \"add server-side search to the documents list\"\n/feature:research\n/feature:plan\n/feature:review\n/feature:implement\n/feature:summary\n```\n\n## Commands\n\n| Command | Description |\n|---|---|\n| `/feature:init [description]` | Capture requirements via the intake-analyst; user must confirm before anything else runs |\n| `/feature:research` | Research the codebase area-by-area (stops at `STATUS: PARTIAL`) |\n| `/feature:continue` | Resume a paused research run at the last resume marker |\n| `/feature:plan` | Convert task + research into an ordered, atomic step plan |\n| `/feature:review` | Plan-critic pass plus user approval gate -- no code is written until this approves |\n| `/feature:implement [STEP-id]` | Implement -> test -> verify one step (one step per invocation) |\n| `/feature:status` | Snapshot: gates open/closed, research coverage, step status, AC delivery, next action |\n| `/feature:summary` | Final report (only valid after every step is in a terminal state) |\n\n## The team\n\nEight specialized agents coordinate through a shared state ledger in `.claude/feature-state/`. Each has a narrow, evidence-enforced role:\n\n| Agent | Role | Writes code? |\n|---|---|---|\n| `feature-orchestrator` | Coordinator -- dispatches all other agents, owns state, enforces gates | State files only |\n| `intake-analyst` | Adversarial requirements interview, writes `task.json` | No |\n| `project-researcher` | Zero-trust per-area researcher -- one area per invocation, explicit evidence required | No |\n| `feature-planner` | Decomposes the feature into atomic, ordered, verifiable steps with anchors | No |\n| `plan-critic` | Independent review of the plan -- confirms or rejects with concrete gaps | No |\n| `feature-implementer` | Applies one step at a time -- minimal change, no scope creep | Yes |\n| `test-engineer` | Writes tests for each step's behavior_checks; runs existing tests | Tests only |\n| `step-verifier` | Independent re-trace of the four truths -- confirms or rejects with evidence | No |\n\n## The flow\n\n```\n/feature:init      ->  capture requirements, user confirms task.json\n/feature:research  ->  project-researcher covers areas one-by-one, writes log/research-*.md\n/feature:plan      ->  feature-planner builds plan.json + steps/STEP-NNNN.json\n/feature:review    ->  plan-critic verdict + user approval flips review.status to \"approved\"\n/feature:implement ->  feature-implementer -> test-engineer -> step-verifier (one step per run)\n/feature:summary   ->  final report: AC delivery, steps executed, residual risks\n```\n\nEach phase is a separate command. Nothing happens automatically between phases -- you stay in control of when to move forward.\n\n## The four pre-implementation gates\n\nNo `feature-implementer` dispatch is allowed until **all** four gates are satisfied:\n\n1. **Task confirmed** -- `task.json.confirmed_by_user == true`. Set only after the intake-analyst presents the captured spec and the user replies with explicit confirmation.\n2. **Research complete** -- every research area is `covered` (or explicitly accepted as partial by the user).\n3. **Plan exists** -- `plan.json` with one `steps/STEP-NNNN.json` per step.\n4. **Plan approved** -- `plan.review.status == \"approved\"`. Set only after the plan-critic's verdict and the user replying with explicit approval.\n\nThese gates are why the user is in the loop *before* code is written, not after it lands as a surprise diff.\n\n## State layout\n\nAll state lives in `.claude/feature-state/` in your project as plain JSON and Markdown -- diffable, reviewable, readable without tooling.\n\n```\n.claude/feature-state/\n+--- task.json                  Confirmed feature spec: goals, ACs, constraints, assumptions\n+--- research.json              Per-area research index: status, integration points, gaps, verdicts\n+--- plan.json                  Ordered plan summary, risks, deferred items, review state\n+--- steps/                     STEP-0001.json, STEP-0002.json, ... -- one file per step\n+--- log/\n|   +--- research-<area>.md     Per-area execution traces from project-researcher\n|   \\--- step-STEP-NNNN.md      Step record: edits + tests + step-verifier verdict\n\\--- README.md                  Schema reference for every state file\n```\n\nThe `feature-state/README.md` schema reference is included in this plugin for reference. The orchestrator writes it to your project during `/feature:init`.\n\n## Design choices\n\n**Why eight agents.** Each agent has one job and a narrow tool set. The implementer cannot research, the researcher cannot plan, the planner cannot edit code, the verifier cannot approve its own team's work. Separation makes scope creep mechanically harder.\n\n**Why one area per research invocation.** Researching a whole codebase in one shot loses fidelity. One area at a time produces a per-area `log/research-<area>.md` with anchors and traces -- survives `/clear`, resumable across sessions on any repo size.\n\n**Why one step per implement invocation.** Batching multi-step changes is where regressions hide. Each step gets its own complete trace: anchor re-location -> edit -> static checks -> tests -> independent re-verification.\n\n**Why the planner cannot edit code.** The planner's incentive to \"just do it\" while planning is the most common source of partial implementations and untraceable diffs. Read-only by construction.\n\n**Why the critic cannot edit the plan.** The critic's job is to find gaps. A critic that can patch the plan it reviews will rationalize gaps instead of flagging them. The critic produces recommendations; the planner must re-run to apply them.\n\n**Why re-verification is a separate agent.** The agent that applied the step is the wrong agent to certify it. The `step-verifier` starts from a clean context and must produce an independent trace against four truths: plan-conformance, behavior-conformance, AC-contribution, no-regression.\n\n**Why steps must declare anti-checks.** \"Diff confined to anchor region\" is not aspirational -- it's a check the verifier runs. Catches scope creep mechanically rather than through diligence.\n\n## Customizing\n\n**Constraint policy** -- edit `agents/feature-planner.md`, the cross-cutting risks step (sensitive paths, breaking-change rules).\n\n**Per-language test conventions** -- the test-engineer auto-detects framework. If your project has unusual test infrastructure, drop a hint in `task.constraints.must_use` (e.g., `\"the existing custom test harness in scripts/test.sh\"`) -- the test-engineer reads constraints first.\n\n**Sensitive path overrides** -- add additional sensitive globs in your task's `constraints.security` field. The planner promotes any step touching them to `requires_human_review: true`.\n\n**Pre-existing research notes** -- drop Markdown into `.claude/feature-state/log/research-<area>.md` matching the format in `feature-state/README.md` and add the area to `research.json` with `status: \"covered\"`. The planner reads both as first-class evidence.\n\n## When not to use this\n\n- **Trivial single-file edits**: overkill -- use plain Claude Code.\n- **Greenfield projects with no existing patterns**: the researcher's value is on accumulated code with conventions to mirror.\n- **Spike/throwaway prototypes**: the gates are intentional. If you want fast and ungated, stay in plain Claude Code.\n- **You already have a written design doc and just want it executed**: you can drop a research summary in by hand and skip `/feature:research`, but the planner will still expect anchors that resolve on disk.\n\n## Companion: the audit plugin\n\nThis plugin builds new features. Its sibling, [Zero-Trust Audit Team](https://github.com/bradselph/zero-trust-audit-team), audits and fixes existing code. They share design DNA: chunked invocations, evidence-backed claims, persistent state, independent verification. Use them together -- audit before adding to fragile areas, feature after to extend solid ones.\n",
  "bytes": 8691,
  "sha": "ce2b1f7baa1931b4fca198339cfd5e27498ee0d9b6f8ac2abaf8d49d95040c76",
  "repo_slug": "bradselph/zero-trust-feature-team",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_bradselph_zero_trust_feature_team_zero_t_b6fdb883/readme"
}