Our review
This skill enforces a structured project flow: triage the problem, write a PRD, track work in task.md, then sync changelog.md, files.md and recorded lessons.
Strengths
- Clear guardrails for non-trivial work: triage before touching code, then a PRD covering root cause, files to change, edge cases and verification steps
- Durable traceability through UTC timestamps, Draft/In Progress/Done statuses and a task completion log
- Consistent docs sync after every feature or fix, with a Keep a Changelog changelog seeded from real `git log --date=short` dates
- A learning loop that records repeated user corrections in prds/lessons.md so mistakes do not recur
Limitations
- Assumes a fixed file convention (prds/, task.md, changelog.md, files.md) that must already exist or be created in the repo
- The full process is deliberately heavyweight and is only shortened for obvious single-file fixes
- Relies on git log access and subagents, which ties it closely to Claude Code
Reach for it whenever a request spans multiple steps or files, alters architecture, or requires project tracking to be updated.
Skip it for typos, tiny copy edits, or an obvious one-file fix.
Security analysis
SafeThe skill only describes a project workflow: creating PRDs, updating task.md, changelog.md, files.md, using git log for dates, and optionally using subagents. It does not declare or invoke any dangerous tools, destructive commands, exfiltration, or obfuscated payloads. The only command mentioned is `git log --date=short -n 10`, which is benign and read-only.
No concerns found
Examples
Add cursor-based pagination to the /orders endpoint — it touches the controller, the repository layer and the API docs. Write a PRD first, then track the work in task.md.@update — sync task.md, changelog.md and files.md now that the SSO redirect fix is merged.Users get logged out randomly after about 10 minutes. Triage the likely causes, write a PRD with the root cause once found, and log the fix in the changelog.name: workflow description: Project workflow for PRDs, task tracking, changelog sync, and documentation updates. Use for any non-trivial task that spans multiple steps, touches several files, changes architecture, or needs project tracking updates. Also activates with @update to sync task.md, changelog.md, and files.md after completing work.
Project Workflow Skill
Use this skill for any non trivial task that spans multiple steps, touches several files, changes architecture, or needs project tracking updates.
Activate with: @update (for docs sync only)
Triage first
Before changing code:
- Identify what is missing, broken, or incomplete.
- Theorize a few likely causes or approaches.
- Narrow to the most likely plan.
- Ask if anything important is still unclear.
Skip the long process only for obvious one file fixes like typos or tiny copy changes.
PRD rules
Create a PRD before non trivial work.
- Path:
prds/<feature-or-problem-slug>.md - Extension:
.md - Include:
- problem
- root cause for bugs
- proposed solution
- files to change
- edge cases
- verification steps
- task completion log
Add metadata at the top:
Created: YYYY-MM-DD HH:mm UTCLast Updated: YYYY-MM-DD HH:mm UTCStatus: Draft | In Progress | Done
Task tracking
Update task.md as the work moves forward.
- Put new work under
## to do - Move finished work to
## completed - Add timestamps in
YYYY-MM-DD HH:mm UTC - Do not mark a task done until it has been verified
- Keep task notes short but specific enough for the next session
When useful, include:
- the PRD path
- the files touched
- the verification command or outcome
Docs sync after changes
After each feature or fix, sync the project docs:
task.mdchangelog.mdfiles.md
For changelog.md:
- use Keep a Changelog structure
- get real dates from
git log --date=short -n 10 - add timestamps when helpful
For files.md:
- add new files
- update descriptions that changed
- keep descriptions brief and concrete
Execution style
- Use subagents for research or parallel analysis when the task is large enough to benefit.
- Use one focused subagent per task.
- Stop and re plan if the work stops making sense.
- Keep the change set tight.
- Ask whether a staff engineer would approve the result before calling it done.
Learning loop
If the user corrects a repeated pattern, record the lesson in prds/lessons.md so the mistake does not come back.
Design-to-Dev Specification Writer
Development
Translate your mockups into technical specifications for developers.
QCC Plus Git Workflow
Development
Defines the Git workflow for the QCC Plus project: branch strategy (test/main/prod), conventional commit format, and release process. Helps developers maintain consistency and avoid mistakes like force-pushing to main.
AXEL Skill Definition Reference
Development
Reference for structuring skill definition files, including frontmatter, templates, roles, and enforcement rules.