About 42 min
Prompt Vault
46 prompts, in full, collected from every article that publishes one.
Every prompt links back to the article that explains why it is worded the way it is — which constraints matter, and what goes wrong without them. A prompt copied without that context still runs; it just stops being the thing that was tested.
AI-Driven SDLC workshop
Session 2 · Activity 1 — AI-driven requirement discovery
Business Context
14 lines · source
You are a Senior Business Analyst.
Task Goal: understand the business problem behind the
Dynamic Appointment Rescheduling & Waiting List Management feature.
Before proposing any requirements:
- Build the Business Context from the current state of the MedBook system.
- Identify the information directly related to the problem.
- Summarise the problem as a Business Problem Canvas.
Rules:
- Use only information present in the case study.
- Do not invent new Business Rules.
- Anything without sufficient grounding must be marked "Needs confirmation".Requirement Clarification
18 lines · source
You are a Senior Business Analyst.
Task Goal: clarify the missing requirements of the
Dynamic Appointment Rescheduling & Waiting List Management feature.
Before writing any User Stories:
- Analyse the Business Context.
- Identify the remaining Information Gaps.
- Propose the questions that need clarifying with stakeholders.
Do not propose solutions.
Do not generate User Stories.
Do not assume unconfirmed Business Rules.
For each question, state:
- What information is missing.
- Why this information matters.
- Which stakeholder should confirm it.User Stories
12 lines · source
You are a Senior Business Analyst.
Using the confirmed Business Problem Canvas and Requirement Clarification Log,
write the User Stories for Dynamic Appointment Rescheduling and Waiting List
Management.
Rules:
- Group by actor: Patient, Doctor, Medical Staff, System Administrator.
- Each User Story describes exactly one goal.
- Do not decide Business Rules that have not been confirmed.
- Explicitly mark any User Story that rests on an Assumption or Open Question.
- Prioritise the User Stories needed for a Minimum Viable Product.Acceptance Criteria
14 lines · source
You are a Senior Business Analyst.
Based on the User Story and the confirmed Business Rules, write Acceptance
Criteria in Given - When - Then format.
Requirements:
- Cover the Happy Path.
- At least one Alternative Flow.
- At least one Exception.
- Include the case where the patient declines.
- Include the case where the patient does not respond within the time limit.
- Include the case where the slot is no longer available.
- Use only confirmed Business Rules.
- Anything unclear must be marked "Open Question" - do not infer.Requirement Review
20 lines · source
You are a Senior Business Analyst and Software Architect.
Review the entire Requirement Package and identify the issues that could affect
system design and development.
Check for:
- Missing Requirements.
- Ambiguous Requirements.
- Conflicting Requirements.
- Duplicate or overlapping User Stories.
- Unconfirmed Assumptions and Open Questions.
- Unhandled Edge Cases.
- Requirements that do not fit the existing system or APIs/Services.
- Missing non-functional requirements (Performance, Security, Privacy,
Reliability, ...).
- Privacy, Security and Fairness risks.
- Items that require a stakeholder decision.
Do not modify Business Rules or Requirements yourself. Only state the issue,
analyse its impact, and propose the questions or items that need confirming.MoSCoW Prioritisation
16 lines · source
You are a Senior Business Analyst.
Based on the Requirement Package, propose a priority level for each User Story
using MoSCoW.
Consider:
- Business Value.
- How essential it is to the main business flow.
- Dependencies between User Stories.
- The risk of not implementing it.
- Whether existing APIs/Services can be reused.
- Estimated implementation complexity.
Do not make the final decision.
Explain your reasoning briefly for each level, and state clearly which cases
need human review.Session 2 · Activity 2 — AI-driven architecture and system design
Impact Analysis
30 lines · source
You are a Software Architect analysing the impact of a requirement change on
the MedBook system.
First, from the Requirement Context and Current System Context, select and
assemble the relevant information into a Task-specific Context for Impact
Analysis:
- Related prioritised User Stories.
- Related Acceptance Criteria.
- Business Rules that affect design.
- Related existing Modules and Services.
- Related existing APIs.
- Related database entities or data.
- Technical, Security and Privacy Constraints.
- Open Questions or Assumptions to keep in mind.
Then, using that Task-specific Context, perform the Impact Analysis and identify:
- Components that can be reused.
- Components that must be extended or changed.
- New components that must be added.
- APIs to add or adjust.
- Data to add or change.
- Business flows and integration points affected.
- Dependencies between components.
- Risks introduced by the change.
Do not propose redesigning the whole system.
Prefer reusing existing modules, services, APIs and data structures where
appropriate.
Do not create new Business Rules or Requirements. Mark anything unclear as
"Needs confirmation".Architecture Exploration
26 lines · source
You are the Software Architect responsible for extending MedBook to support
Dynamic Appointment Rescheduling and Waiting List Management.
MedBook already has a running architecture and live features. Your goal is not
to redesign the system, but to propose evolution options with minimal change.
Using the Task-specific Context, Impact Analysis and Current System Context,
propose at least 3 different architecture options.
For each option:
- Maximise reuse of existing components, services, APIs and database.
- Add or change only what is genuinely necessary.
- Describe the high-level architecture and the components affected.
- Explain how it integrates with the current architecture.
- Describe the strategy for Concurrency, Consistency and Failure Recovery.
- Analyse advantages, limitations, trade-offs and risks.
- State the conditions under which this option is the right choice.
Prioritise:
- Reusability of existing components.
- Minimal impact on running features.
- Avoiding database and public API changes unless truly necessary.
- Backward compatibility.
- Future extensibility and maintainability.
Do not pick the final option on the human's behalf.Architecture Evaluation
25 lines · source
You are the Software Architect of the MedBook system.
Based on the Impact Analysis and the 3 proposed architecture options, evaluate
each option against:
- Fit with the current architecture
- Implementation complexity
- Maintainability
- Scalability
- Reliability
- Security & Privacy
- Operating cost
- Rollback capability
- Fit with the team's current capability
- Time to deliver
For each criterion:
- Score from 1 (low) to 5 (high).
- Explain the score briefly.
- Note any risks or assumptions to be aware of.
Finally:
- Rank the options by suitability.
- Analyse the trade-offs of each option.
- Identify the decisions the Software Architect should make rather than the AI.
- State what information is still missing to reach a final decision.Adversarial review
8 lines · source
Act as an independent Software Architecture Reviewer.
Critique the evaluation above by:
- Naming the assumptions that do not hold.
- Finding the risks that were missed.
- Describing the cases where a different option would fit better.
- Proposing the questions the Software Architect should consider before making
the final decision.Component Design
21 lines · source
You are the Software Architect of the MedBook system.
Based on the Architecture Decision, design the components that realise Dynamic
Appointment Rescheduling and Waiting List Management.
For each component, identify:
- Role (Reuse / Extend / New)
- Main responsibilities
- The Business Rules it is responsible for
- Components or Services it interacts with
- Input
- Output
Also:
- Check whether any component is carrying too many responsibilities.
- Propose splitting or merging components if needed.
- Ensure each Business Rule belongs to exactly one component.
- Briefly explain the reasoning behind the design decisions.
If you need to clarify an existing component or interface, refer to the Current
System Context.Adversarial review
14 lines · source
Act as a Software Architecture Reviewer.
Evaluate the component design against:
- Single Responsibility Principle (SRP)
- Cohesion
- Coupling
- Reusability
- Extensibility
- Maintainability
If you find a problem:
- Name the component that is not right.
- Explain the cause.
- Propose an improvement.API & Interaction Design
27 lines · source
You are the Solution Architect of the MedBook system.
Based on the Requirement Context and Component Design, design the API and
interaction flow for: when a slot becomes available, the system selects a
suitable patient, sends an offer, and handles the patient's reply.
Task 1 - Build Business Flow Context
From the Requirement Context, retrieve the information related to this flow.
Identify: Business Goal, Trigger, Actors, related User Stories, Acceptance
Criteria, Business Rules, Preconditions, Postconditions, Alternative Flows,
Exception Conditions, Open Questions.
If information is missing, write "Needs confirmation" - do not assume.
Task 2 - Design Interaction Flow
For each step, identify: the Actor or Component acting, the action, the API or
Event used, Input, Output, and the state created or changed.
Clearly separate Main Flow, Alternative Flow and Exception Flow.
Task 3 - Design API and Event Contracts
For each API or Event: Existing / Modified / New, Provider, Consumer, Purpose,
Request or Event Payload, Response or Output, Error Response.
Prefer reusing existing APIs before proposing new ones.
Task 4 - Analyse Runtime Behaviours
For each important interaction, analyse: Timeout, Retry Policy, Error Handling,
Concurrency Control, Idempotency, Rollback or Compensation.
If you find a risk or bottleneck, propose an improvement.Data & State Design
41 lines · source
You are the Data Architect of the MedBook system.
Based on the Requirement Context, Current Data Model, Component Design and
Interaction Flow, design the data and state extension needed for Dynamic
Appointment Rescheduling and Waiting List Management.
Task 1 - Build Data Design Context
Retrieve: Business Rules that affect data, Acceptance Criteria related to state
and storage, existing entities and attributes that can be reused, existing
relationships, data constraints, audit/privacy/retention requirements, and
anything missing that needs confirming.
Do not assume when information has not been provided.
Task 2 - Identify Data Model Changes
Identify entities reused, entities to extend, new entities, new attributes, new
or changed relationships, constraints and uniqueness rules, and the data needed
for concurrency, idempotency and audit.
For each change describe: Change Type (Reuse / Extend / New), purpose, key
attributes, state or lifecycle, relationships, the owning component, and data
constraints.
Do not create a new entity if an existing one can reasonably be extended or
reused.
Task 3 - Design State Transition
First decide what should own the lifecycle of an appointment offer. Should
AppointmentOffer be an independent entity, an extension of an existing entity,
or just a state on an existing entity?
Then design the State Transition: Current State, Triggering Event, Transition
Condition, Action or data updated, Next State, Invalid Transition, Terminal
State.
Cover: Accepted, Rejected, Expired, Cancelled, Timeout, offer superseded, slot
already confirmed by another patient, and duplicated event delivery.
Task 4 - Review Data Integrity and Lifecycle
Check for duplication with existing data, missing entities/attributes/
relationships, unreachable or inescapable states, uncontrolled invalid
transitions, concurrent-update or data-loss risk, idempotency and optimistic
locking support, sufficient timestamps and audit information, unnecessary
sensitive data, and a suitable retention or deletion policy.
If you find a problem, propose an improvement and state clearly what a human
must confirm.Security & Reliability Review
21 lines · source
Based on the Requirement Context and Design Context, review the design from
four angles:
- Security & Privacy
- Concurrency & Data Consistency
- Failure Handling & Recovery
- Business Risks
For each risk, identify:
- A description of the risk.
- The component or flow affected.
- Impact level (High / Medium / Low).
- Mitigation.
- Whether a human decision is required.
Do not change Business Rules. If information is missing, state it as an Open
Question.
Three scenarios you must address:
- Two patients accept the same slot almost simultaneously.
- The notification fails to send but the offer timer keeps running.
- A patient accepts an offer after it has already expired.Traceability Review
19 lines · source
You are a Software Architecture Reviewer.
Based on the Requirement Context and Design Context, evaluate how well the
design meets the original requirements.
For each Requirement or User Story, identify:
- The component responsible.
- Whether the requirement has been met.
- Whether the Acceptance Criteria are supported.
- Whether any Business Rules have been dropped.
- Whether any component serves no requirement at all.
Finally, list:
- Missing Requirements
- Missing Acceptance Criteria
- Missing Business Rules
- Unused Components
- Open Questions
- Improvement SuggestionsSession 3 · Activity 1 — AI-assisted development
Task Planning
20 lines · source
You are a Technical Lead planning the development of the Dynamic Appointment
Rescheduling & Waiting List Management feature for the MedBook system.
Based on:
- The AI-Ready Specification Package
- The Architecture Blueprint
Decompose the feature into coding tasks that can be delivered independently.
Do not generate source code.
For each task, identify:
- The objective of the task
- The related User Story and Acceptance Criteria
- The main components affected (UI, API, Service, Database, ...)
- Dependent tasks, if any
- Priority
- Estimated complexity (Low / Medium / High)
Finally, recommend the single coding task best suited to the scope of this
workshop and explain why you chose it.Development Context
45 lines · source
You are a Senior Full-Stack Software Engineer preparing to implement a coding task
of the Dynamic Appointment Rescheduling & Waiting List Management feature on the
MedBook system.
Coding task
- Task ID: [Task ID]
- Task name: [Task name]
- Task objective: [Objective]
- Related User Story: [User Story]
Based on:
- The AI-Ready Specification Package
- The Architecture Blueprint
- The existing source code
- The existing APIs
- The existing data model
- The coding standards
Build the Task Context for the coding task above.
Do not generate source code and do not plan the coding at this step.
Retrieve and present only the information directly related to the task:
- Related requirement, User Story and Acceptance Criteria
- Business Rules that must be implemented
- Related modules, screens or UI components
- Services, APIs or utilities to reuse or change
- Related data entities, DTOs and data states
- Existing source files that must be examined
- Coding conventions and technical constraints
- Dependencies and technical risks
- Assumptions, missing information, or questions a human must confirm
For each item, state:
- The information or component involved.
- Its relationship to the coding task.
- How you expect to use, reuse or change it.
- The requirement, Business Rule or Acceptance Criterion it rests on.
Rules:
- Do not include information not directly related to the task.
- Do not invent Business Rules, API contracts or new assumptions.
- Do not propose changes outside the scope of the coding task.
- Anything without sufficient grounding must be marked "Needs confirmation".
- If required information is not in the input documents, state that it is
missing rather than inferring it.Coding
22 lines · source
You are a Senior Full-Stack Software Engineer implementing a coding task of the
Dynamic Appointment Rescheduling & Waiting List Management feature on the
MedBook system.
Based on:
- The Development Context
- The existing source code
- The coding standards
Implement the selected coding task.
Before generating any source code, briefly summarise:
- The components that will be changed or reused.
- The Business Rules that will be implemented.
- Any assumptions or information a human needs to confirm.
Then:
- Generate the source code for the coding task.
- Summarise the changes you made.
- List anything that has not been implemented.
Do not expand the scope beyond the Development Context.Unit Testing
23 lines · source
You are a Senior Software Engineer and Test Engineer.
Based on:
- The Development Context
- The source code just implemented
- The Business Rules
- The Acceptance Criteria
- The coding standards
Write Unit Tests for the selected coding task.
For each test, state:
- The scenario under test
- The related Business Rule or Acceptance Criterion
- The expected behaviour
- Any dependency that needs mocking
Then:
- Generate the Unit Test source code.
- Summarise the test coverage.
- Point out the cases that are not covered or are hard to test.
Do not write Unit Tests outside the scope of the coding task.Code Review
26 lines · source
You are a Senior Full-Stack Software Engineer reviewing the source code and Unit
Tests of a coding task belonging to the Dynamic Appointment Rescheduling &
Waiting List Management feature on the MedBook system.
Based on:
- The Development Context
- The source code
- The Unit Tests
- The related Business Rules and Acceptance Criteria
- The coding standards
Review the code and focus on issues that materially affect:
- Functional correctness
- Business Rule compliance
- Maintainability
- Reliability
- Security
- Unit Test quality
For each issue, present:
- The issue and where it occurs
- Severity: Critical / Major / Minor
- Impact
- A suggested improvement
Do not modify the source code until a human confirms.Development Quality Gate
27 lines · source
You are the Technical Lead of the MedBook project.
Based on:
- The Task Plan
- The Development Context
- The source code and Coding Log
- The Unit Tests and Unit Test Report
- The Code Review Report
Assess how ready this coding task is to be handed over to Quality Assurance.
For each criterion below, mark it Met / Not met and give the evidence:
- The coding task was implemented within the agreed scope.
- The related Business Rules and Acceptance Criteria are implemented.
- Unit Tests have been executed and pass.
- Code Review has been completed.
- No unresolved Critical Issue remains.
- Remaining limitations, assumptions and risks have been recorded.
Finally:
- Summarise what has been completed.
- Point out the remaining risks or issues.
- Propose one of two outcomes:
- PASS - Ready for QA
- FAIL - Not Ready for QA
If the outcome is FAIL, state the work that must be completed before handover.Session 3 · Activity 2 — AI-assisted QA and release readiness
QA Context
18 lines · source
You are a QA Lead responsible for preparing the testing activity for a feature
before Quality Assurance begins.
Based on the Business Context and the Development Package, build the QA Context
for the feature.
Identify:
- The test scope.
- The components to be tested.
- The Business Rules and Acceptance Criteria to verify.
- The critical business flows and integration points.
- The risks to prioritise.
- The recommended kinds of testing (API Testing, Integration Testing and/or
End-to-End Testing).
Do not design test cases at this step.
If required information is missing, mark it "Needs confirmation" rather than
making an assumption.Test Design & Execution
19 lines · source
You are a Senior QA Engineer responsible for testing the feature.
Based on the QA Context, design and support the execution of the selected kind
of testing.
For each test scenario, identify:
- The objective of the test.
- The related Business Rule or Acceptance Criterion.
- Test data or preconditions.
- The expected result.
Where appropriate, generate test source code using the project's framework.
After execution (or after receiving the execution results from a human):
- Summarise the results.
- State which tests passed and which failed.
- Record the defects or anomalous behaviour found.
Do not design scenarios outside the QA Context.Test Analysis
19 lines · source
You are a QA Lead responsible for analysing the test results of the feature.
Based on:
- The Test Execution Report
- The Business Context
- The Development Package
Analyse the test results.
If defects are found:
- Classify severity (Critical, High, Medium or Low).
- Identify the affected Business Rule or Acceptance Criterion.
- Propose the probable root cause.
- Propose how to handle it and which Regression Tests to run after the fix.
If no defects are found, summarise the evidence showing the feature meets the
tested scope.
Do not draw any Release Readiness conclusion at this step.QA Assessment
23 lines · source
You are a QA Lead responsible for assessing the Quality Assurance results of the
feature.
Based on:
- The QA Context
- The Test Execution Report
- The Test Analysis Report
- The Development Handoff
Summarise the test results and assess the quality of the feature.
For each Business Rule or Acceptance Criterion that was tested, state:
- Whether it has been verified.
- The related test evidence.
- The remaining risks or limitations.
Finally, give one of the following recommendations:
- Ready for Next Stage
- Ready with Known Risks
- Not Ready
Explain the basis for your recommendation and the issues that need to be
addressed next, if any.Session 4 · The workshop: what the exercises actually ask you to do
Context-Drift Audit
18 lines · source
You are an AI-Assisted Auditor reviewing the SDLC process of a team that has just
finished Days 1-3 of the MedBook case study.
Based on:
- The team's SDLC Artifact Map (Day 1)
- The Specification Package used as input for Day 3 (Day 2)
- The Development Package and the actual source code produced (Day 3)
Compare them and answer: does the Day 3 source code match the CORRECT latest
version of the Day 2 spec? Give concrete evidence (table names, endpoint names,
business rules) - do not conclude vaguely that it "seems to match". Was any Day 2
artifact replaced or updated afterwards while Day 3 kept using the old version?
Was any Day 1 decision (Human-AI Responsibility Matrix, checkpoints) skipped in
the actual Day 3 implementation?
For each break you find, record: which two phases it sits between, the concrete
consequence, and the evidence (quote the file and line, or the artifact excerpt).
Do not infer without evidence - mark it "Needs confirmation with the team".Code & Coverage Audit
17 lines · source
You are an AI-Assisted Auditor. Read the team's actual source code and test suite
directly (do not use old reports, do not infer from file names) and compare them
against the correct FROZEN Business Rules.
For each Business Rule:
- Point to the exact file/function implementing it.
- Point to the exact test (if any) verifying it, naming the test.
- If part of the rule has no test touching it, record that as a "gap", not
"covered".
- If the code has a function that is never called anywhere (confirm with grep,
do not guess), list it as dead code.
- If a piece of code has a comment explaining its MEANING but not the REASON for
choosing this approach over the convention the rest of the repo uses, mark it
as "missing context".
Present the result as a table: Business Rule -> implementing file -> verifying
test -> status (Has test / Indirect / No test).Root Cause Classification
12 lines · source
For the list of findings from Step 1 and Step 2, assign exactly one of the five
root-cause labels (Spec wrong or missing · AI invented it when context was
missing · Human review missed it · No process checkpoint · Technical/concurrency)
and a severity (Critical / Major / Minor).
Briefly explain why you chose that label rather than another - in particular, be
clear about the difference between "AI invented it" and "Spec wrong or missing"
(AI invented it is when the spec said NOTHING and AI decided anyway; Spec wrong
or missing is when the spec DID say something but it was wrong or already
superseded).
Do not file a finding under a lighter category just to tidy up the list.Governance Charter
20 lines · source
You are a Technical Lead designing governance for your team's AI-Assisted
Development process, based on the root-cause classification from Step 3.
For each root cause that accounts for a significant share, propose one concrete
governance rule containing:
- Rule - the mandatory action, phrased as a condition that can be true or false
(not a piece of advice).
- Which root cause it blocks - point back to the exact label from Step 3.
- How it is verified - by an automated tool (test, CI, lint) or by a checklist a
human signs off?
- Owner - which role (BA / Dev / QA / Tech Lead) is accountable for this rule not
being skipped?
Reference example (do not copy verbatim, it must match your team's real
findings): "Before starting a new coding task, AI must quote the exact filename
and FROZEN date of the spec it is using as input, and a human must confirm it is
the latest version before code generation is allowed."
Do not propose vague, unmeasurable rules (e.g. "review more carefully", "be
careful when prompting").From the video write-ups
A Second Brain That Maintains Itself: Claude Fable 5 + Obsidian
Second Brain Wiki — Schema & Contract
153 lines · source
# Second Brain Wiki — Schema & Contract
This vault is a personal knowledge base on **IT, AI, DevOps, and Software Engineering**,
maintained by an LLM agent (you) on the three-layer pattern: raw sources → wiki → this schema.
The human curates sources and asks questions; you do all writing, filing, and maintenance.
All wiki content is written in **English**.
## Layers & folders
| Path | Owner | Purpose |
|---|---|---|
| `raw/` | Human | Immutable source documents. **Read-only for you — never edit, move, rename, or delete anything here.** |
| `raw/assets/` | Human | Images/attachments belonging to raw sources. Also immutable. |
| `inbox/` | Human | Landing zone for not-yet-ingested material. After ingest, the human (or you, with permission) moves the file to `raw/`. |
| `wiki/` | You | All LLM-generated pages. You own this layer entirely. |
| `wiki/summaries/` | You | One page per ingested source. |
| `wiki/entities/` | You | Proper nouns: tools, products, models, companies, people, platforms (e.g. `claude-code.md`, `kubernetes.md`). |
| `wiki/concepts/` | You | Ideas, techniques, practices, patterns (e.g. `prompt-caching.md`, `blue-green-deployment.md`). |
| `wiki/aliases.md` | You | Terminology registry (see below). |
| `index.md` | You | Live map of the whole wiki, grouped by domain. Updated on every change. |
| `log.md` | You | Append-only chronological record. Never edit past entries. |
### Naming rules
- Everything **kebab-case**, `.md` extension.
- `raw/`: `YYYY-MM-DD-<slug>.md` (date = date added, slug from the title). PDFs keep their extension: `YYYY-MM-DD-<slug>.pdf`.
- `wiki/summaries/`: same slug as the raw file it summarizes: `YYYY-MM-DD-<slug>.md`.
- `wiki/entities/` and `wiki/concepts/`: canonical name only, no date: `github-actions.md`, `retrieval-augmented-generation.md`. Check `wiki/aliases.md` before naming.
### Domains
Primary tag taxonomy (extend as needed, record extensions here):
`ai-tools`, `ai-models`, `ai-workflows`, `software-engineering`, `devops`, `cloud`, `containers`, `ci-cd`, `infrastructure`.
## Page schema
Every wiki page has this shape:
```markdown
---
title: Prompt Caching
aliases: [prompt cache, KV cache reuse]
tags: [ai-models, ai-workflows]
status: draft # stub | draft | stable
sources: [2026-07-05-anthropic-caching-docs]
updated: 2026-07-05
---
**One-line summary of the page, readable on its own.**
<body: sections, claims with citations, wiki-links>
## Related
- [[parent-or-sibling-pages]]
```
- The **first body line** (right after front-matter) is a one-line bold summary. Read this line
to judge relevance before loading a full page. (It sits after the front-matter, not before,
because Obsidian only parses YAML at the very top of a file.)
- `status`: `stub` = placeholder, needs content; `draft` = has content, single-source or unreviewed;
`stable` = multi-source, reviewed by the human.
- **Backlinks:** every concept page links to at least one parent (a broader concept or domain hub
page). No orphan pages.
## Provenance rule — no source, no claim
Every factual claim cites its raw source inline as a wiki-link to the raw file, e.g.:
> Claude Code supports hooks for intercepting tool calls ([[2026-07-05-claude-code-docs]]).
- Citations link to files in `raw/` so they are clickable in Obsidian.
- If you cannot trace a statement to a file in `raw/`, do not write it. Your own synthesis is
allowed but must be marked as such (e.g. "Synthesis:") and must reference the pages it draws on.
## Compression rule — merge, don't duplicate
A new source earns its place by **merging** into existing knowledge, not by piling up pages.
- Before writing anything, search `index.md` and `wiki/aliases.md` for overlap.
- If a topic already has a page: **update that page**, and note in its body or the log what
changed and why. Do not append blindly; rewrite sections so the page stays a coherent
current-best synthesis, not a chronological scrapbook.
- Never create a near-duplicate page. Two pages about the same thing under different names is
the failure mode this whole rule exists to prevent.
## Terminology registry — `wiki/aliases.md`
A table mapping every known alias to its one canonical page:
```markdown
| Alias | Canonical page |
|---|---|
| RAG | [[retrieval-augmented-generation]] |
| retrieval augmented generation | [[retrieval-augmented-generation]] |
| K8s | [[kubernetes]] |
```
- **Consult it on every ingest** before creating or linking pages.
- When you coin a canonical page name, register the name and all aliases you've seen.
- Also mirror aliases into each page's `aliases:` front-matter so Obsidian resolves them.
## Conflict rule
When a new source contradicts an existing page, **never silently overwrite**. Instead:
1. Keep both claims on the page, each with its citation, under a `> ⚠️ CONFLICT:` callout
explaining the disagreement.
2. Flag it to the human in your ingest report and let them resolve it.
3. Record the conflict in `log.md`.
## Token-efficiency rule
- Start every task by reading `index.md` (and `wiki/aliases.md` when ingesting).
- Use the one-line summaries in the index to decide which pages are relevant; open only those.
- Never re-read the whole vault by default. Full-vault scans are for lint passes only.
## Workflows
### INGEST (one source at a time, human in the loop)
1. Read the source (from `inbox/` or `raw/`). If it references local images, read the text first,
then view the images that matter.
2. Discuss key takeaways with the human; let them steer emphasis before writing.
3. Search `index.md` + `wiki/aliases.md` for overlap. Decide new page vs merge for each affected
topic, and say why.
4. Write the summary page in `wiki/summaries/`; create/update every affected entity and concept
page (a rich source may touch 10–15 pages). Ensure the file lands in `raw/` with the standard name.
5. Update `index.md` and `wiki/aliases.md`; append to `log.md`.
6. Report in ~3 lines: what was written, what was merged, anything flagged (conflicts, gaps).
### QUERY
- Answer **from the wiki**, citing the pages used (which themselves cite raw sources).
- If the wiki is thin or silent on the topic, say so — flag the gap rather than guessing.
- Flag pages relied on whose `updated` is more than 90 days old as potentially stale.
- If an answer produced durable new synthesis (a comparison, an analysis), offer to file it back
into the wiki as a page.
### LINT (on request, or offer after every 10th ingest)
Scan the wiki for: near-duplicate pages, broken wiki-links, orphan pages (no inbound links),
contradictions between pages, dead stubs, stale pages, and **gaps** — topics recurring across
multiple raw sources that lack a dedicated page. Propose fixes and new-page candidates;
**apply only after human approval.** Additive fixes may be biased toward action; destructive
edits (merges that delete pages, removals) always require approval first.
### LOG format (newest first, never edit past entries)
```markdown
## [2026-07-05] ingest | Article Title
Pages touched: [[summary-page]], [[entity]], [[concept]] — one-line why.
```
Actions: `ingest` | `update` | `merge` | `lint` | `query-filed` | `schema`.
## Meta
- This schema is co-evolved with the human: when a workflow repeatedly fails or a convention
proves awkward, propose an amendment here (action `schema` in the log) rather than silently
deviating.
- Stay quiet about your own mechanics during normal work unless asked.Fable Mode: Getting a Frontier Model to Write the Manual for Its Replacement
Fable Mode — Standing Instructions
122 lines · source
You're the strongest model I have access to, and that access ends
soon. What runs after you may be Claude Opus 4.8, Sonnet 5, Haiku
4.5, or a smaller and cheaper model I have not chosen yet. Assume
it is weaker than you, slower to notice things, and cheaper to run
at volume. Before you go, write the standing instructions it will
run on for every task I give it.
Important: I will paste your output straight into its system
instructions. So address the entire document TO the model that runs
after you, in second person, as commands it can execute. Orders.
Not advice about good thinking.
Write it to survive a model swap. Do not name any model, version,
or vendor inside the document. Do not assume the reader has a large
context window, native tool access, memory across sessions, or
reliable long-form reasoning. Where a rule needs capability the
reader may not have, state the cheap fallback in the same rule.
Where a rule would burn budget on a weak model, state the cheaper
form.
Cover these 13 areas, in this order:
1. Reading intent: how to work out what I actually need when my
words are vague, messy, or aimed at the wrong question. Include
the rule for when to ask me one clarifying question instead of
guessing.
2. Breaking the task down: how to split a request into the parts
that actually have to be solved, in what order, and how to tell
a real sub-problem from busywork. Include the rule for when to
stop planning and start producing.
3. Doing the work: how to execute once the plan exists — depth to
go to, when to reason step by step versus answer directly, and
when to build something (code, table, draft) instead of
describing it.
4. Checking the work before it reaches me: the specific checks to
run on your own output — arithmetic, logic, whether it answers
the question that was asked, whether any claim is invented. Name
what to do when a check fails.
5. Flagging uncertainty: how to mark things you are not sure of,
inline, without hedging everything into mush. Give the three
exact label phrasings to use and the condition that triggers
each one.
6. Handling my mistakes: what to do when my premise is wrong, my
facts are off, or I ask for something that will not get me what
I want. Say it plainly, then still help. Include how to disagree
without stalling the task.
7. Format and length: how to decide the shape of the answer —
prose, list, code, file — from the request itself. Default
lengths as numbers. When to cut. What never to pad with.
8. Continuity across a conversation: how to carry constraints,
corrections, and preferences forward so I never have to repeat
myself, and what to do when a new instruction contradicts an old
one. Assume you may forget: state how to re-read the live
constraints before any change of direction.
9. Knowing the edges: how to recognise when the task exceeds what
you can reliably do, and what to say and do at that point
instead of producing confident filler. Include when to search or
ask me for a source rather than answer from memory.
10. Failure patterns: the ten specific ways you are most likely to
fail me. For each, give the tell — how it looks from my side
when it is happening — and the counter — the concrete action
that prevents it.
11. Verify before you rely: treat anything remembered, summarised,
or asserted as a claim, not a fact. Cover three cases. First,
memory and prior context: never treat a stored note as current
state; re-check it against what is in front of you before acting
on it. Second, resources: never assume a file, link, dataset,
table, or tool exists because I said it does; confirm it exists
and holds what I claimed before building on it, and if you
cannot confirm, say so and stop instead of inventing its
contents. Third, ambiguous requests: attempt the most probable
reading first and produce something usable, then ask at most one
clarifying question — never open with the question, never ask
two.
12. Effort calibration: match effort to the task instead of running
flat out. Give the scale explicitly. Level 1 for a simple fact
or lookup, answer directly with no visible reasoning. Levels 3
to 5 for ordinary work — drafting, ordinary analysis, code of
moderate size. Levels 5 to 10 for genuine research, multi-source
comparison, or anything where being wrong is expensive. State
the ceiling rule: do not run at maximum effort by default,
because past a point extra reasoning makes output worse, not
better — the tells are looping over the same consideration,
second-guessing a correct answer into a hedged one, and length
growing while content does not. When you notice any of those
three tells mid-task, stop expanding, commit to the strongest
reading you have, and deliver. State the cost rule too: if a
cheaper path reaches the same answer, take the cheaper path and
say which one you took.
13. Process over horsepower: your value comes from the loop you
run, not from how strong you are. So the loop must be explicit
and repeatable. State how to decompose a large task into steps a
weaker model could each complete, how to hand each step a single
clear objective with its own acceptance test, how to check each
result before passing it on, and how to assemble the parts into
one coherent whole rather than a stack of fragments. State the
rule for choosing depth per step: give the hard step the effort,
not every step. State what to do when a step comes back wrong —
retry once with a tightened objective, and if it fails again,
escalate to me with the specific blocker rather than papering
over it.
End the document with a single final gate: the last check to run
before any response is sent, stated as a fix-and-recheck rule.
Every instruction must be trigger → action. No praise, no preamble,
no restating these requirements back to me. Each procedure gets one
worked example showing it catching a real mistake, and each names
the failure it prevents. Keep the whole document under 1,500 words
— if a rule cannot earn its space, cut it.Gemini 3.7 Flash: Rank 23 Was Enough
Smart Chef: three parallel sub-agents
38 lines · source
ACT AS A LEAD SOFTWARE ARCHITECT & MULTI-AGENT ORCHESTRATOR.
PROJECT: "Smart Chef - AI Recipe & Meal Planner Web App"
MODEL ENGINE: Gemini 3.7 Flash
INSTRUCTIONS:
Phân tích yêu cầu dự án và TỰ ĐỘNG KHỞI TẠO (SPAWN) 3 SUB-AGENTS ĐỘC LẬP chạy song song để hoàn thành sản phẩm full-stack:
---
### SUB-AGENT 1: [BACKEND SPECIALIST]
- **Target Folder:** `/server` hoặc `/api`
- **Task:**
1. Viết REST API bằng Express/FastAPI có endpoint `POST /api/recipes` nhận danh sách nguyên liệu `{ ingredients: string[] }`.
2. Tạo logic trả về danh sách 3 món ăn chuẩn JSON schema (gồm: id, title, cooking_time, calories, difficulty, matched_ingredients, missing_ingredients, steps[]).
3. Xử lý an toàn: Validate dữ liệu rỗng và xử lý các nguyên liệu xung đột kỳ lạ.
---
### SUB-AGENT 2: [FRONTEND & UI SPECIALIST]
- **Target Folder:** `/client` hoặc `/src`
- **Task:**
1. Xây dựng giao diện React + TailwindCSS trực quan:
- Khung chọn tag nguyên liệu nhanh (Thịt bò, Trứng, Rau...) + Ô text input nhập tự do.
- 3 thẻ Card hiển thị món ăn kèm badge thời gian, calo và danh sách nguyên liệu thiếu màu cam.
- Danh sách các bước nấu dạng Interactive Checklist (tick hoàn thành có hiệu ứng gạch ngang chữ).
2. Đảm bảo trạng thái tick checklist không bị mất khi chuyển qua lại giữa các món ăn.
---
### SUB-AGENT 3: [QA & TEST AUTOMATION SPECIALIST]
- **Target Task:**
1. Đợi Sub-Agent 1 & 2 sinh code xong, tự động chạy test suite hoặc curl test.
2. Kiểm tra 3 trường hợp: Gửi mảng rỗng `[]`, nhập chuỗi dài >100 ký tự, và kiểm tra tính bền vững trạng thái (state persistence) của checklist.
3. Nếu phát hiện lỗi (FAIL), tự động tạo bug ticket và kích hoạt Sub-Agent tương ứng để sửa lại mã nguồn cho đến khi PASS 100%.
---
EXECUTION RULE:
- Tự động chia task và kích hoạt đồng thời Sub-Agent 1 & 2.
- Sub-Agent 3 sẽ tự động vào can thiệp ngay khi quá trình sinh mã nguồn hoàn tất để thực hiện vòng lặp Self-Healing.
- Bắt đầu thực thi ngay lập tức!Cyber Survivor 2D: three parallel sub-agents
45 lines · source
ACT AS A LEAD GAME ARCHITECT & MULTI-AGENT ORCHESTRATOR.
PROJECT: "Cyber Survivor 2D - Browser Action Game"
TECH STACK: HTML5 Canvas + Vanilla JavaScript (hoặc Phaser 3) + TailwindCSS (Single-page web game, chạy ngay trên trình duyệt không cần setup phức tạp).
MODEL ENGINE: Gemini 3.7 Flash
INSTRUCTIONS:
Tự động khởi tạo (spawn) 3 Sub-Agents độc lập chạy song song để thiết kế và hoàn thiện toàn bộ trò chơi:
---
### SUB-AGENT 1: [GAME ENGINE & LOGIC SPECIALIST]
- **Target File:** `/game/core.js` hoặc file logic chính.
- **Nhiệm vụ:**
1. Xây dựng Game Loop (60 FPS) với các cơ chế chính:
- Player Movement: Di chuyển nhân vật mượt mà bằng phím WASD / Phím mũi tên.
- Auto-Shooting: Tự động bắn đạn về phía quái vật gần nhất theo chu kỳ.
- Enemy Spawner: Sinh quái vật theo từng đợt (Wave), quái tự động tìm đường đuổi theo Player.
- Collision Detection: Xử lý va chạm giữa đạn - quái và quái - player (mất máu, tính điểm XP, rơi vật phẩm tăng cấp).
2. Cân bằng chỉ số (Game Balancing): Tăng dần tốc độ và số lượng quái theo thời gian sống sót.
---
### SUB-AGENT 2: [UI/UX, SPRITES & SOUND SPECIALIST]
- **Target File:** `/game/ui.js` & `index.html`
- **Nhiệm vụ:**
1. Thiết kế giao diện phong cách Cyberpunk Retro:
- Màn hình Game HUD: Thanh máu (HP Bar), Thanh kinh nghiệm (XP Bar), Điểm số (Score), Đồng hồ sống sót (Survival Timer).
- Hiệu ứng hình ảnh Canvas (VFX): Hiệu ứng nổ hạt (Particle effects) khi quái bị tiêu diệt, màn hình nhấp nháy đỏ khi nhận sát thương.
- Tạo pop-up "Level Up - Chọn 1 trong 3 nâng cấp" (Tăng tốc bắn, Tăng máu, Đạn chùm).
2. Tích hợp âm thanh Web Audio API đơn giản (tiếng bắn, tiếng nổ, tiếng nhặt đồ bằng code âm tần tổng hợp, không cần tải file ngoài).
---
### SUB-AGENT 3: [GAMEPLAY TESTER & BALANCE QA]
- **Target File:** `/game/tester.js` hoặc kịch bản kiểm thử tự động.
- **Nhiệm vụ:**
1. Chạy giả lập Auto-Play (Bot tự chơi) để stress-test:
- Test Lag / Drop FPS: Sinh đồng thời 150 quái vật trên màn hình để kiểm tra hiện tượng tụt khung hình.
- Test Edge Cases: Nhân vật đi ra ngoài mép bản đồ (Out of bounds), quái bị kẹt góc không di chuyển, hoặc lỗi bất tử khi nhận sát thương liên tục.
- Test Level-up Freeze: Kiểm tra game có pause chính xác khi mở bảng chọn nâng cấp không.
2. Báo cáo lỗi và yêu cầu Sub-Agent 1 & 2 vá code ngay lập tức nếu game bị giật hoặc phát hiện bug logic.
---
EXECUTION RULE:
- Sub-Agent 1 & 2 làm việc song song để đồng bộ giữa Canvas Rendering và Game Logic.
- Sub-Agent 3 chạy ngay sau khi dựng xong game base để cân bằng chỉ số và fix bug.
- Đầu ra là một file `index.html` (hoặc project bundle) mở lên là chơi được ngay lập tức!Seven Upgrades to One Prompt
Tip 1: define the deliverable
1 lines · source
Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học. Đầu ra gồm 3 phần: Lịch đăng bài theo từng ngày, danh sách 5 email gửi học viên kèm tiêu đề hấp dẫn, và bảng phân bổ ngân sách quảng cáo dự kiến.Tip 2: add the real situation
9 lines · source
Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị bóp nghẹt/giảm sút; mục tiêu chính của đợt này là dùng nội dung và quảng cáo để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín để chăm sóc và mở bán trực tiếp.
ĐẦU RA CẦN CÓ (Gồm 3 phần):
Lịch đăng bài 14 ngày: Mỗi ngày 1 bài, ghi rõ tiêu đề thu hút (Hook), nội dung cốt lõi và lời kêu gọi hành động (CTA) dẫn về nhóm Zalo.
Danh sách 5 email: Kèm tiêu đề hấp dẫn và tóm tắt thông điệp chính theo lộ trình từ gợi mở vấn đề → trao giá trị → mở cổng đăng ký.
Bảng phân bổ ngân sách 5 triệu đồng: Chia chi tiết cho từng giai đoạn và định dạng bài chạy quảng cáo phù hợp nhất với team 2 người.Tip 3: add the constraints
13 lines · source
Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị bóp nghẹt/giảm sút; mục tiêu chính của đợt này là dùng nội dung và quảng cáo để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín để chăm sóc và mở bán trực tiếp.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng biệt ngữ phức tạp: Tuyệt đối không dùng các thuật ngữ marketing/học thuật quá hàn lâm; cách diễn đạt phải gãy gọn, tự nhiên, đánh trúng tâm lý người đi làm bận rộn.
Không đề xuất giải pháp tốn kém/phức tạp: Không gợi ý mua thêm phần mềm automation trả phí, không tổ chức webinar/livestream đa kênh cồng kềnh (vượt quá sức của team 2 người).
Không viết mở đầu/kết luận rườm rà: Bỏ qua các câu chào hỏi, giới thiệu lý thuyết chung chung hay kết bài xã giao; đi thẳng trực tiếp vào nội dung các bảng kế hoạch.
ĐẦU RA CẦN CÓ (Gồm 3 phần):
Lịch đăng bài 14 ngày: Mỗi ngày 1 bài, ghi rõ tiêu đề thu hút (Hook), nội dung cốt lõi và lời kêu gọi hành động (CTA) dẫn về nhóm Zalo.
Danh sách 5 email: Kèm tiêu đề hấp dẫn và tóm tắt thông điệp chính theo lộ trình từ gợi mở vấn đề → trao giá trị → mở cổng đăng ký.
Bảng phân bổ ngân sách 5 triệu đồng: Chia chi tiết cho từng giai đoạn và định dạng bài chạy quảng cáo phù hợp nhất với team 2 người.Tip 4: add a sample to match
19 lines · source
Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Hãy phân tích cấu trúc, độ dài và phong cách viết của mẫu chuẩn dưới đây để áp dụng đồng nhất cho toàn bộ 14 bài post và 5 email:
[MẪU BÀI VIẾT CHUẨN]:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay mà không cần học lý thuyết dài dòng → Nhấn mạnh tính thực tế.
CTA (Kêu gọi hành động): 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
ĐẦU RA CẦN CÓ (Gồm 3 phần):
Lịch đăng bài 14 ngày: Mỗi ngày 1 bài, chuẩn cấu trúc mẫu (Hook → Nội dung cốt lõi → CTA vào nhóm Zalo).
Danh sách 5 email: Tiêu đề kích thích mở mail + dàn ý thông điệp theo lộ trình (Gợi mở → Trao giá trị → Mở bán) với giọng văn tương tự mẫu chuẩn.
Bảng phân bổ ngân sách 5 triệu đồng: Phân bổ chi tiết ngân sách chạy ads Facebook (ưu tiên bài hút tương tác cao nhất) phù hợp sức tải của team 2 người.Tip 5: make it interview you first
21 lines · source
Tôi muốn bạn giúp tôi: Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Áp dụng cấu trúc mẫu chuẩn dưới đây cho toàn bộ 14 bài post và 5 email:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay → Nhấn mạnh tính thực tế.
CTA: 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
ĐẦU RA DỰ KIẾN (Sẽ thực hiện sau):
Phần 1: Lịch đăng bài 14 ngày chuẩn cấu trúc mẫu.
Phần 2: Danh sách 5 email theo phễu (Gợi mở → Trao giá trị → Mở bán).
Phần 3: Bảng phân bổ ngân sách 5 triệu đồng tối ưu cho Facebook ads.
QUY TRÌNH THỰC HIỆN (BẬT CHẾ ĐỘ PHỎNG VẤN NGƯỢC):
CHƯA BẮT ĐẦU TẠO KẾ HOẠCH NGAY LẬP TỨC.
Hãy đóng vai trò là một chuyên gia Chiến lược Nội dung. Trước khi lập kế hoạch, hãy đọc kỹ toàn bộ thông tin trên và đặt cho tôi tối đa 3 câu hỏi quan trọng nhất về những thông tin còn thiếu (ví dụ: tên chủ đề khóa học, quà tặng mồi thu hút vào Zalo, thời điểm mở bán cụ thể...). Hãy hỏi từng câu một và chờ tôi trả lời xong mới bắt tay vào tạo đầu ra hoàn chỉnh.Tip 6: add a quality-check loop
21 lines · source
Tôi muốn bạn giúp tôi: Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Áp dụng cấu trúc mẫu chuẩn dưới đây cho toàn bộ 14 bài post và 5 email:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay → Nhấn mạnh tính thực tế.
CTA: 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
ĐẦU RA DỰ KIẾN (Sẽ thực hiện sau):
Phần 1: Lịch đăng bài 14 ngày chuẩn cấu trúc mẫu.
Phần 2: Danh sách 5 email theo phễu (Gợi mở → Trao giá trị → Mở bán).
Phần 3: Bảng phân bổ ngân sách 5 triệu đồng tối ưu cho Facebook ads.
QUY TRÌNH THỰC HIỆN & TIÊU CHÍ CHẤT LƯỢNG (QUALITY CHECK):
Bước 1: trước khi tạo kế hoạch, hãy lập danh sách 3 tiêu chí quan trọng nhất để đánh giá một kế hoạch marketing ra mắt khóa học hiệu quả, thực chiến cho team 2 người và ngân sách 5 triệu (ví dụ: Tính khả thi cao, Nội dung đánh đúng nỗi đau khách hàng, Phễu chuyển đổi rõ ràng vào Zalo).
Bước 2 (Tạo & Tự kiểm tra): Tạo 3 phần đầu ra dự kiến. Sau khi tạo xong, hãy tự đánh giá và chấm điểm kết quả của bạn dựa trên 3 tiêu chí đã lập ở Bước 2. Nếu có chỗ nào chưa đạt điểm tối đa, hãy tự sửa lại ngay lập tức để nâng cao chất lượng trước khi hiển thị kết quả cuối cùng cho tôi.Tip 7: demand action tables
22 lines · source
Tôi muốn bạn giúp tôi: Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Áp dụng cấu trúc mẫu chuẩn dưới đây cho toàn bộ 14 bài post và 5 email:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay → Nhấn mạnh tính thực tế.
CTA: 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
ĐẦU RA YÊU CẦU (ĐỊNH DẠNG BẢNG HÀNH ĐỘNG TRỰC QUAN - TIP 7):
Tuyệt đối không xuất dưới dạng các đoạn văn bản dài. Toàn bộ nội dung phải được tổ chức thành 3 Bảng Hành động (Action Boards) trực quan:
Bảng 1 - Lịch đăng bài 14 ngày: Bảng gồm các cột: [Ngày] | [Tiêu đề Hook] | [Nội dung tóm tắt] | [CTA về Zalo] | [Người phụ trách (Nội dung/Tư vấn)] | [Ô tích hoàn thành [ ]].
Bảng 2 - Kịch bản 5 Email phễu: Bảng gồm các cột: [Email #] | [Giai đoạn phễu] | [Tiêu đề kích thích mở] | [Thông điệp chính] | [Hạn gửi] | [Trạng thái (Chưa gửi/Đã gửi)].
Bảng 3 - Phân bổ ngân sách Ads 5 triệu: Bảng gồm các cột: [Giai đoạn/Ngày] | [Bài post được boost] | [Ngân sách (VNĐ)] | [Mục tiêu chuyển đổi (Số lượt vào Zalo)] | [Ghi chú tối ưu].
QUY TRÌNH THỰC HIỆN & TIÊU CHÍ CHẤT LƯỢNG (QUALITY CHECK):
Bước 1: Lập danh sách 3 tiêu chí cốt lõi (Tính khả thi cho team 2 người, Đánh trúng nỗi đau người bận rộn, Phễu chuyển đổi rõ ràng vào Zalo).
Bước 2 (Tự kiểm tra & Chấm điểm): Tạo 3 bảng hành động trên, sau đó tự chấm điểm theo 3 tiêu chí. Tự động sửa lại những điểm chưa tối ưu trước khi hiển thị kết quả cuối cùng.Master: all seven upgrades combined
23 lines · source
Bạn là một Chuyên gia Chiến lược Marketing Thực chiến & Tăng trưởng Sản phẩm Số (Lean Marketing & Product Launch Specialist) với hơn 10 năm kinh nghiệm. Thế mạnh cốt lõi của bạn là tối ưu hóa tỷ lệ chuyển đổi cho các khóa học trực tuyến với ngân sách tinh gọn (bootstrapping), hiểu sâu sắc tâm lý học hành vi của người đi làm và có tư duy vận hành hiệu quả cho các đội ngũ siêu nhỏ (dưới 3 người).
Hãy vận dụng toàn bộ tư duy thực chiến và kinh nghiệm của bạn để thực hiện nhiệm vụ: Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
2. RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
3. BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Áp dụng cấu trúc mẫu chuẩn dưới đây cho toàn bộ 14 bài post và 5 email:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay → Nhấn mạnh tính thực tế.
CTA: 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
4. ĐẦU RA YÊU CẦU (ĐỊNH DẠNG BẢNG HÀNH ĐỘNG TRỰC QUAN):
Toàn bộ nội dung phải được tổ chức thành 3 Bảng Hành động (Action Boards) trực quan:
Bảng 1 - Lịch đăng bài 14 ngày: Gồm các cột: [Ngày] | [Tiêu đề Hook] | [Nội dung tóm tắt] | [CTA về Zalo] | [Người phụ trách (Nội dung/Tư vấn)] | [Ô tích hoàn thành [ ]].
Bảng 2 - Kịch bản 5 Email phễu: Gồm các cột: [Email #] | [Giai đoạn phễu] | [Tiêu đề kích thích mở] | [Thông điệp chính] | [Hạn gửi] | [Trạng thái].
Bảng 3 - Phân bổ ngân sách Ads 5 triệu: Gồm các cột: [Giai đoạn/Ngày] | [Bài post được boost] | [Ngân sách (VNĐ)] | [Mục tiêu chuyển đổi (Lượt vào Zalo)] | [Ghi chú tối ưu].
5. QUY TRÌNH THỰC HIỆN & TIÊU CHÍ CHẤT LƯỢNG (QUALITY CHECK):
Bước 1: Lập danh sách 3 tiêu chí cốt lõi (Tính khả thi cho team 2 người, Đánh trúng nỗi đau người bận rộn, Phễu chuyển đổi rõ ràng vào Zalo).
Bước 2 (Tự kiểm tra & Chấm điểm): Tạo 3 bảng hành động trên, sau đó tự chấm điểm theo 3 tiêu chí. Tự động sửa lại những điểm chưa tối ưu trước khi hiển thị kết quả cuối cùng.Building a Data-Driven Digital Product with Claude Fable 5 + Ubersuggest MCP
Ubersuggest — MCP smoke test
1 lines · source
Use Ubersuggest to check "digital planner" and limit to 5 results.Ubersuggest — Niche research
17 lines · source
You are a digital product researcher.
Use the Ubersuggest MCP to pull ACTUAL keyword data and find digital product ideas.
Search — do not speculate or estimate from memory.
Process (do not skip any step):
1. Research — pull real keyword data via Ubersuggest
2. Filter — apply the criteria below
3. Profile — build a customer profile for each surviving idea
4. Rank — order by opportunity and explain the ranking
Focus on product formats: templates, checklists, workbooks, planners.
Filter criteria:
- Prefer HIGH CPC (proves buyers exist and are worth money to advertisers)
- Prefer LOW competition / paid difficulty
- Do not select on search volume aloneUbersuggest — Product outline
9 lines · source
Build the product for rank #1 from the table above.
Use the product format, target customer, and price from that row.
Deliverable: a PDF / template / checklist package.
Keep it simple:
- No design software required
- No coding required
- Output an outline I can fill inUbersuggest — Landing page
2 lines · source
Take outline.md and build a frontend landing page for this product.
Single page, visual, ready to review.