Token导航 LogoToken导航TokenDH.com
研究检索执行命令github未标认证来源可访问许可证需确认审计提醒

project-context项目背景

Agent Skill

project-context 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

941

周安装

40

GitHub Stars

7

下载量

330
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:project-context(项目背景)
来源仓库:https://github.com/perhapsspy/project-context
仓库路径:skills/project-context
安装命令:
npx skills add https://github.com/perhapsspy/project-context --skill project-context
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/perhapsspy/project-context --skill project-context

简介

提取项目背景信息与上下文知识,辅助理解任务需求。

  • 适用于新接手项目时的快速熟悉与知识沉淀。
  • 通过 GitHub 仓库安装,自动读取 README、文档与代码注释。
  • 输出内容依赖本地文件完整性,缺失文档可能导致信息不全。
  • project-context 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Project Context

Purpose

Keep durable repo context in ordinary files so later sessions can resume without rebuilding state.

Use / Do Not Use

Use this skill when work should leave durable repo context: resume, handoff, long-running work, reusable reference notes, a current task brief, and an append-only trail.

Do not bootstrap for read-only questions, one-shot inspections, or implicit migration of scattered legacy docs. If the layout is missing, choose explicit adoption or migration.

Core Bias

  • Ordinary repo files over external systems or hidden memory.
  • Current trusted topic context: docs/reference/**.
  • Current task resume state: BRIEF.md.
  • Append-only trail: logs/*.md.
  • Small contract, portable paths, no secrets.
  • When reuse is unclear, create a new dated task.

Contract

docs/
  reference/**/*.md
  tasks/yyyy/mm-dd/<task-slug>/
    BRIEF.md
    logs/{DECISIONS,WORKLOG}.md
    [optional] <purpose-named-backlog>.md
    [optional] working/
    [optional] archive/
  [optional] BACKLOG.md
  • docs/reference/**: current trusted reference context only. Keep principles, rules, and reliable facts here. Do not store investigation history, progress, or timeline narrative.
  • docs/tasks/yyyy/mm-dd/<task-slug>/: default task workspace for real work.
  • BRIEF.md: rewrite-only compact resume card, not a report or log. Keep goal, scope, current understanding/facts, current state, and nearest next step.
  • logs/DECISIONS.md and logs/WORKLOG.md: append-only decision and execution trail. Keep evidence here, not in the brief.
  • [optional] <purpose-named-backlog>.md: unresolved carry-over only, such as RESEARCH-BACKLOG.md or QA-BACKLOG.md. Add it only when one next step is not enough.
  • [optional] working/ and [optional] archive/: temporary notes and finished remnants.
  • [optional] docs/BACKLOG.md: not-yet-active repo-level future work only. Once active, move state into a dated task and remove the repo backlog item.

BRIEF.md Limits

Use only these top-level headings unless the user explicitly asks otherwise:

  • Goal or Intent
  • Scope
  • Current Understanding or Current Facts
  • Current State
  • Next Step or Next Actions
  • optional Working Boundary

Hard rules:

  • Usually 300-500 words maximum.
  • Each section should usually have 1-5 bullets.
  • Scope is a 1-3 bullet boundary summary, not a touched-file list.
  • Next Step owns only the nearest restartable move, not a backlog.
  • Do not add sections such as Validation, Files Changed, Touched Files, History, Worklog, Investigation, Evidence, Completed, or Checklist.
  • Do not include command output, validation transcripts, investigation history, completed-work history, or touched-file inventories.
  • If validation status matters, summarize it in one Current State sentence and keep details in logs/WORKLOG.md.
  • If exact paths materially lower reopen cost, put at most 5 repo-relative paths in Working Boundary.

Log Limits

Logs are append-only, but not command transcripts.

For logs/WORKLOG.md:

  • Append one block per meaningful work batch, not per command or file.
  • Merge repetitive edits, retries, validation attempts, and feedback micro-iterations into one short outcome block after the cluster settles.
  • Do not paste raw shell output unless the exact text is essential evidence.
  • Keep evidence concise: command names, repo-relative paths, summarized results, or small nested evidence bullets when that is easier to scan.
  • Record failed attempts only when they affect the next restartable step.
  • Separate task validation from pre-existing repo debt or unrelated warnings.
  • Prefer fewer, denser blocks over many micro-blocks.
  • Use the existing task language and voice. Write natural bullets that include outcome, compact evidence, and remaining restart conditions only when they matter.

For logs/DECISIONS.md:

  • Record only decisions affecting future interpretation, scope, architecture, rollback, or rule application.
  • Do not log routine edits, validation passes, file creation, or obvious implementation steps.
  • Keep each block as 4 bullets: Background, Decision, Why, Impact.
  • When work is paused, rejected, or converted into reference-only status, record the final decision and reopen condition in DECISIONS.md or the compact current state in BRIEF.md.

For both logs:

  • Add entries under dated sections using **YYYY-MM-DD**.
  • Keep language consistent with the existing task; otherwise use the current user language.
  • For log writes, resolve the skill-relative scripts/task_logs.py path and use its append entrypoints by default. If unavailable, append manually with the same block shape.

Path and Ownership Rules

  • Use repo-relative paths or placeholders like <repo-root>, <task-root>, and $CODEX_HOME; never user-specific absolute paths.
  • Never store secrets.
  • Parent agent owns BRIEF.md and canonical logs.
  • Subagents write only temporary notes or artifacts unless explicitly assigned canonical writeback.
  • Subagents start without inherited context; pass a small brief: goal, constraints, boundary notes, validation command, artifact path.

Operating Model

  1. Read reusable context.

- Use rg in docs/reference/**/*.md for the active topic. - Start with up to 3 narrow reference files closest to the task.

  1. Check one related task.

