llm-friendly-context: Clear Prompts, No Guessing

Where this fits

You write a review prompt for one agent, hand the output to another agent for fixes, and the second agent stalls because "appropriate" or "related" means something different to it. That is the failure mode llm-friendly-context prevents: it forces you to specify inputs, outputs, success criteria, decisions, and unresolved conditions in every LLM-facing artifact. When you need community context or examples, you can find them at https://www.openagentskill.com/skills/shinpr-llm-friendly-context.

Why agents benefit

• Agents can self-check their work because success criteria are written as observable conditions like "all tests pass" or "no public API changes," not vague adjectives.
• Unresolved decisions are explicit, so an agent knows which choices remain open and can flag them during execution instead of silently picking a direction.
• Handoffs between models become deterministic: each downstream consumer gets the same structured context, regardless of which model or run executes it.
• Positive, executable instructions preserve agent judgment, while the few prohibitions are limited to contracts that cannot be broken, such as backward compatibility.
• The skill helps agents finish without asking for clarification, which shortens multi-step pipelines and reduces context-window waste.

Practical scenarios

Multi-agent review and fix

A review agent produces a list of findings, then a fix agent is expected to resolve them. Without structure, the fix agent guesses at severity and intent. With the skill, the review output includes the exact files read, which findings are blockers, and how to verify each fix, so the handoff happens without back-and-forth.

Implementation plan execution

A planner agent writes a technical design, and a coding agent executes it later (possibly in a separate session). The skill makes each plan step carry its own inputs, expected outputs, and decision points. For example, "refactor the rate limiter" becomes "move the rate limiter to src/rateLimiter.ts, keep the limit() export, and run npm test to verify."

Generated setup instructions for agents

Your skill generates installation steps for other agents. If those steps say "configure the tool appropriately," the agent must guess. llm-friendly-context directs you to include the config path, allowed values, and a verification command, so generated instructions are runnable without human intervention.

Add it to your agent workflow

Install the skill as a project dependency:

npx skills add shinpr/claude-code-workflows --skill llm-friendly-context

The skill is a prompt-rewriting checklist as much as a template. Use it when you draft a handoff:

## Inputs
- Read: src/api.ts, tests/api.test.ts
- Schema: User type in src/types.ts

## Output
- Refactored api.ts with unchanged public exports

## Success criteria
- `npm test` passes
- Public API surface unchanged

## Unresolved decisions
- Split rate limiter into separate module? (default: no)
- Helper function name? (default: handleRateLimit)

The next consumer can execute immediately, and any question they still have is a real product decision, not a clarity gap.

Compare before adopting

Before you commit, compare this skill with your current prompt templates and other "structured context" skills. Look at three things: the quality of its examples and whether they match your artifacts, the maintenance freshness of the repository (last commit, open issues), and how well it fits into your agent workflow compared to a custom system prompt or document template.

Why it is worth tracking

The project has 675 stars, which indicates a real need for explicit context in agent pipelines. It is worth tracking because as agent pipelines grow, the cost of ambiguous handoffs compounds. Re-evaluate it when your agents ask for clarification more than once per task, or when you see reviews that fail because the writer and reader had different mental models.