🌐 日本語

Practical Application Without Tool Support

NOTE

Even without dedicated rule files or MCP, the principle for dealing with structural constraints is the same.
This page covers "prompt-driven development": reproducing that principle by hand.

Real-World Constraints

Not every development environment has injection control at the same granularity as Claude Code.

• Always-on instructions and conditional injection are not equally fine-grained
• Source control, task tracking, and auth are split across tools
• Tickets and repositories cannot be reached through an MCP-equivalent
• Commit message conventions are missing, so git log does not work as Context

Even then, the principles confirmed in Parts 1–10 still apply. Whether a dedicated command exists does not decide whether the principle can be used.

Workflow for Prompt-Driven Development

Below is a step-by-step development method actually used in environments where CLAUDE.md or Skills are unavailable.

Workflow Diagram

Color coding:

• Green — User actions (review, judgment, commit)
• Blue — LLM actions (generation, implementation, testing)
• Yellow (cylinders) — Deliverables (6 items + checklist + PR)

Why Separate Steps?

IMPORTANT

The reason for not requesting everything at once comes from the structural constraints learned in Parts 1–2.

LLMs are stateless, and context grows with each turn. If you ask to "plan, implement, test, and create a PR" all at once, context becomes huge and quality degrades. By separating steps, you keep context small for each step.

Step	Structural Problem Being Addressed
Create instructions in advance	Knowledge Boundary (explicitly inject project context unknown to LLM)
Create plan first → review	Context Rot (prevent context bloat from all-at-once implementation)
Create E2E test items before implementation	Sycophancy (set acceptance criteria first to prevent lenient judgment)
Externalize checklist	Instruction Decay (prevent forgetting procedures in long sessions)
Commit per task phase	Context Rot (reset session when phase completes)

Deliverables as Context Substitutes

The core of this workflow is persisting deliverables as files and having the LLM reference them by path in the next step.

# Example prompt
Please refer to the following deliverables and proceed with Phase 2 implementation.

- Instructions: ./docs/instructions.md
- Implementation Plan: ./docs/implementation-plan.md
- Checklist: ./docs/checklist.md

First, confirm that you understand the content.

When you pass the path to the LLM, it reads the content, displays a summary, and asks for confirmation. This "comprehension check" step is important—it validates whether the LLM has correctly grasped the context.

TIP

This is essentially doing manually what CLAUDE.md + Skills do.

Manual Process	Claude Code Feature
Create instructions and specify path	CLAUDE.md (resident context)
Pass deliverable paths and say "refer to"	Skills reference-based design
Convert tickets to Markdown and save locally	llms.txt / MCP integration
Have LLM output summary for confirmation	Comprehension check prompt

Markdown-ifying External Information

When MCP cannot directly connect to ticket management systems or repositories, the practical solution is to manually convert information to text and place it in your project folder.

• Copy Backlog / GitHub Issue ticket content to Markdown
• Text-ify backend repository API specifications
• Save related design documents locally

Project Folder/
├── docs/
│   ├── instructions.md        # Instructions (template-ready)
│   ├── implementation-plan.md # Implementation plan generated by LLM
│   ├── e2e-test-spec.md       # E2E test items generated by LLM
│   └── checklist.md           # Checklist generated by LLM
├── references/
│   ├── ticket-123.md          # Ticket content Markdown-ified
│   ├── backend-api-spec.md    # Backend API specification
│   └── design-doc.md          # Design documentation
└── src/

This manual conversion is tedious but has advantages. If you pass raw ticket data, comments and unrelated discussions also end up in context. By Markdown-ifying, you extract "only what the LLM needs." In a sense, this is manual Context Budget management.

Commit Messages and Context Quality

WARNING

In environments where commit messages are not standardized, git log barely functions as LLM context.

When commits like fix bug or update pile up, the LLM cannot grasp the intent behind past changes. With conventions like Conventional Commits and issue numbers attached:

feat(auth): add login flow (#123)
fix(api): handle timeout in payment service (#456)

The LLM can trace Issue #123, understand the background, and track related changes. The quality of "development process metadata" like commit messages, branch naming, and PR templates directly affects the efficiency of LLM utilization.

This has been a concern since before LLMs, but its importance is renewed in the context of AI adoption. Between humans, "that thing at that time" makes sense. With LLMs, it doesn't.

Mapping Principles

The principles of addressing problems are the same regardless of tool support.

Principle	Claude Code Implementation	Prompt-Driven Implementation
Keep resident context minimal	CLAUDE.md 200-line limit	Simplify instruction template
Distribute with conditional injection	.claude/rules/	Specify only needed deliverable paths per step
Inject knowledge on-demand	Skills	Reference deliverable files
Make external info readable to LLM	MCP / llms.txt	Markdown-ify and save locally
Keep sessions short	/compact / /clear	Commit per phase + reset
Mechanical validation outside context	Hooks	CI/CD, manual test execution

Approach of Defining the Workflow Itself as Skills

Up to this point, this page has applied the principles by hand where dedicated machinery is missing. If procedures can be stored as Markdown, the workflow itself can be fixed in a procedure file.

Addy Osmani's agent-skills is an example of defining a development workflow as Plain Markdown Skills.

• Spec before code — Define specification before implementation (corresponds to "create instructions in advance")
• Plan-mode task breakdown — Break tasks into verifiable units (corresponds to "create plan first → review")
• TDD with Prove-It pattern — Reproduce bugs as failing tests first (corresponds to "create E2E test items before implementation")
• 5-axis code review — Review across accuracy, readability, design, security, and performance
• Anti-rationalization table — Pre-define agent excuses for skipping steps and counter-arguments (Sycophancy mitigation)

TIP

What matters is that the procedure is Plain Markdown. Even without a product-specific loader, you can pass a path and have it read. That does not mean every product has the same Skills machinery.

References

• Osmani, A. (2025). "agent-skills: Production-grade engineering skills for AI coding agents." github.com/addyosmani/agent-skills — Systematizes development workflows as Plain Markdown Skills. MIT License

---

Previous: Structural Constraints Are Universal Across Models

Next: Cursor / Cline / Copilot Mapping