agent-instruction-forge
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Data
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Docker
- Runtime requirements
- Docker
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: agent-instruction-forge
description: Guide humans through creating effective instruction rules for coding agents (Copilot, Claude Cod…
category: data
runtime: Docker
---
# agent-instruction-forge output preview
## PART A: Task fit
- Use case: Guide humans through creating effective instruction rules for coding agents (Copilot, Claude Code, Cursor, Windsurf, Aider, AGENTS.md, CLAUDE.md, .cursorrules, copilot-instructions.md). Trigger when someone asks to create, improve, or write agent instructions, copilot rules, AI coding guidelines, context files, or anything shaping agent behavior. Also trigger on 'agent keeps making mistakes', 'make Copilot follow our conventions', 'write rules for repo', 'set up agent context'. Runs an interactive extraction process — reads codebase first, then guides the human through targeted questions to surface implicit knowledge (past failures, non-obvious conventions, architectural decisions) that code alone can't tell an agent. For analyzing gaps in existing context, use context-gap-analyzer. This skill *creates* the rules. Use when this capability is needed..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Seven Properties of a Great Rule / Rules Should NOT Contain / PHASE 1 — Codebase Discovery (Automated)” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Guide humans through creating effective instruction rules for coding agents (Copilot, Claude Code, Cursor, Windsurf, Aider, AGENTS.md, CLAUDE.md, .cursorrules, copilot-instructions.md). Trigger when someone asks to create, improve, or write agent instructions, copilot rules, AI coding guidelines, context files, or anything shaping agent behavior. Also trigger on 'agent keeps making mistakes', 'make Copilot follow our conventions', 'write rules for repo', 'set up agent context'. Runs an interactive extraction process — reads codebase first, then guides the human through targeted questions to surface implicit knowledge (past failures, non-obvious conventions, architectural decisions) that code alone can't tell an agent. For analyzing gaps in existing context, use context-gap-analyzer. This skill *creates* the rules. Use when this capability is needed.”.
- **02** When the source has headings, the agent prioritizes “Seven Properties of a Great Rule / Rules Should NOT Contain / PHASE 1 — Codebase Discovery (Automated)” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Seven Properties of a Great Rule / Rules Should NOT Contain / PHASE 1 — Codebase Discovery (Automated)”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: agent-instruction-forge
description: Guide humans through creating effective instruction rules for coding agents (Copilot, Claude Cod…
category: data
source: tomevault-io/skills-registry
---
# agent-instruction-forge
## When to use
- Guide humans through creating effective instruction rules for coding agents (Copilot, Claude Code, Cursor, Windsurf, A…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Seven Properties of a Great Rule / Rules Should NOT Contain / PHASE 1 — Codebase Discovery (Automated)” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "agent-instruction-forge" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Seven Properties of a Great Rule / Rules Should NOT Contain / PHASE 1 — Codebase Discovery (Automated)
rules -> SKILL.md triggers / order / output contract
runtime -> Docker | read files, write/modify files | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Agent Instruction Forge
Exceptional agent instructions encode specific implicit knowledge, not generic advice. Generic rules ("write clean code") hurt performance (ETH Zurich 2024: LLM-generated context files reduce success ~3%). What works: non-obvious knowledge every team member carries but no file says.
Modes (detected in Phase 1):
- Greenfield: No instruction files. Read codebase, extract, synthesize.
- Augment: Files exist. Audit, validate against code, fill gaps, strengthen.
- Interview-Only: No codebase access. Skip Phase 1 Steps 2-4. Lean on Failure Round + Resource Ingestion. Flag: "Can't validate against code — file paths need manual verification."
Seven Properties of a Great Rule
Specific & falsifiable — agent can verify compliance. Unfailable = not a rule.
"Write clean code"→"Every external API call must return Result<T, AppError>, never throw."Encodes WHY — without rationale, agents optimize around rules.
"Don't use console.log"→"Use src/lib/logger.ts — console.log bypasses Datadog correlation IDs."Born from real failure — past pain produces specificity.
"Never add indexes to reservations table without DBA approval — Q2 2024 compound index locked table 47min."Scoped correctly — highest directory where universally true. Test: "Applies to ALL code agent sees in this directory?" If not, push deeper.
Points to canonical example.
"New endpoints follow src/api/reservations/create.ts — handler → validation → service → response."Includes anti-pattern — overrides training priors when codebase deviates.
"We do NOT use repository pattern. Services call Prisma directly."Token-efficient.
"When writing tests, please make sure to use Vitest and not Jest."→"Tests: Vitest, never Jest."
Rules Should NOT Contain
- Things fixable in code (better type signature, clearer name, linter rule)
- Things linting already enforces
- Language documentation (agent knows the language)
- Obvious patterns derivable from reading the code
- Aspirational rules nobody follows (document reality unless explicitly marked aspirational)
PHASE 1 — Codebase Discovery (Automated)
Read codebase before asking anything. Don't ask what code already answers.
Step 1: Discover instruction infrastructure
Scan: AGENTS.md, CLAUDE.md, GEMINI.md, .cursorrules, .windsurfrules, .github/copilot-instructions.md, .github/instructions/*.instructions.md, .github/prompts/*.prompt.md, .context/, .ctx, README.md, ARCHITECTURE.md, CONTRIBUTING.md, ADR dirs, formatter/linter configs, tsconfig/pyproject.toml, Makefile/justfile, CI/Docker configs.
For each file: topics, staleness, format/tone.
Step 2: Codebase topology
Map: languages, frameworks, package managers, directory structure (2-3 levels), entry points, test structure, external integrations.
Step 3: Pattern extraction
Sample 3-5 files from most-modified directories (git log --stat or inferred from size/complexity). Detect: naming, error handling, import organization, logging, test patterns.
Step 3b: History mining (if git/PR available)
git log for reverts, migrations, convention enforcement, hotfixes — each encodes an implicit rule. Keywords: convention, instead, revert, breaking, deprecated, don't.
PR access (gh pr list --state merged --limit 30): scan review corrections ("nit:", "use X instead"), architectural rationale in descriptions, repeated feedback. Capture: source, candidate rule, category (C1-C9), confidence.
If unavailable: ask in Phase 2: "Patterns you correct repeatedly in reviews but aren't documented?"
Step 4: Rule Audit (Augment Mode Only)
For each existing rule:
- Seven Properties Score (0-7). Flag <=2. P1 failure (specific/falsifiable) = noise regardless of other scores.
- Code Alignment: Confirmed | Stale | Aspirational | Contradicted | Unverifiable
- Coverage: C1 Architecture, C2 Domain/Business, C3 Conventions, C4 Integrations, C5 Operations, C6 Testing, C7 Security, C8 Performance, C9 Historical Decisions
- Redundancy: duplicated by lint/types/CI? Contradicts other rules?
- Scope: over-scoped (push down), under-scoped (pull up), wildcard abuse, missing intermediate levels
Output:
Rule | Score | Alignment | Scope | Verdict (Keep/Rewrite/Verify/Remove/Re-scope)
Summary: N total → keep[n] rewrite[n] verify[n] remove[n] re-scope[n]
Coverage: C1[●/◐/○] ... C9[●/◐/○]
Token budget: ~[current] / [limit] — headroom: [remaining]
Scope health: [N] correct, [N] over-scoped, [N] under-scoped
Step 5: Discovery Brief
- Greenfield: target system, what code reveals, top candidate rules from history, highest-value gaps
- Augment: rule health summary, top issues, undocumented rules from history, coverage gaps
Verify: any "remove" rules actually important? "Confirmed" rules outdated? Which history-surfaced rules are real conventions? Which gaps matter most?
PHASE 2 — Knowledge Extraction (Interactive)
2-4 questions per round. Don't dump 20.
In Augment mode, weave three workstreams:
- Verify flagged rules: "This rule says [X]. Still accurate?"
- Fill coverage gaps: skip well-covered categories, focus on empty ones
- Strengthen weak rules: "Why? What goes wrong otherwise?" / "File that best exemplifies this?"
Prioritize areas where (a) agent writes code most often, (b) code is most ambiguous, (c) existing rules are weakest.
Round 1 — Failures (Always Start Here)
Highest-signal source. Ask 2-4:
- "Last time a developer (human or AI) made a frustrating mistake — what happened, what should they have done?"
- "Landmines where the obvious approach leads to subtle bugs?"
- "Most common mistake from new team members?"
- "Recurring annoyances in agent-generated code you fix every time?"
Probe: "Point me to a file?" / "Correct version?" / "Why this way?"
Round 2 — Conventions
Where codebase deviates from framework defaults — where agent training priors mislead.
- "Where does your codebase intentionally deviate from the framework's recommended approach?"
- "Patterns you enforce in code review that linting/CI doesn't catch?"
- "One rule that eliminates 50% of review nit-picks?"
Round 3 — Architecture
Module boundaries, data flow, where new code goes.
- "How should an agent decide which module/directory new code goes in?"
- "Files that shouldn't be modified without extra caution?"
- "How does data flow for the most common operation?"
Round 4 — Integrations (if external services detected)
API quirks, dependency approval process, wrapper conventions.
Round 5 — Testing
Philosophy, patterns to follow/avoid, mock boundaries.
Round 6 — Resource Ingestion (optional)
"Any existing resource I should read? (Wiki, ADR, Slack thread, postmortem)" — extract using Seven Properties.
Adapt by: codebase type (frontend→components, backend→endpoints), team size (solo→future-self, large→consistency), agent system (Copilot→completion-level, Claude Code→task-level), human energy (target 15-20 min).
PHASE 3 — Synthesis
Greenfield Mode
# [Project] — Agent Instructions
## Philosophy — [2-3 sentences anchoring judgment]
## Critical Rules — [violations break things: what + why + anti-pattern]
## Conventions — [review friction: pattern + example file]
## Architecture — [boundaries, data flow, where new code goes]
## Testing — [philosophy + patterns + mock boundaries]
Augment Mode
Do NOT rewrite from scratch. Produce a reviewable changeset:
- Remove low-signal rules
- Rewrite rules in place, preserving grouping/tone
- Add rules for coverage gaps
- Re-scope rules to appropriate directory
- Show delta from Phase 1
Per edit: what changed, why. Include before/after example.
Both Modes
- Scope: root=universal, package-level=local,
applyToglobs only when truly file-type-specific - Every rule specific and falsifiable (P1)
- Order by impact (critical first — long files may truncate)
- Match existing format/tone in augment mode
Token Budgets
| System | Unit | Root limit | Notes |
|---|---|---|---|
| Copilot | chars | <1000 lines | Code review reads first 4000 chars/file |
| Claude Code | tokens | <4000 | Subdir: <1000 tokens |
| Cursor/Windsurf/AGENTS.md | tokens | ~4000 | Similar to Claude Code |
When WHY and brevity conflict, keep WHY. Main lever: scope rules down to reduce root file size.
PHASE 3b — Adversarial Validation
Before showing rules, stress-test with three isolated subagents receiving ONLY the synthesized file. Read references/adversarial-validation.md for prompts.
Run in parallel:
- Newcomer — finds gaps
- Prior Override — checks rules beat common training priors
- Contradiction Finder — finds conflicts and ambiguities
Update rules. Include summary of gaps, weak spots, resolved contradictions.
PHASE 4 — Review & Delivery
Present rules. Iterate on feedback.
Write to target:
| System | Files |
|---|---|
| Copilot | .github/copilot-instructions.md (repo-wide) + .github/instructions/NAME.instructions.md (scoped) + .github/prompts/NAME.prompt.md |
| Claude Code | CLAUDE.md (root + subdirs) |
| Cursor | .cursorrules |
| Windsurf | .windsurfrules |
| Generic | AGENTS.md (root + subdirs) |
If target unclear, ask. If multiple, generate for primary. Copilot always uses three-layer structure.
After delivery: suggest running agent on a real task. Next mistake = next rule. Revisit monthly.
Source: AndurilCode/craftwork — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review