本文へ移動
cccskills
無料GitHub で公開

project-discovery

Discovers the core attributes of the current code repository and its projects — languages, frameworks, tooling, and where things live — and writes a concise reference section directly into the project's AGENTS.md or CLAUDE.md for other skills, agents, and hooks to consume. Use when scanning, analyzing, or detecting the project's technology stack, build tools, or repository structure. Does not create or update project documentation — use project-documentation for writing feature or system docs.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md7.8 KB
  • references/template.md1.5 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Project Context

  • Default branch: !git symbolic-ref --short refs/remotes/origin/HEAD 2>/dev/null || echo unknown
  • AGENTS.md: !find . -maxdepth 1 -name "AGENTS.md" -type f
  • CLAUDE.md: !find . -maxdepth 1 -name "CLAUDE.md" -type f
  • README: !find . -maxdepth 1 -name "README*" -type f
  • personal config directory: !bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"
  • project .han/config.md: !cat .han/config.md 2>/dev/null || echo ""

As your first action, use the Read tool on .han/config.md inside the personal config directory path above. A read that returns no file is no personal configuration: continue silently. When that file or the project .han/config.md probe supplies content, apply it per config-rule.md, which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Project Discovery

This skill discovers the project's core attributes and writes them as a concise ## Project Discovery section directly into the project's AGENTS.md or CLAUDE.md — not a separate file. The output is small by design: a few notes on where things live, the languages and frameworks, and the commands to run, so an AI agent working in the repo can find its way around. It is not an exhaustive inventory.

Step 1: Choose and read the target file

Pick the single file this discovery is written into, by priority:

  1. If AGENTS.md exists (the label above is non-empty), the target is AGENTS.md.
  2. Otherwise, if CLAUDE.md exists, the target is CLAUDE.md.
  3. If neither exists, the target is a new CLAUDE.md at the repository root, which you will create in Step 4.

If the target file already exists, read it in full and build the deduplication baseline: a list of everything the file already documents that this skill would otherwise write — directory and folder locations, languages, frameworks, package manager, build/test/lint/dev commands, and the docs, ADR, and coding-standards directories. Note whether the file already has a ## Project Discovery section.

If the target is a new CLAUDE.md, there is nothing to deduplicate against.

Step 2: Discover repository structure

Launch a han-core:project-scanner agent to determine whether the repository contains one project or many, and what each project's boundaries are. Wait for the agent to complete.

From the agent's results, build a project list. Each entry has a project name (directory name, or repository name for a root-level project), root path, and dependency manifest path.

Step 3: Explore project attributes

Launch 3 han-core:project-scanner agents in parallel, each with a different focus area. Include the project list from Step 2 in each agent's prompt so they know which roots to explore. Keep each agent on the core facts an AI agent needs to navigate and run the project — not an exhaustive catalog of every config file.

Agent 1 — Languages and Frameworks: For each project, read the dependency manifest to identify languages and version constraints. Determine the package manager from the lock file type. From dependencies, identify the structural/architectural frameworks that define how the project is built (web, frontend, test, ORM/database). Ignore utility packages. Note runtime version requirements.

Agent 2 — Commands: For each project, find the task runner or build definition and extract the actual commands for installing dependencies, running tests, linting, building, and the dev server. Only record commands that actually exist — no guesses.

Agent 3 — Layout: Map where the important things live: the main source directory or directories, the test location, and the documentation, ADR, and coding-standards directories — do not assume names like "docs". Capture only the handful of directories someone needs to know to find their way around the repo; skip incidental files.

After all 3 agents complete, merge their findings, deduplicate across agents, and organize by project. Separate repository-level items (default branch, docs, ADRs, coding standards, layout) from project-level items (language, frameworks, package manager, commands).

Step 4: Write the discovery into the target file

Build a concise ## Project Discovery section using the template at template.md as the structural guide.

Apply two filters before writing anything:

  • Deduplicate. Drop every fact already present in the target file (the Step 1 baseline). Do not restate what the file already says, even in different words.
  • Drop empties. Omit any line with no discovered value. Never leave a {placeholder} behind, and never invent a command or path that was not discovered.

If a discovered fact contradicts what the file already states (for example, the file says make test but no Makefile was discovered), use AskUserQuestion to surface the contradiction and ask which is correct — the existing file or the filesystem discovery. Update the content based on the answer.

Then write the result into the target file:

  • Target exists, no ## Project Discovery section: append the section at the end of the file (or another sensible location).
  • Target exists, already has a ## Project Discovery section: replace that section's body with the new, deduplicated content. Do not leave the old content alongside the new.
  • Neither AGENTS.md nor CLAUDE.md exists: create CLAUDE.md at the repository root containing the section.

If, after deduplication, nothing meaningful remains to add, do not write an empty section. Tell the user the target file already covers the project's core attributes, and stop.

Step 5: Keep the .han/config.md pointer honest

Han skills read project-local overrides from the project's .han/config.md when a project carries one (see ../../references/config-rule.md). This step keeps the target file's pointer to that config accurate, using the same consent gate and deduplication discipline as Step 4. The Project Context probe above shows whether the file exists.

  • .han/config.md exists and the target file contains no reference to it: use AskUserQuestion to offer adding a one-line pointer beside the ## Project Discovery section, for example: Han skills in this project read overrides from [.han/config.md](./.han/config.md). Never add a pointer when any reference to the file is already present, even phrased differently.
  • .han/config.md does not exist but the target file still references it: use AskUserQuestion to offer removing the stale pointer.
  • Otherwise: do nothing and say nothing about the config.

Write or remove the pointer only with the user's consent.

Step 6: Verification

Read back the target file's ## Project Discovery section. Confirm: no {placeholder} text remains, every bullet has a real discovered value, and nothing duplicates content stated elsewhere in the file. Spot-check 2-3 discovered paths or directories with Glob to confirm they exist.

Report to the user: the target file written (and whether it was created or updated), the number of projects discovered, and the languages and frameworks found.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Builds a new Claude Code agent (subagent) from scratch through a relentless, evidence-based interview that walks the agent's design tree decision-by-decision — entity fit, domain focus and vocabulary, role identity, anti-patterns, description, model tier, tools, and self-containment — then reviews the finished agent against the plugin-building guidance and applies every fix it finds. Use when creating, authoring, scaffolding, designing, or drafting a new agent or subagent. Does not build a skill or slash command — use skill-builder. Does not serve, vendor, or refresh the authoring guidance itself — use guidance.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use automated-test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for designing a new interface or contract — use design-an-api. Not for planning the change its findings imply — use plan-a-change. Not for discovering bounded contexts, ubiquitous language, or where code boundaries diverge from domain boundaries — use ddd-analysis. Not for writing documentation or architectural decision records.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Create, extract, or convert an ADR (architectural decision record) using the ADR template. Use when creating new ADRs, extracting an ADR from existing documentation, converting a document into an ADR, recording an architecture or design decision, or updating the status of an existing ADR. Does not create or update enforceable coding standards or conventions — use coding-standard for that. Does not write feature or system documentation — use project-documentation instead.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Produce a standalone test plan by analyzing code for test coverage gaps and edge cases. Use when you need to create, generate, or draft a test plan for a branch, need to analyze test coverage, or need to identify what tests to write for specific files or directories. Does not produce a plain-language plan for a person to run tests by hand — use manual-test-planning for that. Does not write test code — use tdd to implement behavior test-first. Does not refine existing plans — use iterative-plan-review. Does not review code quality, security, or style — use code-review for full code review. Does not evaluate architectural testability or structural coupling — use architectural-analysis for architectural assessment.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Produces a human-readable, progressive-disclosure overview of unfamiliar code or a pull request's changes — why it exists (the real problem it solves or goal it serves for the business or a user), and from there what it does, how it flows, and where to start — so you can get up to speed before working on or reviewing it. Use when you want to understand, get oriented in, make sense of, explain, or get up to speed on a chunk of code, a file, a directory, a symbol, or a PR's changes. Writes the overview to a scratch file and changes no code. Does not review code quality or raise findings — use code-review for auditing changes or post-code-review-to-pr for posting them. Does not produce durable feature or system documentation — use project-documentation. Does not assess architecture or structural risk — use architectural-analysis. Does not diagnose bugs or root-cause failures — use investigate. Does not pace a person through the code one step at a time in conversation — use code-walkthrough.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Produces a progressive-disclosure overview of unfamiliar code or a pull request's changes with code-overview and publishes the resulting overview to a user-specified Confluence location. Use when the user wants code or a PR explained, oriented, or made sense of AND the overview posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not produce the overview to a local file only — use code-overview. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not document an already-understood feature to Confluence — use project-documentation-to-confluence. Does not root-cause a bug to Confluence — use investigate-to-confluence. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence. Does not publish to Jira — use work-items-to-jira.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

testdouble のスキルをすべて見る

このスキルの問題を報告する