harshanandak

@harshanandak source repo

38 skills
0 followers
6 hours ago last updated

▌
Dev · harshanandak bundle
Forge DEV stage — implement an already-planned /plan task list into committed, test-backed code. Reads tasks.md + plan.md, then drives each task through a subagent TDD loop (implementer → spec-compliance reviewer → code-quality reviewer) with RED-GREEN-REFACTOR, HARD-GATE evidence checks, and a spec-gap decision score. Use when a plan and task list already exist and it is time to implement — triggers: "/dev", "start the dev stage", "build the tasks", "implement tasks.md test-first", "run the implementer/reviewer TDD loop", "write the code for the planned tasks one by one", "work through the task list with subagents". Per-task coding ONLY. Do NOT use for creating the design doc or task list (that is plan), for the post-build type-check/lint/security/test gate (validate), for pushing the branch or opening the PR (ship), for addressing PR review feedback (review), or for orchestrating several stages / taking an issue end-to-end to a merged PR (smith).

0
installs
▌
Plan · harshanandak bundle
Forge PLAN stage — first stop when starting a NEW or unscoped feature. Sets up an isolated worktree up front, then runs one-question-at-a-time brainstorming for design intent, commits a design doc, does technical/OWASP/DRY + codebase research, and produces a TDD task list for /dev. Trigger on "let's plan X", "scope a new feature", "brainstorm before we build", "write a design doc", "break this into tasks", or "set up a worktree and task list before coding". Reach for this even when the ask sounds like only design or only scoping — plan owns intent → research → task-list setup as one stage. NOT for driving a feature to a merged PR (that is smith), NOT for implementing tasks that already exist (dev), NOT for a standalone deep-research pass into an approved design doc (research), NOT for reporting where work stands or what is stale (status), and NOT for everyday issue create/list/close or picking the next ready issue (issue-basics / triage-ready).

0
installs
▌
Ship · harshanandak bundle
Push a validated feature branch and open its PR from the project's template, then stop for manual merge. Use only when the user asks to ship or open the PR after validation; never merges, auto-merges, reviews an existing PR, or replaces end-to-end Smith.

0
installs
▌
Gates · harshanandak bundle
Toggle Forge's workflow gates and rails — strong-but-toggleable enforcement. `forge gate enable|disable <gate-id>` flips `workflow.gates.<id>.enabled` in `.forge/config.yaml`; the installed git hooks read resolved config at run time, so disabling a rail makes them genuinely inert. `forge gate approve|reject <issue> <gate>` records durable human-gate approval events; `forge gate status`/`check` query them; `forge control <id> <mandatory|optional|permission>` sets tri-state DECLARED intent (writes the same `enabled` field — no independent runtime enforcement). Use when the user says "disable the gate", "turn off TDD enforcement", "the tdd intent rail is blocking me", "toggle or enable a gate", "loosen enforcement", or "approve a human gate". Common default-ON toggleable rails: `rail.tdd_intent`, `rail.kernel_tracking`, `rail.auto_shepherd` — e.g. `forge gate disable rail.tdd_intent`. NOT for addressing PR review feedback (review), NOT the status snapshot of work in flight (status).

0
installs
▌
Setup · harshanandak bundle
Forge install & setup lifecycle. `forge setup` interactively configures Forge for your coding agents; `forge init [--profile minimal|standard|full]` writes the adoption config in a fresh repo; `forge doctor` reports whether the kernel DB is on a cloud/network path; `forge upgrade [--dry-run]` previews + self-heals upgrade readiness; `forge hooks install --global` installs native hooks; `forge reset --soft|--hard --force` and `forge reinstall --force` undo/redo the install; `forge recommend` lists suggested tools. Use when the user says "install/set up forge", "init forge", "adoption profile", "forge doctor", "upgrade forge", "install the hooks globally", or "reset/reinstall forge". Footguns: setup is interactive — pass `--yes` in automation; `doctor` only checks the kernel-DB filesystem class, NOT general health; `upgrade` self-heals Forge state, NOT the npm package; reset/reinstall need `--force`. NOT toggling a gate/rail (gates), NOT orienting in a set-up repo (status), NOT installing project deps (dev).

