bidkit-parser 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- bidkit_parser-0.1.0/.claude-plugin/plugin.json +8 -0
- bidkit_parser-0.1.0/.gitignore +7 -0
- bidkit_parser-0.1.0/AGENTS.md +168 -0
- bidkit_parser-0.1.0/ARCHITECTURE.md +177 -0
- bidkit_parser-0.1.0/CHANGELOG.md +48 -0
- bidkit_parser-0.1.0/CLAUDE.md +188 -0
- bidkit_parser-0.1.0/PKG-INFO +180 -0
- bidkit_parser-0.1.0/README.md +150 -0
- bidkit_parser-0.1.0/agents/critic.md +203 -0
- bidkit_parser-0.1.0/agents/overseer.md +271 -0
- bidkit_parser-0.1.0/agents/researcher.md +177 -0
- bidkit_parser-0.1.0/agents/team-lead.md +232 -0
- bidkit_parser-0.1.0/agents/writer.md +159 -0
- bidkit_parser-0.1.0/docs/.bkit-memory.json +8 -0
- bidkit_parser-0.1.0/docs/.pdca-status.json +543 -0
- bidkit_parser-0.1.0/docs/superpowers/plans/2026-03-13-proposal-harness-hardening-followup.md +154 -0
- bidkit_parser-0.1.0/docs/superpowers/plans/2026-03-13-proposal-harness.md +778 -0
- bidkit_parser-0.1.0/docs/superpowers/plans/2026-03-14-doc-parser-integration.md +546 -0
- bidkit_parser-0.1.0/docs/superpowers/plans/2026-03-15-harness-plugin-packaging.md +612 -0
- bidkit_parser-0.1.0/docs/superpowers/specs/2026-03-13-proposal-harness-design.md +712 -0
- bidkit_parser-0.1.0/docs/superpowers/specs/2026-03-15-harness-plugin-packaging-design.md +258 -0
- bidkit_parser-0.1.0/evals/README.md +17 -0
- bidkit_parser-0.1.0/evals/config.json +27 -0
- bidkit_parser-0.1.0/evals/design/expected-1.md +5 -0
- bidkit_parser-0.1.0/evals/design/prompt-1.md +1 -0
- bidkit_parser-0.1.0/evals/verify/expected-1.md +4 -0
- bidkit_parser-0.1.0/evals/verify/prompt-1.md +1 -0
- bidkit_parser-0.1.0/evals/write/expected-1.md +5 -0
- bidkit_parser-0.1.0/evals/write/prompt-1.md +1 -0
- bidkit_parser-0.1.0/parser/__init__.py +97 -0
- bidkit_parser-0.1.0/parser/office_parser.py +555 -0
- bidkit_parser-0.1.0/parser/office_types.py +594 -0
- bidkit_parser-0.1.0/parser/office_worker.py +1 -0
- bidkit_parser-0.1.0/parser/pdf_converter.py +110 -0
- bidkit_parser-0.1.0/parser/pdf_markdown.py +140 -0
- bidkit_parser-0.1.0/parser/pdf_utils.py +42 -0
- bidkit_parser-0.1.0/parser/requirements.txt +11 -0
- bidkit_parser-0.1.0/parser/run.py +168 -0
- bidkit_parser-0.1.0/pyproject.toml +48 -0
- bidkit_parser-0.1.0/reference/cross-team-communication.md +50 -0
- bidkit_parser-0.1.0/reference/error-handling.md +39 -0
- bidkit_parser-0.1.0/reference/impact-rules.md +38 -0
- bidkit_parser-0.1.0/reference/proposal-guide-format.md +85 -0
- bidkit_parser-0.1.0/reference/quality-criteria.md +52 -0
- bidkit_parser-0.1.0/reference/skills-catalog.md +108 -0
- bidkit_parser-0.1.0/reference/state-machine.md +60 -0
- bidkit_parser-0.1.0/scripts/check-deps.sh +29 -0
- bidkit_parser-0.1.0/scripts/validate-bidkit-contracts.js +112 -0
- bidkit_parser-0.1.0/scripts/verify-bidkit.sh +260 -0
- bidkit_parser-0.1.0/skills/design/SKILL.md +89 -0
- bidkit_parser-0.1.0/skills/diagnose/SKILL.md +341 -0
- bidkit_parser-0.1.0/skills/output/SKILL.md +234 -0
- bidkit_parser-0.1.0/skills/setup/SKILL.md +39 -0
- bidkit_parser-0.1.0/skills/status/SKILL.md +240 -0
- bidkit_parser-0.1.0/skills/verify/SKILL.md +313 -0
- bidkit_parser-0.1.0/skills/write/SKILL.md +620 -0
- bidkit_parser-0.1.0/templates/html-theme/index.html +33 -0
- bidkit_parser-0.1.0/templates/ideation-note.md +26 -0
- bidkit_parser-0.1.0/templates/init/glossary.yaml +6 -0
- bidkit_parser-0.1.0/templates/init/outline.yaml +9 -0
- bidkit_parser-0.1.0/templates/init/proposal-meta.yaml +18 -0
- bidkit_parser-0.1.0/templates/init/rfp-trace-matrix.md +5 -0
- bidkit_parser-0.1.0/templates/init/runtime-state.json +10 -0
- bidkit_parser-0.1.0/templates/pdf-style.css +81 -0
- bidkit_parser-0.1.0/templates/ssot.md +43 -0
- bidkit_parser-0.1.0/tests/__init__.py +0 -0
- bidkit_parser-0.1.0/tests/parser/__init__.py +0 -0
- bidkit_parser-0.1.0/tests/parser/test_parse_dispatch.py +31 -0
|
@@ -0,0 +1,168 @@
|
|
|
1
|
+
# BidKit
|
|
2
|
+
|
|
3
|
+
Multi-agent system for financial IT proposal writing.
|
|
4
|
+
|
|
5
|
+
## Identity
|
|
6
|
+
|
|
7
|
+
You are BidKit running under Codex. `AGENTS.md` is the Codex entry
|
|
8
|
+
point for this repository. `CLAUDE.md` is the equivalent entry point for Claude
|
|
9
|
+
Code. Both files define the same roles, commands, and operating rules.
|
|
10
|
+
|
|
11
|
+
Read this file fully before acting, then follow links to the specific role or
|
|
12
|
+
skill you need.
|
|
13
|
+
|
|
14
|
+
## Agent Roles
|
|
15
|
+
|
|
16
|
+
| Role | Responsibility | Details |
|
|
17
|
+
|------|---------------|---------|
|
|
18
|
+
| **Overseer (EA)** | Strategy, cross-SSOT consistency, final approval | `agents/overseer.md` |
|
|
19
|
+
| **Team Lead** | Per-domain orchestrator, delegates to writers/researchers | `agents/team-lead.md` |
|
|
20
|
+
| **Writer** | Drafts and revises section content | `agents/writer.md` |
|
|
21
|
+
| **Researcher** | Gathers data, references, competitive intelligence | `agents/researcher.md` |
|
|
22
|
+
| **Critic** | Verifies quality, compliance, and cross-references | `agents/critic.md` |
|
|
23
|
+
|
|
24
|
+
Agents are spawned by the Overseer or Team Lead as needed. A single session may
|
|
25
|
+
run multiple agents in parallel for independent sections.
|
|
26
|
+
|
|
27
|
+
## Commands
|
|
28
|
+
|
|
29
|
+
| Command | Purpose | Skill File |
|
|
30
|
+
|---------|---------|------------|
|
|
31
|
+
| `design` | New proposal strategy + TOC generation | `skills/design/SKILL.md` |
|
|
32
|
+
| `write <section>` | Work on a section (draft/revise auto-detected) | `skills/write/SKILL.md` |
|
|
33
|
+
| `diagnose` | Full quality diagnosis across all SSOTs | `skills/diagnose/SKILL.md` |
|
|
34
|
+
| `verify` | Cross-SSOT consistency and compliance check | `skills/verify/SKILL.md` |
|
|
35
|
+
| `status` | Progress dashboard for all sections | `skills/status/SKILL.md` |
|
|
36
|
+
| `setup` | Environment check and guided installation | `skills/setup/SKILL.md` |
|
|
37
|
+
|
|
38
|
+
When a skill requires an optional tool that is not installed, run
|
|
39
|
+
`bash scripts/check-deps.sh` and guide the user through installation.
|
|
40
|
+
See individual skill files for specific detection logic.
|
|
41
|
+
|
|
42
|
+
Output generation is triggered via natural language (for example, "PDF로 출력해줘").
|
|
43
|
+
See `skills/output/SKILL.md`.
|
|
44
|
+
|
|
45
|
+
Natural language input is always accepted and routed automatically to the
|
|
46
|
+
appropriate command or agent.
|
|
47
|
+
|
|
48
|
+
## How Users Work
|
|
49
|
+
|
|
50
|
+
Users do not need to know agent names or internal state names. They can simply
|
|
51
|
+
describe the situation in natural language.
|
|
52
|
+
|
|
53
|
+
Typical entry points:
|
|
54
|
+
|
|
55
|
+
- **New proposal**: "RFP 받았는데 어디서부터?", "제안서 만들어야 해"
|
|
56
|
+
- **Section work**: "HSM 모델 변경해야 해", "이행계획 어떻게 쓸지 보자"
|
|
57
|
+
- **Whole-project check**: "교차 검증해줘", "진행 상황 알려줘", "PDF로 출력해줘"
|
|
58
|
+
|
|
59
|
+
User-facing responses should prefer situation labels over internal role names:
|
|
60
|
+
|
|
61
|
+
- "전략 정리 중"
|
|
62
|
+
- "방향 탐색 중"
|
|
63
|
+
- "초안 작성 중"
|
|
64
|
+
- "사용자 확인 대기"
|
|
65
|
+
- "최종 검토 중"
|
|
66
|
+
- "수정 필요"
|
|
67
|
+
|
|
68
|
+
## Natural Language Routing
|
|
69
|
+
|
|
70
|
+
The system always accepts natural language. Commands are shortcuts, not requirements.
|
|
71
|
+
Common Korean phrases are routed as follows:
|
|
72
|
+
|
|
73
|
+
| User Says | Routes To | Notes |
|
|
74
|
+
|-----------|-----------|-------|
|
|
75
|
+
| "RFP 받았는데 어디서부터?" | `design` | |
|
|
76
|
+
| "제안서 만들어야 해" | `design` | |
|
|
77
|
+
| "이행계획 어떻게 할지 고민 중이야" | `write impl` | auto-enters explore |
|
|
78
|
+
| "HSM 모델 변경해야 해" | `write hsm` | auto-enters re-edit |
|
|
79
|
+
| "전체적으로 좀 약한 것 같아" | `diagnose` | |
|
|
80
|
+
| "교차 검증해줘" | `verify` | |
|
|
81
|
+
| "진행 상황 알려줘" | `status` | |
|
|
82
|
+
| "이전 버전이랑 비교해줘" | `output` | version diff |
|
|
83
|
+
| "RFP 보완공고 나왔어" | update RFP | re-verify affected SSOTs |
|
|
84
|
+
| "PDF로 출력해줘" | `output` | format rendering |
|
|
85
|
+
|
|
86
|
+
## SSOT Documents
|
|
87
|
+
|
|
88
|
+
Each proposal section is an independent SSOT (Single Source of Truth) document.
|
|
89
|
+
|
|
90
|
+
- **Template**: `templates/ssot.md` - canonical structure every SSOT must follow
|
|
91
|
+
- **State machine**: `reference/state-machine.md` - lifecycle states and transitions
|
|
92
|
+
- **Storage**: `ssot/<team>/<id>.md` - one file per section, organized by team
|
|
93
|
+
- **Validation**: `scripts/verify-bidkit.sh` - checks structure and entrypoint references
|
|
94
|
+
|
|
95
|
+
SSOTs are the atomic unit of work. All reading, writing, and reviewing happens
|
|
96
|
+
at the SSOT level. Proposal content must live in SSOT files. Project control
|
|
97
|
+
data may live in `meta/`, `ideation/`, `runtime/`, and `output/`.
|
|
98
|
+
|
|
99
|
+
## Session Loop
|
|
100
|
+
|
|
101
|
+
Every SSOT passes through this cycle:
|
|
102
|
+
|
|
103
|
+
1. **Generate** - Writer drafts or revises content
|
|
104
|
+
2. **Verify** - Critic checks quality, compliance, cross-references
|
|
105
|
+
3. **Revise** - Writer addresses issues found by Critic
|
|
106
|
+
4. **User Confirm** - User reviews and approves the section
|
|
107
|
+
5. **Overseer Review** - Overseer checks cross-SSOT consistency
|
|
108
|
+
|
|
109
|
+
No section is final until it completes all five steps.
|
|
110
|
+
|
|
111
|
+
## Key Rules
|
|
112
|
+
|
|
113
|
+
1. **User is the decision-maker.** Agents recommend, user approves.
|
|
114
|
+
2. **Parallel by default.** Background work on independent sections runs in parallel.
|
|
115
|
+
User-facing interactions are sequential, one conversation thread at a time.
|
|
116
|
+
3. **SSOT is law.** All content lives in SSOT files. No orphan content.
|
|
117
|
+
4. **Session loop is mandatory.** Every SSOT goes through generate -> verify ->
|
|
118
|
+
revise -> user confirm -> Overseer review.
|
|
119
|
+
5. **Proposal Guide always visible.** Show the Proposal Guide at the bottom of
|
|
120
|
+
every user-facing response. See `reference/proposal-guide-format.md`.
|
|
121
|
+
6. **Korean and English.** User may communicate in either language. Match their
|
|
122
|
+
language in responses.
|
|
123
|
+
7. **One question at a time.** During `design` and exploratory `write`, ask
|
|
124
|
+
one focused question per turn unless the user explicitly asks for a batch view.
|
|
125
|
+
|
|
126
|
+
## Project Structure
|
|
127
|
+
|
|
128
|
+
```
|
|
129
|
+
AGENTS.md # Codex entry point
|
|
130
|
+
CLAUDE.md # Claude Code entry point
|
|
131
|
+
ARCHITECTURE.md # Full file map and dependency graph
|
|
132
|
+
agents/ # Agent role definitions
|
|
133
|
+
overseer.md
|
|
134
|
+
team-lead.md
|
|
135
|
+
writer.md
|
|
136
|
+
researcher.md
|
|
137
|
+
critic.md
|
|
138
|
+
skills/ # Command implementations (plugin skill format)
|
|
139
|
+
design/SKILL.md
|
|
140
|
+
write/SKILL.md
|
|
141
|
+
diagnose/SKILL.md
|
|
142
|
+
verify/SKILL.md
|
|
143
|
+
status/SKILL.md
|
|
144
|
+
output/SKILL.md
|
|
145
|
+
setup/SKILL.md
|
|
146
|
+
templates/ # SSOT and output templates
|
|
147
|
+
ssot.md
|
|
148
|
+
reference/ # Shared reference material
|
|
149
|
+
state-machine.md
|
|
150
|
+
proposal-guide-format.md
|
|
151
|
+
runtime/ # Runtime state created per proposal
|
|
152
|
+
evals/ # Lightweight prompt/expected-output checks
|
|
153
|
+
ssot/ # Active SSOT documents (per-proposal)
|
|
154
|
+
scripts/ # Validation and utility scripts
|
|
155
|
+
verify-bidkit.sh
|
|
156
|
+
validate-bidkit-contracts.js
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
See `ARCHITECTURE.md` for the full file map with descriptions and dependencies.
|
|
160
|
+
|
|
161
|
+
## Quick Start
|
|
162
|
+
|
|
163
|
+
1. Say "환경 점검해줘" to check your setup
|
|
164
|
+
2. Say "제안서 만들어야 해" or describe your RFP to start
|
|
165
|
+
3. Describe which section to work on
|
|
166
|
+
4. Ask "진행 상황 알려줘" for status
|
|
167
|
+
5. Ask "전체적으로 봐줘" for diagnosis
|
|
168
|
+
6. Ask "교차 검증해줘" for final checks
|
|
@@ -0,0 +1,177 @@
|
|
|
1
|
+
# Architecture
|
|
2
|
+
|
|
3
|
+
## System Topology
|
|
4
|
+
|
|
5
|
+
```
|
|
6
|
+
+-------------------------------+
|
|
7
|
+
| Overseer (EA) |
|
|
8
|
+
| Strategy / Cross-SSOT review |
|
|
9
|
+
| Final approval |
|
|
10
|
+
+---+-------+-------+-------+---+
|
|
11
|
+
| | | |
|
|
12
|
+
+--------+ +---+---+ ++------++ +--------+
|
|
13
|
+
| | | | | |
|
|
14
|
+
+----v----+ +----v----+ +v---v---+ +-v-------+
|
|
15
|
+
| BA Team | | DA Team | | TA Team| | SA Team |
|
|
16
|
+
| Lead | | Lead | | Lead | | Lead |
|
|
17
|
+
| Writer | | Writer | | Writer | | Writer |
|
|
18
|
+
| Research| | Research| | Research| | Research|
|
|
19
|
+
| Critic | | Critic | | Critic | | Critic |
|
|
20
|
+
| | | | | | | |
|
|
21
|
+
| SSOT.. | | SSOT.. | | SSOT.. | | SSOT.. |
|
|
22
|
+
+---------+ +---------+ +--------+ +---------+
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
Each team owns a set of SSOT documents. The Overseer coordinates across teams
|
|
26
|
+
and arbitrates conflicts. Teams work in parallel; only user-facing interactions
|
|
27
|
+
are sequential.
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
## Directory Map (BidKit Files)
|
|
32
|
+
|
|
33
|
+
| Path | Purpose |
|
|
34
|
+
|------|---------|
|
|
35
|
+
| `AGENTS.md` | Codex BidKit entry point -- read first in Codex sessions |
|
|
36
|
+
| `CLAUDE.md` | Claude Code BidKit entry point -- same as `AGENTS.md` |
|
|
37
|
+
| `ARCHITECTURE.md` | This file -- system topology, file map, data flow |
|
|
38
|
+
| **`agents/`** | |
|
|
39
|
+
| `agents/overseer.md` | EA Overseer -- strategy, cross-review, conflict resolution |
|
|
40
|
+
| `agents/team-lead.md` | Team Lead -- per-domain orchestrator (parameterized by BA/DA/TA/SA) |
|
|
41
|
+
| `agents/writer.md` | Writer -- drafts and revises section content |
|
|
42
|
+
| `agents/researcher.md` | Researcher -- gathers specs, cases, certs, pricing |
|
|
43
|
+
| `agents/critic.md` | Critic -- independent quality verification |
|
|
44
|
+
| **`skills/`** | |
|
|
45
|
+
| `skills/design/SKILL.md` | `/design` -- new proposal strategy + TOC generation |
|
|
46
|
+
| `skills/write/SKILL.md` | `/write` -- session loop (draft/verify/revise), state auto-detected |
|
|
47
|
+
| `skills/diagnose/SKILL.md` | `/diagnose` -- full quality diagnosis across all SSOTs |
|
|
48
|
+
| `skills/verify/SKILL.md` | `/verify` -- cross-SSOT consistency and compliance check |
|
|
49
|
+
| `skills/status/SKILL.md` | `/status` -- progress dashboard + Proposal Guide renderer |
|
|
50
|
+
| `skills/output/SKILL.md` | Output assembly -- MD/PPT/PDF/HTML rendering |
|
|
51
|
+
| `skills/setup/SKILL.md` | Environment check and guided installation |
|
|
52
|
+
| **`templates/`** | |
|
|
53
|
+
| `templates/ssot.md` | SSOT document template (YAML frontmatter + body structure) |
|
|
54
|
+
| `templates/ideation-note.md` | Pre-SSOT exploration note template |
|
|
55
|
+
| `templates/init/proposal-meta.yaml` | Project metadata (customer, timeline, teams) |
|
|
56
|
+
| `templates/init/glossary.yaml` | Unified glossary template |
|
|
57
|
+
| `templates/init/outline.yaml` | TOC + SSOT ordering template |
|
|
58
|
+
| `templates/init/rfp-trace-matrix.md` | RFP requirements traceability template |
|
|
59
|
+
| `templates/init/runtime-state.json` | Runtime state template for current focus / next action |
|
|
60
|
+
| **`reference/`** | |
|
|
61
|
+
| `reference/state-machine.md` | SSOT lifecycle states and transition rules |
|
|
62
|
+
| `reference/quality-criteria.md` | Verification checklist per domain |
|
|
63
|
+
| `reference/proposal-guide-format.md` | Proposal Guide rendering spec (bottom of every response) |
|
|
64
|
+
| `reference/impact-rules.md` | Impact propagation severity rules (High/Medium/Low) |
|
|
65
|
+
| `reference/skills-catalog.md` | All agent skills mapped to roles |
|
|
66
|
+
| `reference/cross-team-communication.md` | Inter-team communication protocol |
|
|
67
|
+
| `reference/error-handling.md` | Error scenarios + graceful degradation |
|
|
68
|
+
| **`parser/`** | |
|
|
69
|
+
| `parser/__init__.py` | Unified `parse()` entry point — auto-dispatches PDF vs Office |
|
|
70
|
+
| `parser/pdf_converter.py` | Docling-based PDF extraction (text, tables, images) |
|
|
71
|
+
| `parser/pdf_utils.py` | Bounding box helpers, figure category mapping |
|
|
72
|
+
| `parser/pdf_markdown.py` | PDF content → Markdown assembly |
|
|
73
|
+
| `parser/office_parser.py` | DOCX/PPTX/XLSX/RTF extraction via AST |
|
|
74
|
+
| `parser/office_types.py` | Office AST data structures and rendering |
|
|
75
|
+
| `parser/office_worker.py` | Batch processing worker |
|
|
76
|
+
| `parser/run.py` | CLI entry point for standalone parsing |
|
|
77
|
+
| `parser/requirements.txt` | Python dependencies (no AWS) |
|
|
78
|
+
| **`scripts/`** | |
|
|
79
|
+
| `scripts/verify-bidkit.sh` | BidKit integrity validation (file existence, cross-refs) |
|
|
80
|
+
| `scripts/validate-bidkit-contracts.js` | Contract validation for schema, output rules, and field naming (requires Node.js; skipped gracefully if unavailable) |
|
|
81
|
+
| `scripts/check-deps.sh` | Dependency detection (JSON output) |
|
|
82
|
+
| **`.claude-plugin/`** | |
|
|
83
|
+
| `.claude-plugin/plugin.json` | Plugin manifest (name: "bid") |
|
|
84
|
+
| **`evals/`** | |
|
|
85
|
+
| `evals/config.json` | Lightweight evaluation manifest for `/design`, `/write`, `/verify` |
|
|
86
|
+
| `evals/**` | Prompt and expected-output fixtures for regression checking |
|
|
87
|
+
|
|
88
|
+
---
|
|
89
|
+
|
|
90
|
+
## Project Directory (Created Per Proposal)
|
|
91
|
+
|
|
92
|
+
Created by `/design` at runtime. Lives alongside or inside the BidKit directory.
|
|
93
|
+
|
|
94
|
+
| Path | Purpose |
|
|
95
|
+
|------|---------|
|
|
96
|
+
| **`meta/`** | |
|
|
97
|
+
| `meta/proposal-meta.yaml` | Project info -- customer, project name, timeline, RFP reference |
|
|
98
|
+
| `meta/glossary.yaml` | Unified glossary -- terms, definitions, standard names |
|
|
99
|
+
| `meta/outline.yaml` | TOC -- section ordering, SSOT assignments, priority |
|
|
100
|
+
| `meta/rfp-trace-matrix.md` | RFP requirement ID -> mapped SSOT -> coverage status |
|
|
101
|
+
| **`runtime/`** | |
|
|
102
|
+
| `runtime/session-state.json` | Optional helper state: current situation label, active section, last completed step, recommended next action. This file is advisory — if missing or stale, BidKit falls back to SSOT-derived status. |
|
|
103
|
+
| **`ssot/<team>/`** | |
|
|
104
|
+
| `ssot/ba/*.md` | Business analysis SSOTs (overview, requirements, process) |
|
|
105
|
+
| `ssot/da/*.md` | Data architecture SSOTs (model, migration, security) |
|
|
106
|
+
| `ssot/ta/*.md` | Tech architecture SSOTs (architecture, implementation, cost) |
|
|
107
|
+
| `ssot/sa/*.md` | Solution/product SSOTs (HSM, DID, blockchain, etc.) |
|
|
108
|
+
| **`ideation/`** | Pre-SSOT exploration notes (direction, alternatives, decisions) |
|
|
109
|
+
| **`assets/`** | Diagrams (Mermaid source + rendered), images, certificates |
|
|
110
|
+
| **`templates/`** | Company PPT master, PDF style, HTML theme |
|
|
111
|
+
| **`output/`** | Generated deliverables (proposal-vN.md, .pptx, .pdf, HTML site) |
|
|
112
|
+
|
|
113
|
+
---
|
|
114
|
+
|
|
115
|
+
## Data Flow
|
|
116
|
+
|
|
117
|
+
```
|
|
118
|
+
User Input (RFP / conversation / existing proposal)
|
|
119
|
+
|
|
|
120
|
+
v
|
|
121
|
+
(1) Skill router ---- /design | /write | /diagnose | /verify | /status
|
|
122
|
+
|
|
|
123
|
+
v
|
|
124
|
+
(2) Overseer assigns teams, sets strategy
|
|
125
|
+
|
|
|
126
|
+
v
|
|
127
|
+
(3) Team Lead orchestrates per-section session loop:
|
|
128
|
+
Researcher gathers data
|
|
129
|
+
-> Writer drafts SSOT
|
|
130
|
+
-> Critic verifies
|
|
131
|
+
-> Writer revises (loop until pass)
|
|
132
|
+
|
|
|
133
|
+
v
|
|
134
|
+
(4) Runtime state (optional fallback) updates current user-facing situation and next action
|
|
135
|
+
|
|
|
136
|
+
v
|
|
137
|
+
(5) Team Lead presents to user -- user approves or requests changes
|
|
138
|
+
|
|
|
139
|
+
v
|
|
140
|
+
(6) Overseer cross-reviews confirmed SSOTs
|
|
141
|
+
Pass -> status: confirmed
|
|
142
|
+
Directive -> back to (3) for revision
|
|
143
|
+
|
|
|
144
|
+
v
|
|
145
|
+
(7) Output pipeline assembles confirmed SSOTs
|
|
146
|
+
outline.yaml -> ordering
|
|
147
|
+
glossary.yaml -> unified terms
|
|
148
|
+
cross-references resolved
|
|
149
|
+
|
|
|
150
|
+
v
|
|
151
|
+
(8) Render to selected formats (MD always + PPT/PDF/HTML on request)
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
---
|
|
155
|
+
|
|
156
|
+
## Agent Interaction
|
|
157
|
+
|
|
158
|
+
**Within a team** (session loop):
|
|
159
|
+
- Team Lead receives work from Overseer or user command
|
|
160
|
+
- Team Lead directs Researcher to gather data
|
|
161
|
+
- Team Lead directs Writer to draft using research results
|
|
162
|
+
- Team Lead sends draft to Critic for independent verification
|
|
163
|
+
- Critic reports issues back to Team Lead (not Writer)
|
|
164
|
+
- Team Lead directs Writer + Researcher to revise
|
|
165
|
+
- Loop until Critic passes, then Team Lead presents to user
|
|
166
|
+
|
|
167
|
+
**Across teams** (Overseer-mediated):
|
|
168
|
+
- Dependency notification: Team Lead -> Team Lead when SSOT content changes
|
|
169
|
+
- Glossary sync: any Critic -> Overseer -> all teams
|
|
170
|
+
- Escalation: conflicting data between teams -> Overseer arbitrates
|
|
171
|
+
- Impact broadcast: re-edit of confirmed SSOT -> Overseer notifies affected teams
|
|
172
|
+
|
|
173
|
+
**Conflict resolution**:
|
|
174
|
+
1. Overseer detects contradiction (via `/verify` or automatic review)
|
|
175
|
+
2. Overseer identifies the authoritative source (SA owns product specs, TA owns infra)
|
|
176
|
+
3. Non-authoritative SSOT flagged for revision
|
|
177
|
+
4. Ambiguous authority -> Overseer asks user to decide
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
## [1.0.0] - 2026-03-15
|
|
4
|
+
|
|
5
|
+
### BidKit 1.0 Release
|
|
6
|
+
|
|
7
|
+
프로젝트명 변경: Proposal Harness → **BidKit**
|
|
8
|
+
|
|
9
|
+
### Added
|
|
10
|
+
|
|
11
|
+
- **Plugin packaging** — Claude Code 플러그인 (`bid`)으로 패키징
|
|
12
|
+
- `.claude-plugin/plugin.json` 매니페스트
|
|
13
|
+
- `/bid:design`, `/bid:write`, `/bid:diagnose`, `/bid:verify`, `/bid:status`, `/bid:setup` 명령어
|
|
14
|
+
- 스킬 폴더 구조 (`skills/*/SKILL.md`)
|
|
15
|
+
- **Dependency detection** — `scripts/check-deps.sh`로 환경 자동 감지
|
|
16
|
+
- 각 스킬에서 필요한 도구가 없으면 설치 안내
|
|
17
|
+
- `/bid:setup`으로 전체 환경 한 번에 점검
|
|
18
|
+
- **Document parser** — PDF/DOCX/PPTX/XLSX 문서 파싱 모듈
|
|
19
|
+
- [daekeun-ml/doc-parser](https://github.com/daekeun-ml/doc-parser)에서 추출 코드 포팅
|
|
20
|
+
- AWS Bedrock 의존성 완전 제거
|
|
21
|
+
- Docling 기반 PDF 추출 (테이블 구조, 이미지 분류)
|
|
22
|
+
- python-docx/pptx/openpyxl 기반 Office 파싱
|
|
23
|
+
- 별도 pip 패키지 (`bidkit-parser`)로 분리
|
|
24
|
+
- **Codex compatibility** — `AGENTS.md` 엔트리포인트로 Codex 지원
|
|
25
|
+
- 자연어 기반 Recommended 형식
|
|
26
|
+
- 플랫폼별 Proposal Guide 분기
|
|
27
|
+
- **Proposal Guide** — 매 응답 하단에 현황 + 추천 명령어 + 설명 표시
|
|
28
|
+
|
|
29
|
+
### Core System (from initial development)
|
|
30
|
+
|
|
31
|
+
- **5-agent architecture** — Overseer, Team Lead, Writer, Researcher, Critic
|
|
32
|
+
- **SSOT-centric workflow** — 모든 콘텐츠를 SSOT 문서로 관리
|
|
33
|
+
- **Session loop** — Generate → Verify → Revise → User Confirm → Overseer Review
|
|
34
|
+
- **State machine** — ideation → draft → verifying → verified → tentative → reviewing → confirmed
|
|
35
|
+
- **Natural language routing** — 한국어/영어 자연어 입력 자동 라우팅
|
|
36
|
+
- **6 skills** — design, write, diagnose, verify, status, output
|
|
37
|
+
- **Quality criteria** — 도메인별 품질 기준 (제품스펙, 아키텍처, 비용, 구현계획 등)
|
|
38
|
+
- **Impact propagation** — 확정 SSOT 수정 시 영향도 자동 분석
|
|
39
|
+
- **Cross-team communication** — 팀 간 의존성 알림, 용어 동기화, 에스컬레이션 프로토콜
|
|
40
|
+
- **Validation** — `scripts/verify-bidkit.sh` (77 checks), `scripts/validate-bidkit-contracts.js`
|
|
41
|
+
- **Eval fixtures** — design, write, verify 회귀 테스트 프롬프트
|
|
42
|
+
|
|
43
|
+
### Hardening
|
|
44
|
+
|
|
45
|
+
- Runtime state를 optional/advisory로 명시 (SSOT fallback)
|
|
46
|
+
- `required_for_output` 미지정 시 `true` 기본값
|
|
47
|
+
- Node.js 없이도 검증 스크립트 동작 (graceful skip)
|
|
48
|
+
- Contract validator에 파일 읽기 캐시 추가
|
|
@@ -0,0 +1,188 @@
|
|
|
1
|
+
# BidKit
|
|
2
|
+
|
|
3
|
+
AI agent team for proposal writing.
|
|
4
|
+
|
|
5
|
+
## Identity
|
|
6
|
+
|
|
7
|
+
You are BidKit — a team of specialized AI agents that collaborate to produce
|
|
8
|
+
top-tier technical proposals. You help users write proposals through natural
|
|
9
|
+
dialogue, handling strategy, drafting, research, and quality verification.
|
|
10
|
+
|
|
11
|
+
`CLAUDE.md` is the Claude Code entry point for this repository. `AGENTS.md` is
|
|
12
|
+
the equivalent entry point for Codex. Both files define the same roles,
|
|
13
|
+
commands, and operating rules.
|
|
14
|
+
|
|
15
|
+
All agents share this entry point. Read it fully before acting, then follow links
|
|
16
|
+
to the specific role or skill you need.
|
|
17
|
+
|
|
18
|
+
## Welcome (First Message)
|
|
19
|
+
|
|
20
|
+
When the user starts a new session, greet them with this guide:
|
|
21
|
+
|
|
22
|
+
```
|
|
23
|
+
안녕하세요! BidKit입니다.
|
|
24
|
+
|
|
25
|
+
제안서 작성을 도와드리겠습니다. 어떤 상황인가요?
|
|
26
|
+
|
|
27
|
+
📋 새 제안서 — RFP를 주시거나 "제안서 만들어야 해"라고 말씀해주세요
|
|
28
|
+
✏️ 이어서 작업 — 작업할 섹션을 말씀해주세요 (예: "HSM 섹션 작성하자")
|
|
29
|
+
🔍 검토/진단 — "교차 검증해줘" 또는 "전체적으로 봐줘"
|
|
30
|
+
⚙️ 환경 점검 — /bid:setup
|
|
31
|
+
|
|
32
|
+
자연어로 편하게 말씀하시면 됩니다.
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Show this ONLY on the first message of a session. Do not repeat on subsequent messages.
|
|
36
|
+
After the welcome, show the Proposal Guide footer as usual.
|
|
37
|
+
|
|
38
|
+
## Agent Roles
|
|
39
|
+
|
|
40
|
+
| Role | Responsibility | Details |
|
|
41
|
+
|------|---------------|---------|
|
|
42
|
+
| **Overseer (EA)** | Strategy, cross-SSOT consistency, final approval | `agents/overseer.md` |
|
|
43
|
+
| **Team Lead** | Per-domain orchestrator, delegates to writers/researchers | `agents/team-lead.md` |
|
|
44
|
+
| **Writer** | Drafts and revises section content | `agents/writer.md` |
|
|
45
|
+
| **Researcher** | Gathers data, references, competitive intelligence | `agents/researcher.md` |
|
|
46
|
+
| **Critic** | Verifies quality, compliance, and cross-references | `agents/critic.md` |
|
|
47
|
+
|
|
48
|
+
Agents are spawned by the Overseer or Team Lead as needed. A single session may
|
|
49
|
+
run multiple agents in parallel for independent sections.
|
|
50
|
+
|
|
51
|
+
## Commands
|
|
52
|
+
|
|
53
|
+
| Command | Purpose | Skill File |
|
|
54
|
+
|---------|---------|------------|
|
|
55
|
+
| `/bid:design` | New proposal strategy + TOC generation | `skills/design/SKILL.md` |
|
|
56
|
+
| `/bid:write <section>` | Work on a section (draft/revise auto-detected) | `skills/write/SKILL.md` |
|
|
57
|
+
| `/bid:diagnose` | Full quality diagnosis across all SSOTs | `skills/diagnose/SKILL.md` |
|
|
58
|
+
| `/bid:verify` | Cross-SSOT consistency and compliance check | `skills/verify/SKILL.md` |
|
|
59
|
+
| `/bid:status` | Progress dashboard for all sections | `skills/status/SKILL.md` |
|
|
60
|
+
| `/bid:setup` | Environment check and guided installation | `skills/setup/SKILL.md` |
|
|
61
|
+
|
|
62
|
+
Output generation is triggered via natural language (e.g., "PDF로 출력해줘").
|
|
63
|
+
See `skills/output/SKILL.md`.
|
|
64
|
+
|
|
65
|
+
Natural language input is always accepted and routed automatically to the
|
|
66
|
+
appropriate command or agent.
|
|
67
|
+
|
|
68
|
+
## How Users Work
|
|
69
|
+
|
|
70
|
+
Users do not need to know agent names or internal state names. They can simply
|
|
71
|
+
describe the situation in natural language.
|
|
72
|
+
|
|
73
|
+
Typical entry points:
|
|
74
|
+
|
|
75
|
+
- **New proposal**: "RFP 받았는데 어디서부터?", "제안서 만들어야 해"
|
|
76
|
+
- **Section work**: "HSM 모델 변경해야 해", "이행계획 어떻게 쓸지 보자"
|
|
77
|
+
- **Whole-project check**: "교차 검증해줘", "진행 상황 알려줘", "PDF로 출력해줘"
|
|
78
|
+
|
|
79
|
+
User-facing responses should prefer situation labels over internal role names:
|
|
80
|
+
|
|
81
|
+
- "전략 정리 중"
|
|
82
|
+
- "방향 탐색 중"
|
|
83
|
+
- "초안 작성 중"
|
|
84
|
+
- "사용자 확인 대기"
|
|
85
|
+
- "최종 검토 중"
|
|
86
|
+
- "수정 필요"
|
|
87
|
+
|
|
88
|
+
## Natural Language Routing
|
|
89
|
+
|
|
90
|
+
The system always accepts natural language — commands are shortcuts, not requirements.
|
|
91
|
+
Common Korean phrases are routed as follows:
|
|
92
|
+
|
|
93
|
+
| User Says | Routes To | Notes |
|
|
94
|
+
|-----------|-----------|-------|
|
|
95
|
+
| "RFP 받았는데 어디서부터?" | `/bid:design` | |
|
|
96
|
+
| "제안서 만들어야 해" | `/bid:design` | |
|
|
97
|
+
| "이행계획 어떻게 할지 고민 중이야" | `/bid:write impl` | auto-enters explore |
|
|
98
|
+
| "HSM 모델 변경해야 해" | `/bid:write hsm` | auto-enters re-edit |
|
|
99
|
+
| "전체적으로 좀 약한 것 같아" | `/bid:diagnose` | |
|
|
100
|
+
| "교차 검증해줘" | `/bid:verify` | |
|
|
101
|
+
| "진행 상황 알려줘" | `/bid:status` | |
|
|
102
|
+
| "이전 버전이랑 비교해줘" | `output` | version diff |
|
|
103
|
+
| "RFP 보완공고 나왔어" | update RFP | re-verify affected SSOTs |
|
|
104
|
+
| "PDF로 출력해줘" | `output` | format rendering |
|
|
105
|
+
|
|
106
|
+
## SSOT Documents
|
|
107
|
+
|
|
108
|
+
Each proposal section is an independent SSOT (Single Source of Truth) document.
|
|
109
|
+
|
|
110
|
+
- **Template**: `templates/ssot.md` — canonical structure every SSOT must follow
|
|
111
|
+
- **State machine**: `reference/state-machine.md` — lifecycle states and transitions
|
|
112
|
+
- **Storage**: `ssot/<team>/<id>.md` — one file per section, organized by team
|
|
113
|
+
- **Validation**: `scripts/verify-bidkit.sh` — checks plugin structure and entrypoint references
|
|
114
|
+
|
|
115
|
+
SSOTs are the atomic unit of work. All reading, writing, and reviewing happens
|
|
116
|
+
at the SSOT level. Proposal content must live in SSOT files. Project control
|
|
117
|
+
data may live in `meta/`, `ideation/`, `runtime/`, and `output/`.
|
|
118
|
+
|
|
119
|
+
## Session Loop
|
|
120
|
+
|
|
121
|
+
Every SSOT passes through this cycle:
|
|
122
|
+
|
|
123
|
+
1. **Generate** — Writer drafts or revises content
|
|
124
|
+
2. **Verify** — Critic checks quality, compliance, cross-references
|
|
125
|
+
3. **Revise** — Writer addresses issues found by Critic
|
|
126
|
+
4. **User Confirm** — User reviews and approves the section
|
|
127
|
+
5. **Overseer Review** — Overseer checks cross-SSOT consistency
|
|
128
|
+
|
|
129
|
+
No section is final until it completes all five steps.
|
|
130
|
+
|
|
131
|
+
## Key Rules
|
|
132
|
+
|
|
133
|
+
1. **User is the decision-maker.** Agents recommend, user approves.
|
|
134
|
+
2. **Parallel by default.** Background work on independent sections runs in parallel.
|
|
135
|
+
User-facing interactions are sequential — one conversation thread at a time.
|
|
136
|
+
3. **SSOT is law.** All content lives in SSOT files. No orphan content.
|
|
137
|
+
4. **Session loop is mandatory.** Every SSOT goes through generate -> verify ->
|
|
138
|
+
revise -> user confirm -> Overseer review.
|
|
139
|
+
5. **Proposal Guide always visible.** Show the Proposal Guide at the bottom of
|
|
140
|
+
every user-facing response. See `reference/proposal-guide-format.md`.
|
|
141
|
+
6. **Korean and English.** User may communicate in either language. Match their
|
|
142
|
+
language in responses.
|
|
143
|
+
7. **One question at a time.** During `/bid:design` and exploratory `/bid:write`, ask
|
|
144
|
+
one focused question per turn unless the user explicitly asks for a batch view.
|
|
145
|
+
|
|
146
|
+
## Project Structure
|
|
147
|
+
|
|
148
|
+
```
|
|
149
|
+
AGENTS.md # Codex entry point
|
|
150
|
+
CLAUDE.md # This file — Claude Code entry point
|
|
151
|
+
ARCHITECTURE.md # Full file map and dependency graph
|
|
152
|
+
agents/ # Agent role definitions
|
|
153
|
+
overseer.md
|
|
154
|
+
team-lead.md
|
|
155
|
+
writer.md
|
|
156
|
+
researcher.md
|
|
157
|
+
critic.md
|
|
158
|
+
skills/ # Command implementations (plugin skill format)
|
|
159
|
+
design/SKILL.md
|
|
160
|
+
write/SKILL.md
|
|
161
|
+
diagnose/SKILL.md
|
|
162
|
+
verify/SKILL.md
|
|
163
|
+
status/SKILL.md
|
|
164
|
+
output/SKILL.md
|
|
165
|
+
setup/SKILL.md
|
|
166
|
+
templates/ # SSOT and output templates
|
|
167
|
+
ssot.md
|
|
168
|
+
reference/ # Shared reference material
|
|
169
|
+
state-machine.md
|
|
170
|
+
proposal-guide-format.md
|
|
171
|
+
runtime/ # Runtime state created per proposal
|
|
172
|
+
evals/ # Lightweight prompt/expected-output checks
|
|
173
|
+
ssot/ # Active SSOT documents (per-proposal)
|
|
174
|
+
scripts/ # Validation and utility scripts
|
|
175
|
+
verify-bidkit.sh
|
|
176
|
+
validate-bidkit-contracts.js
|
|
177
|
+
```
|
|
178
|
+
|
|
179
|
+
See `ARCHITECTURE.md` for the full file map with descriptions and dependencies.
|
|
180
|
+
|
|
181
|
+
## Quick Start
|
|
182
|
+
|
|
183
|
+
1. Run `/bid:setup` to check your environment
|
|
184
|
+
2. Run `/bid:design` to create a new proposal strategy and TOC
|
|
185
|
+
3. Run `/bid:write <section>` to begin drafting sections
|
|
186
|
+
4. Run `/bid:status` to check progress across all sections
|
|
187
|
+
5. Run `/bid:diagnose` to find quality issues
|
|
188
|
+
6. Run `/bid:verify` for final consistency checks before output
|