BhangeeF16
UserA Claude Code plugin that runs a full software delivery lifecycle — planning, design, implementation, code review, verification, acceptance, and knowledge maintenance — as one in-session orchestrator dispatching named specialist personas, with evidence checked at every gate instead of self-reported.
Categories
Indexed Skills (35)
implement-slice
Use when a delivery run dispatches any code-executing action: implementing an approved backend slice, implementing an approved frontend slice, or applying a minimal fix to an isolated defect. One shared procedure — execute a bounded change per an approved target, produce the change plus targeted validation, never expand scope — parameterized by the action id passed as the first skill argument (backend_implementation, frontend_implementation, or apply_minimal_fix) and the persona dispatched (backend-developer or frontend-developer, who carries the domain lens). Replaces the retired backend-implementation, frontend-implementation, and apply-minimal-fix skills.
review-evidence
Use when a delivery run dispatches a verification-stretch evidence-judging action: test evidence (test_evidence_review, qa-engineer), security evidence (security_evidence_review, security-reviewer), runtime evidence (runtime_evidence_review, devops-ops), or documentation evidence (documentation_evidence_review, documentation-steward). One shared procedure — judge recorded evidence against what it claims, prove existing work without expanding scope, record residual findings explicitly even when empty — parameterized by the action id passed as the first skill argument and the persona dispatched. Replaces the retired test-evidence-review, security-evidence-review, runtime-evidence-review, and documentation-evidence-review skills.
write-document
Use whenever a delivery run needs a Knowledge Object created from its template or an existing one updated to reflect changed behavior: filing a business rule, requirement, ADR, user story, or any other graph-node fact into the knowledge graph, or writing/updating a non-graph prose document (an ExecPlan, a query/roadmap/test-strategy document) under the run workspace. This is the promote_to_product_knowledge action of the planning stretch, the documentation_update action of the implementation stretch, and the ADR-drafting half of technical_design's stop condition — one Agent-tool dispatch each, parameterized by doctype and mode, distinct from the later review-evidence documentation_evidence_review pass that judges this work, not produces it.
record-evidence
Use when a delivery run dispatches a durable-recording action: filing the debugging trail (record_debugging_evidence), filing the knowledge-maintenance pass's evidence (record_maintenance_evidence), or recording the run's final outcome and status update (record_outcome) — all documentation-steward work. One shared procedure — file it where the next reader will look, link rather than restate, update state and evidence in the same change set — parameterized by the action id passed as the first skill argument. Replaces the retired record-debugging-evidence, record-maintenance-evidence, and record-outcome skills.
review-diff
Use when a delivery run dispatches a diff-review action: the correctness/simplification/convention pass (diff_review, code-reviewer persona) or the security-pattern pass (security_pattern_review, security-reviewer persona) over an implementation diff. One shared procedure — findings tied to specific files/lines with concrete failure or exploit scenarios, or an explicit no-findings record — parameterized by the action id passed as the first skill argument and the persona dispatched. Replaces the retired diff-review and security-pattern-review skills.
agent-conduct
Use when starting a new task or session in this repository and deciding what to load first and in what order (AGENTS, README, manifests, active process/stage definitions, role competencies); when a stage step names an execution role and its competencies need resolving; when deciding whether to ask a clarifying question versus proceed; when a different execution role should run as an isolated sub-agent rather than continuing in the current context; when choosing which capability and provider to reach for (semantic, structural, or text search; knowledge retrieval; execution; context optimization) and in what order; when checking whether another installed plugin already owns a rule before writing a new one; or when deciding how verbose to be, whether to read a whole file versus a ranged slice, or how to point at a large existing artifact instead of re-pasting it. Covers `agent-conduct.md` (the canonical capability model, provider mapping, search strategy, and tool-agnostic contributor behavior rules) and `ai-con
documentation-standards
Use whenever writing, reviewing, or restructuring a Markdown document in this knowledge base: choosing YAML front matter fields, a document type (STD, GUIDE, ADR, COMPETENCY, and so on), or a lifecycle status (Idea through Archived); naming a new file; deciding whether a design or feature doc needs a Mermaid sequenceDiagram or stateDiagram-v2 block and what that diagram must show; formatting cross-references, reference-style links, or anchors; writing or reviewing a table; or resolving which document canonically owns a topic. This is the cross-cutting documentation-formatting authority every stage skill (Design, Documentation, Implementation, and others) defers to for these rules rather than restating them — it is not itself a stage and does not gather requirements or write code.
evidence-verification
Use at every workflow checkpoint of a flattened delivery run, in-session by the orchestrating delivery-lead — never as an Agent-tool dispatch: mechanically confirming a stretch's required outputs exist, factually reading whether that evidence satisfies the accepted acceptance criteria or user story, and routing the run per the checkpoint's own routing table. This replaces the retired Blind Re-Score practice for flattened commands: the orchestrator directed the work, so a blind re-score makes no sense — independence comes from the distinct reviewer roles already in the flow, and this check verifies evidence instead. Trigger at every checkpoint position of the currently running command.
exec-plans-standard
Use when authoring a new ExecPlan (a self-contained, novice-followable execution plan for a feature or system change), when executing or continuing work under an existing ExecPlan and updating its Progress/Surprises & Discoveries/Decision Log/Outcomes & Retrospective sections, when checking whether an ExecPlan is genuinely self-contained and formatted correctly (single fenced `md` block when handed off as a standalone artifact, prose-first narrative, mandatory living-document sections), or when discussing what an ExecPlan requires. Distinct from the `documentation-standards` meta-skill, which governs ordinary Markdown documents in this knowledge base (metadata, diagrams, links, tables) — this skill governs the ExecPlan document type specifically: its skeleton, its living-document discipline, and its formatting envelope.
governance
Use when deciding which document canonically owns a topic, whether it is safe to mark documentation or an implementation plan Completed/Archived/Deprecated, whether a documentation change is acceptance-ready, or when running the structure/metadata/old-path/manifest/reindex audits before accepting a change. Also use when a state record (a target README's `## Status` block, or `process-state.yaml`) may have drifted, when deciding whether async messaging/orchestration/auth/external-provider work needs a Mermaid sequence diagram before it can be accepted, or when checking a change against the documentation stop conditions before treating it as done. Covers both canonical-ownership/lifecycle policy (`documentation-governance.md`) and the acceptance-blocking quality gates and stop conditions built on top of it (`quality-gates.md`) — the two are companion documents in this workspace's own governance/README.md and are not meant to be applied separately.
init-workspace
Use when a project has no recorded intelligence-layer location yet and the user wants to get started, set up the knowledge graph, bootstrap this plugin, or begin planning/design/implementation work for the first time in this project. Also use when asked to "initialize the workspace," "set up the knowledge graph," or when a SessionStart nudge reports that no intelligence-layer location is recorded for this project.
parallel-tracks
Use when an orchestrator command has sliced implementation work into multiple pieces and needs to decide whether any of them can run in parallel, isolated git worktrees instead of sequentially. Covers the independence test, the interface-contract precondition, dispatch mechanics via the Agent tool's worktree isolation, and the merge-back/cleanup flow. Trigger from /develop's kickoff_readiness checkpoint when the task distribution decomposes the slice into more than one implementation track.
reasoning
Use for reasoning discipline that applies underneath every domain competency and every stage: decomposing an ambiguous or underspecified request into facts/inferences/recommendations/open questions, deciding whether an unknown is genuinely material enough to ask a required question, attaching High/Medium/Low confidence labels to a non-trivial claim in a handoff artifact (design.md, planning.md, a competency edit, a code review), running the self-critique pass before handing work to the next stage or role, or turning an observed mistake into a durable knowledge-base change. Load this alongside whichever domain competency or stage skill the current work calls for — it does not replace `architecture`, `business-analysis`, or any other domain competency, it underlies all of them.
acceptance-audit
Use when a fully verified slice needs its structured acceptance audit before the final decision: assumptions surfaced, edge cases enumerated, a validation checklist built from the actual evidence, and residual risks stated. This is the acceptance_audit action of the acceptance stretch — one Agent-tool dispatch with subagent_type qa-engineer — the audit that feeds the delivery-lead's final accept/block/return decision, not the decision itself.
clarify-requirements
Use when a delivery run's promoted (draft) requirements need the Solution Architect's own clarification pass before technical design: raising the technical/architectural questions the Business Analyst would not have surfaced — ownership gaps, integration-boundary conflicts, NFR infeasibility, contradiction with an existing decision record — and resolving every one with the human in writing. This is the clarify_requirements action of the design stretch — one Agent-tool dispatch with subagent_type solution-architect — distinct from resolve-open-questions (the BA's business-truth questions) and technical-design (which must not start while these questions are open).
debrief
Use at the very end of a delivery run, after knowledge maintenance and the recorded outcome, to run the propose-only learning pass: reading the run's journal, identifying process-level friction (gates that never bite, questions the human answered repeatedly, rules that misfired, rework loops), and proposing Intelligence-Layer improvements — every proposal gated on explicit human approval, with a changelog entry on apply. This is the process_retrospective action — one Agent-tool dispatch with subagent_type debrief — it studies how the run went, never what it built, and it edits nothing itself.
delivery-governance
Use for the state contract of a delivery run — the `.kaizen/runs/<run-id>/run.yaml` six-field state file and its append-only `journal.md`: reading a run's current stage/step/role/result before doing delivery work, recording the result of an action or checkpoint (pass, pass_with_risks, blocked, failure) and deciding where it routes next, or checking that `run.yaml` and its evidence were updated together. Applies at every run's target resolution and every transition, not one specific stage.
detailed-prototypes
Use when a human-approved design system exists and the in-scope screens need high-fidelity prototypes: one prototype per screen, each tracing to a functional requirement, user story, or acceptance criterion, with mock/API-gap annotations for anything designed ahead of its backend contract. This is the detailed_prototypes action of the design stretch — one Agent-tool dispatch with subagent_type ui-ux-developer — UI-bearing targets only, and it hard-requires the recorded human approval visual-design stopped for.
detect-drift
Use when a completing delivery run must check the knowledge base for drift its changes introduced or exposed: manifests, maps, and changed docs compared against reality, producing a drift report and a canonical-fact sync check. This is the detect_drift action of the knowledge-maintenance stretch — one Agent-tool dispatch with subagent_type documentation-steward — the finder, distinct from repair-manifest-and-links (the fixer that consumes its report).
documentation-update
Use when an implementation slice changed behavior and the canonical documentation must catch up before the slice is treated as done: updating the owning docs, updating manifests, and rebuilding the graph index when knowledge-graph nodes changed. This is the documentation_update action of the implementation stretch — one Agent-tool dispatch with subagent_type documentation-steward — distinct from the documentation_evidence_review action (review-evidence skill, which later verifies this work) and from the knowledge-maintenance actions (which repair repository-wide drift, not this slice's own docs).
finalize-promoted-knowledge
Use when every Solution-Architect clarification question is resolved and the promoted draft documents must become settled product knowledge: flipping each promoted document's lifecycle status from draft to approved, marking register rows finalized, and setting the target's status record to a passing result. This is the finalize_promoted_knowledge action of the design stretch — one Agent-tool dispatch with subagent_type solution-architect (business-analyst and documentation-steward supporting) — the sign-off that promote-to-product-knowledge deliberately withheld.
gather-requirements
Use when a delivery run needs PRD-style requirements produced from a user request: extracting every atomic requirement, rule, decision, and story into a classified requirement register, naming actors and protected actions, recording assumptions, open questions, and acceptance criteria. This is the gather_requirements action of the planning stretch — one Agent-tool dispatch with subagent_type business-analyst — distinct from resolve-open-questions (which answers the questions this action raises) and promote-to-product-knowledge (which files the resolved rows).
planning-security-scope
Use when a delivery run's freshly produced planning scope needs its functional security surface reviewed: which actors and actions are security-sensitive, what the abuse cases are, and what access assumptions the requirements silently make. This is the planning_security_scope action of the planning stretch — one Agent-tool dispatch with subagent_type security-reviewer — a requirements-level security read, distinct from security-architecture-review (design-level) and security-review (implementation-level).
promote-to-product-knowledge
Use when a delivery run's requirement register is fully resolved (no draft or questioned rows) and each resolved row must be filed into its canonical knowledge destination in draft status: creating or updating the destination file, updating the destination folder's index, and marking register rows promoted. This is the promote_to_product_knowledge action of the planning stretch — one Agent-tool dispatch with subagent_type business-analyst (documentation-steward supporting) — distinct from finalize-promoted-knowledge (the later Solution-Architect sign-off that flips draft to approved).
refresh-generated-context
Use when the knowledge base changed during a delivery run and its generated artifacts must be rebuilt: rebuilding the graph index and validating generated indexes against the changed content. This is the refresh_generated_context action of the knowledge-maintenance stretch — one Agent-tool dispatch with subagent_type devops-ops — the tooling-execution step, distinct from the documentation-steward actions around it that decide what changed and record the evidence.
repair-manifest-and-links
Use when a drift report exists and its findings must be fixed: manifests updated to point at active paths and every dangling or stale link repaired. This is the repair_manifest_and_links action of the knowledge-maintenance stretch — one Agent-tool dispatch with subagent_type documentation-steward — the fixer consuming detect-drift's report, never a fresh drift hunt of its own.
reproduce-failure
Use when a bug-fix run must first demonstrate the failure it claims to fix: reproducing the failure with a real command/test run, or — when reproduction is genuinely impossible — inspecting and recording the concrete failure evidence. This is the reproduce_failure action of the debugging stretch — one Agent-tool dispatch with subagent_type qa-engineer — the mandatory first step before any cause is hypothesized: no reproduction or inspection, no fix.
resolve-open-questions
Use when a delivery run's planning has blocking or open questions that must be answered by the human before requirements can be treated as resolved: asking each focused required question, recording the answer in writing, and moving register rows from questioned to resolved. This is the resolve_open_questions action of the planning stretch — one Agent-tool dispatch with subagent_type business-analyst — distinct from gather-requirements (which raises the questions) and from the delivery-lead's own checkpoint escalations.
runtime-validation
Use when an implementation slice touched runtime, container, compose, broker, or service-startup behavior and that behavior must be proven running: real startup of affected services, real endpoint checks, broker topology inspection, producing runtime validation evidence and operational risk notes. This is the runtime_validation action of the implementation stretch — one Agent-tool dispatch with subagent_type devops-ops — proving 'it started', never accepting 'it should start'.
security-architecture-review
Use when a completed technical design needs its independent security pass: reviewing design.md for security NFR evidence, tenant and auth boundary coverage, and naming every security gap found. This is the security_architecture_review action of the design stretch — one Agent-tool dispatch with subagent_type security-reviewer — a design-level review by a role that did not write the design, distinct from planning-security-scope (requirements-level) and security-review (implementation-level).
security-review
Use when an implementation slice's changed surface needs its security review: reviewing the actual changed files for auth, tenant-isolation, permission, and secret-handling correctness, producing applicable security-standard evidence and a residual-risk statement. This is the security_review action of the implementation stretch — one Agent-tool dispatch with subagent_type security-reviewer — implementation-level review of real changes, distinct from security-architecture-review (design-level) and the security_pattern_review action (review-diff skill, the later diff-pattern pass in code review).
technical-design
Use when clarified, finalized requirements need converting into a technical design: design.md with integration boundaries, required diagrams, and NFR review, including auth-boundary, tenant-isolation, and application-security-standard mapping checks. This is the technical_design action of the design stretch — one Agent-tool dispatch with subagent_type solution-architect (db-administrator supporting for schema and data-ownership) — distinct from clarify-requirements (which must complete first) and security-architecture-review (the independent security pass that follows).
testability-review
Use when a completed technical design needs its testability judged before implementation: whether acceptance criteria can actually map to concrete tests, which failure paths need coverage, and what the validation strategy is. This is the testability_review action of the design stretch — one Agent-tool dispatch with subagent_type qa-engineer — the QA read on a design, distinct from the test_evidence_review action (review-evidence skill, which later judges actual test results).
verify-fix
Use when a minimal fix has been applied and the original failure must be proven gone: running the regression validation target and observing it pass where it previously failed. This is the verify_fix action of the debugging stretch — one Agent-tool dispatch with subagent_type qa-engineer — the before/after proof, distinct from the test_evidence_review action (review-evidence skill, the later, broader verification pass over the whole change's evidence).
visual-design
Use when a UI-bearing target needs its visual design system produced or confirmed current: design tokens, palette, typography, spacing, iconography, component style guide, design-tool file link, and a wireframe index mapping each in-scope screen to its wireframe. This is the visual_design action of the design stretch — one Agent-tool dispatch with subagent_type ui-ux-developer — applicable to UI-bearing capabilities/features only (skip for backend-only design passes), and it ends at a mandatory human-approval checkpoint: detailed-prototypes must not begin until the human has approved this action's output.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.