divedra-impl-workflow

name

divedra-impl-workflow

description

Use when implementation work in this repository changes behavior, adds functionality, or fixes bugs and the user has not explicitly asked to avoid workflows. Routes the work through the project-local divedra workflow `.divedra/workflows/design-and-implement-review-loop`, including design/plan alignment, implementation, review, user-facing documentation refresh, commit-message generation, and built-in git commit/push steps.

Divedra Implementation Workflow

Use this skill as the default path for implementation work in this repository.

Apply This Skill When

• fixing a bug
• adding or changing runtime behavior
• implementing a feature from a design or implementation plan
• making a non-trivial refactor that changes implementation behavior

Do Not Apply This Skill When

• the user explicitly says not to use a workflow
• the task is documentation-only or planning-only with no implementation
• the task is specifically to debug or repair divedra itself; use divedra-fix

Default Workflow

Use the project-local workflow bundle:

• Workflow id: design-and-implement-review-loop
• Catalog path: .divedra/workflows/design-and-implement-review-loop

Preferred entry point from the repository root:

task divedra-design-implement -- --output json

Equivalent direct command:

nix run .#divedra -- workflow run design-and-implement-review-loop --output json

Runtime Inputs

For normal implementation work, run the workflow in issue-resolution mode.

Pass structured workflow input through --variables when the task needs explicit issue/reference context. Typical fields:

• workflowInput.issueUrl
• workflowInput.issueNumber
• workflowInput.issueRepository
• workflowInput.issueTitle
• workflowInput.issueBody
• workflowInput.targetFeatureArea
• workflowInput.requestedBehavior
• workflowInput.codexAgentReferences
• workflowInput.referenceRepositoryRoot
• workflowInput.referenceRepositoryUrl

Planning-only mode is available via:

• workflowInput.executionMode: "design-plan-only"

Expected Behavior

The workflow is responsible for:

1. issue or task intake
2. design-document updates
3. design self-review
4. design review
5. implementation-plan creation or revision
6. implementation-plan self-review
7. implementation-plan review
8. implementation work
9. implementation self-review
10. implementation review
11. user-facing documentation refresh (README.md and exposed workflow skill docs)
12. staged secret scan with gitleaks git --pre-commit --redact --staged --verbose
13. commit-message generation
14. built-in git commit and git push add-on steps

Because the workflow ends with commit/push, do not use it when the user has explicitly asked to avoid workflow-driven commits or wants manual local edits only.

Reporting

After the workflow finishes, report:

• workflow mode
• changed files
• verification commands
• commit message
• commit hash
• pushed remote and branch

If the workflow fails because divedra appears incorrect, switch to the divedra-fix skill.