// Use when explicitly asked to discover and document a project's development workflow by indexing the repository
Use when about to make any factual claim — API behavior, library features, configuration options, platform specifics, version details, or any technical assertion — without a verifiable reference link. Requires searching online resources and citing authoritative sources before stating facts.
Use when about to state a conclusion, diagnosis, recommendation, or any technical assertion — requires actively arguing against your own position before committing to it, to catch first-match bias, confirmation bias, and shallow analysis.
Dispatches long-running commands to terminal multiplexers (tmux, screen, zellij) instead of blocking the agent's execution tool. Use when about to execute a command that runs indefinitely or for extended periods, such as dev servers, file watchers, log tails, or long test suites.
Prevents piping command output through tail or head which permanently discards data. Use when about to execute shell commands, especially builds, tests, or any command with potentially large output.
| name | project-workflow |
| description | Use when explicitly asked to discover and document a project's development workflow by indexing the repository |
Index a repository to discover its development workflow and write it to .workflow/workflow.yaml.
Only when explicitly asked. Typically invoked via a headless opencode run or the /workflow-init command.
Analyze the repository:
git log --oneline -50, branch naming, merge patterns.github/workflows/, .gitlab-ci.yml, Jenkinsfilepackage.json scripts, Makefile, Dockerfile.eslintrc, .prettierrc, .editorconfigIdentify the workflow phases the project follows. Common phases include:
For each phase, identify:
Identify project-wide conventions:
Write the result to .workflow/workflow.yaml using this schema:
version: 1
metadata:
last_indexed: "<current ISO timestamp>"
phases:
- id: <short-identifier>
name: <Human Readable Name>
description: <one sentence>
conventions:
- <convention string>
gate:
- <criteria string>
transitions:
- from: <phase-id>
to: <phase-id>
project_conventions:
branching:
pattern: "<glob pattern>"
main_branch: <branch name>
commits:
format: <format name>
code_style:
language: <primary language>
linter: <linter name>
formatter: <formatter name>
transitions array defines the order. Each phase should transition to exactly one next phase.