ArPiStar Methods (ArPiDev + ArPiDoc)#

ArPiStar is a pair of lightweight, AI‑assisted methods for software projects. They are AI‑agnostic (works with any capable assistant), and not vibe coding: the user stays involved, reviews artifacts step by step, and can see exactly what is done and why. They also work well for learning, because every decision and change is written down.

This repo contains two sibling methods:

• ArPiDev: for building and shipping software.
• ArPiDoc: for producing high‑quality documentation.

Both methods are self‑contained folders you can copy into any project root.

1) Philosophy (shared)#

• Concrete over theory: propose real outcomes, not abstract debate.
• Artifacts as memory: if it matters, write it; if it is not written, it can change.
• Short decisions: decide fast, record briefly.
• Scope is sacred: change scope only with the right role and artifact.
• Assume and mark: make minimal assumptions and write them down.

2) Quickstart#

New project (dev)#

1. Copy ArPiDev/ into your project root.
2. Start the AI with ArPiDev/AGENTS.md and a prompt for the Architect to create SPEC.md.
3. Validate SPEC.md, then TASKS.md.
4. When a story is created, let the Dev implement it.

Existing project (dev)#

When adopting ArPiDev mid-project, create ArPiDev/CODEMAP.md after an Architect code review. It is a compact snapshot of entry points, module map, run commands, and pitfalls, so future sessions do not need a full code re-review.

1. Copy ArPiDev/ into your project root.
2. Ask the Architect to derive SPEC.md from the existing code.
3. The Pilot creates TASKS.md, then the first story.
4. The Dev implements story by story.

Documentation project (doc)#

1. Copy ArPiDoc/ into your project root.
2. Start the AI with ArPiDoc/AGENTS.md and a prompt for the Architect to create SPEC.md.
3. Validate SPEC.md, then TASKS.md.
4. When a story is created, let the Documenter execute it.

If ArPiDev/ exists, ArPiDoc will read its artifacts as source context (read‑only).

Canonical prompts for common actions#

These are the prompts to use directly in your AI chat session:

2.1) When to use which method#

Use ArPiDev when you need to build or change software. It drives product framing, planning, and implementation.

Use ArPiDoc when you need documentation as a deliverable. It drives documentation framing, planning, and writing, and can read ArPiDev as context.

You can run both in the same project. Keep them separate and follow each method’s entry file.

2.2) Usage details (human workflow)#

1. Always start by pointing the AI to the correct AGENTS.md.
2. Validate the frame (SPEC.md) before planning.
3. Validate the plan (TASKS.md) before execution.
4. Execute one story at a time.
5. Accept the story, then move to the next one.

3) Canonical prompt (adapt it)#

Read `ArPiDev/AGENTS.md` and apply ArPiDev.
Context: <1-2 lines>
Goal: <expected outcome>
Start.

Read `ArPiDoc/AGENTS.md` and apply ArPiDoc.
Context: <1-2 lines>
Goal: <expected documentation outcome>
Start.

4) Structures#

<project-root>/
  ... project files ...
  ArPiDev/
    AGENTS.md
    definitions/
    stories/

  ArPiDoc/
    AGENTS.md
    definitions/
    stories/
    models/

5) Roles (summary)#

ArPiDev

• Architect: frames the product and writes SPEC.md.
• Pilot: plans work, writes TASKS.md/DECISIONS.md, creates stories.
• Dev: implements the active story and logs in the story file.

ArPiDoc

• Architect: frames the documentation and writes SPEC.md.
• Pilot: plans work, writes TASKS.md/DECISIONS.md, creates stories.
• Documenter: executes the active story and logs in the story file.

6) Where templates live#

Templates are not pre‑created in the root. They live in:

• ArPiDev/definitions/artifacts/
• ArPiDoc/definitions/artifacts/

Artifacts like SPEC.md, TASKS.md, and DECISIONS.md are created when needed by the active role.