Issue driven workflow
Harness Kit is a reusable Codex workflow layer for repositories that want a clean operating system around implementation work.
npx -y skills add HyunKN/harness-kit --skill issue-driven-workflowAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when a project follows an issue-first workflow and implementation should be tracked through docs/issues before, during, and after coding. Trigger for non-trivial bug fixes, features, refactors, or reliability work once the problem is already clear enough to execute. Do not use this skill as a substitute for early problem framing or detailed task decomposition when those are still missing.
SKILL.md
1.7 KB, 280 tokens by cl100k_base, as published. Nobody here has run it
Issue Driven Workflow
Run non-trivial implementation through an issue document so problem, scope, risks, validation, and next steps stay explicit.
Default flow
- If the request is still vague, hand off to
spec-writingfirst. - Create or update an issue doc before coding.
- Keep the issue state in sync with actual work.
- Record affected files, linked docs, and validation commands.
- After completion, update:
docs/issues/current_backlog.mddocs/status/implemented_features.mdwhen real functionality changed
- Use troubleshooting notes, decision records, and review notes when the work produces reusable evidence beyond the issue itself.
- Always remind what was just completed and what remains.
Good fit
- feature work
- bug fixes with more than one file
- reliability or UX cleanup
- refactors with validation requirements
Avoid for
- tiny spelling fixes
- trivial one-line changes with no real scope
Resources
- See
references/issue-lifecycle.mdfor the recommended issue lifecycle. - Pair with
spec-writingwhen scope is loose andplanning-workflowwhen the issue is too large to execute directly. - Keep the issue doc focused on execution state; move durable rationale to
decision-recordingand mechanism explanations totechnical-learning-note.
What ships with it: 2 files
451 B alongside SKILL.md
agents/
- openai.yaml148 B
references/
- issue-lifecycle.md303 B