issue-driven-workflow

Solid

Turn 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.

AI & Automation 130 stars 17 forks Updated 3 days ago

Install

View on GitHub

Quality Score: 80/100

Stars 20%
71
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
0
Description 5%
100

Skill Content

# Issue-Driven Workflow ## Philosophy The plan and Issue CSV are a work amplifier. Front-load the thinking so the agent has a full plate of actionable work to execute autonomously. More rows means more useful work per run. 1. **Planning (interactive)**: search the web, read docs, ask questions, gather context. A thorough plan means more work the agent can do without stopping. 2. **Execution (autonomous)**: be proactive, not passive. Work through the CSV end to end and do not wait for permission on routine decisions. The quality bar: every CSV row is completable, testable, and markable DONE without further clarification. ## E2E loop plan → issues → implement → test → review ## Paths Commands below write `<skill_dir>` for the absolute path of the directory containing this SKILL.md. Your harness usually reports that path when it loads the skill. If it does not, use this SKILL.md's own location. Substitute it before running. Run the scripts from inside the target project. They resolve the project root from the working directory (nearest `.git`, then `AGENTS.md`), and artifacts land at that root: plans in `plans/`, issue CSVs in `issues/`. ## Planning (interactive) 1. Restate the task and assumptions. 2. Gather context: search the web, read project files, inspect dependencies. Make every plan section concrete, not aspirational. 3. Ask up to 2 clarification questions if unclear, then proceed with stated assumptions. 4. Draft the plan body using the structure of `assets/_...

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

AI & Automation Listed

start-issue

Start working on issue <argument>. Run autonomously through the full plan-critique-implement cycle. Use for /start-issue requests.

1 Updated 3 days ago
amurshak
Code & Development Listed

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.

1 Updated 1 months ago
andybaran
AI & Automation Listed

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.

0 Updated 1 weeks ago
gidde032