Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

recap

Estrelas3

Forks0

Atualizado25 de junho de 2026 às 07:48

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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

harshanandak

harshanandak/forge

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Outras ocupações de informáticaInformática e Matemática·SOC 15-1299

SKILL.md

readonly

name	recap
description	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.
metadata	{"author":"forge","command":"forge recap"}

forge recap

Purpose

Reconstruct context on one issue quickly. forge recap <issue> distills the issue's description, status, dependency links, and comment trail into a bounded summary, so you can resume work without manually scrolling its full history.

When to Use

At the start of a session that resumes a previously claimed issue.
After context compaction, to reload what an issue is about and where it stands.
Before commenting or closing, to confirm the latest state.

Command

forge recap <issue>         # bounded summary of one issue

Instructions

Run forge recap <issue> with the id you are resuming.
Read the summarized status, decisions, and open threads.
Treat the recap as the authoritative current state of the issue.
Continue with comment or close.

Example

$ forge recap forge-142
forge-142  Wire kernel selector into dispatch  [in_progress]
- Selector wired in bin/forge.js (commit 467b868).
- Multi-id close acceptance test added and green (commit c3bcb36).
- Remaining: confirm release readiness gate clears.

Success Criteria

Current issue state is understood from the recap alone.
No need to manually re-read the full issue history.

Related Skills

show: full raw detail when the bounded recap is not enough.
comment: record the next progress note after resuming.

Mais deste repositório

mesmo repositório

claim-safety

harshanandak/forge

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).

2026-07-193

dev

harshanandak/forge

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).

2026-07-193

hermes-forge

harshanandak/forge

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).

2026-07-193

issue-basics

harshanandak/forge

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).

2026-07-193

kernel

harshanandak/forge

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`.

2026-07-193

memory

harshanandak/forge

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.

2026-07-193

name	recap
description	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.
metadata	{"author":"forge","command":"forge recap"}

forge recap

Purpose

When to Use

At the start of a session that resumes a previously claimed issue.
After context compaction, to reload what an issue is about and where it stands.
Before commenting or closing, to confirm the latest state.

Command

forge recap <issue>         # bounded summary of one issue

Instructions

Run forge recap <issue> with the id you are resuming.
Read the summarized status, decisions, and open threads.
Treat the recap as the authoritative current state of the issue.
Continue with comment or close.

Example

$ forge recap forge-142
forge-142  Wire kernel selector into dispatch  [in_progress]
- Selector wired in bin/forge.js (commit 467b868).
- Multi-id close acceptance test added and green (commit c3bcb36).
- Remaining: confirm release readiness gate clears.

Success Criteria

Current issue state is understood from the recap alone.
No need to manually re-read the full issue history.

Related Skills

show: full raw detail when the bounded recap is not enough.
comment: record the next progress note after resuming.