🛠️ Update various documentation, scripts, and configuration templates to enhance clarity, functionality, and maintainability across the project
This commit is contained in:
52
resources/skills/copilot-reuse-audit/SKILL.md
Normal file
52
resources/skills/copilot-reuse-audit/SKILL.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
name: copilot-reuse-audit
|
||||
description: "Use when auditing the last 30 days of persisted Copilot artifacts for reusable patterns worth promoting into the shared repo."
|
||||
argument-hint: "days=<n> workspace=<optional path filter> sources=<optional csv>"
|
||||
---
|
||||
|
||||
# Copilot Reuse Audit
|
||||
|
||||
Use this skill when you want a repeatable audit of local Copilot usage artifacts
|
||||
to find patterns that should become shared resources.
|
||||
|
||||
## Procedure
|
||||
|
||||
1. Run `resources/scripts/audit-copilot-usage.sh` instead of manually hunting
|
||||
through transcripts, memories, and publish logs.
|
||||
2. By default, the runner excludes the `copilot-resources` repo root from
|
||||
workspace-backed candidate discovery so the audit does not ask you to review
|
||||
patterns that already live in the shared repository.
|
||||
3. Review the generated `audit-summary.md` first to understand coverage and top
|
||||
candidates.
|
||||
4. Use `selection-manifest.tsv` and `pattern-details/*.md` as the approval
|
||||
surface for each candidate.
|
||||
5. When you want interactive triage inside Copilot, use the
|
||||
`review-audit-candidates` prompt so each pending row is handled one at a
|
||||
time and written back to `selection-manifest.tsv`.
|
||||
6. Use the transcript prompt-cost proxy fields to prioritize repeated long
|
||||
prompts that are likely worth turning into a shared resource.
|
||||
7. Treat those prompt-cost fields as triage signals, not as exact billing data.
|
||||
6. Before asking for a decision, explain the candidate's likely purpose,
|
||||
concrete benefit, audit context, and score rationale. If evidence is thin,
|
||||
call that out explicitly instead of asking the user to infer it.
|
||||
8. Promote only candidates that map cleanly to a portable skill, instruction,
|
||||
prompt adapter, agent, hook, script, or template.
|
||||
9. After rows are approved, run `resources/scripts/prepare-audit-promotions.sh`
|
||||
to create draft resources or staging notes in the audit directory.
|
||||
10. Keep non-portable or repo-specific findings in audit notes rather than
|
||||
forcing them into shared resources.
|
||||
|
||||
## Outputs
|
||||
|
||||
- `audit-summary.md` — high-level run summary and top candidates
|
||||
- `candidates-report.tsv` — scored candidate list with source references
|
||||
- `selection-manifest.tsv` — editable approval surface for promotion decisions
|
||||
- `pattern-details/*.md` — per-candidate evidence bundles with benefit, context, score rationale, and caveats
|
||||
- `draft-resources/` — generated draft resource files for approved portable rows
|
||||
- `staging-notes/` — generated follow-up notes for approved rows that still need design work
|
||||
|
||||
## Notes
|
||||
|
||||
- The runner is macOS-first in this iteration.
|
||||
- Audit history is stored per machine under `.local/audits/<machine-id>/` in the
|
||||
repo checkout and is intentionally git-ignored.
|
||||
Reference in New Issue
Block a user