0
installs
▌
Smith · harshanandak bundle
The flagship Forge orchestrator: given a goal or a ready issue, it composes the stage skills (triage-ready · claim-safety · plan · dev · validate · ship · review · verify) into the right path for the work, running autonomously between human gates and pausing at them. Use this whenever the user wants to work the next ready issue, drive a feature or fix end-to-end, "take this through to a PR", orchestrate the whole workflow with human checkpoints, or asks some form of "what should I work on and get it done" — even if they never say "smith" or "orchestrate". Reach for it especially when the request spans multiple stages (plan → build → ship) or asks to keep a human in the loop at intent, plan, or merge. Prefer a single stage skill only when the user explicitly wants just that one step (e.g. "just open the PR").

0
installs
▌
Kernel · harshanandak bundle
Forge kernel — umbrella index/router for a Forge project. Reach for this FIRST when orienting rather than executing: at session start, when you need the map of how the system fits together, or when unsure WHICH skill or `forge` verb a task belongs to. It indexes `smith` (end-to-end orchestrator), the stage ladder (plan → dev → validate → ship → review → verify), the utility/issue skills, and the day-to-day `forge` CLI verbs. Trigger on "how does the Forge workflow work", "which forge command or skill for X", "I'm new here, how is Forge set up", or "should this be a Forge issue or a TodoWrite". Index layer only — hand off the doing: rank/pick the next ready issue → `triage-ready`; current stage / "where am I" / active or stale work → `status`; create/update/close/search one issue → `issue-basics`; claim-then-prove ownership before mutating → `claim-safety`; drive one issue from plan to a merged PR under gates → `smith`; token-bounded state for the Hermes harness → `hermes-forge`.

0
installs
▌
Memory · harshanandak bundle
Capture and retrieve durable project memory the right way -- and, when the graph backend is enabled, use temporal knowledge-graph memory. Reach for this whenever you are about to write down a lasting fact, decision, convention, or gotcha ("remember that...", "note for later", "save this"), or when you need to recall what was learned before ("what did we decide about X", "have we seen this"). It explains WHEN to use `forge remember` / `forge recall` versus a per-issue `forge issue comment`, how the two public backends work (local JSONL default, opt-in Graphiti; kernel is internal-only), and -- when Graphiti is enabled -- how to add episodes and search facts via the graphiti-memory MCP tools (add_memory, search_memory_facts, search_nodes) with group_id scoping and provenance. The local backend is always the offline floor. Not for: issue create/list/close ops (issue-basics), workflow status (status), or transient scratch notes.

0
installs
▌
Review · harshanandak bundle
Drive an already-open PR's feedback and failing checks to all-green, resolve every thread, run the pre-merge doc gate, then stop for manual merge. Use only when the user asks to address PR feedback or checks; never merges or substitutes for Shepherd monitoring.

0
installs
▌
Status · harshanandak bundle
Report where the project stands and what work is in flight -- the Forge status snapshot. Reach for this at session start or whenever the user says "/status", "where am I", "what's in progress", "catch me up", "resume work", or "what changed recently". It surfaces the workflow stage, your active/claimed issues, all issues ranked by composite score with conflict-risk flags, stale already-merged issues (which it closes), and recent commits. Use it to ORIENT and decide the next move -- it reports state; it does not plan, develop, or claim issues. Not for: routing to a stage skill or documenting the full issue-verb surface (kernel); ranking and EXPLAINING a single next-ready or blocked issue to hand off (triage-ready); everyday create/update/list/close/comment/search issue ops (issue-basics); the Hermes harness's token-bounded orient/recap contract (hermes-forge); or the post-merge CI health check that closes issues after a merge lands (verify).

0
installs
▌
Verify · harshanandak bundle
Runs the Forge verify stage — the post-merge health check performed AFTER a PR is merged: switch to master and pull, confirm the merge landed, check CI is green on master, confirm deployments are up, remove the merged worktree, safe-delete the branch, and close the kernel issues the PR resolved. Use when asked to verify a merge went cleanly, confirm post-merge CI health on master, check deployments after merging, clean up a merged branch or worktree, or close the issue now that its PR is merged — and whenever `/verify` is invoked. Strictly the POST-merge stage: use shepherd instead to monitor a still-open PR toward merge, review to fix and resolve PR feedback before merge, ship to push the branch and open the PR, rollback to undo an already-shipped change, status to merely report the current stage without acting, and issue-basics to close an issue unrelated to a just-merged PR.

