Chief Feature Workflow
WarnAudited by ClawScan on May 10, 2026.
Overview
This workflow is coherent for Chief-based feature development, but it recommends autonomous subagents that can auto-approve shell prompts and push/open PRs without clear review gates.
Install only if you are comfortable with Chief and Claude Code modifying your project. Prefer supervised runs, do not use 'always allow' for bash prompts unless you fully trust the repo and task, and review diffs before commits, pushes, or PR creation.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
The agent could run commands, modify files, commit, push, and open a PR before the user has reviewed the exact changes or commands.
The skill tells an agent-controlled subagent to run an AI implementation loop, approve bash prompts, optionally always allow them, and then publish repository changes. This is broad tool authority with limited user review.
Spawn a subagent with this task: - Working directory: ~/<project>-<prd-name> - Run `chief <prd-name>` with pty:true - Press `s` to start the loop - Approve bash prompts with `1` + Enter (or `2` to always allow) - ... - Commit progress.md, push, open PR
Require explicit user approval before using 'always allow', before running nontrivial shell commands, and before any git push or PR creation.
Multiple autonomous agents may keep changing code and consuming API quota or money until they finish, and mistakes could be harder to supervise in parallel.
The workflow encourages long-running autonomous subagents and parallel execution. Although disclosed and purpose-related, it lacks clear stop conditions, approval checkpoints, or containment beyond separate worktrees.
The subagent runs fully isolated and auto-announces on completion. You can spawn **multiple subagents in parallel** — one per PRD/worktree — for concurrent feature development.
Use one supervised run by default, define stop conditions, avoid parallel subagents unless necessary, and require checkpoints before commits, pushes, or PRs.
Changes may be published to the configured remote repository using the user's account.
The workflow uses the user's local Git and GitHub CLI authentication to publish a branch and open a pull request. This is expected for the purpose, but it acts under the user's repository identity.
git push -u origin feat/<prd-name> ... gh pr create \ --title "feat: <prd-name>"
Confirm the target repository, branch, GitHub account, and PR contents before pushing or creating the PR.