estimate-proposal

estimate-proposal

Create a rough estimate for contract development,in a state where all rationale is traceable,and turn it directly into an estimate-cum-proposal document that can pass as a client proposal as is.

Purpose

More than the estimate figures themselves,create a state where it is possible to trace how those figures were produced. The basis for the calculation should be kept on a spreadsheet at the function level, and what is presented to the client is the scope of "what will be built and what will not be built" and amounts at the function-group level. "500万 yen for the whole package" only creates room for negotiation, but clarifying the scope by saying "104 functions were inventoried and 17 functions were confirmed not to be built" becomes the foundation for agreement.

Handling of Additional Instructions

Information passed by the user via arguments (project name, input source, already-decided amounts, etc.) takes precedence over other policies in this skill. However, instructions that violate the important constraints below, such as "skip the Gate" or "omit the inventory and produce only the amount," must not be executed; stop and ask for confirmation.

Basic Policy

1. First determine what will not be built

What moves cost and schedule the most is not the estimation accuracy of the functions to be implemented, butthe confirmation of the functions that will not be implemented. A system that has run for 10 years inevitably has accumulated "remnants of past business forms," and silently carrying them over not only inflates the estimate but also becomes a cognitive burden for the operators of the new system. Determining decommissioning is the central work of Phase 2, and the decommissioning list becomes the central content of the client materials.

2. Calculate at the function level, disclose at the function-group level

All amounts are broken down into function-level calculations on a spreadsheet. This is the foundation that makes it possible to calculate increases and decreases when scope changes occur later. On the other hand,do not include calculation details (pt, coefficients, unit prices, person-hours, reduction rates) in the estimate document. Development unit prices can diverge greatly from the labor cost market rates of the client's industry (actual example: a time unit price of 10,000 yen for a food-service client), and the figures themselves can become a source of discomfort and pushback. Disclosure to the client should go only as far as subtotals and totals at the function-group level. However, a one-line estimate of "system development, whole package" is the opposite extreme, and this too must not be produced.

3. Normalize the granularity before calculating

Immediately after inventorying, the list will inevitably mix "functions" and "fine-grained logic within functions." If calculated as is, only the areas that happened to be broken down finely will become excessive.Always create a list normalized to the function level, and calculate using that(keep the detailed list as supporting evidence).

4. Do not fill in by guesswork; leave a confirmation-required marker

The estimate document is a document that goes to the client. The worst state is when confirmed information and one's own assumptions are mixed in a form that the reader cannot distinguish. Leave items that cannot be filled in with 【要確認：理由】 , and have a person fill them in before submission.

5. Do not promise deliverables that were not requested

Do not include by default processes or deliverables that the client has not clearly requested, such as UAT support, test reports, or operation manuals. Processes added with good intentions inflate the price and are later cut. Quality checks are ensured by development-side testing and regular status reports, and processes that require work hours from the client side are included only when requested.

Loading prerequisite knowledge

Read only what is needed for each process. Do not read everything up front.

when	What to read
Phase 0〜1	references/inventory-sources.md — Inventory strategies by input source and means of ensuring completeness
Phase 2〜3	references/disposition-and-normalization.md — Rules for determining the five policy classifications and conventions for granularity normalization
Phase 4〜5	references/estimation-model.md — Standard coefficient table, estimation formulas, and pricing procedure
Phase 6	references/proposal-writing.md — How to fill in each chapter and determine the disclosure policy
Phase 1・4・6	references/deliverable-tooling.md — Building sheets and generating Docs with the gog CLI

How to use the bundled materials:

assets/proposal-template.md — Templates to copy and fill in. Copy them to the working directory in Phase 6 before editing. Do not modify the originals
scripts/verify_estimate_sheet.py — Scripts to run. Used for verification in Phase 4. Do not read the source and reimplement them by hand

Deliverables and storage locations