0
installs
▌
Research · harshanandak bundle
Forge RESEARCH — a first-class, freely-invocable investigation skill any agent can call standalone OR mid-workflow (mid-/dev, mid-/validate, mid-/plan), not a plan-only stage. Use it to verify/fact-check a claim against primary sources; web-search best practices, gotchas, and docs; find better options/patterns and weigh trade-offs; see both sides (steelman the right way AND red-team the wrong way); pull inspiration from stronger sources; and run the /plan Phase 2 bundle (web research + OWASP Top 10 + DRY/blast-radius codebase exploration + 3+ TDD scenarios) under `## Technical Research`. Trigger on "verify/fact-check this", "research X", "find a better way/option", "is this true", "get inspiration", "run the research phase", or mid-task "investigate before I decide". Pick over siblings: `parallel-deep-research` for a heavyweight EXTERNAL market/competitive report (paid Parallel AI); `plan` for the full plan stage (brainstorm + tasks); `dev` or `validate` to implement or scan rather than investigate.

0
installs
▌
Rollback · harshanandak bundle
Safely undo committed or shipped changes with non-destructive git revert or restore. Use only when the user explicitly asks to roll back, revert, undo, back out, or restore; never reset hard, force-push, or substitute for PR review, monitoring, or issue status work.

0
installs
▌
Shepherd · harshanandak bundle
Own open PRs to merge-readiness — autonomously. Forge provides a singleton shepherd daemon — start it with `forge shepherd daemon` — that then watches every open PR, converges CI check state into kernel verdicts, re-runs flaky required checks, reaps orphan watchers, and self-retires when no PRs remain; one-shot passes (forge shepherd <pr>) exist for a single bounded check. Use when a PR was just opened or shipped; when a session starts with open PRs (Forge automatically wakes the singleton; the lease makes a duplicate start a safe no-op); when the user asks "why isn't my PR merging", "what's blocking the PR", "is the PR ready", "did a check fail / go red"; when asked to "keep watching / keep an eye on / babysit my PRs"; or to read PR verdicts (forge shepherd <pr> --pull --json, forge shepherd events). NEVER merges and never resolves review threads — fixing review feedback is `review`; opening the PR is `ship`; post-merge health is `verify`; general orientation is `status`.

0
installs
▌
Validate · harshanandak bundle
Forge VALIDATE stage — the pre-pull-request quality gate. Rebases the branch onto the current base branch, then runs type-checking, linting, code review, an OWASP Top 10 security review plus dependency scan, and the full test suite, demanding fresh passing output in THIS session before anything ships. Reach for this whenever a branch is code-complete and someone says: validate my changes, run the quality gates, run the pre-PR checks, type-check and lint before the PR, run the security scan, or run the full test suite before opening a PR — and for the literal `/validate` command or `bun run check`. This is the gate that runs AFTER code is written but BEFORE a PR exists, so discriminate carefully: it does not implement features or write tests (that is `/dev`), it does not push the branch or open the PR (that is `/ship`), it does not answer PR review feedback from Greptile / SonarCloud / CodeRabbit (that is `/review`), and it is not the post-merge CI health check (that is `/verify`).

0
installs
▌
Worktree · harshanandak bundle
Forge's worktree lifecycle. `forge worktree create <slug>` makes an isolated checkout under `.worktrees/`, creates its branch (feat/<slug>), links a kernel issue (`--issue`), and installs dependencies — all in one step; `forge worktree list`/`remove <slug>` manage them; `forge clean` removes worktrees whose branches already merged (squash-aware) and fast-forwards the default branch. Use when the user says "work on this in an isolated branch/worktree", "spin up a worktree", "parallel work on another PR or issue", "clean up merged worktrees", or "why did my worktree miss its dependencies". Footgun it prevents: raw `git worktree add` only creates a branch — it skips the issue link and dep install — so always use `forge worktree create`; and `forge clean` is cwd-scoped, run it from the primary repo root, never inside a worktree. NOT for opening/pushing a PR or the branch (ship), NOT for planning a feature (plan), NOT the stages that create a worktree as one step — this is the worktree lifecycle itself.

