← all publishers

hellotern

@hellotern source repo

Report this profile Claim this profile

• 11 skills
• 0 followers
• 11 hours ago last updated

1. ▌
   Plan · hellotern

   You MUST use this skill before starting multi-step implementation work when no ordered task breakdown exists yet. Use when the requirement is confirmed and clear, and you need to answer "how do we build this and in what order" — producing an ordered task list with skill assignments and acceptance criteria. Stronger signals: "plan this", "how should we build this", "break this into tasks", "sprint plan", "what order should we do this in", "create a task list", "what's the implementation sequence". Use sextant:refine-requirements first if the requirement itself is still ambiguous (that skill answers "what"; this skill answers "how and in what order"). Use sextant:add-feature directly when the task is a single, well-scoped unit that needs no sequencing.
   0
   installs
2. ▌
   Ship · hellotern

   You MUST use this skill before creating a PR, bumping a version, or declaring work ready to merge. Use when the implementation is done and the goal is to get it across the finish line — PR creation, changelog, version bump, final pre-merge checks. Stronger signals: "ship this", "create a PR", "write changelog", "bump version", "prepare for merge", "what do I need before merging", "ready to release". Use sextant:review-code instead when the goal is to evaluate code quality, not to prepare it for shipping.
   0
   installs
3. ▌
   Debug · hellotern

   You MUST use this skill before reading any code or proposing any fix when the bug location is unknown. Use when you have a symptom (error, crash, unexpected output) but cannot yet point to the specific function or line where it originates. Stronger signals: "I don't know where this is coming from", "can't reproduce consistently", "something is wrong but I don't know where", intermittent failures, no stack trace. Use sextant:fix-bug instead when you CAN already point to the specific file or line causing the bug.
   0
   installs
4. ▌
   Fix Bug · hellotern

   You MUST use this skill before writing any fix or editing any code to address a bug. Use when the code should do X but currently does Y — restoring correct behavior in existing code. Stronger signals: error messages, stack traces, "not working", "broken", "failing", "regression", "it used to work". Use sextant:debug instead when you have a symptom but cannot yet point to a specific file or line. Use sextant:modify-feature instead when the requirement itself is changing, not just broken behavior.
   0
   installs
5. ▌
   Migrate · hellotern

   You MUST use this skill before starting any cross-module migration, upgrade, or technology conversion. Use when multiple files or modules must change in a coordinated sequence — framework upgrades, language conversions, schema migrations, or major API version changes. Stronger signals: "migrate", "upgrade", "convert", "port", "move from X to Y", "upgrade to version N", "switch from X to Y", "schema migration". Use sextant:modify-feature instead when only a single module's behavior is changing without coordinated multi-step rollout.
   0
   installs
6. ▌
   Security · hellotern

   You MUST use this skill before approving or merging any code that touches auth, input handling, permissions, or external data. Use when the review focus is specifically on security vulnerabilities, attack surface, or compliance — not general code quality. Stronger signals: "security review", "check for vulnerabilities", "is this safe", "audit this", "OWASP", "injection", "auth check", "XSS", "SQL injection", "pentest", "threat model". Can run standalone or as a follow-up after sextant:review-code. Use sextant:review-code instead when the goal is general code quality without a security focus.
   0
   installs
7. ▌
   Add Feature · hellotern

   You MUST use this skill before writing any code for a new feature, module, class, or API endpoint. Use when the thing being built does not yet exist in the codebase — adding net-new functionality. Stronger signals: "add", "implement", "create", "build", "new feature", "new endpoint", explicit new requirement. Use sextant:modify-feature instead when the functionality already exists and you are changing its behavior. Use sextant:refine-requirements first if the requirement is vague or the scope is unclear.
   0
   installs
8. ▌
   Review Code · hellotern

   You MUST use this skill before evaluating, commenting on, or giving feedback on any code. Use when the primary request is to assess existing code — quality, correctness, style, or readiness to merge. Stronger signals: "review", "PR", "pull request", "code review", "check this code", "is this correct", "review this file", "give me feedback on", "look at this diff". Takes highest priority when the primary request is to evaluate code rather than write or fix it. Use sextant:security instead when the review focus is specifically on security vulnerabilities.
   0
   installs
9. ▌
   Write Tests · hellotern

   You MUST use this skill before writing any test cases or adding test coverage. Use when the goal is to verify code behavior through tests — new tests, missing coverage, or a reproduction test after a bug fix. Stronger signals: "write tests", "add tests", "unit test", "integration test", "test coverage", "TDD", "test this function", "add a regression test". Also apply automatically after completing sextant:fix-bug, before marking the bug as resolved.
   0
   installs
10. ▌
    Modify Feature · hellotern

    You MUST use this skill before changing, enhancing, or refactoring any existing functionality. Use when the code already exists and you are altering its behavior, performance, or structure — not fixing a bug. Stronger signals: "modify", "refactor", "optimize", "improve", "change how X works", "enhance", "update the logic". Use sextant:add-feature instead when the thing being built does not yet exist. Use sextant:fix-bug instead when the existing behavior is broken and needs to be restored.
    0
    installs
11. ▌
    Refine Requirements · hellotern

    You MUST use this skill before writing any design or code when the requirement is vague, ambiguous, or too broad. Use when the "what" is unclear — the requirement needs scoping, feasibility assessment, or decomposition before anyone touches code. Stronger signals: "unclear requirements", "break this down", "is this feasible", "help me design", "what do we need to build", vague one-sentence feature requests, open-ended asks like "build me X". Skip this skill and go directly to sextant:add-feature only when the requirement is already concrete, scoped, and unambiguous.
    0
    installs