issue-driven-workflow
SolidTurn a large task into a persistent plan file and a trackable Issue CSV (local files, not an external issue tracker), then execute the issues autonomously with per-row status updates. Use when work must survive across sessions or hand off between agents, when you need an auditable record of multi-step execution, or to resume a plans/ and issues/ pair from an earlier session. Do not use for single-session tasks that your harness's built-in plan or todo tracking already covers.
Install
Quality Score: 80/100
Skill Content
Details
- Author
- appautomaton
- Repository
- appautomaton/agent-designer
- Created
- 8 months ago
- Last Updated
- 3 days ago
- Language
- Python
- License
- None
Similar Skills
Semantically similar based on skill content — not just same category
start-issue
Start working on issue <argument>. Run autonomously through the full plan-critique-implement cycle. Use for /start-issue requests.
issue-driven-github-flow
Enforces an issue-driven GitHub Flow with multi-agent planning. Use this skill when the user wants to START or CARRY OUT development work in a git repository — implement a feature, fix a bug, make or change code, kick off a new project, or open/land a PR — including when they don't say "issue", "branch", or "gitflow" (e.g. "let's build X", "fix this bug", "add a feature", "start on Y", "get this project going"). It guarantees every change traces to a GitHub issue, gets a reviewed-and-approved plan before any code is written, lands on a `type/description` branch via a squash-merged PR with Conventional Commits, and never edits `main` directly. Do NOT trigger for purely informational or read-only requests that change nothing — e.g. "what's the git command for X", "explain this function", "show me the diff", "what branch am I on" — just answer those directly.
agentic-phase-workflow
Run the issue-backed development loop that turns a ratified spec into shipped increments: select an owning Issue, confirm implementation authority, implement on a focused branch, open a draft PR after the first coherent green commit, review independently, repair with regression tests, reconcile documentation and tracking, and close delivery state after merge. Use when planning or running a feature phase, hardening pass, bundled phase, spec-drift audit, workflow-improvement release, or release closeout; when deciding whether work is phase-shaped or pass-shaped; or when sequencing Issues within a milestone. Do not use for day-one project bootstrap, repository-wide documentation migration, or ordinary Issue/PR administration that does not require choosing or running a development shape. Premise: the workflow is the product, as much as the code.