0
installs
▌
Sonarcloud · harshanandak bundle
Query SonarCloud code-quality data via the `/sonarcloud` slash command — the fast in-context lookup for a project, branch, or PR. Handles `issues`, `metrics`, `gate` (pass/fail + failed conditions), `health`, `pr <number>`, `hotspots`, `history`, plus `--branch`, `--severity`, `--type`, `--new-code` filters. Use the moment the user types `/sonarcloud ...` or asks in plain language: "what does SonarCloud say about this PR", "check the SonarCloud quality gate before I ship", "SonarCloud blocker/critical bugs on develop", "new-code SonarCloud issues on PR 214". Only READS/reports — does NOT fix findings or reply-to/resolve PR threads (that is `review`); it is the lightweight command surface, NOT the deep-analysis session correlating findings with local source or history trends (that is `sonarcloud-analysis`). Not for local SAST scans of your own code, nor the Forge issue tracker (`forge issue ...`, "open/ready issues") — here those bare words always mean SonarCloud.

0
installs
▌
Portability · harshanandak bundle
Forge kernel data portability — getting issue data in and out of the local kernel. `forge export [--dir] [--dry-run]` writes the kernel backlog to deterministic git-tracked JSONL (D16 portability projection); `forge export --import` reads that committed snapshot back into the kernel (hydrate). `forge migrate --from beads [--dry-run] [--source <dir>]` imports a Beads issue store into the kernel — the onboarding path for users coming from Beads. Use when the user says "export the kernel backlog to JSONL", "back up / snapshot the backlog", "re-import / hydrate the backlog", "migrate from beads", or "import a beads store". Honesty: bare `forge migrate --dry-run` (no `--from`) is v2→v3 preview only; a re-import that applies nothing reports "already hydrated". NOT the cloud/backend sync of the kernel (that is `forge sync`, cloud-native), NOT a database/schema migration (plan/dev), NOT memory notes (memory), NOT syncing a git branch with main (ship).

0
installs
▌
Using Forge · harshanandak bundle
Forge dispatch skill: the session bootstrap that makes Forge's skills auto-trigger as a reasoning-driven SYSTEM. Reach for this FIRST, before ANY response (including clarifying questions, codebase exploration, or file reads), whenever there is even a 1% chance a Forge skill applies. Carries the 1%-rule, the announce-before-acting rule, an anti-rationalization red-flags table, a subagent escape hatch, and an intent-to-skill routing table: add/build/scope a feature to plan; implement an existing task to dev; fix a failing test or bug to dev (debug first); type-check/lint/tests to validate; push and open a PR to ship; address PR/review feedback to review; post-merge health to verify; what to work on to triage-ready; where am I / current stage to status; create/close/search an issue to issue-basics; drive one issue end-to-end to smith; monitor a PR to shepherd. Run `forge skill for "<situation>"` for a deterministic fallback. NOT itself a stage; the kernel skill is the fuller umbrella index once oriented.

0
installs
▌
Claim Safety · harshanandak bundle
Claim a Forge issue and then PROVE you hold the live lease before you touch it, using `forge issue owns <id>` (exit 0 iff you hold the single unexpired lease). Use this whenever winning the claim matters: right after `forge claim`, before you `dev`/edit/`close`/`release` a claimed issue, when two agents or a subagent fan-out contend for the same work, or before any irreversible step. A claim's `ok:true` does NOT prove you won — duplicate replays return it and expired leases get reclaimed; only `owns` proves it, so re-verify before close/release. Trigger on "claim this issue safely", "did I actually win the lease", "verify/prove ownership", "claim conflict", "two agents grabbed the same issue", "check I still own it before closing", or before ANY mutation of a claimed issue. NOT for plain single-issue create/update/close/comment with no ownership question (that is issue-basics), and NOT for read-only selecting or ranking the next ready issue without claiming (that is triage-ready).

