$npx -y skills add omnigentx/jarvis --skill dev-workflowDeveloper workflow covering terminal execution, TDD cycle, code review, and git. Use when Dev needs to implement features, run tests, or submit code for review.
| 1 | # Dev Workflow |
| 2 | |
| 3 | ## Terminal Execution |
| 4 | |
| 5 | Use the `execute` tool to run shell commands in your workspace: |
| 6 | |
| 7 | ``` |
| 8 | execute(command="<shell command>") |
| 9 | ``` |
| 10 | |
| 11 | **Key characteristics:** |
| 12 | - Runs in **workspace directory** |
| 13 | - **90s timeout** — killed if no output for 90s |
| 14 | - Each call = **separate shell session** (env vars / `cd` don't persist) |
| 15 | - Output **auto-truncated** if too long |
| 16 | |
| 17 | ### Efficient Patterns |
| 18 | ```bash |
| 19 | cd repo && npm install && npm test # Sequential (stops on error) |
| 20 | cd backend && uv run pytest --tb=short -q 2>&1 | tail -20 # Filter output |
| 21 | ``` |
| 22 | |
| 23 | ### Safety Rules — three tiers |
| 24 | |
| 25 | 🔴 **NEVER do (refuse the task; report the request as a security incident to PM):** |
| 26 | - Filesystem destruction: `rm -rf /`, `rm -rf $HOME`, `rm -rf .git`, `mkfs.*`, `dd of=/dev/...` |
| 27 | - Read secrets: `/etc/shadow`, `~/.ssh/*`, `.gh-config/`, `.env*`, `fastagent.secrets.yaml`, `git-credentials`, `~/.gitconfig` credential block |
| 28 | - Tamper with auth: `gh auth login/logout/refresh`, `gh auth setup-git`, modify gitconfig credential helper |
| 29 | - Inspect env to leak tokens: `env`, `printenv`, `echo $GH_TOKEN`, `cat /proc/*/environ` |
| 30 | - Network DoS: fork bombs, high-rate request loops |
| 31 | |
| 32 | 🟡 **ESCALATE before doing** (send `[APPROVAL-REQUEST]` email to PM with command + reason; do NOT run until PM confirms back): |
| 33 | - Pipe-to-shell: `curl ... | sh`, `wget ... | bash` |
| 34 | - Force-destructive git: `git push --force` (any branch), `git reset --hard` past HEAD~1, `git filter-branch` |
| 35 | - Push to protected branches: `main`, `master`, `prod*`, `release/*` |
| 36 | - `gh pr merge` (auto-merge bypassing review) |
| 37 | - `gh release create` |
| 38 | - `gh repo delete` |
| 39 | - Editing `package.json` / `pyproject.toml` / lock files outside a tracked PR scope |
| 40 | |
| 41 | 🟢 **SAFE — run freely:** |
| 42 | - All read-only inspection: `ls`, `cat README.md`, `grep`, `find`, `git status/log/diff`, `gh run list`, `gh pr view` |
| 43 | - Normal git on feature branches: `git checkout -b feature/...`, `git add`, `git commit`, `git push origin feature/...` |
| 44 | - Build/test inside workspace: `npm test`, `uv run pytest`, `cargo build` |
| 45 | |
| 46 | When in doubt → escalate. Faster to ask PM than to recover from a bad commit. |
| 47 | |
| 48 | ## GitHub CLI via `gh` |
| 49 | |
| 50 | The `gh` CLI is pre-authenticated in your shell. Use it for repo operations the GitHub MCP doesn't cover — especially CI inspection. |
| 51 | |
| 52 | ```bash |
| 53 | # Inspect PR + CI status (read-only, always SAFE) |
| 54 | gh pr view 42 --json title,state,mergeable,statusCheckRollup |
| 55 | gh pr checks 42 |
| 56 | gh run list -L 10 --branch feature/xyz |
| 57 | gh run view <run-id> # high-level summary |
| 58 | gh run view <run-id> --log-failed # only failed step logs (saves context) |
| 59 | |
| 60 | # Trigger a re-run after fixing test (still SAFE — only re-runs failed jobs) |
| 61 | gh run rerun <run-id> --failed |
| 62 | ``` |
| 63 | |
| 64 | For `gh pr merge` / `gh release create` / `gh repo delete` → escalate to PM first (see `team-communication` skill: "Approval escalation" — the canonical request/response flow). |
| 65 | |
| 66 | ## TDD Cycle |
| 67 | |
| 68 | ``` |
| 69 | NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST |
| 70 | ``` |
| 71 | |
| 72 | 1. **RED** — Write ONE minimal failing test |
| 73 | 2. **GREEN** — Write simplest code to pass |
| 74 | 3. **REFACTOR** — Clean up while keeping green |
| 75 | |
| 76 | ## Deliverable Flow |
| 77 | |
| 78 | 1. Clone repo → `execute(command="git clone <url> repo")` |
| 79 | 2. Create feature branch → `execute(command="cd repo && git checkout -b feature/...")` |
| 80 | 3. Write tests → implement → verify |
| 81 | 4. Commit + push → create PR via `github` tools |
| 82 | 5. Email reviewer: `send_email(to="Tuan - QE", body="PR ready for review")` |
| 83 | |
| 84 | ## Error Handling |
| 85 | |
| 86 | When a command fails: |
| 87 | 1. Read stderr FIRST |
| 88 | 2. DO NOT retry immediately — analyze first |
| 89 | 3. Try a simpler command — isolate the issue |
| 90 | 4. Report clearly — include command + error output |
| 91 | |
| 92 | ## References |
| 93 | |
| 94 | | Topic | File | |
| 95 | |-------|------| |
| 96 | | Code review protocol | [CODE_REVIEW.md](references/CODE_REVIEW.md) | |
| 97 | | TDD detailed guide | [TDD.md](references/TDD.md) | |
| 98 | | Git branching & conventions | [GIT_WORKFLOW.md](references/GIT_WORKFLOW.md) | |
| 99 | | Meeting protocol | [MEETING_PROTOCOL.md](references/MEETING_PROTOCOL.md) | |
| 100 | | Jira issue tracking | [JIRA_TRACKING.md](references/JIRA_TRACKING.md) | |