← all publishers

yknothing

@yknothing source repo

Report this profile Claim this profile

• 119 skills
• 0 followers
• 9 hours ago last updated

1. ▌
   Pc Internationalization · yknothing bundle

   Use when user-facing text, locale-sensitive formatting, or multi-language behavior need explicit rules so copy, layout, and data presentation stay correct across locales.
   0
   installs
2. ▌
   Pc Bug History Retrieval · yknothing bundle

   Use when a current bug, incident, regression, or recurring symptom may match a known internal defect and the agent needs canonical evidence from issue trackers, incident systems, error monitoring, or git history before choosing a fix or next debugging step.
   0
   installs
3. ▌
   Pc Verification Before Completion · yknothing bundle

   Use when about to claim a phase, fix, task, build, or release is complete, fixed, passing, or ready for handoff and fresh evidence must be checked before making the claim or creating a commit, PR, or deployment decision.
   0
   installs
4. ▌
   Pc Implementation Integrity Audit · yknothing bundle

   Use after code changes when the reviewer must aggressively audit low-level defects, deceptive implementations, improper mocks, fake evidence, and test shortcuts before a delivery claim is trusted.
   0
   installs
5. ▌
   Pc Implementation Alignment Review · yknothing bundle

   Use after implementation or repair work when the reviewer must judge intent realization, requirement coverage, scope consistency, and claim truth before code-review or delivery-completion can accept the work.
   0
   installs
6. ▌
   Problem Framing · yknothing

   Use when intake has identified the likely lifecycle path but the problem statement, solution direction, or key trade-offs are still too fuzzy for requirements, research, or architecture work to start cleanly
   0
   installs
7. ▌
   CI CD · yknothing

   Use when a reviewed implementation slice needs an automated build, test, and deployment pipeline, especially when brownfield rollback, release-boundary checks, contract/integration gates, and staged delivery must be explicit before shipping.
   0
   installs
8. ▌
   Tdd · yknothing

   Use when a reviewed task is ready for implementation and the team must drive the work by writing failing tests first, especially when contract behavior, brownfield regressions, unsupported flows, or coexistence safety must be proven before code changes.
   0
   installs
9. ▌
   Spec Writing · yknothing

   Use when reviewed requirements need a shared product or technical specification that fixes scope, non-goals, interfaces, rollout concerns, and open questions before architecture or implementation. Skip for routine agile story refinement.
   0
   installs
10. ▌
    Code Review · yknothing

    Use when a concrete code change is ready for review and the reviewer must evaluate correctness, security, maintainability, test adequacy, contract alignment, and brownfield safety before merge, especially when unsupported flows, backward compatibility, or release-boundary constraints must be enforced.
    0
    installs
11. ▌
    Data Modeling · yknothing

    Use when the system structure is known and the team must turn domain concepts and architectural boundaries into durable storage schemas, ownership rules, and migration-safe data flow decisions before implementation.
    0
    installs
12. ▌
    Task Breakdown · yknothing

    Use when reviewed architecture or API contracts must be decomposed into implementation-ready work items, especially when sequencing, reversible brownfield increments, dependency mapping, and vertical slices must be explicit before coding begins.
    0
    installs
13. ▌
    Testing Strategy · yknothing

    Use when a reviewed implementation slice or feature needs a deliberate test plan across unit, integration, contract, and end-to-end layers, especially when brownfield regressions, unsupported flows, coexistence boundaries, or API contracts require explicit coverage beyond the default happy path.
    0
    installs
14. ▌
    Domain Modeling · yknothing

    Use when reviewed requirements still carry ambiguous business nouns, overlapping concepts, or possible bounded contexts, and the team needs a shared domain model before spec writing, API design, or data modeling.
    0
    installs
15. ▌
    API Design · yknothing

    Use when architecture boundaries are already defined and the team must specify stable API contracts between components or for external consumers, especially when backward compatibility, brownfield coexistence, authorization rules, and error semantics must be made explicit before implementation.
    0
    installs
16. ▌
    Security Design · yknothing

    Use when the architecture is defined and the team must turn trust boundaries, sensitive data paths, and attacker assumptions into concrete control design before implementation and audit.
    0
    installs
17. ▌
    User Research · yknothing

    Use when discovery needs evidence about target users, behaviors, and pain points, especially after intake or problem-framing surfaces open questions that must be validated before requirements are written
    0
    installs
18. ▌
    System Design · yknothing

    Use when reviewed requirements or specifications are ready and the team must decide high-level architecture, component boundaries, integration seams, or brownfield coexistence strategy before API design, technology selection, or task planning.
    0
    installs
19. ▌
    Requirements Engineering · yknothing

    Use when the work is still at the “what should we build” stage rather than design or implementation. Apply before spec-writing, architecture, API design, planning, or coding when interviews, personas, stakeholder notes, or discovery artifacts must be turned into prioritized functional requirements, non-functional requirements, scope boundaries, traceable sources, and explicit “the system shall” statements; not for acceptance criteria, PRD drafting from an approved requirements doc, spec review, or implementation.
    0
    installs