baram2584/Agentic-AI-Template
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

modify coding template

Browse Source
This commit is contained in:
NINI
2026-05-09 02:20:01 +09:00
parent 38291723f0
commit a1aea6a449
55 changed files with 437 additions and 2862 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Coding/Codex/.agents/plugins/marketplace.json
-20
View File
@@ -1,20 +0,0 @@
{
"name": "local-harness-engineering",
"interface": {
"displayName": "Local Harness Engineering"
},
"plugins": [
{
"name": "harness-engineering",
"source": {
"source": "local",
"path": "./plugins/harness-engineering"
},
"policy": {
"installation": "AVAILABLE",
"authentication": "ON_INSTALL"
},
"category": "Productivity"
}
]
}
Coding/Codex/.agents/skills/harness-review/SKILL.md
+26 -41
View File
@@ -1,57 +1,42 @@
---
name: harness-review
description: Review a Harness Engineering repository against its persistent rules and design docs. Use when Codex is asked to review local changes, generated phase files, or implementation output against `AGENTS.md`, `docs/ARCHITECTURE.md`, `docs/ADR.md`, `docs/UI_GUIDE.md`, testing expectations, and Harness step acceptance criteria.
description: Use when reviewing this Harness repository: local changes, generated phase files, step outputs, implementation diffs, missing tests, build readiness, or compliance with AGENTS.md, docs/ARCHITECTURE.md, docs/ADR.md, and Harness acceptance criteria.
---
# Harness Review
Use this skill when the user wants a repository-grounded review instead of generic commentary.
## Overview
## Review input set
Use this skill to review Harness work against the repository's persistent rules, architecture docs, and executable verification requirements. Prioritize bugs, regressions, missing tests, and rule violations.
Read these first:
## Review Process
- `/AGENTS.md`
- `/docs/ARCHITECTURE.md`
- `/docs/ADR.md`
- `/docs/UI_GUIDE.md`
- the changed files or generated `phases/` files under review
If the user explicitly asks for delegated review, prefer the repo custom agent `harness_reviewer` or built-in read-only explorers.
1. Read `/AGENTS.md`, `/docs/ARCHITECTURE.md`, and `/docs/ADR.md`.
2. Inspect the changed files with `git status --short` and `git diff`.
3. Check architecture, stack choices, tests, critical rules, and build readiness.
4. Run relevant verification commands when feasible. If a command cannot be run, report that as residual risk.
5. Lead with actionable findings. Keep summaries secondary.
## Checklist
Evaluate the patch against these questions:
| Item | Question |
| --- | --- |
| Architecture | Does the change follow `docs/ARCHITECTURE.md` directory and module boundaries? |
| Stack | Does the change stay within choices documented in `docs/ADR.md`? |
| Tests | Are new or changed behaviors covered by tests? |
| Critical Rules | Does the change violate any `AGENTS.md` CRITICAL rule? |
| Build | Do relevant build/test/lint commands pass? |
1. Does it follow the architecture described in `docs/ARCHITECTURE.md`?
2. Does it stay within the technology choices documented in `docs/ADR.md`?
3. Are new or changed behaviors covered by tests or other explicit validation?
4. Does it violate any CRITICAL rule in `AGENTS.md`?
5. Do generated `phases/` files remain self-contained, executable, and internally consistent?
6. If the user expects verification, does `python scripts/validate_workspace.py` succeed or is the failure explained?
## Output Format
## Output rules
If there are findings, list them first in severity order with file and line references when possible. Then include this table:
- Lead with findings, ordered by severity.
- Include file references for each finding.
- Explain the concrete risk or regression, not just the rule name.
- If there are no findings, say so explicitly and mention residual risks or missing evidence.
- Keep summaries brief after the findings.
| 항목 | 결과 | 비고 |
| --- | --- | --- |
| 아키텍처 준수 | PASS/FAIL | {상세} |
| 기술 스택 준수 | PASS/FAIL | {상세} |
| 테스트 존재 | PASS/FAIL | {상세} |
| CRITICAL 규칙 | PASS/FAIL | {상세} |
| 빌드 가능 | PASS/FAIL | {상세} |
## Preferred review table
When the user asks for a checklist-style review, use this table:
| Item | Result | Notes |
|------|------|------|
| Architecture compliance | PASS/FAIL | {details} |
| Tech stack compliance | PASS/FAIL | {details} |
| Test coverage | PASS/FAIL | {details} |
| CRITICAL rules | PASS/FAIL | {details} |
| Build and validation | PASS/FAIL | {details} |
## What not to do
- Do not approve changes just because they compile.
- Do not focus on style-only issues when correctness, architecture drift, or missing validation exists.
- Do not assume a passing hook means the implementation is acceptable; review the actual diff and docs.
When there are no findings, say that clearly, then mention any commands not run or remaining risk.
Coding/Codex/.agents/skills/harness-review/agents/openai.yaml
+2 -2
View File
@@ -1,4 +1,4 @@
interface:
display_name: "Harness Review"
short_description: "Review changes against Harness project rules"
default_prompt: "Use Harness review to check architecture, tests, and rules."
short_description: "Review Harness changes safely"
default_prompt: "Use $harness-review to review Harness repository changes."
Coding/Codex/.agents/skills/harness-workflow/SKILL.md
+71 -92
View File
@@ -1,47 +1,36 @@
---
name: harness-workflow
description: Plan and run the Harness Engineering workflow for this repository. Use when Codex needs to read `AGENTS.md` and `docs/*.md`, discuss implementation scope, draft phase plans, or create/update `phases/index.json`, `phases/{phase}/index.json`, and `phases/{phase}/stepN.md` files for staged execution.
description: Use when planning or running this Harness framework: reading AGENTS.md and docs/*.md, discussing implementation scope, creating or updating phases/index.json, phases/{task}/index.json, phases/{task}/stepN.md, or invoking scripts/execute.py for staged Codex execution.
---
# Harness Workflow
Use this skill when the user is working in the Harness template and wants structured planning or phase-file generation.
## Overview
Use this skill to turn a user-approved task into small, self-contained Harness steps that another Codex session can execute reliably. Keep the workflow grounded in repository docs and executable acceptance criteria.
## Workflow
### 1. Explore first
1. Read `AGENTS.md` and relevant files under `docs/`, especially `docs/PRD.md`, `docs/ARCHITECTURE.md`, and `docs/ADR.md`.
2. Discuss unresolved product or technical decisions with the user before writing phase files.
3. When the user asks for an implementation plan, draft steps and get approval before creating files.
4. Create or update `phases/index.json`, `phases/{task-name}/index.json`, and one `phases/{task-name}/stepN.md` per step.
5. Run the phase with `python scripts/execute.py {task-name}` when asked to execute it. Use `--push` only when the user asks to push.
Read these files before proposing steps:
## Step Design Rules
- `/AGENTS.md`
- `/docs/PRD.md`
- `/docs/ARCHITECTURE.md`
- `/docs/ADR.md`
- `/docs/UI_GUIDE.md`
- Scope each step to one layer or module. Split steps when multiple modules would otherwise change together.
- Make every step self-contained. Do not rely on prior conversation; include all required context and file paths.
- Force context gathering. Each step must tell Codex which docs and previous outputs to read before editing.
- Specify interfaces and signatures, not full implementations, unless exact code is required for a constraint.
- Put core invariants directly in the step: idempotency, security, data integrity, API contracts, or other non-negotiables.
- Use executable acceptance criteria such as `npm run build && npm test`, not abstract statements.
- Write cautions concretely: "Do not do X. Reason: Y."
- Name steps with kebab-case slugs such as `project-setup`, `api-layer`, or `auth-flow`.
If the user explicitly asks for parallel exploration, use built-in Codex subagents such as `explorer`, or the repo-scoped custom agent `phase_planner`.
## Phase Files
### 2. Discuss before locking the plan
If scope, sequencing, or architecture choices are still ambiguous, surface the decision points before creating `phases/` files.
### 3. Design steps with strict boundaries
When drafting a phase plan:
1. Keep scope minimal. One step should usually touch one layer or one module.
2. Make each step self-contained. Every `stepN.md` must work in an isolated Codex session.
3. List prerequisite files explicitly. Never rely on "as discussed above".
4. Specify interfaces or invariants, not line-by-line implementations.
5. Use executable acceptance commands, not vague success criteria.
6. Write concrete warnings in "do not do X because Y" form.
7. Use kebab-case step names.
## Files to generate
### `phases/index.json`
Top-level phase registry. Append to `phases[]` when the file already exists.
Create or update `phases/index.json`:
```json
{
@@ -54,16 +43,12 @@ Top-level phase registry. Append to `phases[]` when the file already exists.
}
```
- `dir`: phase directory name.
- `status`: `pending`, `completed`, `error`, or `blocked`.
- Timestamp fields are written by `scripts/execute.py`; do not seed them during planning.
### `phases/{phase}/index.json`
Create `phases/{task-name}/index.json`:
```json
{
"project": "<project-name>",
"phase": "<phase-name>",
"phase": "<task-name>",
"steps": [
{ "step": 0, "name": "project-setup", "status": "pending" },
{ "step": 1, "name": "core-types", "status": "pending" },
@@ -72,74 +57,68 @@ Top-level phase registry. Append to `phases[]` when the file already exists.
}
```
- `project`: from `AGENTS.md`.
- `phase`: directory name.
- `steps[].step`: zero-based integer.
- `steps[].name`: kebab-case slug.
- `steps[].status`: initialize to `pending`.
Rules:
### `phases/{phase}/stepN.md`
- `project` comes from `AGENTS.md`.
- `phase` matches the task directory name.
- `steps[].step` starts at `0`.
- Initial status is always `pending`.
- Do not add timestamps when creating files. `scripts/execute.py` records `created_at`, `started_at`, `completed_at`, `failed_at`, and `blocked_at`.
Each step file should contain:
1. A title.
2. A "read these files first" section.
3. A concrete task section.
4. Executable acceptance criteria.
5. Verification instructions.
6. Explicit prohibitions.
Recommended structure:
## Step Template
```markdown
# Step {N}: {name}
## Read First
- /AGENTS.md
- /docs/ARCHITECTURE.md
- /docs/ADR.md
- {files from previous steps}
## 읽어야 할 파일
## Task
{specific instructions}
먼저 아래 파일들을 읽고 프로젝트의 아키텍처와 설계 의도를 파악하라:
- `/AGENTS.md`
- `/docs/ARCHITECTURE.md`
- `/docs/ADR.md`
- {previously created or modified files}
이전 step에서 만들어진 코드를 꼼꼼히 읽고, 설계 의도를 이해한 뒤 작업하라.
## 작업
{Concrete instructions with file paths, interfaces, signatures, and rules.}
## Acceptance Criteria
```bash
python scripts/validate_workspace.py
```
## Verification
1. Run the acceptance commands.
2. Check AGENTS and docs for rule drift.
3. Update the matching step in phases/{phase}/index.json:
- completed + summary
- error + error_message
- blocked + blocked_reason
## Do Not
- {concrete prohibition}
```
```
## Execution
Run the generated phase with:
```bash
python scripts/execute.py <phase-name>
python scripts/execute.py <phase-name> --push
npm run build
npm test
```
`scripts/execute.py` handles:
## 검증 절차
- `feat-{phase}` branch checkout/creation
- guardrail injection from `AGENTS.md` and `docs/*.md`
- accumulation of completed-step summaries into later prompts
- up to 3 retries with prior error feedback
- two-phase commit of code changes and metadata updates
- timestamps such as `created_at`, `started_at`, `completed_at`, `failed_at`, and `blocked_at`
1. 위 AC 커맨드를 실행한다.
2. 아키텍처 체크리스트를 확인한다:
- ARCHITECTURE.md 디렉토리 구조를 따르는가?
- ADR 기술 스택을 벗어나지 않았는가?
- AGENTS.md CRITICAL 규칙을 위반하지 않았는가?
3. 결과에 따라 `phases/{task-name}/index.json`의 해당 step을 업데이트한다:
- 성공: `"status": "completed"`, `"summary": "산출물 한 줄 요약"`
- 3회 수정 시도 후 실패: `"status": "error"`, `"error_message": "구체적 에러 내용"`
- 사용자 개입 필요: `"status": "blocked"`, `"blocked_reason": "구체적 사유"` 후 중단
## Recovery rules
## 금지사항
- If a step is `error`, reset its status to `pending`, remove `error_message`, then rerun.
- If a step is `blocked`, resolve the blocker, reset to `pending`, remove `blocked_reason`, then rerun.
- {Do not do X. Reason: Y.}
- 기존 테스트를 깨뜨리지 마라.
```
## Execution And Recovery
Run:
```bash
python scripts/execute.py {task-name}
python scripts/execute.py {task-name} --push
```
`scripts/execute.py` creates or checks out `feat-{task-name}`, injects `AGENTS.md` and `docs/*.md` into each prompt, carries completed step summaries forward, retries failed steps up to three times, separates code and metadata commits, and records timestamps.
If a step is `error`, set it back to `pending` and remove `error_message` after fixing the cause. If a step is `blocked`, resolve `blocked_reason`, set it back to `pending`, remove `blocked_reason`, and rerun.
Coding/Codex/.agents/skills/harness-workflow/agents/openai.yaml
+2 -2
View File
@@ -1,4 +1,4 @@
interface:
display_name: "Harness Workflow"
short_description: "Guide Codex through Harness phase planning"
default_prompt: "Use the Harness workflow to plan phases and step files."
short_description: "Plan staged Harness workflow steps"
default_prompt: "Use $harness-workflow to plan Harness phases and step files."