← all publishers

m0m0i

@m0m0i source repo

Report this profile Claim this profile

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

1. ▌
   Prd · m0m0i

   Write the product requirements — who it is for, what capabilities it must have, what it deliberately is not — with stable capability ids that specs cite. Use at project inception, after northstar and before any technical design.
   0
   installs
2. ▌
   Init · m0m0i

   Set up this SDD harness in a project — detect the toolchain, interview for what cannot be inferred, and write .steering, .specs, .work_logs, a project-specific reviewer, and the hooks. Use once per project, or to migrate a project that already has parts of the harness.
   0
   installs
3. ▌
   Spec · m0m0i bundle

   Turn a feature idea or tracker issue into ONE reviewable spec — Requirements, Design, TDD-ordered Tasks — under .specs/. Use at the start of any new feature, before writing code.
   0
   installs
4. ▌
   Epics · m0m0i

   Decompose capabilities into epics — chunks of work with a demonstrable outcome — each grouping the issues that specs will be written from. Use between the PRD and the backlog.
   0
   installs
5. ▌
   Sprint · m0m0i

   Decompose the top of the product backlog into typed tracker issues for this iteration — each sized as one issue, one branch, one spec, one PR. Use at the start of an iteration. This is where a plan becomes committed work.
   0
   installs
6. ▌
   Archive · m0m0i

   Sweep shipped specs out of .specs/ into .specs/_archive/ and set Status archived, so a session globbing .specs/ sees only live work. Use on request, when .specs/ has accumulated enough finished work to be noise — not after every merge.
   0
   installs
7. ▌
   Backlog · m0m0i

   Order the whole of the known work into a product backlog, with an explicit critical path and reasons for the order. Use after epics, and to re-groom when reality diverges. Creates no issues — sprint does that.
   0
   installs
8. ▌
   Clarify · m0m0i

   Interrogate a draft spec's Requirements for ambiguity before any Design or Tasks exist — at most 5 targeted questions, answers recorded in the spec. Use between drafting Requirements and writing the rest.
   0
   installs
9. ▌
   Worklog · m0m0i

   Append a dated entry to .work_logs/ summarizing what changed this session — activities, decisions, next steps. Use at the end of a working session or right after implement.
   0
   installs
10. ▌
    Contract · m0m0i

    Write the development contract — the language, style, testing, and review rules this project holds itself to — and compile the enforceable ones into the reviewer's rulebook. Use at project inception, or when recurring review findings reveal an unwritten rule.
    0
    installs
11. ▌
    Implement · m0m0i

    Execute an approved .specs/<slug>/spec.md through the TDD Red-Green-Refactor loop, then pass the mandatory reviewer gate before any PR. Use after a spec has been reviewed and approved.
    0
    installs
12. ▌
    Northstar · m0m0i

    Name the one metric this product moves, the levers that move it, and the quality property a defect would most damage. Use at project inception, before the PRD. Produces the anchor that every reviewer severity is judged against.
    0
    installs
13. ▌
    Design Doc · m0m0i

    Write the technical design — the architecture, the seams between components, and the decisions worth recording as ADRs. Use after the PRD and before the backlog, or when a capability needs a design bigger than one spec.
    0
    installs