From zensu
Implement a tracked Zensu feature end-to-end. Loads feature context and security profile, then runs disciplined implementation via the **`/zensu:tdd` skill** in the main thread (strict RED-GREEN TDD, PreToolUse phase-gate, guaranteed code-review chain). After TDD completes, links all artifacts and creates a revision.
How this skill is triggered — by the user, by Claude, or both
Slash command
/zensu:implementThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Implement a tracked Zensu feature end-to-end. Loads feature context and security profile, then runs disciplined implementation via the **`/zensu:tdd` skill** in the main thread (strict RED-GREEN TDD, PreToolUse phase-gate, guaranteed code-review chain). After TDD completes, links all artifacts and creates a revision.
Implement a tracked Zensu feature end-to-end. Loads feature context and security profile, then runs disciplined implementation via the /zensu:tdd skill in the main thread (strict RED-GREEN TDD, PreToolUse phase-gate, guaranteed code-review chain). After TDD completes, links all artifacts and creates a revision.
curl -fsSL https://zensu.dev/install.sh | sh) and on PATHzensu auth login (check with zensu auth status)Every command accepts --json for machine-readable output; run zensu <noun> <verb> --help for the full flag set.
Workflow gate (first + last action). As the VERY FIRST action, run bash "$(cat "$HOME/.zensu/plugin-root")/hooks/lib/zensu-log.sh" --workflow-begin --tools "analyze_feature_security,link_test,link_source_files,bulk_link_source_files,link_docs,create_wiki_page,create_revision,update_feature". This marks the Zensu product workflow active so the CLI write-gate (hooks.mcpGate, default-on) recognizes this skill's zensu link test / zensu link source / zensu link docs / zensu features revision commands as workflow-driven rather than freelance and does not block them. As the VERY LAST action (after Step 6, or on early exit), run bash "$(cat "$HOME/.zensu/plugin-root")/hooks/lib/zensu-log.sh" --workflow-end.
zensu features get <feature-id> to load the full feature details (title, description, status, priority, component, security classification)zensu security analyze <feature-id> to load the security context (classification, data sensitivity, OWASP tags, compliance requirements, score)zensu knowledge search --query "<feature title + key terms>" to surface related org context — existing features, visions, journeys, and connected sources — so the implementation builds on what the org already knows. It is retrieval-only: synthesize from the returned passages and cite their provenance.Based on the feature context and security profile, help the user plan the implementation:
If the feature's security classification is confidential or restricted, emphasize:
Invoke the /zensu:tdd skill (Skill tool, skill='zensu:tdd') with a feature specification built from Steps 1-2 as the input. Include the feature title, description, component, security classification, security constraints from Step 1, and the implementation plan from Step 2. End the spec with: "Reference this feature as [KEY-N] (the feature's actual id, e.g. [ZEN-42]) in all commit messages." You run the TDD workflow yourself in THIS main thread — do not spawn a subagent.
If the TDD workflow cannot proceed or all steps are blocked, continue manually from Step 4.
The /zensu:tdd workflow will:
.zensu/plans/hooks.tddImplementation is false — the skill branches itself at --tdd-begin).zensu/logs/At the end of the workflow (Phase 6) it marks implementation complete and spawns @zensu:code-reviewer for the 5-perspective review. The Stop hook (stop-chain-enforcer.sh) guarantees the review chain runs, and post-review-tdd-delegate.sh routes any findings back for in-thread fixing until PASS or max rounds.
For trivial changes (single-line fix, config change, migration-only): Skip the /zensu:tdd skill and implement directly, then continue with Step 4.
For each test file written (by the /zensu:tdd workflow or manually), run zensu link test <feature-id> with:
--test-type (required): unit | integration | e2e | security | performance | accessibility--file (required): Path to the test file--function (optional): Specific test function--last-run-status (optional): passed | failed | skippedRun zensu link source <feature-id> to map implementation files to the feature. Pass each file with a repeatable --file flag in the form path[:type[:language[:linecount]]] (type: source | test | config | migration | docs | generated | other). For cross-feature mapping, run zensu link source once per target feature id.
Documentation must be code-grounded — written from the real source you just
implemented, not a restatement of the feature record.
Read docs/documentation-guide.md first, then follow it:
zensu doc gen-context <feature-id> --doc-type <type> for the context map
(source-file paths, symbols, security posture), not the source.## Purpose / ## Source files / ## Security / ## Notes sections — that
metadata dump is the exact failure this step prevents.zensu wiki create --product <product-id> --title <title> --content <markdown>
(plus --entity-type, --entity-id, --doc-type, --audience).Then register the doc with zensu link docs <feature-id> (updates the feature's docs score):
--doc-type (required): user_facing | api_reference | tutorial | adr | internal | release_notes | migration_guide | overview--title (optional): Document title--file (optional): Path to the doc file--external-url (optional): External URL--audience (optional): end_user | developer | admin | internal--publication-status (optional): draft | published | archivedRun zensu link docs alone (no wiki page) only for docs that already live in the repo
or at an external URL.
Run zensu features revision <feature-id> to version the implementation:
--scope-summary (required): Brief summary of what was implemented--scope-details (optional): Detailed scope description--estimated-effort (optional): S | M | L | XL--coverage-target (optional): Target coverage percentage (0-100)--docs-required (optional): Whether docs are required for this revision--created-by (optional): identifier for who created the revisionRun zensu security validate <feature-id> to check if the implementation meets all security requirements for release.
Present the validation results:
Present a completion summary:
zensu features update does NOT change status. Status transitions (planned -> in-progress -> testing -> released) go through zensu features status <feature-id> <new-status>.feat(component): description [KEY-N]/zensu:security-review if not yet set).zensu/plans/{timestamp}_tdd-{feature-slug}.md and a progress log at ${CLAUDE_PROJECT_DIR:-.}/.zensu/logs/{timestamp}_tdd-{feature-slug}.log| Command | Step | Purpose |
|---|---|---|
zensu features get | 1 | Load feature details |
zensu security analyze | 1 | Load security context |
zensu knowledge search | 1 | Surface related org knowledge (retrieval-only) |
zensu link test | 4 | Link test files |
zensu link source | 5 | Map source files to feature (bulk via repeated --file) |
zensu doc gen-context | 6 | Get the context map to read source before writing docs |
zensu wiki create | 6 | Publish authored markdown to the wiki |
zensu link docs | 6 | Register the doc; updates docs score |
zensu features revision | 7 | Create feature revision |
zensu security validate | 8 | Check release readiness |
| Component | Type | Step | Purpose |
|---|---|---|---|
/zensu:tdd | skill (main thread) | Step 3 | Strict RED-GREEN TDD, phase-gated, guaranteed review chain |
zensu:code-reviewer | subagent | Step 3 (Phase 6) | 5-perspective code review + auto-fix routing |
npx claudepluginhub mkitconsulting/zensu-claude-code --plugin zensuProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.