Support external reference links for agent context

[eranco74]

Summary

Allow users to attach external URLs (documentation, API specs, design references, etc.) that Forge fetches and injects into the agent's context at each relevant workflow stage. These references are not checked into the repo or defined in skills — they're supplementary context the agent should read.

Motivation

Sometimes the context needed to produce a good PRD, spec, or implementation lives outside the repository — in external docs, wikis, API references, or design specs. Today there's no way to point Forge at these resources. Users should be able to supply external links both per-ticket and as standing project-level references.

Proposed Behavior

1. Jira Comment Syntax (per-ticket)

A new comment prefix to attach references to a running workflow:

@forge ref <url> [optional description]

Examples:

@forge ref https://docs.example.com/api/v2 API v2 reference
@forge ref https://gist.github.com/user/abc123 error handling patterns

Multiple refs can be added via separate comments at any point in the workflow. The agent should accumulate them.

2. Project-Level Configuration

A Jira project property (similar to forge.prd_proposals_repo) to define standing references that apply to every ticket in the project. Particularly useful for the PRD phase where common context (product guidelines, architecture docs, style guides) should always be available.

Property	Example	Description
forge.references	JSON array of {url, description?}	Standing external references for all tickets in this project

Set via: forge project-setup <PROJECT> --add-reference <url> [--description "..."]
Remove via: forge project-setup <PROJECT> --remove-reference <url>
List via: forge project-setup <PROJECT> --list-references

3. Content Fetching

• Support any fetchable URL (HTTP GET) — web pages, raw GitHub files, pastebins, PDFs, etc.
• HTML content should be converted to markdown/text for context injection
• Fetch failures should be logged as warnings, not block the workflow
• Consider caching fetched content within a workflow run to avoid redundant requests

4. Context Injection

• References should be fetched and injected at each relevant workflow stage (PRD, spec, plan, task plan, implementation)
• Project-level references are always included
• Ticket-level references (@forge ref) accumulate and are included from the point they're added onward
• Content should be clearly delineated in the prompt (e.g., ## External References section)

Open Questions

• Should there be a size limit on fetched content? (e.g., truncate after N tokens)
• Should we support authenticated URLs (e.g., via project-level auth config)?
• Should references be editable/removable via comment syntax? (e.g., @forge unref <url>)