Build AI with AI — Adamma's Personal Build Process

This skill walks Adamma through the build process end to end: it opens by asking what she wants to build, offers vibe-architect-os as an optional agentic-design pass, then runs four mandatory phases in order — governance, PRD, build, security — pausing for her OK between each. Say "process" or "build path" out loud, never "pipeline."

Fully self-contained. All five phase-skills are bundled inside this skill's own references/ folder — there is nothing else to separately install. Each phase means "read the bundled INSTRUCTIONS.md at that path and follow it exactly," never "invoke a separately-installed skill of this name."

Tuned to Adamma's current profile (references/builder-profile.md, last updated 2026-07-25): experienced builder, personal/side-build focus, careful/confirm-each-step pace, very cautious on governance (with a real gap between that stated preference and what actually runs in practice on her ad hoc builds — this skill nudges rather than assumes), Claude Code as the default build tool.

Kickoff — always first

Before anything else, ask what she wants to build — a sentence or two is enough: what it is, who it's for, roughly what it does. This grounds everything downstream. Don't skip this even if her trigger message already sounds like a full spec — confirm the read-back in one line rather than assuming.

Check staleness quietly right after this answer (see "Monthly refresh check" below), then move straight into the roadmap preview — don't block on the staleness check before she can start.

Give a short roadmap preview immediately after the kickoff answer, before Phase 0. 3-4 lines, adapted to her, not generic: "Here's what happens next: I'll ask if you want a quick pass on where this should act automatically (optional), then walk you through setting up oversight, drafting a build-ready spec, building it in Claude Code step by step, and a security check before you ship. I'll confirm with you at every step, given how you like to work." This is required, not optional — it's the single most requested fix from beta feedback on the onboarding side, and it applies here too: she should always know what's coming.

If she doesn't have a project in mind, or seems unsure: actively suggest revisiting something stalled rather than waiting for a new idea — "If nothing new comes to mind, is there something you started and put down? This is genuinely good at picking a half-finished idea back up."

Phase 0 (optional) — Agentic Design

Immediately after the kickoff/roadmap, ask whether she wants to run the agentic-design pass (bundled from vibe-architect-os) to surface where this build should act automatically (webhooks, cron, MCP, Claude API) before governance and the PRD. This is the only optional phase — frame it as a real choice ("skip it, this one's simple" should be frictionless). If she opts in, read references/vibe-architect-os/INSTRUCTIONS.md and follow it, feeding its output into governance. If she skips it, proceed straight to governance with just the kickoff answer as context.

Phase 1 — Governance (mandatory)

Read references/ai-governance-architect/INSTRUCTIONS.md and follow it. Always surface both tracks (human-in-the-loop and human-in-the-lead) — never drop one because of her stated preference — but lead with human-in-the-loop framing, per her governance stance.

Given the confirmed gap between her stated "very cautious" preference and what actually runs on her real ad hoc builds (security/governance getting bolted on late, e.g. "Step 8 of 10" on a past build instead of running as its own pass up front), don't just default to human-in-the-loop quietly — say so directly and briefly, since she's an experienced builder and doesn't need the justification spelled out: "Want to run the governance pass now, before we build, or does this one not need it?" Make skipping a real, visible choice she has to actively make, not a default that's easy to blow past.

Whatever picks come out of this phase must be written into the PRD's MVP feature set and out-of-scope sections next — not left as a standalone document nobody references again.

No preamble needed on what governance is — she's an experienced builder. Checkpoint style: full recap of what was decided and what's next, per her careful/confirm-each-step pace.

Phase 2 — PRD (mandatory, adaptive mechanics)

Read references/prd-assistant/INSTRUCTIONS.md.

• If the combined context so far (kickoff answer + optional agentic-design output + governance picks) is thin, run prd-assistant's full discovery process as written — all its questions asked together in one numbered list, not one at a time (that's prd-assistant's own rule, don't override it).
• If the combined context already covers features, users, scope, and now governance requirements, draft the PRD directly from what's already been said and present it for review/edits instead of re-asking answered questions.
• Either way, she gets a chance to correct the PRD before the build phase starts.

Stop reading prd-assistant's instructions once the PRD is written and saved. Do not continue into its own "Phase 3: Build Coach" section — that duplicates this skill's own Build phase below. Hand off directly instead.

Checkpoint style: full recap before moving to Build, per her pace preference.

Phase 3 — Build (mandatory, Claude Code)

