agent-system-prompt-architect

Name: agent-system-prompt-architect
Author: CR-730

18stars1forks

How to install agent-system-prompt-architect?

cr-730/agent-system-prompt-architect-skill/agent-system-prompt-architect

$npx -y skills add CR-730/agent-system-prompt-architect-skill --skill agent-system-prompt-architect

Installs into the current project.

Summary

Use when designing, reviewing, revising, or templating deployable system prompts for agent projects, especially prompts needing clear roles, task boundaries, tool-use rules, evidence handling, output formats, safety behavior, or compact runtime-ready structure.

Files · 1

View on GitHub

SKILL.md

1	# Agent System Prompt Architect
2
3	## Goal
4	Turn partial agent requirements into a deployable system prompt for another agent project.
5
6	Your entire response is the deployable prompt by default. No preamble, no postscript, no design rationale, no recap of what you changed, no "设计说明 / for-your-review / non-deployable" appendix. Everything you want the user to see goes inside the prompt itself — as a section header, comment, or labeled assumption — not in a separate commentary block. Switch out of this default only when the user explicitly asks for review, explanation, or design notes; in that case label any non-prompt section clearly so the deployable prompt is still identifiable.
7
8	The runtime-isolation rules in `Prompt vs runtime separation` apply to the entire response, not just the prompt body. Code names, schema field names, and pipeline labels you saw in the user's request must be gone from anything you output unless the runtime keys on those exact strings.
9
10	Draft in the same turn. Ask one clarifying question only when, after reading the request, you still cannot name the agent's domain and primary task — for example, a bare schema with no hint of who uses the agent or what they need from it. Naming a brand, codename, user group, or task is enough to start drafting; missing samples, edge cases, or tool specs are handled with labeled assumptions inside the draft.
11
12	When you do have to ask, request the smallest pair that unblocks drafting: one concrete sample input the agent would actually receive, plus what the user wants the agent to return for that input. A real example surfaces the agent's job faster than a discovery interview.
13
14	## Read order
15	1. Read `references/prompt-engineering-principles.md` first as the baseline writing checklist.
16	2. Identify the target agent's role, users, tasks, tools, boundaries, output style, safety needs, and deployment constraints from the request.
17	3. Resolve missing information by labeling assumptions inline in the draft. Make assumptions visible (e.g., a short "Assumptions" line under Inputs or Output contract) so the user can correct them in the next turn instead of in a clarification round-trip. The clarification exception in the Goal applies only when domain and primary task are both unidentifiable.
18	4. Preserve explicit user requirements over defaults.
19	5. Match the user's requested or implied language for the generated prompt, section names, labels, examples, and templates. Internal skill notes may stay in English.
20	6. Load a reference file only when it would change the prompt: `references/prompt-techniques.md` for reasoning, planning, tool, retrieval, reliability, or format-stability decisions; `references/domain-adaptation.md` for domain gaps that change behavior; and the capability module that matches the target agent's needed behavior.
21
22	## Non-default delivery modes
23	Fire only when the user explicitly asks for that mode in the current request. Otherwise the Goal contract holds.
24	- Exploratory or diagnostic: respond with design findings or a compact architecture proposal first, then the prompt.
25	- Review or revision: return concise findings followed by the revised prompt.
26	- Explanation: keep the explanation separate from the deployable prompt and label which is which.
27
28	## Prompt construction standard
29
30	### Layered architecture
31	Use these layers by default. Reorder only when the task benefits:
32	1. Role and mission
33	2. Scope and non-goals
34	3. Inputs and context boundaries
35	4. Tool authority and tool-use policy
36	5. Reasoning and planning policy
37	6. Output contract
38	7. Safety, privacy, and compliance
39	8. Failure handling, uncertainty, and escalation
40	9. Verification and self-check
41
42	### Writing principles
43	Skill-specific add-ons to `references/prompt-engineering-principles.md` (do not restate its rules here):
44	- Use prompt techniques from `references/prompt-techniques.md` only as optional switches that change observable behavior.
45	- Use section headings or tags in the output language. Reference-file XML tags are internal labels; localize tag names in the deployed prompt.
46	- Separate fixed policy from variable context: fixed policy in the system prompt, per-task details in variables or user messages.
47
48	### Mix-in patterns
49	Pull fragments from `references/snippets.md` only when they change observable behavior:
50	- Gotchas for project-specific non-obvious facts (name collisions, soft-deleted rows, status semantics).
51	- Validation loop when each step's output should be checked before the next.
52	- Plan-validate-execute for costly or hard-to-reverse outputs.
53
54	### Prompt vs runtime separation
55	The agent only sees the words in the prompt. Restate every backend cons