0
installs
▌
Hermes Forge · harshanandak bundle
Hermes⇄Forge boundary: Hermes CONSUMES Forge state, never a second source of truth. Use whenever a Hermes session runs on a Forge repo: at session start, before acting on an issue, or when you need CURRENT state. Read state ONLY via `forge orient` / `forge recap <issue-id>` (bounded JSON envelope), citing each source's `path`/`authority`; never reconstruct it from raw stores or kernel internals. Writeback ONLY via `forge comment`/`update`/`create`; NEVER leak Hermes profile or session memory into Forge state. Triggers: "orient me / current project state", "where did this fact come from, cite it", "orient came back truncated", "persist a decision into Forge", "safe to store in kernel state?". NOT the Forge session router over stage skills (kernel), NOT the human "what stage am I in" report (status), NOT everyday issue create/update/close/search CRUD (issue-basics), NOT ranking the next ready issue (triage-ready), NOT live PR monitoring (shepherd—outside Hermes, unseen by orient).

0
installs
▌
Issue Basics · harshanandak bundle
Everyday single-issue CRUD over the `forge issue` verbs: create/update/show/list/search/close/reopen/comment, set priority/labels/assignee, claim or release one issue, add/remove dependency edges, plus backlog `stats`. Use for ANY routine one-off issue op: "create an issue/bug/task for X", "update/edit issue <id>", "close or reopen this issue", "comment a handoff note on <id>", "list/filter open bugs by status/label/priority", "bump this to P1", "reassign to alice", "mark <id> blocked by <id>". Also the parity floor migrating off a Beads-style tracker (label/reopen/delete map to forge equivalents). Single-operation plumbing only. Does NOT choose, rank, or explain the next issue to work on or why it's blocked (use triage-ready); does NOT run claim-then-prove-lease-ownership safety (use claim-safety); does NOT drive an issue through the plan->dev->validate->ship pipeline or open a PR (use smith or stage skills); does NOT report the current stage or what's in flight (use status).

0
installs
▌
Triage Ready · harshanandak bundle
Surfaces, ranks, and EXPLAINS the single best next issue in a Forge project — strictly read-only. Recomputes the live ready queue and explains what is blocked via `forge issue ready`/`blocked`/`stats`/`show`, always against the live kernel, never `forge board`. Recommends ONE issue with a one-line reason, then hands off; never claims, comments, closes, or mutates. Use when the user asks "what should I work on", "what's next", "what's ready", "pick/triage my next task", "top of the ready queue", "which issue should I start", "why is this issue blocked", or "what's blocking the most work". NOT for claiming or taking ownership of the pick (use claim-safety), not for everyday issue create/update/list/search/close/comment/dep CRUD (use issue-basics), not for reporting the current workflow stage or "where am I / what's in flight" (use status), not for orienting a whole session or routing to stage skills (use kernel), not for driving an issue to a merged PR (use smith).

0
installs
▌
Activation · harshanandak
Forge's front door — invoke FIRST when starting work in a project that has Forge available but you are not yet oriented: no `.forge/` yet, a fresh session, or the user says "/activation", "set up Forge", "start Forge", "is Forge active here?". Orients on the actual repo (detects project type, states findings) BEFORE offering anything, then offers the bare-minimum gates-disabled setup WITHOUT forcing it. Do NOT use this to run a specific stage (use /plan, /dev, /status, /ship directly) or once `.forge/` is already initialized and you know the workflow.

0
installs
▌
Sonarcloud Analysis · harshanandak bundle
SonarCloud deep-dive via its REST API: pull open issues (bugs, vulnerabilities, code smells), coverage/duplication metrics, quality-gate pass/fail with failed thresholds, security hotspots, and measure/analysis history for a whole project, branch, or PR, then return a ranked summary. Use whenever the user names SonarCloud or asks about code-quality metrics, technical debt, a red/failing quality gate, or static-analysis vulnerabilities/hotspots — e.g. 'why is the SonarCloud gate failing on this PR' or 'pull every BLOCKER vulnerability with file and line'. NOT for: the thin `/sonarcloud <query> <project>` slash command for a quick lookup (sibling 'sonarcloud'); replying to/resolving PR review threads across Greptile, CodeRabbit, or GitHub Actions ('review'); running local lint/type-check/test/security scans pre-ship ('validate'); implementing or patching a flagged issue ('dev'); or an external market/competitor report on SonarSource or DevSecOps vendors ('parallel-deep-research').

