How to Make Application

Build software as a solo developer with a lightweight, specification-driven system.

Quick start · Compatibility · How it works · Case study

English · 简体中文

How to Make Application is a portable Agent Skill for turning an app idea—or an existing codebase—into a product that one person can understand, implement, verify, release, and resume.

It treats documentation as a control system for decisions and evidence, not as paperwork. The workflow scales up for substantial application work and stays out of the way for isolated questions or trivial edits.

Why this skill

Shape the right release	Turn an idea into a focused product brief, explicit constraints, and the smallest coherent version worth testing.
Protect product truth	Keep planned intent, current implementation, human acceptance, and public release facts in clearly separated records.
Build in safe slices	Deliver important features and refactors as reversible, independently verifiable vertical slices.
Diagnose with evidence	Preserve symptoms, observations, rejected hypotheses, layered causes, and invariants instead of guessing at fixes.
Verify what ships	Test the actual production artifact and release identity rather than treating compilation as proof of quality.
Resume without rediscovery	Leave a precise baseline, open risks, and next action so a future session can continue immediately.

Quick start

Clone the repository into the personal skill directory used by your agent:

# Codex
mkdir -p ~/.codex/skills
git clone https://github.com/Duoasa/how-to-make-application.git ~/.codex/skills/how-to-make-application

# Claude Code
mkdir -p ~/.claude/skills
git clone https://github.com/Duoasa/how-to-make-application.git ~/.claude/skills/how-to-make-application

# DeepSeek Harness
mkdir -p ~/.dsh/skills
git clone https://github.com/Duoasa/how-to-make-application.git ~/.dsh/skills/how-to-make-application

Then invoke it explicitly with a real task:

Codex:            Use $how-to-make-application to shape this app idea into a focused first release.
Claude Code:      /how-to-make-application Shape this app idea into a focused first release.
DeepSeek Harness: /how-to-make-application Shape this app idea into a focused first release.

The repository root is the skill root. Each supported agent reads the same canonical SKILL.md and the same on-demand references.

Agent compatibility

Agent	Support	Personal discovery path	Explicit invocation	Details
Codex	Native	~/.codex/skills/how-to-make-application/	$how-to-make-application	agents/openai.yaml
Claude Code	Native Agent Skill	~/.claude/skills/how-to-make-application/	/how-to-make-application	Adapter guide
DeepSeek Harness	Native Skill, developer preview	~/.dsh/skills/how-to-make-application/	/how-to-make-application	Adapter guide

For repository-scoped use, install the repository under .claude/skills/ or .dsh/skills/. DeepSeek Harness also scans compatible bundles in personal and project .agents/skills/ directories. The adapter guides include project installation, update, invocation, and verification details.

Agent-specific metadata never replaces the canonical workflow. An adapter changes discovery and invocation only; it does not grant extra tools, permissions, publishing authority, paid-service access, or secret access.

How it works

Reality → Specification → Slice → Evidence → Release → Handoff

The skill selects the smallest working mode that fits the task:

Mode	Outcome
Shape	Product brief, constraints, risks, and first testable release
Bootstrap	App skeleton, minimum document system, development loop, and first vertical slice
Build	An approved feature implemented against a focused execution specification
Evolve	Architecture or behavior changed while preserving explicit invariants
Diagnose	Symptoms, evidence, layered causes, rejected hypotheses, and a verified fix path
Release	A particular artifact verified and published only with explicit authorization
Resume	Current baseline reconstructed and the next unblocked slice continued

Core principles

1. Establish reality before planning.
2. Separate durable rules, planned intent, current work, release facts, and human acceptance.
3. Define invariants and failure semantics before choosing architecture.
4. Implement in reversible, independently verifiable slices.
5. Produce evidence proportional to risk.
6. Never report a proposal as implemented, a candidate as released, or an unobserved result as passed.

The document system

Each document owns one kind of truth:

Artifact	Owns	Must not claim
Stable project rules	Long-lived product, engineering, privacy, and release constraints	Transient progress
Product or execution specification	Planned intent, boundaries, decisions, phases, and acceptance design	Implementation or release completion
Implementation report	What actually landed and how it was verified	Future scope as completed
Handoff	Current workspace, evidence, open risks, and exact next action	A chronological project diary
Version history	Verified public release identity and withdrawn-release history	Candidates or internal builds as released
Acceptance record	Human-observed product, visual, interaction, hardware, or accessibility results	Unobserved results as passed

When sources conflict, the default priority is: current user instruction, current production reality, verified release artifacts, current handoff, approved specifications, then external references and conventions.

Usage examples

Start a new application

Use the how-to-make-application skill to turn this idea into a product brief,
define the smallest coherent release, and identify the first vertical slice.

Evolve an existing codebase

Use the how-to-make-application skill to inspect this repository, establish the
real baseline, and write an execution specification for the next feature.

Prepare a release without publishing

Use the how-to-make-application skill to verify this release candidate, record
the evidence, and prepare a precise handoff. Do not publish yet.

Real-world proof: QuotaView

This skill was distilled from the SDD system used to build and release QuotaView, a native macOS application developed through repeated product, architecture, UI-stability, packaging, and release iterations.

Public artifact	What it demonstrates
Stable project rules	Durable product, design, implementation, privacy, and release constraints
Core architecture execution specification	Goals, non-goals, invariants, target architecture, phases, quality gates, ADRs, and stop conditions
WidgetKit specialized specification	Narrow subsystem responsibilities, data flow, privacy, failure modes, budgets, and acceptance
Implementation report	Delivered facts and automated evidence separated from pending human acceptance
Current handoff	Production baseline, active work, verification, workspace boundaries, and release gates
Version history	Public release identities, artifacts, verification, and withdrawn-release history

The skill generalizes the working method—not QuotaView's macOS stack, visual system, product scope, or project-specific constraints.

Repository structure

.
├── SKILL.md                    # Portable workflow entrypoint
├── agents/
│   └── openai.yaml            # Codex UI metadata
├── adapters/
│   ├── claude-code.md          # Claude Code discovery and invocation
│   └── deepseek-harness.md     # DeepSeek Harness discovery and invocation
├── references/
│   ├── document-system.md      # Source-of-truth model
│   ├── execution-playbook.md   # Working modes and execution guidance
│   ├── quality-and-release.md  # Verification, release, and handoff gates
│   └── templates.md            # Reusable document templates
├── README.md                   # English documentation
└── README.zh-CN.md             # 简体中文文档

The entrypoint stays compact. Agents load focused references only when the current task needs them.

Feedback and contributions

Issues, compatibility reports, documentation improvements, and focused pull requests are welcome through GitHub Issues.