Skip to content

feat: Add work item type distinction#95

Draft
dvic wants to merge 1 commit intosubsy:mainfrom
dvic:dvic/work-item-types
Draft

feat: Add work item type distinction#95
dvic wants to merge 1 commit intosubsy:mainfrom
dvic:dvic/work-item-types

Conversation

@dvic
Copy link

@dvic dvic commented Jan 15, 2026

Addresses #88

Changes

Adds work item type distinction to PRD skills and JSON tracker:

Prefix Type When to Use
US-xxx story User-facing features ("As a user, I want...")
TA-xxx task Technical work (schema, backend, bugs, maintenance)
  • PRD skills now document US-xxx for stories, TA-xxx for tasks
  • Adds type field to prd.json schema (inferred from prefix if not explicit)
  • Beads converter uses --type=story|task flag
  • Backward compatible: existing files without type field still work

Note: Haven't tested this yet - wanted to run it by you early. Happy to adjust based on feedback.

@vercel
Copy link

vercel bot commented Jan 15, 2026

@dvic is attempting to deploy a commit to the plgeek Team on Vercel.

A member of the Team first needs to authorize it.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 15, 2026

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@subsy
Copy link
Owner

subsy commented Jan 15, 2026

@dvic I think just keeping it as story / task is the best path here. My inclination is that bug and chore types dont add much value context-wise for the model - they're both tasks. Does that work for you?

Update PRD skills and JSON tracker to support typed work items:

- US-xxx → story (user-facing features, "As a user, I want...")
- TA-xxx → task (technical work: schema, backend, bugs, maintenance)
- Add type field to prd.json schema, inferred from ID prefix if not explicit
- Support both workItems and userStories arrays for backward compatibility
- Use --labels="ralph" only; type classification via --type= flag

Addresses subsy#88
@dvic dvic force-pushed the dvic/work-item-types branch from 23f277a to 14f15b7 Compare January 15, 2026 23:45
@dvic
Copy link
Author

dvic commented Jan 15, 2026

@dvic I think just keeping it as story / task is the best path here. My inclination is that bug and chore types dont add much value context-wise for the model - they're both tasks. Does that work for you?

Sure, I've updated the PR

@dvic dvic changed the title feat: Add work item type distinction (F/T/B/C prefixes) feat: Add work item type distinction Jan 16, 2026
@subsy
Copy link
Owner

subsy commented Jan 16, 2026

@dvic I've been reviewing the changes and they are fine.
But I can't help thinking about the net change to the system and how it performs.
Have you done any a/b tests with the same input ie what you want to build) into the PRD creator, and assessed differences in eventual output of what gets build by the ralph loop?
Because models are so good at figuring things out, I'm wondering if the extra dimensions here is help or hindrance to the model, and perhaps just letting it figure out what it needs to do from a set of user stories is the better approach. Curious to learn about what results you've seen in testing.

@dvic
Copy link
Author

dvic commented Jan 16, 2026

@dvic I've been reviewing the changes and they are fine. But I can't help thinking about the net change to the system and how it performs. Have you done any a/b tests with the same input ie what you want to build) into the PRD creator, and assessed differences in eventual output of what gets build by the ralph loop? Because models are so good at figuring things out, I'm wondering if the extra dimensions here is help or hindrance to the model, and perhaps just letting it figure out what it needs to do from a set of user stories is the better approach. Curious to learn about what results you've seen in testing.

I'll try to do a mini project with and without this PR and see what the differences are :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants