CLIne documentation editing prompt

You are the best software eningeer in the world and your goal is to draft a CLIne prompt which will edit the following documents for the purpose of filling in context for CLIne to later code a project. So the prompt will instruct for a deliverable of another prompt except this one is for CLIne to edit the files which will then fill in the context for the project. Reference https://github.com/kliewerdaniel/workflow.git for the description of what each of the files is meant to be used for.

Here’s a **master prompt** you can feed into entity["software", "CLine", 0] to edit and enrich the docs from the entity["software", "workflow", 0] repo so they become full-context input for a later coding phase: --- > You are a documentation editor and context‐gathering assistant working as part of a structured AI-assisted development workflow. > Your task is to **edit**, **enhance**, and **fill in missing context** across the following markdown files: `ai_guidelines.md`, `requirements.md`, `architecture.md`, `implementation.md`, `testing.md`, `security.md`, `deployment.md`, `sop.md`, `standards.md`, `prompts.md`, `personas.md`, `seo.md`, `accessibility.md`. > > For each file: > 1. Ensure the **purpose** of the file is clearly stated (based on the workflow repository’s description). citeturn0view0 > 2. Insert placeholders or tables for project-specific information (project name, domain, stakeholders, personas, technologies, constraints, business objectives, non-functional requirements, security/risk assumptions, deployment environments, KPIs, etc.). > 3. Ask clarifying questions in the document (via "TODO" or “**?”” markers) where context is missing—so we can later fill them in. > 4. Ensure each section aligns with standards defined in the `standards.md` (or if no explicit standards exist yet, create a “Standards” sub-section with prompts for what the standards *should* cover). > 5. Cross-link between docs: e.g., link user-stories in `requirements.md` to components in `architecture.md`; link testing strategies in `testing.md` to features in `implementation.md`; reference deployment pipelines in `deployment.md` that assume architecture decisions from `architecture.md`, etc. > 6. Maintain a consistent flavour and style across all docs: use markdown headings, bullet lists, tables where helpful, and mark items clearly as “Must / Should / Could / Won’t” where applicable. > 7. Annotate any area that will later require code generation or AI prompt generation (for the later CLine coding phase) — e.g., in `prompts.md`, add a section “Prompt templates for CLine coding” with placeholders like `[COMPONENT_NAME]`, `[API_ENDPOINT]`, `[TEST_SCENARIO]`, etc. > > Deliverable: A **single merged prompt** (for CLine) that instructs it to perform the editing/enrichment for *all* the files listed above, with clear ordering, scope, how to handle each file, what to fill in, where to ask questions, and how to prepare the project context so that the next phase (coding) is well-supported. > > Important: This prompt is *not* the coding phase — it’s purely the editing and context-filling phase. It should make clear to CLine the difference, and that once this is done, we will move to code generation. > > You may refer to the description in the workflow repository’s README for what each file is meant to cover. citeturn0view0 > > Be concise but thorough in your instruction: define the sequence in which files should be processed (typically: ai_guidelines → requirements → architecture → implementation → testing → security → deployment → sop → standards → prompts → personas → seo → accessibility), how cross-linking is to be done, and what output format (markdown) is expected (overwriting or creating “filled-in” versions, while keeping original commentary sections for later review). > > Also instruct CLine to output a summary at the end listing **which questions (context gaps)** remain unanswered (so we can fill them manually). > > Deliver your prompt now. --- If you like this draft, I can **generate a ready-to-use version** of the prompt (fully quoted, ready to paste into CLine). Would you like me to produce that?

You are a documentation editor and context‐gathering assistant working as part of a structured AI-assisted development workflow. Your task is to edit, enhance, and fill in missing context across the following markdown files: ai_guidelines.md, requirements.md, architecture.md, implementation.md, testing.md, security.md, and sop.md. For each file: 1. Ensure the purpose of the file is clearly stated (based on the workflow repository’s description).  2. Insert placeholders or tables for project-specific information (project name, domain, stakeholders, personas, technologies, constraints, business objectives, non-functional requirements, security/risk assumptions, deployment environments, KPIs, etc.). 3. Ask clarifying questions in the document (via “TODO” or “**?”” markers) where context is missing—so we can later fill them in. 4. Ensure each section aligns with standards defined in the standards.md (or if no explicit standards exist yet, create a “Standards” sub-section with prompts for what the standards should cover). 5. Cross-link between docs: e.g., link user-stories in requirements.md to components in architecture.md; link testing strategies in testing.md to features in implementation.md; reference deployment pipelines in deployment.md that assume architecture decisions from architecture.md, etc. 6. Maintain a consistent flavour and style across all docs: use markdown headings, bullet lists, tables where helpful, and mark items clearly as “Must / Should / Could / Won’t” where applicable. 7. Annotate any area that will later require code generation or AI prompt generation (for the later CLine coding phase) — e.g., in prompts.md, add a section “Prompt templates for CLine coding” with placeholders like [COMPONENT_NAME], [API_ENDPOINT], [TEST_SCENARIO], etc. Deliverable: A single merged prompt (for CLine) that instructs it to perform the editing/enrichment for all the files listed above, with clear ordering, scope, how to handle each file, what to fill in, where to ask questions, and how to prepare the project context so that the next phase (coding) is well-supported. Important: This prompt is not the coding phase — it’s purely the editing and context-filling phase. It should make clear to CLine the difference, and that once this is done, we will move to code generation. Be concise but thorough in your instruction: define the sequence in which files should be processed (typically: ai_guidelines → requirements → architecture → implementation → testing → security→ sop), how cross-linking is to be done, and what output format (markdown) is expected (overwriting or creating “filled-in” versions, while keeping original commentary sections for later review). Also instruct CLine to output a summary at the end listing which questions (context gaps) remain unanswered (so we can fill them manually). Deliver your prompt now.

Here is your **ready-to-use, fully structured CLine prompt**. You can copy and paste this directly into CLine to initiate the **documentation enhancement and context-gathering phase**. --- ### ✅ **CLine Prompt — Documentation Editing & Context Preparation Phase** You are an AI documentation editor and context-gathering assistant working within a structured AI-assisted development workflow. Your task is to **edit, enhance, and fill in context across the following markdown files** in this repository: `ai_guidelines.md`, `requirements.md`, `architecture.md`, `implementation.md`, `testing.md`, `security.md`, and `sop.md`. This phase is **NOT for coding or implementation**. It is only for editing documentation and gathering project context so future prompts can generate code. --- ### **📂 Processing Order** Process the files in this order: 1. `ai_guidelines.md` 2. `requirements.md` 3. `architecture.md` 4. `implementation.md` 5. `testing.md` 6. `security.md` 7. `sop.md` --- ### **📌 For Each File — Apply the Following Instructions** For every file listed above: #### ✅ 1. **Declare Purpose** - At the top of each file, clearly state its purpose based on the workflow repository’s intent. #### ✅ 2. **Insert Context Placeholders & Tables** Add missing context using markdown tables or placeholder sections for information such as: | Field | Description | |-------|-------------| | Project Name | TODO: | | Domain / Industry | TODO: | | Stakeholders | TODO: | | Personas / Users | TODO: | | Technologies / Frameworks | TODO: | | Business Objectives | TODO: | | Functional Requirements | TODO: | | Non-functional Requirements | TODO: | | Constraints | TODO: | | Deployment Environments | TODO: | | Metrics / KPIs | TODO: | | Security / Risk Assumptions | TODO: | #### ✅ 3. **Ask Clarifying Questions** Where context is missing, insert in-line prompts using: - `TODO:` - `**?**` next to the missing information or unclear sections. #### ✅ 4. **Align with Standards** - If `standards.md` exists, ensure language/structure matches it. - If no standards apply, add a placeholder section: ```md ### Standards Alignment TODO: Define how this document should follow standards for formatting, naming, architecture, security, testing, and documentation. ``` #### ✅ 5. **Cross-Link Relevant Documentation** - In `requirements.md`, link each user story to system components in `architecture.md`. - In `architecture.md`, reference implementation strategy in `implementation.md`. - In `testing.md`, link each test scenario to requirements and implemented features. - In `security.md`, reference risks related to architecture decisions. - In `sop.md`, reference implementation and deployment flows. Use relative markdown links, e.g.: `See [Component A](architecture.md#component-a)` #### ✅ 6. **Consistent Formatting & Style** - Use clear headings (`##`, `###`, etc). - Use bullet points and tables for clarity. - Use MoSCoW format (Must / Should / Could / Won’t) for priority lists. #### ✅ 7. **Mark Sections Needed for Future Code Generation** Add placeholders for future use during coding phase, e.g.: ```md ### Prompt Templates for CLine Coding (To be used later) - Implement [COMPONENT_NAME] that connects to [API_ENDPOINT] - Generate unit tests for [FEATURE] - Create service for [DATA_MODEL] ``` --- ### **📤 Output Requirements** - Overwrite each markdown file with the enhanced/document-ready version. - Preserve original content where it is useful, but reorganize for clarity. - Add new sections, tables, placeholders, and TODO questions where needed. - At the end of the process, generate a **summary file or console output** listing: - All unanswered questions (TODOs / **?**) - Files updated - Sections requiring manual input --- ### ⚠️ **Reminder** This prompt is only for documentation refinement and context collection. **Do not write code or implementation logic yet.** Once documentation is complete, a separate prompt will initiate the coding phase. --- **Begin editing the documents now.** Output summaries and unanswered context questions once complete. --- Let me know if you want me to expand this to include: ✅ `deployment.md`, `prompts.md`, `personas.md`, `seo.md`, `accessibility.md` or generate these files automatically. Would you like me to do that next?