- Read BRIEF.md first. - Open logs only if the brief still matches the same unfinished work.

  1. Decide reuse or new task.

- Reuse only when unresolved work and expected output still match. - Use boundary notes as hints, not task identity. - Otherwise start a new dated task.

  1. Ensure the task shell.

- If durable context is warranted and the repo is effectively empty, create docs/reference/ and one dated task with BRIEF.md and logs. - For most write-bearing tasks, create or update one dated task. - Skip task creation only for very small, low-judgment, immediately finished changes.

  1. Write canonical surfaces.

- Rewrite BRIEF.md in place. - Append decisions and worklog entries. - Move reusable current rules or facts into docs/reference/**; keep investigation and progress in logs.

  1. Add optional surfaces only when needed.

- Add a task-local backlog only when one next step is not enough. - Keep repo backlog only for inactive future work. - Do not mirror open work across brief, backlog, working notes, and logs.

  1. If context is missing, proceed with explicit assumptions and record corrections after execution.

Anti-Patterns

  • Bootstrapping project-context files for read-only or one-shot work.
  • Reusing a task because the topic is similar rather than the same unresolved work.
  • Turning BRIEF.md into append history, reusable docs, validation notes, file inventory, or rationale.
  • Letting Scope become a touched-file list.
  • Letting Current State narrate work sequence instead of resumable state.
  • Letting Next Step become a backlog.
  • Turning docs/reference/** into investigation notes, progress, or timeline narrative.
  • Creating generic overflow files instead of purpose-named task-local docs.
  • Keeping completed items in docs/BACKLOG.md.
  • Mixing canonical docs, temporary notes, and finished remnants at one task root.
  • Dumping raw command transcripts, repetitive micro-steps, or noisy shell output into WORKLOG.md.
  • Duplicating the same benchmark numbers or validation matrix in both BRIEF.md and WORKLOG.md unless the second surface adds a new interpretation.
  • Logging routine edits or validation passes as decisions.
  • Saving absolute user-specific paths or secrets.

Guardrail Check

Run the bundled checker by resolving scripts/check_runtime_shape.py from the installed project-context skill directory and executing it from the active repo root. If running from a subdirectory, pass --repo-root <path> when nested docs trees could confuse root detection.

The checker covers runtime shape only: required files, latest log-block shape, task/reference path markers, and secret-like markers. It does not judge ownership, semantic quality, full history, merge correctness, or broader scope discipline.

Before finalizing, reject or rewrite BRIEF.md if:

  • It contains forbidden sections such as validation, files changed, history, evidence, or checklist.
  • Scope is functioning as a file inventory.
  • Current State narrates the work sequence instead of the current resumable state.
  • Next Step contains a backlog instead of one nearest action.
  • The brief is longer than needed to resume the task.

Final Gates

  • Can a later session reopen the work from BRIEF.md without reconstructing state?
  • Is reusable current context in docs/reference/** instead of task logs?
  • Is the execution and decision trail confined to logs/*.md?
  • Are canonical docs separate from temporary notes and finished remnants?
  • Did task reuse follow unresolved work and expected output rather than topic similarity?
  • Are paths portable and secrets absent?

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

38.65%
按下载量换算128

Claude

31.5%
按下载量换算104

Cursor

17.92%
按下载量换算59

Gemini CLI

9.42%
按下载量换算31

安全审计

Gen Agent Trust Hub

通过

Socket

可疑

Snyk

通过

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/perhapsspy/project-context --skill project-context 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills