skills.rest
envoydev
envoydevCOMMUNITY
Explore all skills by this author →
GitHub

project-related-context

Characterizes sibling repositories and generates awareness rules and orientation docs for cross-repo work.

1|Updated Jun 2, 2026
Search Tags:#context capture#codebase analysis#multi-repo#cross-repo#sibling repositories#awareness rule#orientation doc
One-click install
npx skills add https://github.com/envoydev/claude-stack --skill project-related-context-envoydev
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: project-related-context
Source: https://github.com/envoydev/claude-stack/tree/main/stack/skills/project-related-context
Command: npx skills add https://github.com/envoydev/claude-stack --skill project-related-context-envoydev

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? When a product spans multiple repositories, an AI session in one repo has no knowledge of the sibling repos it integrates with, leading to missed seams, wrong assumptions about contracts, and duplicated investigation. This Skill captures named sibling repos and writes both an always-on awareness rule and an on-demand orientation doc so every session knows the edges that bind the product. ## Core Features & Use Cases - Deliberate, args-driven capture: Analyzes only the sibling repos you name (local paths or git URLs, with optional relation hints) - it never scans the filesystem guessing at siblings. - Two-tier output: Writes the pathless always-on rule .claude/rules/baseline-project-related-context.md (name / location / relation / seam per sibling) and the full orientation doc <docs-path>/related-projects/RELATED-PROJECTS.md with first_read files and evidence. - Delegated or inline analysis: Fans out one read-only analyzer subagent per sibling when dispatch is available, or characterizes each sibling in-session when it is not. - Upsert-on-rerun: Re-running refreshes named siblings' entries keyed by location while keeping unlisted entries intact, and hands off sibling-owned work as task cards instead of writing into other repos. - Use Case: You work in a frontend repo that consumes a backend API and a shared contracts package. Run the capture naming both siblings, and every future session loads the seam summary automatically and can read the full orientation doc when a task touches the API contract. ## Quick Start Capture the related projects ../backend and [email protected]:org/shared-contracts.git so this repo knows its sibling seams.

Frequently Asked Questions about project-related-context

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I give an AI agent context about related repositories?▼

Run the capture naming each sibling repo as a local path or git URL, optionally with a relation hint. It writes an always-on awareness rule with name, location, relation, and seam per sibling, plus a full orientation doc with evidence and first_read files.

How to document cross-repo dependencies in a monorepo or multi-repo product?▼

Name each sibling (including in-repo sub-projects like ./server and ./client) and the capture characterizes each one, recording the dependency direction and seam. Entries are upserted on re-run, so the documentation stays current as siblings drift.

Does the capture scan the filesystem to find related projects?▼

No, it is strictly args-driven and never scans. You pass local paths or git URLs explicitly; with no arguments it asks you for them and stops rather than guessing siblings from the filesystem.

What happens when a sibling repo is unreachable or cannot be verified?▼

Unreachable siblings stay in both the rule and the doc as UNVERIFIED entries rather than being silently dropped. Invalid locations are reported and skipped, and contradicting evidence against a relation hint is surfaced instead of smoothed over.

Will re-running the capture overwrite my existing sibling entries?▼

Re-running is an upsert keyed by location: siblings passed this run get refreshed entries, while entries whose locations were not passed are kept exactly as-is. Removal is a manual edit, and the report lists which entries were left untouched.

Can the capture make changes directly in a sibling repository?▼

No, a session belongs to one project and cross-project writes are blocked. When the capture surfaces work a sibling owns, it writes a task card to the cross-project-tasks folder describing the change, the contract, and how the other side verifies it.

Related Skills

Explore More Software Engineering Skills→
CommunityToolkitCommunityToolkit
619

distributed-mesh

Configure and synchronize distributed team state using Git.

Official
Advanced
rodoHasArrivedrodoHasArrived

meridian-repo-navigation

Route AI tasks to Meridian subsystems using repository navigation references.

Community
Basic
MSamiulHasnatMSamiulHasnat
1

github-multi-repo

Coordinate cross-repo development across multiple GitHub repositories.

Community
Advanced
wan-huiyanwan-huiyan
1

skill-portfolio-repo-placement-scan

Maps authored Claude Code skills to target repos with ADD, UPDATE, and CROSS-LINK recommendations.

Community
Advanced