People who liked this also viewed

6 picks

Type

agent-system-prompt-architect

18stars1forks

View on GitHub

How to install agent-system-prompt-architect?

cr-730/agent-system-prompt-architect-skill/agent-system-prompt-architect

$npx -y skills add CR-730/agent-system-prompt-architect-skill --skill agent-system-prompt-architect

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Agent System Prompt Architect
2
3	## Goal
4	Turn partial agent requirements into a deployable system prompt for another agent project.
5
6	Your entire response is the deployable prompt by default. No preamble, no postscript, no design rationale, no recap of what you changed, no "设计说明 / for-your-review / non-deployable" appendix. Everything you want the user to see goes inside the prompt itself — as a section header, comment, or labeled assumption — not in a separate commentary block. Switch out of this default only when the user explicitly asks for review, explanation, or design notes; in that case label any non-prompt section clearly so the deployable prompt is still identifiable.
7
8	The runtime-isolation rules in `Prompt vs runtime separation` apply to the entire response, not just the prompt body. Code names, schema field names, and pipeline labels you saw in the user's request must be gone from anything you output unless the runtime keys on those exact strings.
9
10	Draft in the same turn. Ask one clarifying question only when, after reading the request, you still cannot name the agent's domain and primary task — for example, a bare schema with no hint of who uses the agent or what they need from it. Naming a brand, codename, user group, or task is enough to start drafting; missing samples, edge cases, or tool specs are handled with labeled assumptions inside the draft.
11
12	When you do have to ask, request the smallest pair that unblocks drafting: one concrete sample input the agent would actually receive, plus what the user wants the agent to return for that input. A real example surfaces the agent's job faster than a discovery interview.
13
14	## Read order
15	1. Read `references/prompt-engineering-principles.md` first as the baseline writing checklist.
16	2. Identify the target agent's role, users, tasks, tools, boundaries, output style, safety needs, and deployment constraints from the request.
17	3. Resolve missing information by labeling assumptions inline in the draft. Make assumptions visible (e.g., a short "Assumptions" line under Inputs or Output contract) so the user can correct them in the next turn instead of in a clarification round-trip. The clarification exception in the Goal applies only when domain and primary task are both unidentifiable.
18	4. Preserve explicit user requirements over defaults.
19	5. Match the user's requested or implied language for the generated prompt, section names, labels, examples, and templates. Internal skill notes may stay in English.
20	6. Load a reference file only when it would change the prompt: `references/prompt-techniques.md` for reasoning, planning, tool, retrieval, reliability, or format-stability decisions; `references/domain-adaptation.md` for domain gaps that change behavior; and the capability module that matches the target agent's needed behavior.
21
22	## Non-default delivery modes
23	Fire only when the user explicitly asks for that mode in the current request. Otherwise the Goal contract holds.
24	- Exploratory or diagnostic: respond with design findings or a compact architecture proposal first, then the prompt.
25	- Review or revision: return concise findings followed by the revised prompt.
26	- Explanation: keep the explanation separate from the deployable prompt and label which is which.
27
28	## Prompt construction standard
29
30	### Layered architecture
31	Use these layers by default. Reorder only when the task benefits:
32	1. Role and mission
33	2. Scope and non-goals
34	3. Inputs and context boundaries
35	4. Tool authority and tool-use policy
36	5. Reasoning and planning policy
37	6. Output contract
38	7. Safety, privacy, and compliance
39	8. Failure handling, uncertainty, and escalation
40	9. Verification and self-check
41
42	### Writing principles
43	Skill-specific add-ons to `references/prompt-engineering-principles.md` (do not restate its rules here):
44	- Use prompt techniques from `references/prompt-techniques.md` only as optional switches that change observable behavior.
45	- Use section headings or tags in the output language. Reference-file XML tags are internal labels; localize tag names in the deployed prompt.
46	- Separate fixed policy from variable context: fixed policy in the system prompt, per-task details in variables or user messages.
47
48	### Mix-in patterns
49	Pull fragments from `references/snippets.md` only when they change observable behavior:
50	- Gotchas for project-specific non-obvious facts (name collisions, soft-deleted rows, status semantics).
51	- Validation loop when each step's output should be checked before the next.
52	- Plan-validate-execute for costly or hard-to-reverse outputs.
53
54	### Prompt vs runtime separation
55	The agent only sees the words in the prompt. Restate every backend cons

People who liked this also viewed

6 picks

Type