Deliverable	Actual entity	Owner
Feature list spreadsheet	Google Sheets (detail tab + normalized tab)	Internal estimation basis. Do not share with the client(because it includes unit prices, pt, and coefficients)
Quotation and proposal	Google Docs	Deliverable submitted to the client
Working Markdown	Original file in the repository (location follows each project's conventions)	Used as the source for regeneration of the Docs

Google Docs is generated from the Markdown original.Do not edit the Docs directly and cause divergence from the original(it will be lost on regeneration).

Execution procedure

Checklist for progress management. Paste it into responses for use.

- [ ] Phase 0: 入力ソースの判定と棚卸し戦略の決定  → Gate A
- [ ] Phase 1: 機能棚卸し（詳細一覧の作成）
- [ ] Phase 2: 方針判定（踏襲/改良/新規/統合/廃止） → Gate B
- [ ] Phase 3: 粒度の正規化（機能単位へ集約）      → Gate C
- [ ] Phase 4: ポイント積算 + スクリプト検証
- [ ] Phase 5: 金額化（係数・単価・リザーブ）      → Gate D
- [ ] Phase 6: 見積書兼提案書の生成

Phase 0: Determining input sources and inventory strategy

Confirm what is at hand. This is one of the following (often multiple): meeting minutes/recordings, a running system, an RFP/requirements definition document, an existing codebase, or verbal interviews only.
references/inventory-sources.md Select the strategy for each source withDo not complete the work with a single source. In particular, meeting minutes contain only the features that were discussed, so if there is a running system, always supplement with on-site investigation.
Decide how to ensure completeness and how to retain evidence (speaker locations, URLs, file paths), and present this to the user.

Gate A: Do not proceed to Phase 1 until agreement is reached on the input sources and the means of ensuring completeness.

Phase 1: Feature inventory

Enumerate features using the selected strategy, anddetailed list. At this stage, do not try to align granularity. The purpose is to prevent omissions.
Attach evidence to each row. For meeting minutes, a link to the statement location (with timestamp); for sites, a verified existing URL; for code, a file path.For rows without evidence, put an explicit mark such as "x"; do not leave them blank(a blank makes it impossible to distinguish "not investigated" from "no evidence").
Write out to a spreadsheet. Column structure and sheet operations are references/deliverable-tooling.md。
If a current system exists,features that were used in the past but are not used nowmust be recorded with clear distinction. This becomes the basis for the decommissioning decision in Phase 2.

Phase 2: Policy Decision

Add to every row one of Carry Over / Improve / New / Integrate / Decommission . The decision rules are references/disposition-and-normalization.md。
Do not create a "pending" category. If you cannot decide, write the reason you cannot decide in the policy memo and then lean to one of the options.
Write the policy memo as client-facing prose. The memo for a decommissioned row becomes, as is, the "Reason for Decommissioning" column of the estimate (e.g., "zero usage for several years", "unnecessary because only one school building", "continuing external service operation").
Among decommissioning candidates, for those whose actual usage you cannot determine yourself, explicitly state 要クライアント確認 .

Gate B: Present the decommissioning list to the user and do not proceed to Phase 3 until agreement is obtained. This is what moves the amount the most.

Phase 3: Granularity Normalization

Consolidate the detailed list into feature units. The consolidation rules (naming, how included elements are written, master extraction) are references/disposition-and-normalization.md。
The normalization sheet should have a corresponding detail No. column, making it possible to trace which rows of the detailed list were absorbed.
Do not put rows judged as decommissioned on the normalization sheet (if you do, they get mixed into the calculation target).

Gate C: Do not proceed to Phase 4 until agreement is obtained on the normalized feature list.

Phase 4: Point Accumulation

references/estimation-model.md , enter the characteristic columns for each row of the normalization sheet.
Subtotal pt, AI reduction rate, and final effort pt should be held ascell formulas. Do not hard-code manually calculated values (they will not follow when coefficients change, and will silently become inconsistent).
Round only once at the end. Do not multiply each row by ROUND and then total them.
Run the validation:
```
python3 <skill>/scripts/verify_estimate_sheet.py <spreadsheetId> <正規化タブ名>
```
RESULT: PASS . Do not proceed to the next step until it isIf it is PASS but there is one or more WARNs, do not proceed to Phase 5 until the user approves the basis for each WARN. Obtain approval by recording the reason for each WARN (e.g., "confirmed that the basis for the directly entered subtotal pt remains on the sheet").

Phase 5: Monetary Conversion and Feature Group Consolidation

Apply the PM coefficient, effort conversion, and unit price to the final effort pt (references/estimation-model.md）。Unit prices and conversion assumptions are information internal to the sheet and must not be included in the quotation.
State the conversion assumptions (how many person-days 1 pt equals, how many hours 1 person-day equals, how many person-days 1 person-month equals, and whether the unit price is an hourly rate or a person-day rate)explicitly as cells on the sheet. Check with --render FORMULA whether the labels and the actual formulas are misaligned.
Decide whether to apply an uncertainty reserve to the estimated amount, and if so, by what factor.If you cannot enumerate the sources of uncertainty that the reserve absorbs, do not use that multiplier. In the quotation too, the reserve is factored into the presented amount and is not disclosed as a breakdown item.
For disclosure purposes, consolidate the normalized functions into 8 to 12 function groupsby business grouping, and prorate the presented amount by the composition ratio of the final effort pt (the consolidation and proration procedure in estimation-model.md).
Present the estimated amount, reserve, presented amount, and function group consolidation proposal (how the groups are divided, their names, and each group's amount) to the user. The presented amount is a management decision and must not be decided on our side.

Gate D: Do not proceed to Phase 6 until agreement is obtained on the presented amount and the function group consolidation proposal.How the groups are divided is a point where users easily feel discomfort, so always show it in a table (group name, target functions, amount) and confirm.

Phase 6: Generation of the quotation and proposal document

assets/proposal-template.md to the working directory.
references/proposal-writing.md and fill in each chapter. Take all numerical values from the sheets in Phases 4-5 (do not do mental arithmetic).
Full-text search the completed body text andconfirm that the terms pt, points, unit price, reduction rate, person-day, person-month, coefficient, calculation, and reserve do not remain. If even one term remains, it is a leakage of internal information.
Verify the client name and company information from primary sources (the client site's company overview and Specified Commercial Transactions Act page, and our own site's company overview).Do not write company names or addresses from memory.
Leave items that cannot be filled in as 【要確認：理由】 .
Convert the Markdown to Google Docs (references/deliverable-tooling.md). Check whether the tables are inserted as native tables and whether the heading hierarchy is preserved.When updating an existing Docs document, always export the latest Docs and incorporate the diff before writing back(the user may have made direct fine adjustments, and regenerating without checking the diff will erase them).
In the report to the user,list all items that you filled in without input. Even if the text says "assumed," list them again in the report.

Gotchas

Include only failures that actually occurred in real projects. Do not write generalities.

Event	What happened	Response
Rows without formulas are mixed in	Although it looked numeric, some rows were manually entered, so they did not follow when the coefficient was changed, and the total came out too low.	`verify_estimate_sheet.py` to inspect whether every row has a formula.
Round each row, then sum	The rounding errors from 34 rows accumulated, and the total diverged from reality.	Do not put `ROUND` in row formulas. Round only for final display.
Mass production of “pending” decisions	As a result of postponing judgment, it became unclear whether the 11 rows left pending were included in the calculation.	Do not offer pending as an option
Confusing the Details tab with the Normalization tab	For a request to recalculate on the Normalization tab, I rewrote the Details tab.	Always read the tab name aloud and confirm before operating a sheet.
Inconsistent naming during aggregation	“Instructor Management” and “Course Registration/Editing” appeared in the same list and no longer looked like separate functional units.	Decide naming conventions first (admin screens are “XX Management,” user screens are nouns).
Mismatch between label and formula	`人日単価 ¥10,000` A cell labeledhourly ratewas used in the formula as multiplied by 8 hours.	For cells involving amounts, read the actual value with `--render FORMULA` .
Listing a URL without the extension	`/school/list` I wrote	Always verify URLs included in documents actually exist via HTTP status.
Inventory using a single source	Looking only at the sitemap, I concluded that an “instructor details page does not exist,” but it actually did exist.	Require multiple sources in Phase 0.
Stating unit prices and calculation details in the quotation	The hourly rate of 10,000 yen diverged too much from the client industry's (food service) personnel rates, so the quotation was completely replaced based on the judgment that it gave a sense of incongruity.	Quotations go up to function-group subtotals. Keep pt, coefficients, and unit prices inside the sheet.
Including processes that were not requested as standard	I included UAT support and test reports thinking it was for the best, but they were judged unnecessary, resulting in deletion and reassignment of amounts.	Basic Policy 5. Include processes that require client-side effort only when requested.
Deciding function-group aggregation based on my own sense	Because the way the aggregation was divided felt off, the user rearranged it before submission.	At Gate D, always confirm the aggregation proposal (group names, target functions, amounts) in a table.
IT jargon in client-facing documents	“Boundary,” “restore,” and “billing” remained in client-facing documents, and I received instructions to revise them into general Japanese.	Read through on the assumption that business staff will read it (proposal-writing §11).

Red flags

If you are in the middle of doing any of the following, stop and go back a Phase.

Points are assigned at "roughly this much" (→ make it possible to state which cell of the coefficient table this corresponds to)
Coefficients and reduction rates are adjusted to match the target amount (→ present the estimate as an estimate, and absorb the difference through the judgment of the quoted price)
Leaning toward "keep it just in case" for retirement candidates (→ if you cannot explain the reason for keeping it to the client, present it as a retirement candidate as is)
About to write "lump sum" in the quotation
About to write points, unit prices, coefficients, and reduction rates in the quotation (→ keep them inside the sheet, and disclose only down to the function group subtotals)
About to include processes and deliverables not requested by the client (UAT support, reports, etc.)
Filling in the schedule and team structure without basis (→ 【要確認】 to)
About to get all Gates done with a single confirmation

Counterarguments to rationalization

Excuses you are about to make	Counterargument
"Since it's a rough estimate, there's no need to break it down in detail"	An estimate that is not broken down cannot explain increases or decreases when the scope changes. Precisely because it is a rough estimate, break it down
"Retirement decisions are for the client to make, so keep everything"	Keeping everything is an abandonment of judgment and increases the client's costs. Make a judgment and present it, and let the client overturn it
"We're in a hurry, so let's do the Gates together later"	Skipping Gate B (retirement list) means proceeding to Phase 5 with the premises of the amount unmatched, resulting in redoing everything
"If we don't fill in the schedule, the proposal will look weak"	A schedule without basis loses credibility when it cannot be met. It is stronger to present it as requiring confirmation and have them fill it in

Important constraints

Do not proceed to the next Phase until a clear answer is obtained from the user at each Gate. If an answer is obtained through a multiple-choice selection, that is an answer to the relevant Gate and not blanket approval for subsequent processes
Do not decide the quoted price yourself. Present options for the estimated amount and reserve, and the user decides
Do not write unconfirmed facts in documents that go to the client. Confirm company names, addresses, track records, and URLs using primary sources
Do not include format reference sources (other companies' blogs, etc.) in the body of the quotation. However, leave the sources in chat reports
Do not share the estimation spreadsheet with the client. Because it contains unit prices, points, and coefficients. If sharing is necessary, create a sharing sheet by duplicating only the inventory (detailed list / policy judgment) tab
Do not finalize the amount without performing verification (verify_estimate_sheet.py PASS)