I want you to write a prompt for an LLM which will generate a prompt for CLIne, take what you knowYou are a senior software engineer and you are building a prompt for CLIne. What you are doing is using the context in the docs folder to guide CLIne as it goes along with the coding process. The first thing you should tell CLIne to do is to create a checklist.md file in the docs folder to act as a ledger for CLIne to keep track of its progress but also for observability. The overall goal for CLIne is to output the absolute very best boilerplate repo for next.js using all of the context in the docs folder. I want you to think of everything CLIne has to offer and to think of all of the intricacies to software development and I want you to know that you have all of the files in the docs folder to help you code this project. This is the CLIne prompt which will build the next.js boilerplate repo as outlined in the docs folder.

Here’s a **prompt for an LLM** that will in turn generate the precise prompt you’ll feed into entity["software","CLine",0]. Use this to orchestrate CLine’s work in creating a best-in-class entity["software","Next.js",0] boilerplate repository, guided by the docs folder you already have. --- > You are a senior software engineer designing a **prompt for CLine** to build a Next.js boilerplate repo. > > **Your goal**: produce a single prompt that instructs CLine to: > 1. Create a new `docs/checklist.md` inside the docs folder. This file will act as a progress ledger/observability guide for CLine: each major step, sub-task, status, and link back to the docs context must be tracked here. > 2. Use *all* of the context found in the existing docs folder (ai_guidelines.md, requirements.md, architecture.md, implementation.md, testing.md, security.md, sop.md, etc) to inform the structure, architecture, tooling, conventions, and deliverables of the boilerplate. > 3. Produce a Next.js repository incorporating best practices and boilerplate parameters (folder structure, TypeScript support, linting, formatting, CI/CD, testing, deployment, security hardening, observability, performance, etc). Use referenced best-practice sources as guidance. > 4. Maintain traceability between docs context and code structure: e.g., link from requirements to implemented components, architecture decisions to folder/file naming, testing strategies to code coverage setup, deployment instructions to folder layout. > 5. Use the checklist.md as a continuous ledger: for each step (init repo, set up TypeScript, set up lint/prettier, create folder structure, create sample component, wiring CI/CD, create tests, set up security config, set up observability/monitoring, create README, etc) mark status (“Not Started / In Progress / Done”), timestamp, docs references, and next actions. > 6. Ensure the overall boilerplate is **absolutely best-in-class**: incorporate modern patterns (for example, TypeScript, Next.js App Router or Pages Router as appropriate, modular folder structure, environment management, performance optimization) as hinted by best-practice sources. citeturn0search2turn0search3turn0search5 > 7. At the end of the generated prompt, tell CLine explicitly how to output: > - Create the `docs/checklist.md` file and update it as it works. > - Commit code / files in the repository according to each checklist entry. > - Provide the created boilerplate repo in a zipped format (or push instructions) once checklist is complete. > > **Important**: The prompt you generate for CLine should itself be clear, step-by-step, numbered, and quote placeholders like `[PROJECT_NAME]`, `[TECH_STACK]`, `[DEPLOYMENT_TARGET]` etc so that the next phase is parameterized. It should define the sequence of tasks CLine must follow, and reference the docs context at each step. > > Deliverables: > - The prompt that you’ll feed to CLine. > - Ensure that prompt tells CLine to create the `docs/checklist.md` ledger first. > - Ensure that prompt defines how the docs folder context influences the code generation. > > Remember: This is the *prompt-generation phase* (you’re generating a prompt for CLine), not the code-generation phase itself. > > Output now the full prompt for CLine. --- If you like this, I can also generate **templated placeholders** for `[PROJECT_NAME]`, `[DOMAIN]`, `[TECH_STACK]`, `[TARGET_ENV]`, etc., so you can fill them in before sending to CLine.