mirror of
https://github.com/github/awesome-copilot.git
synced 2026-08-14 05:06:54 +00:00
fix: repair broken skill references, fence nesting, and invisible unicode (#2568)
While implementing the Agent Plugin v1 spec in https://github.com/stbenjam/skillsaw/pull/483, I used this repository as a canonical real-world source for tests. Along the way its checks surfaced genuine correctness issues worth fixing regardless of tooling: - Internal links that do not resolve (22): wrong relative paths, links whose targets are runtime output paths rather than bundled files (now inline code), a schemeless external URL parsed as a relative path, and links to files that do not exist (removed). - Bundled skill files never referenced from their SKILL.md (14): each is now cited from the section where it is used, so nothing ships unreachable from the skill's instructions. - Unclosed or mis-nested code fences (11): markdown templates embedding code blocks now use four-backtick outer fences so inner fences nest instead of closing the template early and leaking example content as live markdown; also removed stray orphan fences and closed an unterminated block at end of file. - Invisible unicode (1): removed a zero-width space from a code example, a copy-paste artifact invisible to reviewers.
This commit is contained in:
@@ -19,7 +19,7 @@ The specification file must define the requirements, constraints, and interfaces
|
||||
- Include examples and edge cases where applicable.
|
||||
- Ensure the document is self-contained and does not rely on external context.
|
||||
|
||||
The specification should be saved in the [/spec/](/spec/) directory and named according to the following convention: `[a-z0-9-]+.md`, where the name should be descriptive of the specification's content and starting with the highlevel purpose, which is one of [schema, tool, data, infrastructure, process, architecture, or design].
|
||||
The specification should be saved in the `/spec/` directory and named according to the following convention: `[a-z0-9-]+.md`, where the name should be descriptive of the specification's content and starting with the highlevel purpose, which is one of [schema, tool, data, infrastructure, process, architecture, or design].
|
||||
|
||||
The specification file must be formatted in well formed Markdown.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user