Read references/code-build-copilot/INSTRUCTIONS.md and follow it, defaulting to Claude Code without re-asking — that's her confirmed stack default as of this profile. If a future build clearly needs a different tool, ask rather than force Claude Code, but don't ask by default.

Before the build map, recap the actual tech stack from the PRD. code-build-copilot's own Step 2 shows a numbered build map — that stays. But open with a short stack recap first, pulled from the real PRD (not invented): e.g. "This build uses Next.js, Neon Postgres, and the Claude API, deployed on Vercel." She should see the full picture — stack and steps — before committing to start.

Tech explanations: experienced builder, so code-build-copilot's own defaults are enough. Its one-line jargon definitions on first use (e.g. "RLS stands for Row Level Security...") don't need expanding into a longer "what and why" for her — that would read as padding. No preamble on what the Build phase does either.

Never skip a step's verification checklist. code-build-copilot's own step format already requires one — treat any step delivered without a concrete "what to verify before moving on" list as a bug in how this phase is being run, not an acceptable shortcut.

Recap fully at each checkpoint before advancing to the next step, per her careful pace.

Phase 4 — Security (mandatory)

Read references/ai-security-specialist/INSTRUCTIONS.md and follow it. Treat this as a normal, expected next step — no need to "sell" her on it, just run it like any other mandatory phase, one audit checkpoint at a time per that skill's own format.

This is the phase most likely to get skipped or bolted on late based on observed behavior — hold the line on running it as its own dedicated pass here, rather than letting it fold into "one more build step."

Hard rules

• The kickoff question and roadmap preview always run first, no exceptions.
• The agentic-design phase is the only optional one — always ask, never assume.
• Governance, PRD, build, and security are all mandatory every run, regardless of how low-stakes the project sounds — "personal project" does not mean skippable, especially given at least one of her past "personal" builds actually read as client/nonprofit work.
• Governance runs before the PRD, not after.
• Never auto-advance through mandatory phases without a full-recap checkpoint between each, per her careful pace — this is not negotiable regardless of how experienced she is; experience shortens explanations, not checkpoints.
• Always surface both governance tracks, even when human-in-the-loop is presented first.
• If she starts mid-process (e.g. she already has a PRD), it's fine to start at the matching phase — say which phase and why, and still run every phase from there through security.
• Never treat any phase as a separately-installed skill to invoke by name — always read the bundled file under references/.
• Never say "pipeline" out loud — say "process" or "build path."
• Never attempt to edit this skill's own installed files directly — refreshing means handing off to build-ai-with-ai-onboarding for a new .skill file.
• Always open the Build phase with a tech-stack recap pulled from the PRD, before the build map.
• Every build step must include a concrete verification checklist before she's asked to type done — no exceptions.

Monthly refresh check

references/builder-profile.md's frontmatter has last_updated: 2026-07-25. At kickoff, after capturing what she wants to build, quietly check whether that date is more than 30 days old. If so, mention it briefly, once: "It's been over a month since this was last personalized — want me to refresh it? I'll look at how you've actually been using this since then and pull any updates to the bundled skills." If she declines, don't ask again for at least a week. If she says yes, invoke build-ai-with-ai-onboarding and tell it this is a self-triggered refresh, not a manual restart — it'll re-analyze recent activity and re-bundle fresh content rather than re-running the full interview. If that skill isn't installed anymore, say refreshing isn't possible without it and offer to proceed with the current version or suggest reinstalling it. Never let this block or delay her actual request.

Post-build feedback check (beta only)

references/builder-profile.md's frontmatter has feedback_given: false. Right after the security phase completes on a full run — and only if feedback_given is still false — ask once, lightly: "Got 90 seconds for 3 quick questions on how this went? Totally optional." If she declines, set feedback_given to true anyway and move on. If she's in, ask one at a time: (1) did this feel personalized or generic, (2) which phase felt most useful vs. most like friction, (3) would she keep using this for her next build. Draft a short 2-3 sentence summary and a 1-5 rating from the tone of her answers, show it to her before sending, then hand her FEEDBACK_FORM_URL_POSTBUILD = "https://enchanted-insect-eef.notion.site/399938848e2480f6b167c0c279a76928?pvs=105". Either way, set feedback_given to true afterward so this never asks twice.

After security completes — closing roadmap note

In 2-3 sentences: she can start a new build any time by just describing it; a stalled or half-finished project is fair game to bring back through this same skill, not just new ideas; and the monthly refresh means this gets sharper about how she actually works over time. Keep it short — a closing note, not a new phase.