← all publishers

eduwxyz

@eduwxyz source repo

Report this profile Claim this profile

• 6 skills
• 0 followers
• 7 hours ago last updated

1. ▌
   Tdd · eduwxyz bundle

   Drives feature work and bug fixes through a tight failing-test-first loop. Trigger when implementing, fixing, or refactoring behavior in a codebase that already has tests. Skip for spikes, visual-only edits, throwaway scripts, and generated files.
   0
   installs
2. ▌
   Verify · eduwxyz bundle

   Verify that a spec.md's Acceptance criteria are observably covered by green tests before opening a PR. Reads the spec, finds the tests that cover each AC, runs the suite to confirm everything green, and reports gaps (uncovered AC, skipped tests, missing edge-case coverage). When gaps exist, automatically iterates with `tdd` until the spec is satisfied — does not stop while gaps remain. Surfaces tests not mapping to any AC as warnings (no auto-fix; user decides). Trigger after `tdd` is green and before sending the work for review, when the user says "verify the spec", "are we done", "check coverage against spec", "ready for review", "is this PR-ready".
   0
   installs
3. ▌
   Feature · eduwxyz

   Feature
   0
   installs
4. ▌
   Diagnose · eduwxyz

   Diagnose
   0
   installs
5. ▌
   Spec Approach · eduwxyz bundle

   Add a refined `## Approach` section to an existing feature spec.md before TDD executes it. Reads the spec, explores the codebase to ground the approach in real modules and patterns, proposes 2–3 alternatives when they exist, validates with the user, then appends `## Approach` to the same spec file. Trigger after `interview-to-spec` for non-trivial features when the user says "plan the approach", "spec the implementation", "design the approach", "how are we building this", or before invoking `tdd` on a feature whose HOW is unclear.
   0
   installs
6. ▌
   Interview To Spec · eduwxyz

   Conduct a focused interview to draft a spec.md for an upcoming task (the input step of SDD — spec-driven development). Walks through goal, behaviors, acceptance criteria, edge cases, and out-of-scope one branch at a time, then writes the spec to disk. If during the interview the scope turns out to be multiple independent features, pauses and asks the user to pick one — the chosen one becomes the spec, the rest stay outside the repo. Trigger when the user wants to draft a spec before implementation, mentions "draft the spec", "let's spec this out", "what should we build", or starts an SDD workflow.
   0
   installs