0
installs
▌
Parallel Deep Research · harshanandak bundle
Heavyweight EXTERNAL research reports — market, industry, competitive, strategic — via Parallel AI's paid pro/ultra processors that crawl and synthesize dozens of sources into one long cited report. Use when the user wants a market analysis, competitive landscape, industry deep-dive, multi-vendor/technology comparison, strategic recommendations, or market sizing/growth outlook — any multi-source synthesis needing more than 3-4 web searches. Typical phrasings: "market analysis of X", "competitive landscape comparing A/B/C", "industry deep-dive on...", "deep research report on...", "strategic report with predictions for 2027". WRONG tool for quick facts, a single-page fetch, one-URL scraping, or small structured-field extraction — use built-in WebSearch/WebFetch. Also NOT the Forge RESEARCH or PLAN stage: "run the research stage", "do Phase 2", or codebase/OWASP/DRY investigation into a design doc route to `research` and `plan` (they may INVOKE this skill). Requires PARALLEL_API_KEY.

0
installs
▌
Test Lane · harshanandak
Use when a push suddenly takes ~10 minutes, when a test run says "unmapped pushed files require full unit coverage", or before adding a new top-level path or command to Forge. Do not use to skip tests or to raise a timeout — this is about routing, not about running less.

0
installs
▌
Worktree Flow · harshanandak
Use before starting any Forge code change, and whenever a second agent is about to work in the same repo — creating, entering, or cleaning an isolated worktree. Do not use raw `git worktree add`; it creates a branch and nothing else.

0
installs
▌
Agents Md Edit · harshanandak
Use before changing AGENTS.md — a workflow rule, a stage table, a glossary entry, or a maintainer note. Do not use for CLAUDE.md (it is a pointer and holds no content) and do not use for the generated harness mirrors under .claude/, .codex/, .cursor/, or .hermes/.

0
installs
▌
Ship And Watch · harshanandak
Use after pushing a Forge branch, opening a PR, or when asked "is the PR ready / what's the status / are checks green" — reads shepherd verdicts instead of polling GitHub. Do not use to merge a PR, and do not use to resolve review threads; both stay with the human and /review.

0
installs
▌
Show · harshanandak
Read the full detail of a single issue — title, description, status, dependencies, and discussion — by its id. Wraps `forge show` so you gather complete context before claiming, commenting on, or closing an issue.

0
installs
▌
Command Surface · harshanandak
Use when adding, renaming, or deleting a file in lib/commands/, or when a build fails with a manifest-drift error or an unresolved command require. Do not use for changing behaviour inside an existing command — that needs no surface work.

0
installs
▌
Claim · harshanandak
Take ownership of a ready issue and move it into in-progress for the current agent. Wraps `forge claim` so work is visibly assigned in the Forge issue backend before any code is written, preventing two agents from racing on the same task.

0
installs
▌
Close · harshanandak
Mark one or more completed issues as done. Wraps `forge close` so finishing work updates the Forge issue backend, releases the claim, and unblocks any issues that depended on the one you just completed.

0
installs
▌
Ready · harshanandak
Find the issues an agent can start right now — those whose dependencies are all satisfied and that nobody is actively working. Wraps `forge ready` so you pick the next unit of work from the Forge issue backend instead of guessing or reading the issue store by hand.

0
installs
▌
Recap · harshanandak
Produce a bounded, token-aware summary of an issue's history and current state — its description, status, dependencies, and accumulated comments. Wraps `forge recap` so an agent can rebuild context on a single issue after a session break without re-reading the entire issue store.

0
installs
▌
Protected Commit · harshanandak
Use when a commit is refused with "Protected state edit detected", or before editing AGENTS.md, CLAUDE.md, a lockfile, .forge/config.yaml, .github/workflows, lefthook.yml, .beads/**, or a generated harness mirror. Do not use to find a way around the gate — there is no environment variable that authorizes a protected write.

0
installs
▌
Comment · harshanandak
Append a progress note, decision, or finding to an issue's discussion thread. Wraps `forge comment` so durable context lives on the issue in the Forge issue backend — recoverable across sessions and visible to every other agent — rather than only in a transcript.

0
installs

38 published skills