daw

Plugin daw in DiluxOne/dilux-agentic-workflow. Commands read from the repo's manifest — 7 days ago.

Skills (21)

• daw-commit

  Creates a commit following Gitmoji + Conventional Commits, with mandatory AI attribution. Trigger: /daw-commit, when a DAW phase closes and has artifacts to commit (DEFINE, PLAN, CODE, DISCOVERY, CLOSEOUT).

• daw-context-check

  Compares what the repository already declares about how it is built — linters, type checkers, CI, pre-commit, runtime versions — against what the tool's context file tells DAW. Reports the commands DAW would otherwise run wrong. Never blocks. Trigger: /daw-context-check, and once per ticket in CLASS

• daw-create-adr

  Records an architecture or design decision as an ADR (Architecture Decision Record). Captures the context, the options considered, the decision taken and its consequences. Trigger: /daw-create-adr, during DAW's PLAN or CODE phase.

• daw-create-pr

  Opens a Pull Request with a standard format and AI attribution labels, or records why one is not possible in this repo. Trigger: /daw-create-pr, during DAW's CLOSEOUT phase.

• daw-create-prd

  Creates a new PRD (Product Requirements Document) or updates an existing one. The PRD defines WHAT will be built: functional and non-functional requirements, acceptance criteria, scope and risks. Trigger: /daw-create-prd, during DAW's DEFINE phase.

• daw-create-spec

  Creates a new spec or fix-plan from an approved PRD or a fix diagnosis. Trigger: /daw-create-spec, during DAW's PLAN phase.

• daw-eject

  Copies the method out of the plugin and into this repository, so it can be read, edited and versioned with the project. After this, the repo's copy is the one that runs. Trigger: /daw-eject, available in any DAW phase.

• daw-family-catalog

  Regenerates the workspace's family catalog from each member repo's own `## Repo family` declaration — derived, never hand-edited, so it cannot rot. Trigger: /daw-family-catalog, standing in a family's workspace repo.

• daw-family-impact

  The impact analysis a family repo owes before leaving CLASSIFY: gathers the whole family fresh (cloning missing members via gh, reading every seam at origin), you write the verdict — every member impacted or excluded with a reason — and validation earns the receipt the CLASSIFY→DEFINE gate demands.

• daw-family-status

  The initiative's next step across the family, answered from ANY member repo: reads the index at the workspace's origin, asks the forge which children actually merged, and puts exactly one verdict on screen — the stale row to correct first, the next repo to walk to with its command, the blockers by n

• daw-help

  Getting-started guide for DAW. Use it when the user asks "how do I use DAW", "how do I start / install DAW", "what is DAW", or "what commands does DAW have". Trigger: /daw-help.

• daw-init

  Sets a project up with DAW: asks which spec format it uses and writes `.daw/config.yml`, the project's DAW settings, validated against its schema. Use it when the session boot offers it, or when the user asks to set DAW up, configure it, or use OpenSpec. Trigger: /daw-init.

• daw-security-sast

  Static Application Security Testing (SAST). Scans the code for security vulnerabilities. A BLOCKING GATE — the `sast` receipt is what lets a ticket leave CODE, in every tier. Trigger: /daw-security-sast, during DAW's CODE phase.

• daw-self-check

  Full coherence validation of the internal state. Checks that the DAW installation in the repo is sound and that the pipeline state is consistent with the artifacts on disk. Read-only. Trigger: /daw-self-check, available in any DAW phase.

• daw-status

  Reads .daw-state.json and prints a formatted summary of where the pipeline is. Read-only — it modifies no file. Trigger: /daw-status, available in any DAW phase.

• daw-test

  Runs the project's tests, generating missing ones when needed. A blocking gate. Trigger: /daw-test, during DAW's CODE phase.

• daw-threat-modeling

  Threat analysis of the proposed design. Identifies new attack surfaces and security risks before any code is written. The findings become mitigations folded into the spec. Trigger: /daw-threat-modeling, during DAW's PLAN phase.

• daw-validate-arch

  Validates that the code follows the project's architecture decisions and conventions. An advisory check, not a gate: the graph carries no `arch` condition, so it reports and the orchestrator decides. Produces disambiguation questions when a finding needs the user's context. Trigger: /daw-validate-ar

• daw-validate-prd

  Validates a PRD against the catalog's PRD rules and the project's architecture. Produces a disambiguation question for every FAIL, so gaps get resolved before approval. Trigger: /daw-validate-prd, during DAW's DEFINE phase.

• daw-validate-spec

  Validates that a spec/fix-plan is complete, coherent and consistent with its PRD, against the catalog's spec rules. Produces a disambiguation question for every FAIL. Trigger: /daw-validate-spec, during DAW's PLAN phase.

• daw-verify-module

  Verifies that a completed module meets every acceptance criterion in its PRD and every task in its spec. A blocking gate. Trigger: /daw-verify-module, during DAW's VERIFY phase.

Subagents (5)

• daw-arch-auditor

  Read-only architecture auditor. Spawn it in PLAN to check a proposed spec against the project's conventions, and in CODE after each block to audit the files it touched. Reports violations of the project's conventions and architectural patterns; never modifies code.

• daw-impact-scanner

  Read-only codebase scanner. Given a draft technical plan, finds every file the change actually touches — sibling implementations, call sites, exports and repeated patterns — and reports the gaps. Never edits anything.

• daw-implementer

  Implements exactly ONE block of an approved spec, with its tests, in an isolated context. Returns a report of what it built. Does not commit, does not touch the state, does not go beyond its block.

• daw-module-verifier

  Spawn it on an implementation it did not write, at either of two moments — per block in CODE, to check that block against its spec and to check the TDD evidence (which test was seen to fail, and on which assertion); and in VERIFY, to cross-check the whole module against the PRD, the spec and the tes

• daw-sec-auditor

  Security auditor. Spawn it in CODE when a SAST scan reports findings, to triage them before anyone starts fixing. Classifies true and false positives and provides remediation guidance.

Similar plugins